{"id":"CVE-2026-82355","aliases":["BIT-airflow-2026-82355","EUVD-2026-83943","GHSA-9x6g-jfj6-r3jg","PYSEC-2026-3989"],"status":"published","title":"Apache Airflow: Session cookie silently overrides explicit Authorization bearer header, enabling session fixation","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","severity":{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium","assessor":"adp","from":"cve"},"epss":{"day":"2026-11-11","score":0.00735,"percentile":0.54884,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-384"],"published":"2026-09-21T14:32:04Z","modified":"2026-11-04T02:30:43Z","fixes":[{"ecosystem":"Bitnami","package":"airflow","fixed_in":["3.3.2"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Bitnami","package":"airflow","ranges":[{"type":"SEMVER","events":[{"introduced":"3.3.0"},{"fixed":"3.3.2"}]}]},{"source":"osv","ecosystem":"PyPI","package":"apache-airflow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.3.0"},{"last_affected":"3.3.1"}]}],"versions":["1.10.0","1.10.1","1.10.10","1.10.10rc1","1.10.10rc2","1.10.10rc3","1.10.10rc4","1.10.10rc5","1.10.11","1.10.11rc1","1.10.11rc2","1.10.12","1.10.12rc1","1.10.12rc2","1.10.12rc3","1.10.12rc4","1.10.13","1.10.13rc1","1.10.14","1.10.14rc1","1.10.14rc2","1.10.14rc3","1.10.14rc4","1.10.15","1.10.15rc1","1.10.1b1","1.10.1rc2","1.10.2","1.10.2b2","1.10.2rc1","1.10.2rc2","1.10.2rc3","1.10.3","1.10.3b1","1.10.3b2","1.10.3rc1","1.10.3rc2","1.10.4","1.10.4b2","1.10.4rc1","1.10.4rc2","1.10.4rc3","1.10.4rc4","1.10.4rc5","1.10.5","1.10.5rc1","1.10.6","1.10.6rc1","1.10.6rc2","1.10.7","1.10.7rc1","1.10.7rc2","1.10.7rc3","1.10.8","1.10.8rc1","1.10.9","1.10.9rc1","1.8.1","1.8.2","1.8.2rc1","1.9.0","2.0.0","2.0.0b1","2.0.0b2","2.0.0b3","2.0.0rc1","2.0.0rc2","2.0.0rc3","2.0.1","2.0.1rc1","2.0.1rc2","2.0.2","2.0.2rc1","2.1.0","2.1.0rc1","2.1.0rc2","2.1.1","2.1.1rc1","2.1.2","2.1.2rc1","2.1.3","2.1.3rc1","2.1.4","2.1.4rc1","2.1.4rc2","2.10.0","2.10.0b1","2.10.0b2","2.10.0rc1","2.10.1","2.10.1rc1","2.10.2","2.10.2rc1","2.10.3","2.10.3rc1","2.10.3rc2","2.10.4","2.10.4rc1","2.10.5","2.10.5rc1","2.11.0","2.11.0rc1","2.11.1","2.11.1rc1","2.11.1rc2","2.11.2","2.11.2rc1","2.2.0","2.2.0b1","2.2.0b2","2.2.0rc1","2.2.1","2.2.1rc1","2.2.1rc2","2.2.2","2.2.2rc1","2.2.2rc2","2.2.3","2.2.3rc1","2.2.3rc2","2.2.4","2.2.4rc1","2.2.5","2.2.5rc1","2.2.5rc2","2.2.5rc3","2.3.0","2.3.0b1","2.3.0rc1","2.3.0rc2","2.3.1","2.3.1rc1","2.3.2","2.3.2rc1","2.3.2rc2","2.3.3","2.3.3rc1","2.3.3rc2","2.3.3rc3","2.3.4","2.3.4rc1","2.4.0","2.4.0b1","2.4.0rc1","2.4.1","2.4.1rc1","2.4.2","2.4.2rc1","2.4.3","2.4.3rc1","2.5.0","2.5.0rc1","2.5.0rc2","2.5.0rc3","2.5.1","2.5.1rc1","2.5.1rc2","2.5.2","2.5.2rc1","2.5.2rc2","2.5.3","2.5.3rc1","2.5.3rc2","2.6.0","2.6.0b1","2.6.0rc1","2.6.0rc2","2.6.0rc3","2.6.0rc4","2.6.0rc5","2.6.1","2.6.1rc1","2.6.1rc2","2.6.1rc3","2.6.2","2.6.2rc1","2.6.2rc2","2.6.3","2.6.3rc1","2.7.0","2.7.0b1","2.7.0rc1","2.7.0rc2","2.7.1","2.7.1rc1","2.7.1rc2","2.7.2","2.7.2rc1","2.7.3","2.7.3rc1","2.8.0","2.8.0b1","2.8.0rc1","2.8.0rc2","2.8.0rc3","2.8.0rc4","2.8.1","2.8.1rc1","2.8.2","2.8.2rc1","2.8.2rc2","2.8.2rc3","2.8.3","2.8.3rc1","2.8.4","2.8.4rc1","2.9.0","2.9.0b1","2.9.0b2","2.9.0rc1","2.9.0rc2","2.9.0rc3","2.9.1","2.9.1rc1","2.9.1rc2","2.9.2","2.9.2rc1","2.9.3","2.9.3rc1","3.0.0","3.0.0b4","3.0.0rc1","3.0.0rc1.post1","3.0.0rc1.post2","3.0.0rc1.post3","3.0.0rc1.post4","3.0.0rc2","3.0.0rc3","3.0.0rc4","3.0.1","3.0.1rc1","3.0.2","3.0.2rc1","3.0.2rc2","3.0.3","3.0.3rc1","3.0.3rc2","3.0.3rc3","3.0.3rc4","3.0.3rc5","3.0.3rc6","3.0.4","3.0.4rc1","3.0.4rc2","3.0.5","3.0.5rc1","3.0.5rc2","3.0.5rc3","3.0.6","3.0.6rc1","3.0.6rc2","3.1.0","3.1.0b1","3.1.0b2","3.1.0rc1","3.1.0rc2","3.1.1","3.1.1rc1","3.1.1rc2","3.1.2","3.1.2rc1","3.1.2rc2","3.1.3","3.1.3rc1","3.1.4","3.1.4rc1","3.1.4rc2","3.1.5","3.1.5rc1","3.1.6","3.1.6rc1","3.1.7","3.1.7rc1","3.1.7rc2","3.1.8","3.1.8rc1","3.1.8rc2","3.2.0","3.2.0b1","3.2.0b2","3.2.0rc1","3.2.0rc2","3.2.1","3.2.1rc1","3.2.1rc2","3.2.1rc3","3.2.2","3.2.2rc1","3.2.2rc2","3.2.2rc3","3.3.0","3.3.0b1","3.3.0b2","3.3.0rc1","3.3.0rc2","3.3.1"]}],"products":[{"vendor":"apache","product":"airflow"},{"vendor":"apache software foundation","product":"apache airflow"}],"references":[{"url":"https://github.com/apache/airflow/pull/72225","tags":["patch","Issue Tracking","Patch","fix"]},{"url":"https://github.com/apache/airflow/pull/72723","tags":["patch","Issue Tracking","Patch","fix"]},{"url":"https://lists.apache.org/thread/3p7zpdvv40tn01m0xk5mt2rxg88mw8w1","tags":["vendor-advisory","Mailing List","Vendor Advisory","advisory"]},{"url":"http://www.openwall.com/lists/oss-security/2026/09/21/4","tags":["Mailing List","Third Party Advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-82355","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-9x6g-jfj6-r3jg"},{"url":"https://pypi.python.org","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/82xxx/CVE-2026-82355.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-82355","title":"Apache Airflow: Session cookie silently overrides explicit Authorization bearer header, enabling session fixation","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T14:32:04.932Z","modified":"2026-11-03T07:00:47.198Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium","assessor":"adp"}],"cwes":["CWE-384"],"updated_at":"2026-11-03T08:49:08.781116Z"}],"euvd":[{"id":"EUVD-2026-83943","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T14:32:04Z","modified":"2026-11-03T07:00:47Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-03T08:50:00.381029Z"}],"ghsa":[{"id":"GHSA-9x6g-jfj6-r3jg","title":"When a request to the Airflow core API carries both a session cookie and an explicit ...","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T15:32:05Z","modified":"2026-09-21T21:31:51Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T15:12:16.582397Z"}],"nvd":[{"id":"CVE-2026-82355","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T15:17:32.43Z","modified":"2026-11-03T07:20:58.41Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-384"],"updated_at":"2026-11-03T11:52:55.230783Z"}],"osv":[{"id":"CVE-2026-82355","title":"Apache Airflow: Session cookie silently overrides explicit Authorization bearer header, enabling session fixation","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T14:32:04.932Z","modified":"2026-11-04T02:30:43.350363738Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-384"],"updated_at":"2026-11-04T02:54:44.889498Z"},{"id":"PYSEC-2026-3989","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-21T15:17:32.43Z","modified":"2026-09-26T09:25:59.744943687Z","cvss":[{"version":"3.1","score":4.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:52:57.255153Z"},{"id":"BIT-airflow-2026-82355","title":"Apache Airflow: Session cookie silently overrides explicit Authorization bearer header, enabling session fixation","description":"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.\n\nOnly 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.\n\nExploiting 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.\n\nUsers 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.","status":"published","published":"2026-09-26T08:41:41.787Z","modified":"2026-09-29T10:00:06.204163007Z","updated_at":"2026-11-02T15:28:28.267217Z"}]}}