| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component.
The Camel-Keycloak KeycloakSecurityPolicy does not validate the iss (issuer) claim of JWT tokens against the configured realm. A token issued by one Keycloak realm is silently accepted by a policy configured for a completely different realm, breaking tenant isolation.
This issue affects Apache Camel: from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. |
| A vulnerability in Apache IoTDB.
This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7.
Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue. |
| The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
Solr deployments are subject to this vulnerability if they meet the following criteria:
* Solr is running in its "standalone" mode.
* Solr's "allowPath" setting is being used to restrict file access to certain directories.
* Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.
Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue. |
| Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability:
* Use of Solr's "RuleBasedAuthorizationPlugin"
* A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles"
* A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read".
* A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission
* A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway)
Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1. |
| Exposure of Private Personal Information to an Unauthorized Actor vulnerability in Apache Answer.
This issue affects Apache Answer: through 1.7.1.
An unauthenticated API endpoint incorrectly exposes full revision history for deleted content. This allows unauthorized user to retrieve restricted or sensitive information.
Users are recommended to upgrade to version 2.0.0, which fixes the issue. |
| Improper Neutralization of Data within XPath Expressions ('XPath Injection') vulnerability in Apache HertzBeat.
This issue affects Apache HertzBeat: from 1.7.1 before 1.8.0.
Users are recommended to upgrade to version 1.8.0, which fixes the issue. |
| Use After Free vulnerability in Apache Arrow C++.
This issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. It can be triggered when reading an Arrow IPC file (but not an IPC stream) with pre-buffering enabled, if the IPC file contains data with variadic buffers (such as Binary View and String View data). Depending on the number of variadic buffers in a record batch column and on the temporal sequence of multi-threaded IO, a write to a dangling pointer could occur. The value (a `std::shared_ptr<Buffer>` object) that is written to the dangling pointer is not under direct control of the attacker.
Pre-buffering is disabled by default but can be enabled using a specific C++ API call (`RecordBatchFileReader::PreBufferMetadata`). The functionality is not exposed in language bindings (Python, Ruby, C GLib), so these bindings are not vulnerable.
The most likely consequence of this issue would be random crashes or memory corruption when reading specific kinds of IPC files. If the application allows ingesting IPC files from untrusted sources, this could plausibly be exploited for denial of service. Inducing more targeted kinds of misbehavior (such as confidential data extraction from the running process) depends on memory allocation and multi-threaded IO temporal patterns that are unlikely to be easily controlled by an attacker.
Advice for users of Arrow C++:
1. check whether you enable pre-buffering on the IPC file reader (using `RecordBatchFileReader::PreBufferMetadata`)
2. if so, either disable pre-buffering (which may have adverse performance consequences), or switch to Arrow 23.0.1 which is not vulnerable |
| Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4].
[1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html
[2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html
[3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html
[4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/
Users are recommended to upgrade to version 3.2.0, which fixes this issue. |
| Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low.
Users are recommended to upgrade to Apache Airflow 3.2.0, which resolves this issue. |
| Header injection vulnerability in Apache APISIX.
The attacker can take advantage of certain configuration in forward-auth plugin to inject malicious headers.
This issue affects Apache APISIX: from 2.12.0 through 3.15.0.
Users are recommended to upgrade to version 3.16.0, which fixes the issue. |
| Cleartext Transmission of Sensitive Information vulnerability in Apache APISIX.
This can occur due to `ssl_verify` in openid-connect plugin configuration being set to false by default.
This issue affects Apache APISIX: from 0.7 through 3.15.0.
Users are recommended to upgrade to version 3.16.0, which fixes the issue. |
| When user logged out, the JWT token the user had authtenticated with was not invalidated, which could lead to reuse of that token in case it was intercepted. In Airflow 3.2 we implemented the mechanism that implements token invalidation at logout. Users who are concerned about the logout scenario and possibility of intercepting the tokens, should upgrade to Airflow 3.2+
Users are recommended to upgrade to version 3.2.0, which fixes this issue. |
| An Exposure of Sensitive Information to an Unauthorized Actor vulnerability exists in Apache DolphinScheduler.
This vulnerability may allow unauthorized actors to access sensitive information, including database credentials.
This issue affects Apache DolphinScheduler versions 3.1.*.
Users are recommended to upgrade to:
* version ≥ 3.2.0 if using 3.1.x
As a temporary workaround, users who cannot upgrade immediately may restrict the exposed management endpoints by setting the following environment variable:
```
MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=health,metrics,prometheus
```
Alternatively, add the following configuration to the application.yaml file:
```
management:
endpoints:
web:
exposure:
include: health,metrics,prometheus
```
This issue has been reported as CVE-2023-48796:
https://cveprocess.apache.org/cve5/CVE-2023-48796 |
| Improper Input Validation vulnerability in Apache IoTDB.
This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7.
Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue. |
| Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.
When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.
This issue affects Apache Tomcat Native: from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.
The following versions were EOL at the time the CVE was created but are
known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.
Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.
Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue. |
| Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component.
The Camel-LevelDB DefaultLevelDBSerializer class deserializes data read from the LevelDB aggregation repository using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. An attacker who can write to the LevelDB database files used by a Camel application can inject a crafted serialized Java object that, when deserialized during normal aggregation repository operations, results in arbitrary code execution in the context of the application.
This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. For the 4.10.x LTS releases, users are recommended to upgrade to 4.10.9, while for 4.14.x LTS releases, users are recommended to upgrade to 4.14.5 |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat via invalid chunk extension.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Other, unsupported versions may also be affected.
Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue. |
| Deserialization of Untrusted Data vulnerability in Apache Storm.
Versions Affected:
before 2.8.6.
Description:
When processing topology credentials submitted via the Nimbus Thrift API, Storm deserializes the base64-encoded TGT blob using ObjectInputStream.readObject() without any class filtering or validation. An authenticated user with topology submission rights could supply a crafted serialized object in the "TGT" credential field, leading to remote code execution in both the Nimbus and Worker JVMs.
Mitigation:
2.x users should upgrade to 2.8.6.
Users who cannot upgrade immediately should monkey-patch an ObjectInputFilter allow-list to ClientAuthUtils.deserializeKerberosTicket() restricting deserialized classes to javax.security.auth.kerberos.KerberosTicket and its known dependencies. A guide on how to do this is available in the release notes of 2.8.6.
Credit: This issue was discovered by K. |
| Privilege escalation in Apache Cassandra 5.0 on an mTLS environment using MutualTlsAuthenticator allows a user with only CREATE permission to associate their own certificate identity with an arbitrary role,
including a superuser role, and authenticate as that role via ADD IDENTITY.
Users are recommended to upgrade to version 5.0.7+, which fixes this issue. |
| Use of Hard-coded Cryptographic Key vulnerability in Apache OpenMeetings.
The remember-me cookie encryption key is set to default value in openmeetings.properties and not being auto-rotated. In case OM admin hasn't changed the default encryption key, an attacker who has stolen a cookie from a logged-in user can get full user credentials.
This issue affects Apache OpenMeetings: from 6.1.0 before 9.0.0.
Users are recommended to upgrade to version 9.0.0, which fixes the issue. |
