CVE-2026-30911: 
Apache Airflow vulnerability analysis and mitigation

CVE-2026-30911 is a missing authorization vulnerability in Apache Airflow's Execution API Human-in-the-Loop (HITL) endpoints. It affects Apache Airflow versions 3.1.0 through 3.1.7, allowing any authenticated task instance to read, approve, or reject HITL workflows belonging to any other task instance. The vulnerability was disclosed on March 17, 2026, with the fix merged on March 5, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (Feedly, Openwall).

The root cause is CWE-862 (Missing Authorization): the Execution API's HITL endpoints fail to validate that the requesting task instance is the intended owner of the HITL workflow being accessed or modified. Because no per-task authorization check is enforced, any authenticated task instance can issue API calls to read, approve, or reject HITL workflow states belonging to other task instances. The fix, contributed by Aritra Basu and merged into the main branch on March 5, 2026, adds task instance validation to HITL endpoint handlers (GitHub PR, Openwall).

Successful exploitation allows an authenticated attacker controlling one task instance to read sensitive workflow data from other task instances (high confidentiality impact) and to fraudulently approve or reject HITL workflow decisions that they are not authorized to control (high integrity impact). This can disrupt or manipulate critical business processes that rely on human approval gates within Airflow pipelines. Availability is not directly impacted, but unauthorized workflow state changes could cause downstream pipeline failures or incorrect automated actions (Feedly).

1. Gain authenticated access: Obtain credentials or execution context for any task instance running within an Apache Airflow 3.1.0–3.1.7 deployment (e.g., by compromising a DAG task, a worker node, or obtaining a valid task instance token).
2. Identify HITL endpoints: Enumerate the Execution API's HITL endpoints (e.g., endpoints under the Airflow Execution API path for Human-in-the-Loop workflows) using API documentation or by inspecting network traffic from a legitimate task instance.
3. Query other task instances' HITL workflows: Send authenticated API requests to the HITL read endpoint without specifying ownership constraints, retrieving HITL workflow states belonging to other task instances.
4. Approve or reject target workflows: Issue authenticated API calls to the HITL approve or reject endpoints targeting workflow IDs belonging to other task instances, manipulating their approval state without authorization.
5. Achieve objective: Cause unauthorized approval or rejection of critical business workflows, potentially triggering unintended downstream pipeline actions or suppressing required human review steps (GitHub PR, Openwall).

• Logs: Airflow API access logs showing a single task instance token or identity making HITL API requests (read, approve, or reject) against workflow IDs associated with multiple different task instances; unexpected HITL approval or rejection events in the Airflow audit log not matching the expected approving user or task.
• Network: Unusual volume of requests to Execution API HITL endpoints from a single source IP or task worker, particularly cross-referencing workflow IDs that do not belong to the requesting task instance.
• Application Behavior: HITL workflows being approved or rejected without corresponding human interaction in the Airflow UI; pipeline stages advancing past human approval gates unexpectedly.

The primary remediation is to upgrade Apache Airflow to version 3.1.8 or later, which includes the fix adding per-task instance validation to HITL endpoints (GitHub PR). As an interim workaround, restrict network-level access to the Execution API and HITL endpoints to only trusted internal networks or authorized task workers. Additionally, review Airflow access logs for any suspicious HITL approval or rejection activity on affected versions and consider temporarily disabling HITL workflows if the risk is unacceptable before patching (Openwall, Feedly).

The vulnerability was credited to Kai Aizen as the finder and Aritra Basu as the remediation developer, as noted in the oss-security disclosure (Openwall). The Apache Security Team classified the severity as "low" in the oss-security announcement, though the CVSS score of 8.1 reflects a higher technical severity. Social media activity was limited, with brief mentions on Mastodon via @thehackerwire and coverage by several CVE aggregator and advisory sites shortly after disclosure (Feedly).