Filtered by vendor Apache
Subscribe
Total
3520 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-22922 | 1 Apache | 1 Airflow | 2026-06-17 | N/A | 6.5 MEDIUM |
| Apache Airflow versions 3.1.0 through 3.1.6 contain an authorization flaw that can allow an authenticated user with custom permissions limited to task access to view task logs without having task log access. Users are recommended to upgrade to Apache Airflow 3.1.7 or later, which resolves this issue. | |||||
| CVE-2026-22444 | 1 Apache | 1 Solr | 2026-06-17 | N/A | 7.1 HIGH |
| 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. | |||||
| CVE-2026-22022 | 1 Apache | 1 Solr | 2026-06-17 | N/A | 8.2 HIGH |
| 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. | |||||
| CVE-2025-69219 | 1 Apache | 1 Airflow Providers Http | 2026-06-17 | N/A | 8.8 HIGH |
| A user with access to the DB could craft a database entry that would result in executing code on Triggerer - which gives anyone who have access to DB the same permissions as Dag Author. Since direct DB access is not usual and recommended for Airflow, the likelihood of it making any damage is low. You should upgrade to version 6.0.0 of the provider to avoid even that risk. | |||||
| CVE-2025-68675 | 1 Apache | 1 Airflow | 2026-06-17 | N/A | 7.5 HIGH |
| In Apache Airflow versions before 3.1.6, and 2.11.1 the proxies and proxy fields within a Connection may include proxy URLs containing embedded authentication information. These fields were not treated as sensitive by default and therefore were not automatically masked in log output. As a result, when such connections are rendered or printed to logs, proxy credentials embedded in these fields could be exposed. Users are recommended to upgrade to 3.1.6 or later for Airflow 3, and 2.11.1 or later for Airflow 2 which fixes this issue | |||||
| CVE-2025-68438 | 1 Apache | 1 Airflow | 2026-06-17 | N/A | 7.5 HIGH |
| In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] max_templated_field_length, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered mask_secret() patterns, so secrets were not reliably masked before truncation and display. Users are recommended to upgrade to 3.1.6 or later, which fixes this issue | |||||
| CVE-2025-68161 | 1 Apache | 1 Log4j | 2026-06-17 | N/A | 4.8 MEDIUM |
| The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. | |||||
| CVE-2025-67895 | 1 Apache | 1 Apache-airflow-providers-edge3 | 2026-06-17 | N/A | 9.8 CRITICAL |
| Edge3 Worker RPC RCE on Airflow 2. This issue affects Apache Airflow Providers Edge3: before 2.0.0 - and only if you installed and configured it on Airflow 2. The Edge3 provider support in Airflow 2 has been always development-only and not officially released, however if you installed and configured Edge3 provider in Airflow 2, it implicitly enabled non-public (normally) API which was used to test Edge Provider in Airflow 2 during the development. This API allowed Dag author to perform Remote Code Execution in the webserver context, which Dag Author was not supposed to be able to do. If you installed and configured Edge3 provider for Airflow 2, you should uninstall it and migrate to Airflow 3. The new Edge3 provider versions (>=2.0.0) has minimum version of Airflow set to 3 and the RCE-prone Airflow 2 code is removed, so it should no longer be possible to use the Edge3 provider 2.0.0+ on Airflow 2. If you used Edge Provider in Airflow 3, you are not affected. | |||||
| CVE-2025-66614 | 1 Apache | 1 Tomcat | 2026-06-17 | N/A | 9.1 CRITICAL |
| Improper Input Validation vulnerability. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected. Tomcat did not validate that the host name provided via the SNI extension was the same as the host name provided in the HTTP host header field. If Tomcat was configured with more than one virtual host and the TLS configuration for one of those hosts did not require client certificate authentication but another one did, it was possible for a client to bypass the client certificate authentication by sending different host names in the SNI extension and the HTTP host header field. The vulnerability only applies if client certificate authentication is only enforced at the Connector. It does not apply if client certificate authentication is enforced at the web application. Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue. | |||||
| CVE-2025-66524 | 1 Apache | 1 Nifi | 2026-06-17 | N/A | 8.8 HIGH |
| Apache NiFi 1.20.0 through 2.6.0 include the GetAsanaObject Processor, which requires integration with a configurable Distribute Map Cache Client Service for storing and retrieving state information. The GetAsanaObject Processor used generic Java Object serialization and deserialization without filtering. Unfiltered Java object deserialization does not provide protection against crafted state information stored in the cache server configured for GetAsanaObject. Exploitation requires an Apache NiFi system running with the GetAsanaObject Processor, and direct access to the configured cache server. Upgrading to Apache NiFi 2.7.0 is the recommended mitigation, which replaces Java Object serialization with JSON serialization. Removing the GetAsanaObject Processor located in the nifi-asana-processors-nar bundle also prevents exploitation. | |||||
| CVE-2025-66516 | 1 Apache | 1 Tika | 2026-06-17 | N/A | 8.4 HIGH |
| Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways. First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable. Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module. | |||||
| CVE-2025-66249 | 1 Apache | 1 Livy | 2026-06-17 | N/A | 6.3 MEDIUM |
| Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Livy. This issue affects Apache Livy: from 0.3.0 before 0.9.0. The vulnerability can only be exploited with non-default Apache Livy Server settings. If the configuration value "livy.file.local-dir-whitelist" is set to a non-default value, the directory checking can be bypassed. Users are recommended to upgrade to version 0.9.0, which fixes the issue. | |||||
| CVE-2025-66169 | 1 Apache | 1 Camel | 2026-06-17 | N/A | 5.3 MEDIUM |
| Cypher Injection vulnerability in Apache Camel camel-neo4j component. This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.3, from 4.15.0 before 4.17.0 Users are recommended to upgrade to version 4.10.8 for 4.10.x LTS and 4.14.3 for 4.14.x LTS and 4.17.0. | |||||
| CVE-2025-66168 | 1 Apache | 1 Activemq | 2026-06-17 | N/A | 5.4 MEDIUM |
| WARNING: Users of 6.x should upgrade to 6.2.4 or later as the fix was missed in previous 6.x releases. See the following for more details: https://activemq.apache.org/security-advisories.data/CVE-2026-40046-announcement.txt https://www.cve.org/CVERecord?id=CVE-2026-40046 Original Report: Apache ActiveMQ does not properly validate the remaining length field which may lead to an overflow during the decoding of malformed packets. When this integer overflow occurs, ActiveMQ may incorrectly compute the total Remaining Length and subsequently misinterpret the payload as multiple MQTT control packets which makes the broker susceptible to unexpected behavior when interacting with non-compliant clients. This behavior violates the MQTT v3.1.1 specification, which restricts Remaining Length to a maximum of 4 bytes. The scenario occurs on established connections after the authentication process. Brokers that are not enabling mqtt transport connectors are not impacted. This issue affects Apache ActiveMQ: before 5.19.2, 6.0.0 to 6.1.8, and 6.2.0 Users are recommended to upgrade to version 5.19.2, 6.1.9, or 6.2.1, which fixes the issue. | |||||
| CVE-2025-65995 | 1 Apache | 1 Airflow | 2026-06-17 | N/A | 6.5 MEDIUM |
| When a DAG failed during parsing, Airflow’s error-reporting in the UI could include the full kwargs passed to the operators. If those kwargs contained sensitive values (such as secrets), they might be exposed in the UI tracebacks to authenticated users who had permission to view that DAG. The issue has been fixed in Airflow 3.1.4 and 2.11.1, and users are strongly advised to upgrade to prevent potential disclosure of sensitive information. | |||||
| CVE-2025-62728 | 1 Apache | 1 Hive | 2026-06-17 | N/A | 5.4 MEDIUM |
| SQL injection vulnerability in Hive Metastore Server (HMS) when processing delete column statistics requests via the Thrift APIs. The vulnerability is only exploitable by trusted/authorized users/applications that are allowed to call directly the Thrift APIs. In most real-world deployments, HMS is accessible to only a handful of applications (e.g., Hiveserver2) thus the vulnerability is not exploitable. Moreover, the vulnerable code cannot be reached when metastore.try.direct.sql property is set to false. This issue affects Apache Hive: from 4.1.0 before 4.2.0. Users are recommended to upgrade to version 4.2.0, which fixes the issue. Users who cannot upgrade directly are encouraged to set metastore.try.direct.sql property to false if the HMS Thrift APIs are exposed to general public. | |||||
| CVE-2025-62235 | 1 Apache | 1 Nimble | 2026-06-17 | N/A | 8.1 HIGH |
| Authentication Bypass by Spoofing vulnerability in Apache NimBLE. Receiving specially crafted Security Request could lead to removal of original bond and re-bond with impostor. This issue affects Apache NimBLE: through 1.8.0. Users are recommended to upgrade to version 1.9.0, which fixes the issue. | |||||
| CVE-2025-60021 | 1 Apache | 1 Brpc | 2026-06-17 | N/A | 9.8 CRITICAL |
| Remote command injection vulnerability in heap profiler builtin service in Apache bRPC ((all versions < 1.15.0)) on all platforms allows attacker to inject remote command. Root Cause: The bRPC heap profiler built-in service (/pprof/heap) does not validate the user-provided extra_options parameter and executes it as a command-line argument. Attackers can execute remote commands using the extra_options parameter.. Affected scenarios: Use the built-in bRPC heap profiler service to perform jemalloc memory profiling. How to Fix: we provide two methods, you can choose one of them: 1. Upgrade bRPC to version 1.15.0. 2. Apply this patch ( https://github.com/apache/brpc/pull/3101 ) manually. | |||||
| CVE-2025-60012 | 1 Apache | 1 Livy | 2026-06-17 | N/A | 6.3 MEDIUM |
| Malicious configuration can lead to unauthorized file access in Apache Livy. This issue affects Apache Livy 0.7.0 and 0.8.0 when connecting to Apache Spark 3.1 or later. A request that includes a Spark configuration value supported from Apache Spark version 3.1 can lead to users gaining access to files they do not have permissions to. For the vulnerability to be exploitable, the user needs to have access to Apache Livy's REST or JDBC interface and be able to send requests with arbitrary Spark configuration values. Users are recommended to upgrade to version 0.9.0 or later, which fixes the issue. | |||||
| CVE-2025-59390 | 1 Apache | 1 Druid | 2026-06-17 | N/A | 9.8 CRITICAL |
| Apache Druid’s Kerberos authenticator uses a weak fallback secret when the `druid.auth.authenticator.kerberos.cookieSignatureSecret` configuration is not explicitly set. In this case, the secret is generated using `ThreadLocalRandom`, which is not a crypto-graphically secure random number generator. This may allow an attacker to predict or brute force the secret used to sign authentication cookies, potentially enabling token forgery or authentication bypass. Additionally, each process generates its own fallback secret, resulting in inconsistent secrets across nodes. This causes authentication failures in distributed or multi-broker deployments, effectively leading to a incorrectly configured clusters. Users are advised to configure a strong `druid.auth.authenticator.kerberos.cookieSignatureSecret` This issue affects Apache Druid: through 34.0.0. Users are recommended to upgrade to version 35.0.0, which fixes the issue making it mandatory to set `druid.auth.authenticator.kerberos.cookieSignatureSecret` when using the Kerberos authenticator. Services will fail to come up if the secret is not set. | |||||