Summary
Apache Airflow's asset queued-events DELETE endpoints authorize callers with Dag read permission instead of edit permission. An authenticated user who can read a Dag may therefore delete its queued asset events, potentially suppressing asset-triggered scheduling when that feature is in use.
Affected context
The vulnerability occurs in Apache Airflow deployments that use asset-triggered scheduling and expose Dag read access more broadly than Dag edit access. In these environments, the asset queued-events DELETE endpoints may treat read permission as sufficient for an operation that changes scheduling-related state.
Exploit preconditions
- Attack surface: Apache Airflow asset queued-events DELETE endpoints
- Required access: An authenticated account with read permission for the target Dag
- Trigger point: A request that deletes queued asset events associated with that Dag
- Why exploitation is possible: The endpoint checks
READpermission even though deleting queued events is a state-changing action that should requireEDITauthorization
Why this happens
The underlying bug is an authorization-boundary failure mapped to CWE-863: Incorrect Authorization. A state-changing endpoint performs a permission check against a read-only Dag capability, allowing the caller's ability to view a resource to be treated as authority to modify its scheduling-related state.
Potential impact
- An authenticated user could delete queued asset events for a Dag they can read.
- Asset-triggered Dag scheduling may be silently suppressed or delayed.
- Scheduling state and workflow behavior could be altered without edit permission.
- Operational monitoring and downstream automation could be disrupted.
General mitigation guidance
Mitigation focuses on aligning authorization checks with the sensitivity and effect of each operation.
Common defensive patterns include:
- Require an edit-level or equivalent state-changing permission for queued-event deletion.
- Define endpoint-specific authorization policies rather than reusing read checks.
- Apply consistent server-side authorization for every state-mutating request.
- Minimize broad Dag read access where operational scheduling data is sensitive.
- Use least-privilege roles and separate observation permissions from workflow-control permissions.
- Add regression tests covering read-only, edit-capable, and unauthorized identities.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and policy checks that compare HTTP methods with authorization requirements.
- Code review signals where DELETE or other mutating handlers use read-only permission constants.
- Authorization matrices that document the required permission for each endpoint and resource action.
- Integration tests verifying that read-only users cannot change scheduling or workflow state.
- Audit-log analysis for queued-event deletion by identities lacking edit privileges.
Automated security review tools may help identify mismatches between endpoint behavior and access-control checks.
