Filtered by vendor Apache
Subscriptions
Filtered by product Airflow
Subscriptions
Total
146 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-45192 | 1 Apache | 1 Airflow | 2026-06-01 | 6.5 Medium |
| A bug in the GET `/api/v2/connections/{connection_id}` REST API endpoint in Apache Airflow allowed an authenticated UI/API user with Connection-read permission to retrieve secrets stored in a Connection's `extra` JSON blob under field names not present in the redaction allowlist (`DEFAULT_SENSITIVE_FIELDS`) — for example, official Slack-provider credential field names were returned in plaintext. Affects deployments that store credentials in Connection `extra` blobs and grant Connection-read access to multiple users. Users are advised to upgrade to `apache-airflow` 3.2.2 or later. As a defense-in-depth mitigation, deployment operators can store sensitive credential values in a secret-backend rather than inlined into the Connection's `extra` field. | ||||
| CVE-2026-40963 | 1 Apache | 1 Airflow | 2026-06-01 | 3.1 Low |
| The structure_data endpoint in the Airflow UI returned external dependency graph nodes for linked Dags without checking whether the caller had read permission on those linked Dags. An authenticated UI/API user authorized for one Dag could enumerate linked Dag IDs and dependency metadata for other Dags they were not authorized to read. Affects deployments that rely on per-Dag read scoping to keep Dag dependency topology private across teams. Users are advised to upgrade to `apache-airflow` 3.2.2 or later. | ||||
| CVE-2026-42360 | 1 Apache | 1 Airflow | 2026-06-01 | 6.5 Medium |
| A bug in Apache Airflow's rendered-template field handling caused nested sensitive-key masking (e.g. nested `password` / `token` / `secret` / `api_key` keys inside a JSON template structure) to be bypassed when the rendered field exceeded `[core] max_templated_field_length`: Airflow stringified the structure before redaction, losing the nested key context, and persisted the plaintext value into `rendered_fields`. An authenticated UI/API user with permission to read rendered template fields could harvest secret values intended to be masked. Affects deployments where Dag authors pass structured JSON to operators with nested sensitive keys. This is a variant of `CWE-200` previously addressed for the user-registered `mask_secret()` patterns in CVE-2025-68438; that fix did not cover the nested sensitive-keyword allowlist. Users who already upgraded for CVE-2025-68438 should additionally upgrade to `apache-airflow` 3.2.2 or later to cover the nested-key path. | ||||
| CVE-2026-40948 | 1 Apache | 2 Airflow, Apache-airflow-providers-keycloak | 2026-05-11 | 5.4 Medium |
| The Keycloak authentication manager in `apache-airflow-providers-keycloak` did not generate or validate the OAuth 2.0 `state` parameter on the login / login-callback flow, and did not use PKCE. An attacker with a Keycloak account in the same realm could deliver a crafted callback URL to a victim's browser and cause the victim to be logged into the attacker's Airflow session (login-CSRF / session fixation), where any credentials the victim subsequently stored in Airflow Connections would be harvestable by the attacker. Users are advised to upgrade `apache-airflow-providers-keycloak` to 0.7.0 or later. | ||||
| CVE-2026-41016 | 1 Apache | 2 Airflow, Airflow Providers Smtp | 2026-05-01 | 5.9 Medium |
| Apache Airflow's SMTP provider `SmtpHook` called Python's `smtplib.SMTP.starttls()` without an SSL context, so no certificate validation was performed on the TLS upgrade. A man-in-the-middle between the Airflow worker and the SMTP server could present a self-signed certificate, complete the STARTTLS upgrade, and capture the SMTP credentials sent during the subsequent `login()` call. Users are advised to upgrade to the `apache-airflow-providers-smtp` version that contains the fix. | ||||
| CVE-2026-40690 | 1 Apache | 1 Airflow | 2026-04-27 | 4.3 Medium |
| The asset dependency graph did not restrict nodes by the viewer's DAG read permissions: a user with read access to at least one DAG could browse the asset graph for any other asset in the deployment and learn the existence and names of DAGs and assets outside their authorized scope. Users are recommended to upgrade to version 3.2.1, which fixes this issue. | ||||
| CVE-2026-38743 | 1 Apache | 1 Airflow | 2026-04-27 | 4.3 Medium |
| The authenticated /ui/dags endpoint did not enforce per-DAG access control on embedded Human-in-the-Loop (HITL) and TaskInstance records: a logged-in Airflow user with read access to at least one DAG could retrieve HITL prompts (including their request parameters) and full TaskInstance details for DAGs outside their authorized scope. Because HITL prompts and TaskInstance fields routinely carry operator parameters and free-form context attached to a task, the leak widens visibility of DAG-run data beyond the intended per-DAG RBAC boundary for every authenticated user. Users are recommended to upgrade to version 3.2.1 , which fixes this issue. | ||||
| CVE-2026-25917 | 1 Apache | 1 Airflow | 2026-04-22 | 7.2 High |
| Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue. | ||||
| CVE-2026-30898 | 1 Apache | 1 Airflow | 2026-04-22 | 8.8 High |
| 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. Users should review if any of their own DAGs have adopted this incorrect advice. | ||||
| CVE-2026-30912 | 1 Apache | 1 Airflow | 2026-04-21 | 7.5 High |
| 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 recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue. | ||||
| CVE-2026-32690 | 1 Apache | 1 Airflow | 2026-04-21 | 3.7 Low |
| Secrets in Variables saved as JSON dictionaries were not properly redacted - in case thee variables were retrieved by the user the secrets stored as nested fields were not masked. If you do not store variables with sensitive values in JSON form, you are not affected. Otherwise please upgrade to Apache Airflow 3.2.0 that has the fix implemented | ||||
| CVE-2026-32228 | 1 Apache | 1 Airflow | 2026-04-21 | 7.5 High |
| UI / API User with asset materialize permission could trigger dags they had no access to. Users are advised to migrate to Airflow version 3.2.0 that fixes the issue. | ||||
| CVE-2026-31987 | 1 Apache | 1 Airflow | 2026-04-20 | 7.5 High |
| 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, which fixes this issue. | ||||
| CVE-2025-54550 | 1 Apache | 1 Airflow | 2026-04-19 | 8.1 High |
| 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 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. | ||||
| CVE-2026-22922 | 1 Apache | 1 Airflow | 2026-04-17 | 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-2025-66236 | 1 Apache | 1 Airflow | 2026-04-17 | 7.5 High |
| Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4]. [1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/ Users are recommended to upgrade to version 3.2.0, which fixes this issue. | ||||
| CVE-2026-33858 | 1 Apache | 1 Airflow | 2026-04-17 | 8.8 High |
| Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low. Users are recommended to upgrade to Apache Airflow 3.2.0, which resolves this issue. | ||||
| CVE-2026-25219 | 1 Apache | 1 Airflow | 2026-04-17 | 6.5 Medium |
| 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 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.8 | ||||
| CVE-2025-57735 | 1 Apache | 1 Airflow | 2026-04-17 | 9.1 Critical |
| When user logged out, the JWT token the user had authtenticated with was not invalidated, which could lead to reuse of that token in case it was intercepted. In Airflow 3.2 we implemented the mechanism that implements token invalidation at logout. Users who are concerned about the logout scenario and possibility of intercepting the tokens, should upgrade to Airflow 3.2+ Users are recommended to upgrade to version 3.2.0, which fixes this issue. | ||||
| CVE-2026-24098 | 1 Apache | 1 Airflow | 2026-04-16 | 6.5 Medium |
| Apache Airflow versions 3.0.0 - 3.1.7, has vulnerability that allows authenticated UI users with permission to one or more specific Dags to view import errors generated by other Dags they did not have access to. Users are advised to upgrade to 3.1.7 or later, which resolves this issue | ||||