Apache The Apache Software Foundation
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Apache product.
RSS Feeds for Apache security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Apache products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Apache Sorted by Most Security Vulnerabilities since 2018
Recent Apache Security Advisories
| Advisory | Title | Published |
|---|---|---|
| 2.4.68 | 13 Vulnerabilities Fixed in Apache HTTP Server 2.4.68 | June 8, 2026 |
| 2.4.67 | 11 Vulnerabilities Fixed in Apache HTTP Server 2.4.67 | May 4, 2026 |
| 2.4.66 | 5 Vulnerabilities Fixed in Apache HTTP Server 2.4.66 | December 4, 2025 |
| 2.4.65 | Vulnerability Fixed in Apache HTTP Server 2.4.65 | July 23, 2025 |
| 2.4.64 | 8 Vulnerabilities Fixed in Apache HTTP Server 2.4.64 | July 10, 2025 |
| 2.4.62 | 2 Vulnerabilities Fixed in Apache HTTP Server 2.4.62 | July 17, 2024 |
| 2.4.61 | Vulnerability Fixed in Apache HTTP Server 2.4.61 | July 16, 2024 |
| 2.4.60 | 8 Vulnerabilities Fixed in Apache HTTP Server 2.4.60 | July 15, 2024 |
| 2.4.59 | 3 Vulnerabilities Fixed in Apache HTTP Server 2.4.59 | April 4, 2024 |
| 2.4.58 | 4 Vulnerabilities Fixed in Apache HTTP Server 2.4.58 | October 19, 2023 |
Known Exploited Apache Vulnerabilities
The following Apache vulnerabilities have recently been marked by CISA as Known to be Exploited by threat actors.
| Title | Description | Added |
|---|---|---|
| Apache ActiveMQ Improper Input Validation Vulnerability |
Apache ActiveMQ contains an improper input validation vulnerability that allows for code injection. CVE-2026-34197 Exploit Probability: 87.0% |
April 16, 2026 |
| Apache HTTP Server Improper Escaping of Output Vulnerability |
Apache HTTP Server contains an improper escaping of output vulnerability in mod_rewrite that allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure. CVE-2024-38475 Exploit Probability: 100.0% |
May 1, 2025 |
| Apache Tomcat Path Equivalence Vulnerability |
Apache Tomcat contains a path equivalence vulnerability that allows a remote attacker to execute code, disclose information, or inject malicious content via a partial PUT request. CVE-2025-24813 Exploit Probability: 99.9% |
April 1, 2025 |
| Apache OFBiz Forced Browsing Vulnerability |
Apache OFBiz contains a forced browsing vulnerability that allows a remote attacker to obtain unauthorized access. CVE-2024-45195 Exploit Probability: 100.0% |
February 4, 2025 |
| Apache HugeGraph-Server Improper Access Control Vulnerability |
Apache HugeGraph-Server contains an improper access control vulnerability that could allow a remote attacker to execute arbitrary code. CVE-2024-27348 Exploit Probability: 99.2% |
September 18, 2024 |
| Apache OFBiz Incorrect Authorization Vulnerability |
Apache OFBiz contains an incorrect authorization vulnerability that could allow remote code execution via a Groovy payload in the context of the OFBiz user process by an unauthenticated attacker. CVE-2024-38856 Exploit Probability: 99.4% |
August 27, 2024 |
| Apache OFBiz Path Traversal Vulnerability |
Apache OFBiz contains a path traversal vulnerability that could allow for remote code execution. CVE-2024-32113 Exploit Probability: 99.4% |
August 7, 2024 |
| Apache Flink Improper Access Control Vulnerability |
Apache Flink contains an improper access control vulnerability that allows an attacker to read any file on the local filesystem of the JobManager through its REST interface. CVE-2020-17519 Exploit Probability: 97.9% |
May 23, 2024 |
| Apache Superset Insecure Default Initialization of Resource Vulnerability |
Apache Superset contains an insecure default initialization of a resource vulnerability that allows an attacker to authenticate and access unauthorized resources on installations that have not altered the default configured SECRET_KEY according to installation instructions. CVE-2023-27524 Exploit Probability: 97.4% |
January 8, 2024 |
| Apache ActiveMQ Deserialization of Untrusted Data Vulnerability |
Apache ActiveMQ contains a deserialization of untrusted data vulnerability that may allow a remote attacker with network access to a broker to run shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath. CVE-2023-46604 Exploit Probability: 99.7% |
November 2, 2023 |
| Apache RocketMQ Command Execution Vulnerability |
Several components of Apache RocketMQ, including NameServer, Broker, and Controller, are exposed to the extranet and lack permission verification. An attacker can exploit this vulnerability by using the update configuration function to execute commands as the system users that RocketMQ is running as or achieve the same effect by forging the RocketMQ protocol content. CVE-2023-33246 Exploit Probability: 96.6% |
September 6, 2023 |
| Apache Tomcat Remote Code Execution Vulnerability |
Apache Tomcat contains an unspecified vulnerability that allows for remote code execution if JmxRemoteLifecycleListener is used and an attacker can reach Java Management Extension (JMX) ports. This CVE exists because this listener wasn't updated for consistency with the Oracle patched issues for CVE-2016-3427 which affected credential types. CVE-2016-8735 Exploit Probability: 90.3% |
May 12, 2023 |
| Apache Log4j2 Deserialization of Untrusted Data Vulnerability |
Apache Log4j2 contains a deserialization of untrusted data vulnerability due to the incomplete fix of CVE-2021-44228, where the Thread Context Lookup Pattern is vulnerable to remote code execution in certain non-default configurations. CVE-2021-45046 Exploit Probability: 100.0% |
May 1, 2023 |
| Apache Spark Command Injection Vulnerability |
Apache Spark contains a command injection vulnerability via Spark User Interface (UI) when Access Control Lists (ACLs) are enabled. CVE-2022-33891 Exploit Probability: 93.0% |
March 7, 2023 |
| Apache APISIX Authentication Bypass Vulnerability |
Apache APISIX contains an authentication bypass vulnerability that allows for remote code execution. CVE-2022-24112 Exploit Probability: 96.2% |
August 25, 2022 |
| Apache CouchDB Insecure Default Initialization of Resource Vulnerability |
Apache CouchDB contains an insecure default initialization of resource vulnerability which can allow an attacker to escalate to administrative privileges. CVE-2022-24706 Exploit Probability: 92.5% |
August 25, 2022 |
| Apache Kylin OS Command Injection Vulnerability |
Apache Kylin contains an OS command injection vulnerability which could permit an attacker to perform remote code execution. CVE-2020-1956 Exploit Probability: 97.3% |
March 25, 2022 |
| Apache Struts Improper Input Validation Vulnerability |
Apache Struts allows remote attackers to execute arbitrary Object-Graph Navigation Language (OGNL) expressions. CVE-2013-2251 Exploit Probability: 100.0% |
March 25, 2022 |
| Apache Tomcat on Windows Remote Code Execution Vulnerability |
When running Apache Tomcat on Windows with HTTP PUTs enabled, it is possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. CVE-2017-12615 Exploit Probability: 99.6% |
March 25, 2022 |
| Apache Tomcat Remote Code Execution Vulnerability |
When running Apache Tomcat, it is possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. CVE-2017-12617 Exploit Probability: 100.0% |
March 25, 2022 |
Of the known exploited vulnerabilities above, 20 are in the top 1%, or the 99th percentile of the EPSS exploit probability rankings.
Top 10 Riskiest Apache Vulnerabilities
Based on the current exploit probability, these Apache vulnerabilities are on CISA's Known Exploited vulnerabilities list (KEV) and are ranked by the current EPSS exploit probability.
| Rank | CVE | EPSS | Vulnerability |
|---|---|---|---|
| 1 | CVE-2021-44228 | 100.0% | Apache Log4j2 Remote Code Execution Vulnerability |
| 2 | CVE-2017-5638 | 100.0% | Apache Struts Jakarta Multipart parser exception handling vulnerability |
| 3 | CVE-2021-40438 | 100.0% | Apache HTTP Server-Side Request Forgery (SSRF) |
| 4 | CVE-2013-2251 | 100.0% | Apache Struts Improper Input Validation Vulnerability |
| 5 | CVE-2018-11776 | 100.0% | Apache Struts 2.3 to 2.3.34 and 2.5 to 2.5.16 Remote Code Execution Vulnerability |
| 6 | CVE-2021-41773 | 100.0% | Apache HTTP Server Path Traversal Vulnerability |
| 7 | CVE-2017-12617 | 100.0% | Apache Tomcat Remote Code Execution Vulnerability |
| 8 | CVE-2024-45195 | 100.0% | Apache OFBiz Forced Browsing Vulnerability |
| 9 | CVE-2021-45046 | 100.0% | Apache Log4j2 Deserialization of Untrusted Data Vulnerability |
| 10 | CVE-2021-42013 | 100.0% | Apache HTTP Server 2.4.49 and 2.4.50 Path Traversal |
By the Year
In 2026 there have been 439 vulnerabilities in Apache with an average score of 7.3 out of ten. Last year, in 2025 Apache had 229 security vulnerabilities published. That is, 210 more vulnerabilities have already been reported in 2026 as compared to last year. However, the average CVE base score of the vulnerabilities in 2026 is greater by 0.03.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 439 | 7.31 |
| 2025 | 229 | 7.29 |
| 2024 | 275 | 7.45 |
| 2023 | 274 | 7.47 |
| 2022 | 228 | 7.63 |
| 2021 | 212 | 7.61 |
| 2020 | 160 | 7.56 |
| 2019 | 163 | 7.37 |
| 2018 | 155 | 7.24 |
It may take a day or so for new Apache vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Apache Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-59173 | Jul 18, 2026 |
Apache Traffic Server Uncontrolled Resource Consumption ( 9.1.13, 10.1.2)Uncontrolled Resource Consumption vulnerability in Apache Traffic Server. This issue affects Apache Traffic Server: from 9.0.0 through 9.1.13, from 10.0.0 through 10.1.2. Users are recommended to upgrade to version 9.1.14 or 10.1.3, which fixes the issue. |
Traffic Server
|
| CVE-2026-62764 | Jul 17, 2026 |
Apache Accumulo 2.1.4-2.1.5: Unauth DDoS via Remote Shutdown (Insuff Priv)Improper Handling of Insufficient Privileges vulnerability in Apache Accumulo. An authenticated, but low-privileged user without system permissions may issue a remote command to gracefully shutdown system components (compaction-coordinator, compactor, gc, manager, monitor, tserver, or sserver), leading to a denial of service. This issue affects Apache Accumulo 2.1.4 and 2.1.5. Users are recommended to upgrade to version 2.1.6, which fixes the issue. |
Accumulo
|
| CVE-2026-26032 | Jul 15, 2026 |
Vuln: PackagerResolver Path Traversal in Apache Ivy 2.0-2.5.3The PackagerResolver of Apache Ivy is able to download online artifacts and to (re)package them in a format defined by a packager.xml file. This repackaging is done by an Ant script, which is stored in a subdirectory of the configured "buildRoot" directory. This subdirectory is calculated based on modules coordinates, like the organisation, name or version. If one of the coordinates contains "../" sequences - which are valid characters for Ivy coordinates in general- it is possible to break out of the configured "buildRoot" directory where other files can be overwritten. In order to exploit this vulnerability an attacker needs to have access to a packager repository and add or modify the coordinates in ivy.xml files to have such "../" sequences. Users of Apache Ivy 2.0.0 to 2.5.3 (inclusive) should upgrade to Ivy 2.6.0. |
Ivy
|
| CVE-2026-57821 | Jul 15, 2026 |
SQLi in Apache Fineract Office Search API (orderBy) <=1.14.0A SQL Injection vulnerability exists in Apache Fineract's Office Search API (GET /api/v1/offices) in versions up to and including 1.14.0. The orderBy request parameter is concatenated into a SQL query without sufficient validation, allowing an authenticated user with permission to view offices to inject arbitrary SQL via a crafted orderBy value. This is a bypass of the ColumnValidator fix introduced for CVE-2024-32838, which does not detect bare subqueries in the ORDER BY position. This can be leveraged to perform time-based blind SQL injection for data exfiltration. Because the injected query blocks the database connection for its full duration, concurrent exploitation can exhaust the application's database connection pool, resulting in denial of service for other users. Users are recommended to upgrade to a version containing the fix. |
Fineract
|
| CVE-2026-35152 | Jul 15, 2026 |
Apache Fineract 1.14.0 Report API runreports SQL InjectionA SQL Injection vulnerability exists in Apache Fineract's Report Execution API (runreports endpoint) in versions up to and including 1.14.0. Report parameter values are incorporated into the generated SQL query without sufficient validation, allowing an authenticated user with permission to run reports to inject arbitrary SQL via crafted parameter values. This can be leveraged to perform unauthorized access to data beyond what the report was designed to expose. Users are recommended to upgrade to a version containing the fix. |
Fineract
|
| CVE-2026-56287 | Jul 15, 2026 |
Apache Fineract <=1.14.0 Boolean SQLi in Client Search APIA boolean-based SQL Injection vulnerability exists in Apache Fineract's Client Search API (GET /api/v1/clients) in versions up to and including 1.14.0. The orderBy and sortOrder request parameters are concatenated into a SQL query without sufficient validation, allowing an authenticated user with permission to view clients to inject arbitrary SQL via a crafted orderBy value. This can be leveraged to perform blind boolean-based data extraction and, on MySQL/MariaDB, to disclose arbitrary files readable by the database process via the LOAD_FILE() function. Users are recommended to upgrade to a version containing the fix |
Fineract
|
| CVE-2026-49488 | Jul 14, 2026 |
Apache OpenMeetings Path Traversal | 5.0.09.1.0 | Moderator-level AccessImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache OpenMeetings. This issue affects Apache OpenMeetings: from 5.0.0 before 9.1.0. An attacker with moderator rights in any room can read arbitrary files accessible to the OS account running the OM server, including credentials and secrets, via a crafted download request. Users are recommended to upgrade to version 9.1.0, which fixes the issue. |
Openmeetings
|
| CVE-2026-62393 | Jul 14, 2026 |
Apache Kylin v4-5.0.3: Improper Auth on Job RetrievalImproper Handling of Insufficient Permissions or Privileges vulnerability in Apache Kylin. Improper authorization in job information retrieval, where an attacker may get access to unauthorized jobs in other projects. This issue affects Apache Kylin: from 4 through 5.0.3. Users are recommended to upgrade to version 5.0.4, which fixes the issue. |
Kylin
|
| CVE-2026-62392 | Jul 14, 2026 |
Apache Kylin OS Command Injection 45.0.3 (fixed 5.0.4)Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Apache Kylin. A backend API may bring job config parameters to OS command line. This issue affects Apache Kylin: from 4 through 5.0.3. Users are recommended to upgrade to version 5.0.4, which fixes the issue. |
Kylin
|
| CVE-2026-62390 | Jul 14, 2026 |
Apache Kylin <5.0.4: SQL Injection via Catalog Refresh APIImproper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Kylin. A backend API refreshing table catalog may cause the injection to the generated SQL. This issue affects Apache Kylin: from 4 through 5.0.3. Users are recommended to upgrade to version 5.0.4, which fixes the issue. |
Kylin
|
| CVE-2026-58319 | Jul 14, 2026 |
Apache Doris <3.1.0 FE REST API Unauth Access Enables Admin OpsCertain Apache Doris FE HTTP REST administrative APIs were accessible without proper authentication. An unauthenticated attacker with network access to the FE HTTP service could perform unauthorized administrative operations, potentially affecting cluster integrity and availability and leading to cluster instability or denial of service. This issue affects Apache Doris versions prior to 3.1.0. Users are advised to upgrade to Apache Doris 3.1.0 or later. |
Doris
|
| CVE-2026-59084 | Jul 14, 2026 |
Apache Tomcat EncryptInterceptor Insufficient Docs 7.0-11.0.23Insufficient Technical Documentation vulnerability in Apache Tomcat since the requirements to securely configure the EncryptInterceptor were not clearly documented. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.23, from 10.1.0-M1 through 10.1.56, from 9.0.13 through 9.0.119, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109. Other versions that have reached end of support may also be affected. Users are recommended to upgrade to version 11.0.24, 10.1.57 or 9.0.120 which fix the issue. |
Tomcat
|
| CVE-2026-59083 | Jul 14, 2026 |
Apache Tomcat RewriteValve URL Decode Bypass <=11.0.23,<10.1.56,<9.0.119,<8.5.100Improper Handling of URL Encoding (Hex Encoding) vulnerability in Apache Tomcat's rewrite valve allowed security constraint bypass for some configurations. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.23, from 10.1.0-M1 through 10.1.56, from 9.0.0.M1 through 9.0.119, from 8.5.0 through 8.5.100. Other versions that have reached end of support may also be affected. Users are recommended to upgrade to version 11.0.24, 10.1.57 or 9.0.120, which fix the issue. |
Tomcat
|
| CVE-2026-59245 | Jul 13, 2026 |
Apache Airflow FAB: DAG ID 'DAGs' collision grants global DAG accessIn the Apache Airflow FAB auth manager, a DAG whose `dag_id` is `DAGs` collided with the global all-DAGs permission resource name produced by `resource_name()`, so a user granted per-DAG `access_control` on that one DAG was silently granted the global all-DAGs permission (privilege escalation). The escalation triggers when a DAG named `DAGs` exists and a lower-privileged user is given per-DAG access to it, granting that user read/edit access to every DAG. Users are advised to upgrade to `apache-airflow-providers-fab` 3.7.2 or later, which disambiguates the resource-name collision. |
AirFlow
|
| CVE-2026-58065 | Jul 13, 2026 |
Apache Airflow Git Provider SSH Host Key Verification Disabled (0.4.1 Fix)The Apache Airflow Git provider runs its git-over-SSH operations with `StrictHostKeyChecking=no` by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git `0.4.1` or later and configure a `known_hosts` file. |
AirFlow
|
| CVE-2026-41041 | Jul 13, 2026 |
Apache Gravitino <1.2.1 URL Path InjectionURL path injection via unencoded user-supplied identifiers vulnerability in Apache Gravitino. This issue affects Apache Gravitino: from 1.0.0 before 1.2.1. Users are recommended to upgrade to version 1.2.1, which fixes the issue. |
|
| CVE-2026-49876 | Jul 13, 2026 |
Authenticated SSRF in Apache Gravitino JobManager v1.0.0-1.2.1 via unvalidated job template URIsAuthenticated SSRF in Gravitino JobManager allows server-side HTTP requests to internal network and cloud metadata endpoints via unvalidated job template URIs. A vulnerability in Apache Gravitino. This issue affects Apache Gravitino: from 1.0.0 through 1.2.1. Users are recommended to upgrade to version 1.3.0, which fixes the issue. |
|
| CVE-2026-49844 | Jul 10, 2026 |
Apache Log4j API V2.13.1-2.26.0 MapMessage JSON Non-Finite Float EncodingImproper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0. The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document. The defect is reachable only when both of the following conditions hold: * The application uses the message resolver https://logging.apache.org/log4j/2.x/manual/json-template-layout.html#event-template-resolver-message of JsonTemplateLayout or any other layout that relies on MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}). * The application logs a MapMessage that contains an attacker-controlled floating-point value. An attacker who can supply a non-finite value can cause the affected layout to emit malformed JSON, which may corrupt the enclosing log record or disrupt downstream log ingestion and parsing. Users are advised to upgrade to Apache Log4j API 2.25.5 or 2.26.1, both of which emit RFC 8259-compliant JSON for non-finite values. |
Log4j Api
|
| CVE-2026-40454 | Jul 10, 2026 |
Apache IoTDB C++ Client OOB Read before 1.3.8 & 2.0.10Out-of-bounds Read, Improper Input Validation vulnerability in Apache IoTDB C++ client. Out-of-bounds reads in IoTDB C++ client TsBlock deserializer crash client process on malformed server data. This issue affects Apache IoTDB C++ client: from 1.3.5 before 1.3.8, from 2.0.5 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40452 | Jul 10, 2026 |
Apache IoTDB 1.3.5-1.3.7 / 2.0.5-2.0.9 Improper Auth: /rest/v2/fastLastQueryIncorrect Authorization, Improper Access Control vulnerability in Apache IoTDB. Authorization bypass in /rest/v2/fastLastQuery exposes last-value data to unauthorized authenticated users. This issue affects Apache IoTDB: from 1.3.5 before 1.3.8, from 2.0.5 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40009 | Jul 10, 2026 |
Apache IoTDB Privilege Escalation via __internal_auditor Rename (pre-2.0.10)Improper Privilege Management, Improper Access Control vulnerability in Apache IoTDB. Authenticated users can escalate to full tree-path access by renaming themselves to __internal_auditor. This issue affects Apache IoTDB: from 2.0.8 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40008 | Jul 10, 2026 |
Apache IoTDB 1.0.0-<2.0.10 Unsafe Reflection via Class.forName()Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache IoTDB. The pipe processor reads a fully qualified Java class name and instantiates it using Class.forName().newInstance() without any validation or allowlisting. This issue affects Apache IoTDB: from 1.0.0 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40007 | Jul 10, 2026 |
Apache IoTDB Uncontrolled Recursion in AirGap Receiver (before 2.0.10)Uncontrolled Recursion, Uncontrolled Resource Consumption vulnerability in Apache IoTDB. When pipe_air_gap_receiver_enabled=true, the IoTDB AirGap receiver's readLength method calls itself recursively each time it recognises the E-language prefix in socket data, with no depth limit. An unauthenticated attacker can send a stream of repeated E-language prefixes that drives the recursion arbitrarily deep, exhausting the receiver thread's JVM stack and raising StackOverflowError. This issue affects Apache IoTDB: from 1.0.0 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40006 | Jul 10, 2026 |
Apache IoTDB 1.x-2.0.9 AirGap Pipe Auth Bypass & OOM via readLengthMemory Allocation with Excessive Size Value, Allocation of Resources Without Limits or Throttling, Missing Authentication for Critical Function vulnerability in Apache IoTDB. When pipe_air_gap_receiver_enabled=true, the IoTDB AirGap pipe receiver accepts raw TCP connections on port 9780 with no authentication. The readLength method reads an attacker-controlled 32-bit integer from the socket and readData passes it directly to new byte[length] with no upper-bound check. An unauthenticated attacker can cause the JVM to attempt an allocation of up to 2,147,483,647 bytes per connection, exhausting heap memory and crashing or severely degrading the DataNode process. This issue affects Apache IoTDB: from 1.0.0 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-40005 | Jul 10, 2026 |
Apache IoTDB Path Traversal CVE-2026-40005 (1.0.0<2.0.10)Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache IoTDB. An attacker can write arbitrary files anywhere the IoTDB process has write permissions with unsafe API. This issue affects Apache IoTDB: from 1.0.0 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-28564 | Jul 10, 2026 |
Apache IoTDB Session Expiration Auth Bypass CVE-2026-28564Insufficient Session Expiration, Authentication Bypass by Capture-replay vulnerability in Apache IoTDB. REST Basic Authentication Accepts Stale Cached Credentials This issue affects Apache IoTDB: from 1.0.0 before 2.0.10. Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
Iotdb
|
| CVE-2026-57111 | Jul 09, 2026 |
Apache Helix CORS Misconfiguration (CORSFilter) before 2.0.1Permissive Cross-Origin Resource Sharing (CORS) in the REST API (helix-rest, org.apache.helix.rest.server.filters.CORSFilter) in Apache Helix through 2.0.0 on all platforms allows a remote attacker controlling a web page visited by an authorized user to read responses from and issue cross-origin requests to administrative REST endpoints via a cross-origin request from an arbitrary origin, since the filter unconditionally returns Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true and reflects arbitrary Access-Control-Request-Method / Access-Control-Request-Headers values in preflight responses. Users are recommended to upgrade to version 2.0.1, which fixes this issue. |
|
| CVE-2026-41042 | Jul 08, 2026 |
Apache Gravitino <1.2.1 H2 JDBC INIT Arbitrary Code Exec via testConnectionUnauthenticated callers can supply a malicious H2 JDBC URL through the testConnection API, which executes arbitrary Java code on the server via H2's INIT parameter. Vulnerability in Apache Gravitino. This issue affects Apache Gravitino: before 1.2.1. Users are recommended to upgrade to version 1.2.1, which fixes the issue. This issue only happens when using H2, and H2 is mainly used for testing and local development. Also, Gravitino is typically deployed in the internal environment, so the severity is low. |
|
| CVE-2026-33264 | Jul 07, 2026 |
Remote Code Exec via BaseSerialization.deserialize() in Apache Airflow <3.3.0A bug in `BaseSerialization.deserialize()` allowed unrestricted `import_string()` of attacker-controlled class paths when the Scheduler / API Server loaded a serialized DAG: a DAG author could embed a malicious trigger into a DAG to gain remote code execution on the API Server / Scheduler process, crossing the Airflow security boundary that DAG-author code must never execute in those processes. Users are advised to upgrade to `apache-airflow` 3.3.0 or later. As a defense-in-depth mitigation, deployments where DAG-author trust is limited can restrict the `[core] allowed_deserialization_classes` config to a narrow allowlist. |
AirFlow
|
| CVE-2026-49487 | Jul 07, 2026 |
Apache Airflow <3.3 REST API leak of trigger kwargs secretsIn Apache Airflow before 3.3.0, the REST API task-instance detail and list endpoints returned a deferred task's trigger kwargs without masking. When a deferred operator passed a secret (for example a provider API key) into its trigger, any authenticated user with DAG-scoped task-instance read access for that DAG could read that secret in clear text while the task was deferred. Users should upgrade to apache-airflow 3.3.0 or later, which masks sensitive values in trigger kwargs returned by the API. |
AirFlow
|
| CVE-2026-48828 | Jul 07, 2026 |
Apache Airflow Bulk Variable API leaks secrets via JSON (fixed in 3.3.0)The Bulk Variables API in Apache Airflow called the redactor without passing the variable's key, so the key-based `should_hide_value_for_key` check (which triggers on secret-suffixed key names like `*_password` / `*_token` / `*_secret`) could not fire for JSON-decodable variable values. An authenticated UI/API user with bulk Variable read permission could retrieve plaintext values from JSON variables whose key would otherwise trigger redaction. Affects deployments that store sensitive values in JSON-typed Airflow Variables under secret-suffixed key names. Users are advised to upgrade to `apache-airflow` 3.3.0 or later (the fix landed on `main` after 3.2.2; no 3.2.x backport). |
AirFlow
|
| CVE-2026-49296 | Jul 07, 2026 |
Apache Airflow <3.3.0: DAG source info disclosure via /api/v2/dagSourcesBefore apache-airflow 3.3.0, a user authorized to read one Dag could disclose the source of other Dags co-located in the same source file. `GET /api/v2/dagSources/{dag_id}` and the equivalent Dag-source view in the UI returned the entire source file without redacting Dags the caller was not authorized to read, bypassing per-DAG read authorization. Deployments that co-locate multiple Dags in a single file and rely on per-DAG access control to limit source visibility are affected; single-Dag-per-file deployments are not. Upgrade to apache-airflow 3.3.0 or later. |
AirFlow
|
| CVE-2026-48891 | Jul 07, 2026 |
CVE-2026-48891: Airflow 3.3+ Fix for Dag ID Leakage via /ui/dependenciesA bug in Apache Airflow's `/ui/dependencies` scheduling graph endpoint applied the caller's readable-Dag filter to the top-level serialized Dag key but still emitted referenced Dag IDs through the `dep.source` and `dep.target` fields of trigger / sensor dependency entries. An authenticated UI user with read permission on some Dags could enumerate the identifiers of other Dags they were not authorized to read by inspecting the dependency graph for trigger / sensor references. Affects deployments that rely on per-Dag read scoping to keep Dag identifiers private across teams. This is a residual gap in the fix for CVE-2026-28563, which filtered the top-level Dag key but did not propagate the filter into the trigger / sensor dep-source / dep-target fields. Users who already upgraded for CVE-2026-28563 should additionally upgrade to `apache-airflow` 3.3.0 or later to cover the residual trigger / sensor dependency leak. |
AirFlow
|
| CVE-2026-48892 | Jul 07, 2026 |
Apache Airflow Config API v3.3+ Fix: Env Override Secret ExposureThe Config API in Apache Airflow surfaced per-key secrets-backend overrides (environment variables like `AIRFLOW__SECRETS__BACKEND_KWARG__SECRET_ID` and `AIRFLOW__WORKERS__SECRETS_BACKEND_KWARG__SECRET_ID`) as synthetic config options whose option names were not in `sensitive_config_values`, so the masker did not redact them. An authenticated UI/API user with Config read permission could retrieve plaintext secrets-backend credentials (Vault `role_id` / `secret_id`, etc.) from the Config API output. Affects deployments that configure secrets backends via per-key environment overrides. Users are advised to upgrade to `apache-airflow` 3.3.0 or later. |
AirFlow
|
| CVE-2026-43825 | Jul 06, 2026 |
Untrusted Java Deserialization in OpenNLP <3.0.0-M4 (SvmDoccatModel)Untrusted Java Deserialization in Apache OpenNLP SvmDoccatModel Versions Affected: before 3.0.0-M4 (libsvm document categorization module; introduced in OPENNLP-1808 and only present on the 3.x line) Description: SvmDoccatModel.deserialize(InputStream) reads an attacker-controlled stream with java.io.ObjectInputStream and calls readObject() without an ObjectInputFilter installed. ObjectInputStream materialises every class referenced in the stream before the resulting object is cast to SvmDoccatModel, so the cast that follows readObject() executes only after the foreign object graph has already been deserialised in full. If a Java deserialization gadget chain is available on the consumer's classpath, a crafted payload supplied to deserialize() executes arbitrary code in the JVM that loads it. Apache OpenNLP itself does not ship a known gadget chain, so the realistic risk is to downstream applications that embed the libsvm module alongside vulnerable transitive dependencies. The method is public and static, so any caller can pass an untrusted stream to it directly. The practical impact is remote code execution against processes that load SvmDoccatModel instances from untrusted or semi-trusted origins. Mitigation: 3.x users should upgrade to 3.0.0-M4. Users who cannot upgrade immediately should treat all serialized SvmDoccatModel streams as untrusted input unless their provenance is verified, and should avoid invoking SvmDoccatModel.deserialize() on streams supplied by end users or fetched from third-party sources without integrity checks. |
|
| CVE-2026-49297 | Jul 06, 2026 |
Apache Airflow GCS Provider Path Traversal via GCSToSFTPOperator before 22.2.1Apache Airflow's Google provider operators `GCSToSFTPOperator` and `GCSTimeSpanFileTransformOperator` joined GCS object names returned by the bucket listing API directly to a destination filesystem path without normalisation or containment check. A user with write access to the source GCS bucket (typically a different trust principal than the DAG author partner uploads, ingest-only service accounts, public-data buckets) could create an object whose name contains `..` segments and cause the DAG run to write the downloaded blob outside the configured destination (the SFTP `destination_path` for `GCSToSFTPOperator`; the worker-local temp directory for `GCSTimeSpanFileTransformOperator`), enabling overwrite of arbitrary files on the SFTP server or the worker host. Affects deployments that ingest from buckets writable by less-trusted principals. Users are advised to upgrade to `apache-airflow-providers-google` 22.2.1 or later. |
AirFlow
|
| CVE-2026-46588 | Jul 06, 2026 |
Apache Camel Improper Input Validation (pre-4.14.8/4.18.3/4.21.0)Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue. |
Camel
|
| CVE-2026-46587 | Jul 06, 2026 |
Apache Camel Improper Input Validation CVE-2026-46587 (4.14.7-4.20.0)Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue. |
Camel
|
| CVE-2026-49042 | Jul 06, 2026 |
Apache Camel CVE-2026-49042: Improper Input Validation (4.8.0-4.20.0)Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: from 4.8.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.18.3, 4.21.0, which fixes the issue. |
Camel
|
| CVE-2026-24013 | Jul 06, 2026 |
Apache IoTDB Auth Bypass via Forged SessionId (pre2.0.8)Authentication Bypass by Spoofing vulnerability in Apache IoTDB. Certain Thrift RPC query handlers lack strict validation of the sessionId parameter. An attacker can construct requests with a forged sessionId and, without performing openSession authentication, receive valid query results. This allows authentication bypass and unauthorized reading of time-series data. This issue affects Apache IoTDB: from 1.3.3 before 2.0.8. Users are recommended to upgrade to version 2.0.8, which fixes the issue. |
Iotdb
|
| CVE-2026-24012 | Jul 06, 2026 |
Uncontrolled Resource Consumption in Apache IoTDB 1.3.3<2.0.8Uncontrolled Resource Consumption vulnerability in Apache IoTDB. Some interface fails to impose reasonable limits on the time span and aggregation interval of the query. An attacker can construct a request with extreme parameters (e.g., a very large time range combined with a minimal interval). This forces the DataNode to build an enormous result set in memory, which exhausts the Java heap and causes the DataNode process to crash. This issue affects Apache IoTDB: from 1.3.3 before 2.0.8. Users are recommended to upgrade to version 2.0.8, which fixes the issue. |
Iotdb
|
| CVE-2026-43866 | Jul 06, 2026 |
Deserialization Bypass in Apache Camel (camel-jms) before 4.21.0Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component. JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it. This issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes. |
Camel
|
| CVE-2026-24014 | Jul 06, 2026 |
Apache IoTDB <2.0.8 Trigger JAR RPC path traversal file writeApache IoTDB DataNodes internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process. This issue affects Apache IoTDB: from 1.3.3 before 2.0.8. Users are recommended to upgrade to version 2.0.8, which fixes the issue. |
Iotdb
|
| CVE-2026-43867 | Jul 06, 2026 |
Apache Camel PQC Deserialization Flaw 4.184.21 (CVE202643867)Deserialization of Untrusted Data vulnerability in Apache Camel PQC Component. The camel-pqc component persists post-quantum key metadata (KeyMetadata) through pluggable KeyLifecycleManager implementations. AwsSecretsManagerKeyLifecycleManager.deserializeMetadata() reads that metadata back from the configured AWS Secrets Manager secret by Base64-decoding the stored value and deserializing it with a raw java.io.ObjectInputStream.readObject() and no ObjectInputFilter or class allow-list; the cast to KeyMetadata happens only after readObject() returns, so any readObject() side effects in a crafted object run before the type check. A principal who can write to the AWS Secrets Manager secret that holds this metadata (requiring secretsmanager:PutSecretValue on that secret) could store a crafted serialized object that is deserialized during normal key-lifecycle operations, potentially leading to code execution in the context of the application that manages the keys. This is the same underlying defect, in the same code path and remediated by the same fix, as CVE-2026-46590, which was reported independently and additionally covers the HashiCorp Vault and file-based sibling managers; both are incomplete-remediation follow-ons to CVE-2026-40048 (CAMEL-23200). This issue affects Apache Camel: from 4.18.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, restrict write access to the AWS Secrets Manager secret that holds the camel-pqc key metadata so that only the applications own identity holds secretsmanager:PutSecretValue on it (least-privilege IAM), and keep the PQC key material in a secret separate from any data that less-trusted principals can write. |
Camel
|
| CVE-2026-56140 | Jul 06, 2026 |
Apache Camel AWS SNS Improper Input Validation CVE-2026-56140Improper Input Validation vulnerability in Apache Camel AWS SNS component. The camel-aws2-sns component filters Camel headers through a component-specific HeaderFilterStrategy, Sns2HeaderFilterStrategy. Like the sibling Sqs2HeaderFilterStrategy, it originally configured only an outbound filter (setOutFilterPattern, which blocks Camel*, breadcrumbId and org.apache.camel.* headers from being written out) and did not configure an inbound filter rule. For the related camel-aws2-sqs component this inbound gap was exploitable, because the Sqs2Consumer maps inbound SQS message attributes into the Camel Exchange via HeaderFilterStrategy.applyFilterToExternalHeaders, allowing a message sender to inject Camel control headers (tracked as CVE-2026-46456). camel-aws2-sns, by contrast, is producer-only: Sns2Endpoint does not support consumers (createConsumer throws UnsupportedOperationException, 'You cannot receive messages from this endpoint'), so no externally-supplied message attributes are ever mapped inbound into a Camel Exchange through SNS, and the missing inbound filter rule on Sns2HeaderFilterStrategy was therefore not reachable by an attacker. As part of the same fix (CAMEL-23506), an inbound filter rule (setInFilterStartsWith for the Camel namespace) was added to Sns2HeaderFilterStrategy so that its configuration matches the corrected Sqs2HeaderFilterStrategy and the other sibling strategies. This is a defense-in-depth alignment with no known exploit path in camel-aws2-sns. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. This is a defense-in-depth hardening change with no known exploit path in camel-aws2-sns, which is producer-only, so no urgent action or workaround is required. Users who want the aligned behaviour can upgrade to version 4.21.0, or to 4.14.8 on the 4.14.x LTS releases stream, or to 4.18.3 on the 4.18.x releases stream, which contain the change. As a general best practice, operators should continue to apply least-privilege IAM permissions on their SNS topics. |
Camel
|
| CVE-2026-56139 | Jul 06, 2026 |
Apache Camel Undertown Stack Trace Leak before 4.21.0Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component. The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied. |
Camel
|
| CVE-2026-55994 | Jul 06, 2026 |
Apache Camel Iggy SSRF via unfiltered headers before 4.18.3Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Iggy component. The camel-iggy consumer mapped the user-headers of inbound Iggy messages into the Camel Exchange header map without applying any HeaderFilterStrategy (IggyFetchRecords copied the message user-headers straight into the Exchange). Because nothing blocked the Camel header namespace, an actor able to publish to the consumed Iggy stream/topic could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as message user-headers. In a route where the Iggy consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. This issue affects Apache Camel: from 4.17.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix adds a dedicated IggyHeaderFilterStrategy (and a headerFilterStrategy endpoint option) that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), restrict who can publish to the consumed Iggy stream/topic, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers. |
Camel
|
| CVE-2026-55993 | Jul 06, 2026 |
Apache Camel Atmosphere Websocket SSRF via Unfiltered Camel Headers <4.21.0Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Atmosphere Websocket Component. The camel-atmosphere-websocket consumer mapped inbound WebSocket query parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() iterates the query-string map collected in WebsocketConsumer.service() and copies each entry into the Exchange). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the consumer apply the HeaderFilterStrategy it already inherits from the HTTP/servlet stack, filtering the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers. |
Camel
|
| CVE-2026-53913 | Jul 06, 2026 |
Apache Camel Keycloak Auth Bypass in camel-keycloak v4.154.21Improper Authentication, Missing Authentication for Critical Function, Not Failing Securely ('Failing Open') vulnerability in Apache Camel Keycloak Component. The KeycloakSecurityPolicy of camel-keycloak guards a route by running KeycloakSecurityProcessor.beforeProcess(), which performs three checks in sequence: it rejects a request that carries no access token, then - only if requiredRoles is non-empty - validates the roles, and - only if requiredPermissions is non-empty - validates the permissions. The actual cryptographic verification of the bearer access token (signature, issuer and expiry for a local JWT, or active-state and issuer for token introspection) is performed exclusively inside those role and permission checks. KeycloakSecurityPolicy defaults requiredRoles and requiredPermissions to empty - which is the documented 'Basic Setup' - so on a route configured that way the role and permission checks are skipped and the access token is therefore never verified. The token-presence check still rejects a missing token, but an invalid token is accepted: any non-null value in the Authorization: Bearer header - including an arbitrary string or a forged, unsigned JWT - passes the policy and the request reaches the protected route, with no signature, issuer or expiry check and no request to Keycloak. The token is read from the inbound request header because allowTokenFromHeader defaults to true. Because the normal reason to place a route behind this policy is that the route performs server-side work, the bypass results in unauthenticated access to that work; where the protected route forwards to a code-execution-capable producer, it can result in unauthenticated remote code execution. This defect is independent of CVE-2026-23552: that issue concerned the issuer claim and was fixed by adding a check inside the verification routine, but here the verification routine is not reached at all in the default configuration, so the defect remains. This issue affects Apache Camel: from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy so that the token-verification path is exercised, set allowTokenFromHeader to false where the token is not expected from the request header, or perform token verification at the framework layer ahead of the policy. |
Camel
|
| CVE-2026-49365 | Jul 06, 2026 |
Apache Camel Netty HTTP: Stack Trace Leak via muteException (4.0.0-4.21.0)Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Netty HTTP component. The camel-netty-http HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false because the backing field was an uninitialised primitive boolean (Java's default of false), whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain (via DefaultNettyHttpBinding) instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-netty-http consumer (for example netty-http: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.netty-http.configuration.mute-exception=true property), so that processing errors no longer return the stack trace to the client. |
Camel
|