CVE-2020-13927: Apache Airflow's Experimental API Authentication Bypass
The previous default setting for Airflow's Experimental API was to allow all API requests without authentication, but this poses security risks to users who miss this fact. From Airflow 1.10.11 the default has been changed to deny all requests by default and is documented at https://airflow.apache.org/docs/1.10.11/security.html#api-authentication. Note this change fixes it for new installs but existing users need to change their config to default `[api]auth_backend = airflow.api.auth.backend.deny_all` as mentioned in the Updating Guide: https://github.com/apache/airflow/blob/1.10.11/UPDATING.md#experimental-api-will-deny-all-request-by-default
CVE-2020-13927 is an authentication bypass in Apache Airflow's Experimental API. By default, that API previously accepted requests without requiring authentication, so anyone who could reach it could call its functions. For teams running Airflow, this matters because the Experimental API can expose workflow and operational controls; unauthenticated access raises the risk of unauthorized use of those capabilities. Confirm exact impact and fixed releases against the vendor advisory.
How it works
This issue falls under missing authentication for a critical function (CWE-306) and insecure default initialization (CWE-1188). The Experimental API was configured by default to allow all API requests without authentication. An attacker who can reach the endpoint does not need valid credentials to invoke whatever operations that API exposes. Abuse is therefore a matter of network reachability plus knowledge of the API surface, not of stealing or guessing passwords. Specific request formats, endpoints, or post-authentication effects are not detailed here; treat any unauthenticated call to the Experimental API as potentially abusive and verify behavior against the vendor advisory and your own configuration.
Am I affected? How to find it in your systems
Apache Airflow is commonly deployed for orchestrating data pipelines, often on internal servers, containers, or cloud VMs, sometimes with web and API ports exposed to broader networks. Inventory hosts and images that run Airflow, including development, staging, and CI environments. Check whether the Experimental API is enabled and what authentication setting it uses; the vulnerability centers on the prior default that allowed unauthenticated access. Compare your installed Airflow version and API configuration to the fixed releases and guidance in the vendor advisory—do not rely on version guesses from secondary sources.
For detection of possible exploitation, review access logs for the Airflow webserver or API front end for requests to Experimental API paths that lack authentication headers or tokens, especially from unexpected source IPs or at unusual times. Correlate with changes to DAGs, connections, variables, or task runs that were not initiated by known operators. Telemetry that shows anonymous or failed-then-succeeded API use against that surface is worth investigating. Absence of such logs does not prove safety if logging was incomplete.
How to remediate
Patch first: apply the updates specified by the Apache Airflow vendor advisory for CVE-2020-13927 so that the Experimental API no longer defaults to allowing unauthenticated requests. After upgrading, confirm that authentication is required for the Experimental API and that your deployment no longer relies on the insecure default. Restart or redeploy services as the advisory instructs, then re-check configuration and run a controlled authenticated test to verify the control is enforced.
Beyond the patch, harden this class of weakness: disable the Experimental API entirely if you do not need it; require strong authentication on all Airflow API and UI endpoints; restrict administrative and API listeners to management networks; and ensure secrets and connection credentials used by Airflow are not reachable via unauthenticated interfaces. Document the hardened baseline so future installs do not reintroduce the old default.
If you can't patch immediately
Reduce exposure until you can update. Block or tightly limit network access to the Airflow API and web ports with host firewalls, security groups, or internal reverse proxies so only trusted operator networks can reach them. If you use a WAF or API gateway, apply rules that deny unauthenticated requests to Experimental API paths (virtual patching); tune carefully to avoid breaking legitimate automation. Disable the Experimental API feature if your version and config allow it without breaking required workflows. Increase monitoring on remaining access: alert on any hit to those paths without valid auth, and on configuration or DAG changes. These steps do not replace the vendor fix; they only lower risk while you schedule the update.
If your data may have been exposed
Actively exploited authentication-bypass flaws can lead to unauthorized access and, in some environments, follow-on compromise or data exposure. Ransomware use of this CVE is not documented in the provided facts. If you suspect the Experimental API was reachable without auth, review Airflow and downstream system logs for unauthorized actions, rotate credentials that Airflow could have exposed, and follow your incident process. You can also run a free exposure scan of your email addresses against known breach data to see whether your identities appear in unrelated breaches while you complete containment.
AICompiled with AI assistance from public sources and published under our editorial standards.
Details
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- packetstormsecurity.com/files/162908/Apache-Airflow-1.10.10-Remote-Code-Executio
- packetstormsecurity.com/files/174764/Apache-Airflow-1.10.10-Remote-Code-Executio
- lists.apache.org/thread.html/r23a81b247aa346ff193670be565b2b8ea4b17ddbc7a35fc099
- www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-13927