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 …
A bug in the login redirect route in Apache Airflow allowed authenticated users to craft URLs that bypassed the is_safe_url check, enabling redirection from a trusted Airflow domain to an attacker-controlled origin. Users are advised to upgrade to apache-airflow 3.2.2 or later. As a defense-in-depth mitigation, deployment operators can place Airflow behind a reverse proxy that strips off-domain next= query parameters before they reach the login endpoint.
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. …
Apache Airflow's official documentation at core-concepts/dag-run.html ("Passing Parameters when triggering Dags") showed a verbatim BashOperator(bash_command="echo value: {{ dag_run.conf['conf1'] }}") example without any quoting / sanitization warning. Dag authors who copied the pattern verbatim into deployments where users had Dag.can_trigger permission on the affected Dag (typical multi-team deployments, hosted offerings exposing a trigger API) could be exposed to shell-metacharacter injection via the conf field of the trigger API: an authenticated trigger …
A bug in Apache Airflow's Variable response masker caused nested-key redaction (triggered by secret-suffixed key names like password, token, secret, api_key) to be bypassed when the JSON value's nesting depth exceeded the shared secrets masker's recursion limit: the masker returned the original nested item before checking the sensitive key name. An authenticated UI/API user with Variable read permission could harvest plaintext secret values stored under sensitive keys nested deep enough …
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 …
Apache Airflow's scheduler-side deadline-reference decoder (SerializedCustomReference.deserialize_reference) imported and dispatched arbitrary class paths drawn from DAG-author-controlled serialized state without an allowlist or plugin-registry gate. A DAG author whose code reaches the scheduler — the default on single-host deployments where the DAG bundle is importable from the scheduler process — could embed a custom DeadlineReference whose serialized form named an attacker-controlled module path, causing the scheduler to import_string(…) and instantiate that class …
A bug in Apache Airflow's bulk Task Instances API (PATCH/DELETE /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances) evaluated authorization against the dag_id resolved from the URL path while operating on the dag_id / dag_run_id extracted from request-body entity fields. An authenticated UI/API user with edit permission on one Dag could mutate Task Instance state in any other Dag by keeping the authorized Dag's ID in the URL path and naming the target Dag's IDs in the …
Apache Airflow's EmailOperator and the underlying airflow.utils.email helpers established SMTP STARTTLS connections without verifying the remote certificate when the deployment used [email] smtp_starttls=True without [email] smtp_ssl. An attacker positioned between the worker and the configured SMTP server (network MITM — typical hostile-network attack-surface for environments where the SMTP relay sits outside the worker's trust boundary) could present a self-signed certificate, have the worker complete the STARTTLS handshake silently, and capture …
Exploitation requires the attacker to already be an authenticated Airflow worker holding a valid Log-server JWT issued for at least one Dag. Apache Airflow's Log server authorized JWT tokens against Dag IDs by applying Python's str.lstrip() to the requested path segment when verifying the JWT's sub claim. str.lstrip() strips any of a set of characters from the left (not a prefix), so a JWT issued for a Dag named e.g. …
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 …
The Event Log detail endpoint GET /api/v2/eventLogs/{event_log_id} in Apache Airflow fetched audit-log rows directly by numeric ID after only the generic Audit Log permission check, while the collection endpoint GET /api/v2/eventLogs applied per-Dag scoping. An authenticated UI/API user with audit-log read permission for one Dag could retrieve audit-log entries for any other Dag by guessing or enumerating the numeric event log ID. Affects deployments that rely on per-Dag audit-log scoping. …
Apache Airflow's JWTRefreshMiddleware set the JWT auth cookie without the Secure flag, so deployments running the Airflow API server behind an HTTPS-terminating reverse proxy (e.g. nginx / Envoy / a managed load balancer that terminates TLS and forwards plaintext to the API server, the default cloud-native topology) would have the user's session JWT replayed over any cleartext HTTP request to the same host. A network-positioned attacker (Wi-Fi MITM, hostile LAN, …
The partitioned_dag_runs endpoints in the Airflow UI enforced only asset-level access control, not per-Dag authorization. An authenticated UI/API user with global Asset:read permission could enumerate partition run state, schedule configuration, and asset wiring for Dags they were not authorized to read. Affects deployments that rely on per-Dag read scoping while granting users broader Asset access. Users are advised to upgrade to apache-airflow 3.2.2 or later.
A Dag author could either (a) create a symlink under their task's log directory pointing to an arbitrary file readable by the API server process (read-path attack — e.g. /etc/passwd or airflow.cfg) or (b) supply a task_id containing .. sequences accepted by the Task SDK's KEY_REGEX (write-path attack), and in both cases the FileTaskHandler resolves the log path outside the configured base_log_folder, leaking or overwriting arbitrary files. Only affects deployments …
A bug in Apache Airflow's XCom PATCH endpoint PATCH /api/v2/xcomEntries/{key} allowed an authenticated UI/API user with XCom write permission on a Dag to set XCom entries under reserved key names (e.g. return_value) that the matching POST endpoint already validated against FORBIDDEN_XCOM_KEYS. The endpoint also accepted serialized payload shapes the triggerer's deserializer treats as code; combined, this allowed RCE on the triggerer when the affected task next deferred. Affects deployments where …
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 …
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.
Secrets in Variables saved as JSON dictionaries were not properly redacted - in case the variables were retrieved by the user the secrets stored as nested fields were not masked. If developers do not store variables with sensitive values in JSON form, their projects are not affected. Otherwise upgrade to the fixed version, Apache Airflow 3.2.0.
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 …
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.
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 accidently 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 …
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.
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, workload isolation, and JWT authentication details are now described in …
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 …
Apache Airflow versions 3.0.0 through 3.1.8 DagRun wait endpoint returns XCom result values even to users who only have DAG Run read permissions, such as the Viewer role.This behavior conflicts with the FAB RBAC model, which treats XCom as a separate protected resource, and with the security model documentation that defines the Viewer role as read-only. Airflow uses the FAB Auth Manager to manage access control on a per-resource basis. …
Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice. This issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0. Users are recommended to upgrade to version 1.12.0, which fixes the issue.
Apache Airflow versions 3.0.0 through 3.1.7 FastAPI DagVersion listing API does not apply per-DAG authorization filtering when the request is made with dag_id set to "~" (wildcard for all DAGs). As a result, version metadata of DAGs that the requester is not authorized to access is returned. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Apache Airflow versions 3.1.0 through 3.1.7 session token (_token) in cookies is set to path=/ regardless of the configured [webserver] base_url or [api] base_url. This allows any application co-hosted under the same domain to capture valid Airflow session tokens from HTTP request headers, allowing full session takeover without attacking Airflow itself. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Apache Airflow versions 3.1.0 through 3.1.7 missing authorization vulnerability in the Execution API's Human-in-the-Loop (HITL) endpoints that allows any authenticated task instance to read, approve, or reject HITL workflows belonging to any other task instance. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Apache Airflow versions 3.1.0 through 3.1.7 /ui/dependencies endpoint returns the full DAG dependency graph without filtering by authorized DAG IDs. This allows an authenticated user with only DAG Dependencies permission to enumerate DAGs they are not authorized to view. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
DAG Author (who already has quite a lot of permissions) could manipulate database of Airflow 2 in the way to execute arbitrary code in the web-server context, which they should normally not be able to do, leading to potentially remote code execution in the context of web-server (server-side) as a result of a user viewing historical task information. The functionality responsible for that (log template history) has been disabled by …
Airflow versions before 2.11.1 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive connection parameters were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to …
When a DAG failed during parsing, Airflow’s error-reporting in the UI could include the full kwargs passed to the operators. If those kwargs contained sensitive values (such as secrets), they might be exposed in the UI tracebacks to authenticated users who had permission to view that DAG. The issue has been fixed in Airflow 3.1.5rc1 and 2.11.1, and users are strongly advised to upgrade to prevent potential disclosure of sensitive …
Exposure of Sensitive Information: An information disclosure vulnerability exists in the Apache Airflow UI that allows authenticated users to view Import Errors for DAGs they are not authorized to access. In affected versions, the Import Errors view does not correctly filter errors based on granular DAG permissions. This means a user with access to only DAG_A can view import errors generated by DAG_B, DAG_C, or system-level DAGs. These error logs …
Confidentiality Loss: Task logs often contain sensitive operational data, debugging information, or potentially leaked secrets (environment variables, connection strings) that should not be visible to all users with basic task access. Broken Access Control: This bypasses the intended security model for restricted user roles.
In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] max_templated_field_length, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered mask_secret() patterns, so secrets were not reliably masked before truncation and display. Users are recommended to upgrade to 3.1.6 or later, which fixes this issue
In Apache Airflow versions before 3.1.6, and 2.11.1 the proxies and proxy fields within a Connection may include proxy URLs containing embedded authentication information. These fields were not treated as sensitive by default and therefore were not automatically masked in log output. As a result, when such connections are rendered or printed to logs, proxy credentials embedded in these fields could be exposed. Users are recommended to upgrade to 3.1.6 …