CVE-2026-41084: Apache Airflow Task Instances API Authorization Bypass

Technical summary

The bulk Task Instances API endpoints (`PATCH` and `DELETE` operations on `/api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances`) contain an authorization bypass vulnerability classified as improper access control (CWE-639). The vulnerability stems from a logic error in which the authorization framework validates permissions against the `dag_id` and `dag_run_id` extracted from the URL path, while the actual mutation operations are performed on entities specified by `dag_id` and `dag_run_id` fields in the request body JSON payload. An authenticated attacker can construct a request that includes an authorized DAG in the URL path while embedding a target DAG's identifiers in the request body, causing the API to modify task instances in the target DAG without performing permission checks against it. This breaks the per-DAG authorization model that Airflow deployments commonly use to enforce team-level isolation.

Business impact

Organizations using Airflow's DAG-level permissions to enforce operational boundaries—such as separating task execution controls between teams, departments, or customer environments—face significant risk from this vulnerability. An insider or compromised account with edit access to a non-critical workflow can covertly manipulate task states across the entire Airflow deployment, including critical production DAGs. Potential consequences include: silent task failures masked to hide operational incidents, unauthorized task re-runs that consume resources or trigger downstream systems, state corruption that undermines audit trails and compliance records, and cross-team interference that erodes trust in multi-tenant or multi-team Airflow deployments. The impact is particularly severe in regulated environments where task execution integrity and audit logging are compliance requirements.

Affected systems

Apache Airflow versions prior to 3.2.2 are vulnerable. The flaw affects any Airflow deployment that relies on the REST API v2 for programmatic task management and uses per-DAG edit permissions to enforce access control. Deployments are at risk if: (1) multiple teams or entities share a single Airflow cluster with distinct DAG edit scopes, (2) the bulk Task Instances API endpoints are exposed to authenticated users (including the web UI), or (3) Airflow's default authorization model is used without additional external access controls. Single-team or air-gapped deployments without multi-tenant isolation requirements may have lower exposure.

Exploitability

The vulnerability requires an authenticated user (not anonymous) and a valid edit permission on at least one DAG within the target Airflow instance. No special privilege escalation is needed—a regular UI or API user with baseline editing rights can exploit it. The attack surface is broad: exploitation can occur via the REST API or indirectly through the web UI if it calls the affected endpoints. No client-side complexity or race conditions are required; the exploit is deterministic and repeatable. The barrier to exploitation is low for insiders or accounts whose credentials have been compromised, making this a credible risk in multi-team environments.

Remediation

Upgrade Apache Airflow to version 3.2.2 or later. The patch corrects the authorization logic to enforce permission checks against the actual DAG and DAG run being modified, not just the URL path parameters. Administrators should prioritize patching Airflow instances that support multiple teams, expose the REST API, or manage sensitive workflows. During the patching window, monitor API access logs for unusual bulk task modification requests (especially those with mismatched dag_id values between URL and request body), and restrict API access to trusted internal networks if feasible.

Patch guidance

Verify that your Airflow deployment is running a version prior to 3.2.2 by checking the version output (e.g., `airflow version`). Review the Apache Airflow release notes and security advisories for version 3.2.2 to confirm the patch scope and any breaking changes. Test the upgrade in a non-production environment first, paying particular attention to REST API v2 functionality and task state mutation workflows. After upgrading, confirm that DAG-level permission enforcement is working as expected by attempting a cross-DAG task modification with a limited-permission account (should fail post-patch). Roll out the patch across all Airflow instances, prioritizing those with multi-tenant or team-based isolation requirements.

Detection guidance

Search Airflow API access logs for `PATCH` or `DELETE` requests to `/api/v2/dags/*/dagRuns/*/taskInstances` where the `dag_id` in the URL path differs from the `dag_id` in the request body JSON payload. Monitor for task state changes (e.g., mark-failed, mark-success, clear) attributed to users or service accounts that should not have permission on the modified DAG. Review Airflow's task instance audit logs for unexplained state transitions, particularly in sensitive or isolated workflows. Consider implementing a Web Application Firewall (WAF) rule that validates consistency between URL parameters and request body fields for these endpoints before the patch is applied.

Why prioritize this

This vulnerability warrants immediate attention because it undermines access control in multi-team Airflow deployments without requiring privilege escalation or advanced exploitation techniques. The attack surface includes any authenticated API user, and the impact directly violates expected isolation boundaries. Organizations that rely on per-DAG permissions for operational security or compliance (e.g., separating production from test environments, or isolating customer data) should treat this as a critical remediation item. The June 2026 publication date and availability of a clear fix (version 3.2.2) support prompt patching.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible vulnerability with no special complexity, requiring only basic authentication and resulting in high integrity impact (unauthorized task state modification). The attack vector is unauthenticated-network-accessible; however, the PR (Privileges Required) field is set to 'None' in the severity vector, indicating that the flaw affects authenticated users broadly without elevation. The integrity impact is rated high because task state is a critical operational control, while confidentiality and availability impacts are none. The score appropriately captures a serious but not critical vulnerability; the actual risk to a specific organization depends heavily on how Airflow is deployed and whether multi-DAG isolation is a security boundary.

Frequently asked questions