CVE-2026-111455 in Airflow
Summary
by MITRE • 11/09/2026
Apache Airflow's asynchronous connection test checked permissions when the test was queued — only create permission when the connection ID did not exist yet — but, when the test completed with `commit_on_success`, wrote the tested connection under that ID. A user allowed to create but not edit connections could overwrite a connection someone else had created in the meantime. Only deployments that enable the non-default `[core] test_connection` setting are affected. Users are advised to upgrade to apache-airflow 3.4.0 or later.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/09/2026
The vulnerability identified in Apache Airflow represents a race condition rooted in improper synchronization of resource access during asynchronous operations, specifically within the connection testing mechanism. This flaw allows for an unauthorized modification of existing configuration data through a classic time-of-check to time-of-use (TOCTOU) scenario. The core issue arises from the decoupling between permission validation and state mutation. When a user initiates a test for a specific connection ID, the system checks if the user possesses create permissions only at the moment the task is queued. This check assumes that no other process will modify the target resource before the asynchronous operation completes. However, because Airflow processes these tests asynchronously with potential delays between queuing and execution, another authorized user can intervene during this window to create or update a connection using the same ID.
From a technical perspective, the flaw is exacerbated by the use of `commit_on_success` logic within the task execution flow. Once the asynchronous test completes successfully, it writes the tested configuration data back to the database under the specified connection ID without re-verifying current ownership or permissions for write operations beyond the initial create check. Consequently, a user who has permission to create connections but lacks edit privileges can effectively overwrite an existing connection defined by another user if they submit a test request that gets queued before the original owner updates their configuration. This behavior violates the principle of least privilege and fails to enforce strict access control during state changes, leading to data integrity issues where critical infrastructure configurations are silently replaced with potentially malicious or incorrect values.
The operational impact of this vulnerability is significant for environments relying on Apache Airflow for orchestrating complex workflows that depend on secure external service connections. An attacker exploiting this flaw could disrupt ongoing pipelines by altering database credentials, API keys, or other sensitive connection parameters. This disruption can lead to workflow failures, data loss, or the exfiltration of sensitive information if the overwritten connection points to a malicious endpoint controlled by the attacker. Furthermore, because only deployments with the non-default `[core] test_connection` setting enabled are affected, many standard installations may remain secure, but those utilizing this specific feature for automated connectivity verification face direct risk. The ability to overwrite connections undermines trust in the platform's configuration management and can cause cascading failures across dependent data pipelines that rely on consistent connection definitions.
This vulnerability aligns with CWE-367, which describes Time-of-check Time-of-use (TOCTOU) Race Conditions, as well as CWE-284 regarding Improper Access Control. In the context of the MITRE ATT&CK framework, this behavior facilitates unauthorized configuration modification and can be leveraged for persistence or impact objectives by disrupting service availability through misconfigured connections. To mitigate this risk, organizations must upgrade to Apache Airflow version 3.4.0 or later, where these synchronization issues have been addressed. Until upgrading is possible, administrators should disable the `[core] test_connection` setting if it is not strictly necessary for their operational workflows, thereby removing the attack vector entirely. Additionally, implementing strict audit logging and monitoring for connection changes can help detect any unauthorized modifications that may occur in unpatched environments.