In case of SQL errors, exception/stack trace of errors was exposed in API even if "api/expose_stack_traces" was set to false. That could lead to exposing additional information to potential attacker. Users are recommende...Show moreIn case of SQL errors, exception/stack trace of errors was exposed in API even if "api/expose_stack_traces" was set to false. That could lead to exposing additional information to potential attacker. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue.Show less |
An example of BashOperator in Airflow documentation suggested a way of passing dag_run.conf in the way that could cause unsanitized user input to be used to escalate privileges of UI user to allow execute code on worker....Show moreAn example of BashOperator in Airflow documentation suggested a way of passing dag_run.conf in the way that could cause unsanitized user input to be used to escalate privileges of UI user to allow execute code on worker. Users should review if any of their own DAGs have adopted this incorrect advice.Show less |
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 th...Show moreDag 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 fixes the issue.Show less |
JWT Tokens used by tasks were exposed in logs. This could allow UI users to act as Dag Authors.
Users are advised to upgrade to Airflow version that contains fix.
Users are recommended to upgrade to version 3.2.0, whic...Show moreJWT Tokens used by tasks were exposed in logs. This could allow UI users to act as Dag Authors.
Users are advised to upgrade to Airflow version that contains fix.
Users are recommended to upgrade to version 3.2.0, which fixes this issue.Show less |
The `access_key` and `connection_string` connection properties were not marked as sensitive names in secrets masker. This means that user with read permission could see the values in Connection UI, as well as when Connec...Show moreThe `access_key` and `connection_string` connection properties were not marked as sensitive names in secrets masker. This means that user with read permission could see the values in Connection UI, as well as when Connection was accidentaly logged to logs, those values could be seen in the logs. Azure Service Bus used those properties to store sensitive values. Possibly other providers could be also affected if they used the same fields to store sensitive data.
If you used Azure Service Bus connection with those values set or if you have other connections with those values storing sensitve values, you should upgrade Airflow to 3.1.8Show less |
The SkyWalking OAP /debugging/config/dump endpoint may leak sensitive configuration information of MySQL/PostgreSQL.
This issue affects Apache SkyWalking: from 9.7.0 through 10.3.0.
Users are recommended to upgrade to...Show moreThe SkyWalking OAP /debugging/config/dump endpoint may leak sensitive configuration information of MySQL/PostgreSQL.
This issue affects Apache SkyWalking: from 9.7.0 through 10.3.0.
Users are recommended to upgrade to version 10.4.0, which fixes the issue.Show less |
The example example_xcom that was included in airflow documentation implemented unsafe pattern of reading value
from xcom in the way that could be exploited to allow UI user who had access to modify XComs to perform arbi...Show moreThe example example_xcom that was included in airflow documentation implemented unsafe pattern of reading value
from xcom in the way that could be exploited to allow UI user who had access to modify XComs to perform arbitrary
execution of code on the worker. Since the UI users are already highly trusted, this is a Low severity vulnerability.
It does not affect Airflow release - example_dags are not supposed to be enabled in production environment, however
users following the example could replicate the bad pattern. Documentation of Airflow 3.2.0 contains version of
the example with improved resiliance for that case.
Users who followed that pattern are advised to adjust their implementations accordingly.Show less |
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache PDFBox Examples.
This issue affects the
ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36,...Show moreImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache PDFBox Examples.
This issue affects the
ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36, from 3.0.0 through 3.0.7.
Users are recommended to update to version 2.0.37 or 3.0.8 once
available. Until then, they should apply the fix provided in GitHub PR
427.
The ExtractEmbeddedFiles example contained a path traversal vulnerability (CWE-22) mentioned in CVE-2026-23907. However the change in the releases 2.0.36 and 3.0.7 is flawed because it doesn't consider the file path separator. Because of that, a user having writing rights on /home/ABC could be victim to a malicious PDF resulting in a write attempt to any path starting with /home/ABC, e.g. "/home/ABCDEF".
Users who have copied this example into their production code should apply the mentioned change. The example
has been changed accordingly and is available in the project repository.Show less |
Cleartext Transmission of Sensitive Information vulnerability in Apache APISIX.
tencent-cloud-cls log export uses plaintext HTTP
This issue affects Apache APISIX: from 2.99.0 through 3.15.0.
Users are recommended to up...Show moreCleartext Transmission of Sensitive Information vulnerability in Apache APISIX.
tencent-cloud-cls log export uses plaintext HTTP
This issue affects Apache APISIX: from 2.99.0 through 3.15.0.
Users are recommended to upgrade to version 3.16.0, which fixes the issue.Show less |
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:...Show moreCleartext 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.Show less |
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....Show moreHeader 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.Show less |
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 th...Show moreDag 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.Show less |
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 De...Show moreBefore 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.Show less |
Server-Side Request Forgery via SW-URL Header vulnerability in Apache SkyWalking MCP.
This issue affects Apache SkyWalking MCP: 0.1.0.
Users are recommended to upgrade to version 0.2.0, which fixes this issue. |
Stored Cross-Site Scripting (XSS) via Unsanitized Topology Metadata in Apache Storm UI
Versions Affected: before 2.8.6
Description: The Storm UI visualization component interpolates topology metadata including compon...Show moreStored Cross-Site Scripting (XSS) via Unsanitized Topology Metadata in Apache Storm UI
Versions Affected: before 2.8.6
Description: The Storm UI visualization component interpolates topology metadata including component IDs, stream names, and grouping values directly into HTML via innerHTML in parseNode() and parseEdge() without sanitization at any layer. An authenticated user with topology submission rights could craft a topology containing malicious HTML/JavaScript in component identifiers (e.g., a bolt ID containing an onerror event handler). This payload flows through Nimbus → Thrift → the Visualization API → vis.js tooltip rendering, resulting in stored cross-site scripting.
In multi-tenant deployments where topology submission is available to less-trusted users but the UI is accessed by operators or administrators, this enables privilege escalation through script execution in an admin's browser session.
Mitigation: 2.x users should upgrade to 2.8.6. Users who cannot upgrade immediately should monkey-patch the parseNode() and parseEdge() functions in the visualization JavaScript file to HTML-escape all API-supplied values including nodeId, :capacity, :latency, :component, :stream, and :grouping before interpolation into tooltip HTML strings, and should additionally restrict topology submission to trusted users via Nimbus ACLs as a defense-in-depth measure. A guide on how to do this is available in the release notes of 2.8.6.
Credit: This issue was discovered while investigating another report by K.Show less |
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-en...Show moreDeserialization 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.Show less |
Apache Log4cxx's XMLLayout https://logging.apache.org/log4cxx/1.7.0/classlog4cxx_1_1xml_1_1XMLLayout.html , in versions before 1.7.0, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.o...Show moreApache Log4cxx's XMLLayout https://logging.apache.org/log4cxx/1.7.0/classlog4cxx_1_1xml_1_1XMLLayout.html , in versions before 1.7.0, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in log messages, NDC, and MDC property keys and values, producing invalid XML output. Conforming XML parsers must reject such documents with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
An attacker who can influence logged data can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4cxx 1.7.0, which fixes this issue.Show less |
Apache Log4net's XmlLayout https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list and XmlLayoutSchemaLog4J https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list , i...Show moreApache Log4net's XmlLayout https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list and XmlLayoutSchemaLog4J https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list , in versions before 3.3.0, fail to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in MDC property keys and values, as well as the identity field that may carry attacker-influenced data. This causes an exception during serialization and the silent loss of the affected log event.
An attacker who can influence any of these fields can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4net 3.3.0, which fixes this issue.Show less |
Apache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-...Show moreApache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (NaN, Infinity, or -Infinity), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.
An attacker can exploit this issue only if both of the following conditions are met:
* The application uses JsonTemplateLayout.
* The application logs a MapMessage, or logs an object directly (e.g., via Logger.info(Object), which wraps it in an ObjectMessage), where the message contains an attacker-controlled floating-point value.
Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue.
Note: The fix released in version 2.25.4 did not cover all affected code paths. CVE-2026-49844 was assigned to the remaining issue, which concerns the MapMessage.asJson() serialization in Apache Log4j API and is fixed in versions 2.25.5 and 2.26.1.Show less |
Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www...Show moreApache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters.
The impact depends on the StAX implementation in use:
* JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.
* Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.Show less |