CVE-2020-13927

What is Apache Airflow's Experimental API?

Apache Airflow is a widely-used workflow orchestration platform for scheduling and monitoring data pipelines. Airflow's Experimental REST API (/api/experimental/) provides programmatic access to Airflow functions including triggering DAG runs, pausing/unpausing DAGs, and querying task status. DAGs (Directed Acyclic Graphs) in Airflow are Python code files that define workflows — a DAG can execute arbitrary Python code, run shell commands, call external APIs, or trigger any automated process. Because Airflow DAGs execute Python code and can run shell commands, triggering a DAG run is equivalent to executing code on the Airflow worker systems. The Experimental API defaults determined whether triggering DAGs required authentication.

Overview

CVE-2020-13927 is a missing authentication vulnerability (CWE-306) in Apache Airflow's Experimental API. In Airflow 1.10.10 and earlier, the /api/experimental/ endpoints allowed all API requests without authentication by default — the configuration setting api.auth_backend defaulted to airflow.api.auth.backend.default which permits all requests. An unauthenticated remote attacker could trigger DAG runs, execute arbitrary code on Airflow workers, and access sensitive workflow configuration. Fixed in Airflow 1.10.11 by changing the default to deny all. CISA added it to KEV in January 2022.

Affected Versions

Technical Details

• Root cause: Missing authentication (CWE-306) — Airflow's experimental API's default auth_backend setting was airflow.api.auth.backend.default, which implements no authentication and allows all requests; operators who did not explicitly configure authentication were unknowingly running an unauthenticated API endpoint
• DAG trigger → code execution: Airflow DAGs are Python code files; triggering a DAG run via /api/experimental/dags/{dag_id}/dag_runs causes Airflow workers to execute the Python functions defined in the DAG, including ShellOperator, PythonOperator, or BashOperator tasks; an attacker who can trigger a DAG run can execute code if any DAG contains shell or system commands
• Airflow worker access scope: Airflow workers typically have access to cloud credentials (AWS, GCP, Azure), database connection strings, API keys, and data pipeline source/destination systems stored in Airflow's connections and variables store; code execution on Airflow workers provides access to all of these
• Data pipeline exfiltration: Beyond code execution, an attacker can query DAG configurations, task logs, and Airflow variable/connection stores to exfiltrate credentials and configuration for all data pipelines — a particularly high-value target in data-rich environments
• Exposure patterns: Organizations that deployed Airflow on cloud infrastructure with internet-accessible webservers or that failed to configure network access controls for the Airflow API endpoint were directly vulnerable; Airflow deployments on Kubernetes or cloud-managed services (MWAA, Cloud Composer) with public endpoints were at risk

Discovery

Identified by security researchers and documented in CVE-2020-13927. Apache fixed the default in Airflow 1.10.11 by changing api.auth_backend to airflow.api.auth.backend.deny_all. CISA's January 2022 KEV addition reflects active exploitation of internet-accessible Airflow deployments with default authentication settings.

Exploitation Context

Apache Airflow is widely deployed in data engineering teams at technology companies, financial institutions, and media companies. Internet-exposed Airflow instances with unauthenticated APIs are discovered regularly via Shodan and similar tools — data engineers frequently expose Airflow webservers for external scheduling triggers without configuring authentication. The combination of Python code execution via DAG triggers and access to all data pipeline credentials makes Airflow a high-value target for data exfiltration and cloud credential theft.

Remediation

1. Upgrade Apache Airflow to 1.10.11 or later — the default API authentication is changed to deny-all
2. If running 1.10.10 or earlier: explicitly set auth_backend = airflow.api.auth.backend.deny_all in airflow.cfg to block unauthenticated API access immediately
3. For production deployments: configure auth_backend = airflow.api.auth.backend.basic_auth or a proper OAuth/OIDC backend — not just deny-all — to enable legitimate authenticated API access
4. Restrict network access to Airflow webserver and API to authorized internal networks only — the Airflow webserver should not be directly internet-accessible
5. Audit Airflow connections and variables store for credentials that may have been exposed via unauthenticated API access; rotate any potentially exposed secrets
6. Enable Airflow audit logging to detect unexpected DAG triggers, API access, or variable/connection queries that may indicate exploitation