CVE-2026-42360 is a medium severity vulnerability in Apache Airflow affecting versions prior to 3.2.2. It involves exposure of sensitive information due to improper masking of nested sensitive keys (such as password, token, secret, api_key) in rendered JSON templates when the rendered field length exceeds a configured limit. Authenticated users with permission to read rendered template fields could access plaintext secret values that should have been masked. This issue is a variant of a previously addressed vulnerability (CVE-2025-68438) but affects nested key paths. Users should upgrade to Apache Airflow 3.2.2 or later to remediate this issue.
CVE-2026-42358 is a vulnerability in Apache Airflow where the Variable response masker fails to redact sensitive nested keys in deeply nested JSON values beyond a certain recursion depth. Authenticated users with Variable read permission can access plaintext secrets stored under deeply nested keys named with sensitive suffixes like 'password' or 'token'. This issue affects versions prior to 3.2.2 and is a residual gap from a previous fix that only addressed shallower nesting. Upgrading to Apache Airflow 3.2.2 or later mitigates this vulnerability.
CVE-2026-42359 is a high-severity vulnerability in Apache Airflow 3.2.0 affecting the XCom PATCH endpoint. It allows an authenticated user with XCom write permission to set entries under reserved keys, bypassing existing validation. This can lead to remote code execution (RCE) when the affected task defers to the triggerer. The issue is a bypass of a previous fix (CVE-2026-33858) because the PATCH endpoint lacked the forbidden key validation present in the POST endpoint. Users who upgraded for the previous CVE must upgrade to Apache Airflow 3.2.2 or later to fully mitigate this vulnerability.
CVE-2026-45426 is an authorization vulnerability in Apache Airflow 3.0.0 affecting the Log server's JWT token validation. The issue arises because the Log server uses Python's str.lstrip() to verify the JWT's subject claim against the requested Dag ID, which incorrectly strips characters rather than matching prefixes. This allows an authenticated Airflow worker with a valid Log-server JWT for one Dag to access logs of other Dags whose names share characters from the original Dag's name, potentially leaking task output and error traces. The vulnerability impacts deployments relying on per-Dag log-access scoping, such as multi-team or shared-worker setups. The CVSS score is 3.1 (low severity).
Apache Airflow versions prior to 3.2.2 contain an authorization bypass vulnerability in the Event Log detail endpoint. Authenticated users with audit-log read permission scoped to one Dag could access audit-log entries of other Dags by enumerating numeric event log IDs. This affects deployments relying on per-Dag audit-log scoping. The issue is addressed in Apache Airflow 3.2.2 and later versions.
A bug in Apache Airflow's auth manager logout handling left previously-issued JWT tokens valid after the user clicked logout in the UI: the logout flow for `FabAuthManager` and `KeycloakAuthManager` did not actually reach the underlying `revoke_token()` call, so the JWT remained accepted by the API server until its natural expiry. An attacker holding a previously-issued JWT for a logged-out user could continue to make authenticated API calls as that user. Affects deployments configured with `FabAuthManager` or `KeycloakAuthManager` (the bug does not affect SimpleAuthManager). This is a residual gap in the fix for CVE-2025-57735, which addressed cookie-side invalidation in PR #57992 / PR #61339 but did not cover the provider-side `revoke_token()` reachability in the FAB / Keycloak code paths. Users who already upgraded for CVE-2025-57735 should additionally upgrade to `apache-airflow` 3.2.2 or later to cover the FAB / Keycloak logout paths.
A bug in Apache Airflow's KubernetesExecutor caused JWT tokens used by worker pods to authenticate against the Execution API to be passed to the worker container as command-line arguments visible in the pod spec. An authenticated UI/API user with Kubernetes read-only access to the cluster (e.g. `pods/get` in the Airflow namespace) could harvest the JWT from `kubectl describe pod` output and then call state-mutating Execution API endpoints — triggering Dag runs, clearing runs, reading or writing Variables / Connections / XComs — as if they were a running task. Affects deployments using the `KubernetesExecutor`. Users are advised to upgrade to `apache-airflow` 3.2.2 or later. This is the airflow-core half of the same vulnerability addressed by [CVE-2026-27173](https://www.cve.org/CVERecord?id=CVE-2026-27173), which shipped the apache-airflow-providers-cncf-kubernetes side of the fix. Deployments that already upgraded `apache-airflow-providers-cncf-kubernetes` to 10.17.0 or later per the CVE-2026-27173 advisory should additionally upgrade `apache-airflow` to 3.2.2 or later to close the core-side surface — the two fixes are complementary, not duplicates.
Apache ActiveMQ contains a cross-site scripting (XSS) vulnerability in its web console API's MessageServlet. The servlet copies JMS message properties into HTTP response headers without validation, allowing potential injection or overwriting of security headers. This affects Apache ActiveMQ versions before 5.19.7 and versions from 6.0.0 before 6.2.6. The vulnerability has a medium severity rating with a CVSS score of 6.1. The MessageServlet has been deprecated and disabled by default in fixed versions. Users are advised to upgrade to Apache ActiveMQ 5.19.7 or 6.2.6 or later to remediate this issue.
Apache ActiveMQ versions before 5.19.7 and from 6.0.0 before 6.2.6 have an incorrect default permissions vulnerability in the Jolokia authorization settings. This misconfiguration allows low-privilege web-login users to perform broker management operations intended only for administrators, such as adding or removing queues. The issue is addressed in versions 5.19.7 and 6.2.6.
Apache ActiveMQ Broker versions before 5.19.7 and from 6.0.0 before 6.2.6 have a vulnerability that allows unauthenticated attackers to obtain sensitive metadata about durable topic subscriptions. This includes client identifiers, subscription names, topic destinations, and JMS selector expressions. The issue arises when brokers are configured with a network connector with syncDurableSubs set to true and respond to BrokerInfo commands without verifying authentication. Upgrading to versions 5.19.7 or 6.2.6 resolves this vulnerability.
Apache Directory LDAP API version 2.0.0 contains a vulnerability where the LDAP client does not verify that the server certificate matches the intended LDAP hostname. Although the certificate chain is validated against trusted authorities, the lack of endpoint identification allows acceptance of valid certificates issued for unrelated hosts. This flaw enables potential server impersonation and connection compromise if an attacker can perform a man-in-the-middle attack with a trusted certificate. Hostname verification has been enforced in newer versions of the LDAP API.
A vulnerability in Apache Airflow's REST API endpoint /api/v2/connections/{connection_id} allows authenticated users with Connection-read permission to access sensitive credential information stored in the Connection's extra JSON blob if the field names are not in the redaction allowlist. This affects deployments that store credentials in the extra field and grant read access to multiple users. The issue is fixed in Apache Airflow version 3.2.2 and later. Operators are advised to upgrade and consider storing sensitive credentials in a secret backend as a defense-in-depth measure.
A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission.
This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.54.0, which fixes the issue.
A Relative Path Traversal vulnerability (CWE-23) exists in the Apache Ignite REST API that allows authenticated users to read arbitrary files on the server by exploiting the "cmd=log" command with a specially crafted log path. This affects Apache Ignite versions from 2.0.0 through 2.17.0. The issue is fixed in version 2.18.0. The vulnerability has a high severity with a CVSS 4.0 base score of 8.5.
Files or Directories Accessible to External Parties, Server-Side Request Forgery (SSRF) vulnerability in Apache Flink Kubernetes Operator.
The FlinkSessionJob jarURI is currently not validated so that it points to user-owned files or addresses. This lets a user with CR create permissions read files from the operator pod's filesystem and pull content from any backing store reachable through Flink's pluggable filesystem layer and access them through the submitted Flink job. Furthermore for fetching from http/https addresses there is currently no allowlist on the URI scheme, no host check, no IP-range restriction, and no protection against pointing the URI at internal or link-local addresses.This issue affects Apache Flink Kubernetes Operator: from 1.3.0 before 1.15.0.
Users are recommended to upgrade to version 1.15.0, which fixes the issue.
With valid login credentials, URL Redirection to Untrusted Site ('Open Redirect'), Server-Side Request Forgery (SSRF) vulnerability in Apache Shiro. This issue affects Apache Shiro from 2.0-alpha to 2.1.0, and 3.0.0-alpha-1, only when using shiro-jakarta-ee integration module. Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue by encrypting the cookie. After successful login, Jakarta EE integration module uses shiroSavedRequest cookie to redirect to a particular web page after login. This cookie was not validated, and can be forged to send a HTTP GET request from the server itself to an arbitrary URL from the cookie.
Default configurations of Apache Shiro send sensitive cookies in HTTPS session without 'Secure' attribute. This issue affects Apache Shiro from 1.0 to 2.1.0, and 3.0.0-alpha-1. Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue. In the affected versions, Shiro-native session manager, as well as Remember-Me manager sends JSESSIONID and rememberMe cookies without 'secure' attribute by default.
Apache Shiro versions 1.0, 3.0.0-alpha, and up to 2.1.0 have a session fixation vulnerability in their default configurations. The issue occurs because existing sessions are not invalidated nor replaced with new session IDs upon successful login. This vulnerability allows an attacker to fixate a user's session ID, potentially leading to unauthorized session use. The vulnerability is fixed in Apache Shiro versions 2.1.1 and 3.0.0-alpha-2 or later.
Apache Syncope contains a vulnerability that allows exposure of sensitive information through crafted data queries. Specifically, an administrator with entitlements to manage Derived Schemas can create malicious JEXL expressions. These expressions enable any administrator with User read entitlements to access security-sensitive user information. The issue affects Apache Syncope versions 3.0 through 3.0.16, 4.0 through 4.0.5, and 4.1.0. Upgrading to versions 4.0.6 or 4.1.1 mitigates this vulnerability by restricting JEXL expression definitions.
Apache Syncope versions 3.0 through 3.0.16, 4.0 through 4.0.5, and 4.1.0 contain an improper isolation vulnerability. An administrator with sufficient privileges can create malicious Groovy code that executes outside the intended sandbox, including static initializers. This can lead to unauthorized code execution with high impact on confidentiality, integrity, and availability. Fixed versions 4.0.6 and 4.1.1 enforce sandboxing even for static initializers in Groovy code.