GHSA-hhx9-p69v-cx2j BIT-airflow-2020-13927 GHSA-hhx9-p69v-cx2j PYSEC-2020-18

Authentication bypass in Apache Airflow

Critical Known exploited PyPI

Severity: 9.3 / 10; Critical · CVSS 4.0
Exploit chance (EPSS): 99.78%; Chance of exploitation in the next 30 days. Higher than 99.95% of scored vulnerabilities.
Known exploited: Yes; In CISA's catalog
Weakness: CWE-287 Improper Authentication; CWE-306 Missing Authentication for Critical Function; CWE-1056 Invokable Control Element with Variadic Parameters; CWE-1188 Initialization of a Resource with an Insecure Default
Fix: 1.10.11; Upgrade apache-airflow to this version or later

Description

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

Affected versions

PyPI

Package	Vulnerable	Fixed in
apache-airflow	`< 1.10.11`	`1.10.11`
apache-airflow	`< 1.10.11`	`1.10.11`
apache-airflow	`< 1.10.11`	`1.10.11`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

apache-airflow PyPI → `1.10.11`

pip

pip install --upgrade "apache-airflow>=1.10.11"

poetry

poetry add "apache-airflow>=1.10.11"

uv

uv add "apache-airflow>=1.10.11"

Severity breakdown

CVSS 4.0 9.3

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:A

Attack vector: Network
Attack complexity: Low
Attack requirements: None
Privileges required: None
User interaction: None
Confidentiality (vulnerable system): High
Integrity (vulnerable system): High
Availability (vulnerable system): High
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None
Exploit maturity: Attacked

CVSS 3.1 9.8

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: High
Exploit maturity: H

Weakness

CWE-287: Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

How to prevent it

Architecture and Design: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CWE-306: Missing Authentication for Critical Function

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

How to prevent it

Architecture and Design: Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Architecture and Design: Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks. In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CWE-1056: Invokable Control Element with Variadic Parameters

A named-callable or method control element has a signature that supports a variable (variadic) number of parameters or arguments.

CWE-1188: Initialization of a Resource with an Insecure Default

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

References

Advisories

Fixes and patches

Packages

github.com/apache/airflow

Timeline

Nov 10, 2020 Published
Jun 17, 2026 Last updated by the source

Advisory	Severity	Why it's related
CVE-2020-11978 Remote code execution (RCE) in Apache Airflow	High Known exploited	Also affects apache-airflow
PYSEC-2026-3990 Apache Airflow: the Core API logout endpoint revokes only a session token presented as the _token cookie.	Critical	Also affects apache-airflow
PYSEC-2026-3989 When a request to the Airflow core API carries both a session cookie and an explicit `Authorization: Bearer` token, Airflow resolves the caller from the cookie…	Medium	Also affects apache-airflow
PYSEC-2026-3988 Apache Airflow's `/assets/events` API returned asset events for every Dag in the deployment, with no filter restricting them to the Dags the caller is…	Medium	Also affects apache-airflow
GHSA-5247-m8w9-2v4m Apache Airflow missing team context permits cross-team Dag actions and XCom reads	Medium	Also affects apache-airflow
GHSA-f3c2-j7g8-vpp8 Apache Airflow Task SDK fails to mask list-shaped JSON Variables	Medium	Also affects apache-airflow
GHSA-cjv4-7hp2-2x9h Apache Airflow bulk endpoints log Variable and Connection secrets in cleartext	Medium	Also affects apache-airflow
GHSA-j4jc-cq9h-xrhr Apache Airflow Backfill API parser discrepancy permits cross-DAG authorization bypass	High	Also affects apache-airflow

Credits: sunSUNQ

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor