CVE-2026-82355Medium· 4.2▾ SunlitWhen 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 and ignores the bearer token, inverting the intended precedence of bearer ove…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 23.1 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Sep 23.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
— → 4.2
none → medium
0.3%
Last analysed / modified upstream
0.3% → 0.7%
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 and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented.
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable.
Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation.
Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.
airflow = 3.3.0airflow = 3.3.1Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Affected packages:
apache-airflow <= 3.3.1Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-75158Medium· 4.3Apache 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 authorized to read
CVE-2026-86473Critical· 9.1Apache Airflow: the Core API logout endpoint revokes only a session token presented as the _token cookie
CVE-2026-68971Medium· 6.5Apache Airflow's asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site
CVE-2026-59242Medium· 5.4Apache Airflow's XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passed a string-literal payload through `BaseXCom.deserialize_value` without the `_check_forbidden_xcom_keys` guard, allowing an authenticated API user…
CVE-2026-58076High· 8.8Apache Airflow's serialization layer reconstructed exception nodes by calling `import_string()` on a class name taken from the serialized blob and instantiating it with arguments from the same blob, with no restriction on what could be i…
CVE-2026-65017Medium· 6.5Apache Airflow's Config API did not mask team-scoped sensitive configuration values in multi-team deployments