Filtered by vendor Apache
Subscriptions
Total
2499 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-41151 | 1 Apache | 1 Hertzbeat | 2025-06-24 | 8.8 High |
| Deserialization of Untrusted Data vulnerability in Apache HertzBeat. This vulnerability can only be exploited by authorized attackers. This issue affects Apache HertzBeat: before 1.6.1. Users are recommended to upgrade to version 1.6.1, which fixes the issue. | ||||
| CVE-2024-45505 | 1 Apache | 1 Hertzbeat | 2025-06-24 | 8.8 High |
| Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in Apache HertzBeat (incubating). This vulnerability can only be exploited by authorized attackers. This issue affects Apache HertzBeat (incubating): before 1.6.1. Users are recommended to upgrade to version 1.6.1, which fixes the issue. | ||||
| CVE-2024-45791 | 1 Apache | 1 Hertzbeat | 2025-06-24 | 7.5 High |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache HertzBeat. This issue affects Apache HertzBeat: before 1.6.1. Users are recommended to upgrade to version 1.6.1, which fixes the issue. | ||||
| CVE-2024-47208 | 1 Apache | 1 Ofbiz | 2025-06-24 | 9.8 Critical |
| Server-Side Request Forgery (SSRF), Improper Control of Generation of Code ('Code Injection') vulnerability in Apache OFBiz. This issue affects Apache OFBiz: before 18.12.17. Users are recommended to upgrade to version 18.12.17, which fixes the issue. | ||||
| CVE-2024-51504 | 1 Apache | 1 Zookeeper | 2025-06-24 | 9.1 Critical |
| When using IPAuthenticationProvider in ZooKeeper Admin Server there is a possibility of Authentication Bypass by Spoofing -- this only impacts IP based authentication implemented in ZooKeeper Admin Server. Default configuration of client's IP address detection in IPAuthenticationProvider, which uses HTTP request headers, is weak and allows an attacker to bypass authentication via spoofing client's IP address in request headers. Default configuration honors X-Forwarded-For HTTP header to read client's IP address. X-Forwarded-For request header is mainly used by proxy servers to identify the client and can be easily spoofed by an attacker pretending that the request comes from a different IP address. Admin Server commands, such as snapshot and restore arbitrarily can be executed on successful exploitation which could potentially lead to information leakage or service availability issues. Users are recommended to upgrade to version 3.9.3, which fixes this issue. | ||||
| CVE-2025-26413 | 1 Apache | 1 Kvrocks | 2025-06-23 | 7.5 High |
| Improper Input Validation vulnerability in Apache Kvrocks. The SETRANGE command didn't check if the `offset` input is a positive integer and use it as an index of a string. So it will cause the server to crash due to its index is out of range. This issue affects Apache Kvrocks: through 2.11.1. Users are recommended to upgrade to version 2.12.0, which fixes the issue. | ||||
| CVE-2025-27636 | 2 Apache, Redhat | 3 Camel, Apache Camel Spring Boot, Camel Quarkus | 2025-06-23 | 5.6 Medium |
| Bypass/Injection vulnerability in Apache Camel components under particular conditions. This issue affects Apache Camel: from 4.10.0 through <= 4.10.1, from 4.8.0 through <= 4.8.4, from 3.10.0 through <= 3.22.3. Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases. This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific headers that for some Camel components can alter the behaviours such as the camel-bean component, to call another method on the bean, than was coded in the application. In the camel-jms component, then a malicious header can be used to send the message to another queue (on the same broker) than was coded in the application. This could also be seen by using the camel-exec component The attacker would need to inject custom headers, such as HTTP protocols. So if you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include malicious HTTP headers in the HTTP requests that are send to the Camel application. All the known Camel HTTP component such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http would be vulnerable out of the box. In these conditions an attacker could be able to forge a Camel header name and make the bean component invoking other methods in the same bean. In terms of usage of the default header filter strategy the list of components using that is: * camel-activemq * camel-activemq6 * camel-amqp * camel-aws2-sqs * camel-azure-servicebus * camel-cxf-rest * camel-cxf-soap * camel-http * camel-jetty * camel-jms * camel-kafka * camel-knative * camel-mail * camel-nats * camel-netty-http * camel-platform-http * camel-rest * camel-sjms * camel-spring-rabbitmq * camel-stomp * camel-tahu * camel-undertow * camel-xmpp The vulnerability arises due to a bug in the default filtering mechanism that only blocks headers starting with "Camel", "camel", or "org.apache.camel.". Mitigation: You can easily work around this in your Camel applications by removing the headers in your Camel routes. There are many ways of doing this, also globally or per route. This means you could use the removeHeaders EIP, to filter out anything like "cAmel, cAMEL" etc, or in general everything not starting with "Camel", "camel" or "org.apache.camel.". | ||||
| CVE-2025-26865 | 1 Apache | 1 Ofbiz | 2025-06-23 | 3.5 Low |
| Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Apache OFBiz. This issue affects Apache OFBiz: from 18.12.17 before 18.12.18. It's a regression between 18.12.17 and 18.12.18. In case you use something like that, which is not recommended! For security, only official releases should be used. In other words, if you use 18.12.17 you are still safe. The version 18.12.17 is not a affected. But something between 18.12.17 and 18.12.18 is. In that case, users are recommended to upgrade to version 18.12.18, which fixes the issue. | ||||
| CVE-2024-29120 | 1 Apache | 1 Streampark | 2025-06-23 | 5.9 Medium |
| In Streampark (version < 2.1.4), when a user logged in successfully, the Backend service would return "Authorization" as the front-end authentication credential. User can use this credential to request other users' information, including the administrator's username, password, salt value, etc. Mitigation: all users should upgrade to 2.1.4 | ||||
| CVE-2025-27531 | 1 Apache | 1 Inlong | 2025-06-23 | 9.8 Critical |
| Deserialization of Untrusted Data vulnerability in Apache InLong. This issue affects Apache InLong: from 1.13.0 before 2.1.0, this issue would allow an authenticated attacker to read arbitrary files by double writing the param. Users are recommended to upgrade to version 2.1.0, which fixes the issue. | ||||
| CVE-2023-29055 | 1 Apache | 1 Kylin | 2025-06-20 | 7.5 High |
| In Apache Kylin version 2.0.0 to 4.0.3, there is a Server Config web interface that displays the content of file 'kylin.properties', that may contain serverside credentials. When the kylin service runs over HTTP (or other plain text protocol), it is possible for network sniffers to hijack the HTTP payload and get access to the content of kylin.properties and potentially the containing credentials. To avoid this threat, users are recommended to * Always turn on HTTPS so that network payload is encrypted. * Avoid putting credentials in kylin.properties, or at least not in plain text. * Use network firewalls to protect the serverside such that it is not accessible to external attackers. * Upgrade to version Apache Kylin 4.0.4, which filters out the sensitive content that goes to the Server Config web interface. | ||||
| CVE-2024-56128 | 2 Apache, Redhat | 2 Kafka, Amq Streams | 2025-06-20 | 5.3 Medium |
| Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation. Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation. Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue. How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted. Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802. Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below. Fixed Versions: 3.9.0 3.8.1 3.7.2 Users are advised to upgrade to 3.7.2 or later to mitigate this issue. Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by: - Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception. - Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security. | ||||
| CVE-2023-46226 | 1 Apache | 1 Iotdb | 2025-06-20 | 9.8 Critical |
| Remote Code Execution vulnerability in Apache IoTDB.This issue affects Apache IoTDB: from 1.0.0 through 1.2.2. Users are recommended to upgrade to version 1.3.0, which fixes the issue. | ||||
| CVE-2023-51441 | 1 Apache | 1 Axis | 2025-06-18 | 7.2 High |
| ** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF This issue affects Apache Axis: through 1.3. As Axis 1 has been EOL we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome. | ||||
| CVE-2023-49657 | 1 Apache | 1 Superset | 2025-06-17 | 9.6 Critical |
| A stored cross-site scripting (XSS) vulnerability exists in Apache Superset before 3.0.3. An authenticated attacker with create/update permissions on charts or dashboards could store a script or add a specific HTML snippet that would act as a stored XSS. For 2.X versions, users should change their config to include: TALISMAN_CONFIG = { "content_security_policy": { "base-uri": ["'self'"], "default-src": ["'self'"], "img-src": ["'self'", "blob:", "data:"], "worker-src": ["'self'", "blob:"], "connect-src": [ "'self'", " https://api.mapbox.com" https://api.mapbox.com" ;, " https://events.mapbox.com" https://events.mapbox.com" ;, ], "object-src": "'none'", "style-src": [ "'self'", "'unsafe-inline'", ], "script-src": ["'self'", "'strict-dynamic'"], }, "content_security_policy_nonce_in": ["script-src"], "force_https": False, "session_cookie_secure": False, } | ||||
| CVE-2024-31391 | 1 Apache | 1 Solr Operator | 2025-06-17 | 6.5 Medium |
| Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator. This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0. When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr. One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic. By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well. Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account. Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`. Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`. | ||||
| CVE-2024-24746 | 1 Apache | 1 Nimble | 2025-06-17 | 7.5 High |
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache NimBLE. Specially crafted GATT operation can cause infinite loop in GATT server leading to denial of service in Bluetooth stack or device. This issue affects Apache NimBLE: through 1.6.0. Users are recommended to upgrade to version 1.7.0, which fixes the issue. | ||||
| CVE-2025-47868 | 1 Apache | 1 Nuttx | 2025-06-17 | 9.8 Critical |
| Out-of-bounds Write resulting in possible Heap-based Buffer Overflow vulnerability was discovered in tools/bdf-converter font conversion utility that is part of Apache NuttX RTOS repository. This standalone program is optional and neither part of NuttX RTOS nor Applications runtime, but active bdf-converter users may be affected when this tool is exposed to external provided user data data (i.e. publicly available automation). This issue affects Apache NuttX: from 6.9 before 12.9.0. Users are recommended to upgrade to version 12.9.0, which fixes the issue. | ||||
| CVE-2025-47869 | 1 Apache | 1 Nuttx | 2025-06-17 | 9.8 Critical |
| Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability was discovered in Apache NuttX RTOS apps/exapmles/xmlrpc application. In this example application device stats structure that stored remotely provided parameters had hardcoded buffer size which could lead to buffer overflow. Structure members buffers were updated to valid size of CONFIG_XMLRPC_STRINGSIZE+1. This issue affects Apache NuttX RTOS users that may have used or base their code on example application as presented in releases from 6.22 before 12.9.0. Users of XMLRPC in Apache NuttX RTOS are advised to review their code for this pattern and update buffer sizes as presented in the version of the example in release 12.9.0. | ||||
| CVE-2024-26307 | 1 Apache | 1 Doris | 2025-06-17 | 5.3 Medium |
| Possible race condition vulnerability in Apache Doris. Some of code using `chmod()` method. This method run the risk of someone renaming the file out from under user and chmodding the wrong file. This could theoretically happen, but the impact would be minimal. This issue affects Apache Doris: before 1.2.8, before 2.0.4. Users are recommended to upgrade to version 2.0.4, which fixes the issue. | ||||