Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-x5wm-j6wh-2834

LOW

Apache Airflow has an Incorrect Authorization issue

Also known asBIT-airflow-2026-45426CVE-2026-45426PYSEC-2026-174
Published
Jun 1, 2026
Updated
Jul 9, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk27th percentile0.00%
0.00%0.28%0.56%0.84%0.0%0.3%0.3%Jun 26Jul 26Jul 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐍apache-airflow

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Exploitation requires the attacker to already be an authenticated Airflow worker holding a valid Log-server JWT issued for at least one Dag. Apache Airflow's Log server authorized JWT tokens against Dag IDs by applying Python's str.lstrip() to the requested path segment when verifying the JWT's sub claim. str.lstrip() strips any of a set of characters from the left (not a prefix), so a JWT issued for a Dag named e.g. dag_a would authorize log access to any other Dag whose name began with any subset of the characters {d, a, g, _} (e.g. dag_attacker, aaaa_target, _dag_secret). Such an authenticated worker could enumerate and read worker logs of other Dags whose names happened to share that character-class prefix, leaking task output and error traces beyond the documented per-Dag isolation boundary. Affects deployments relying on per-Dag log-access scoping (multi-team, shared-executor, shared-worker topologies). Users are advised to upgrade to apache-airflow 3.2.2 or later.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIapache-airflow3.0.0&&< 3.2.23.2.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apache-airflow. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update apache-airflow to 3.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x5wm-j6wh-2834 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-x5wm-j6wh-2834 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-x5wm-j6wh-2834. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

Exploitation requires the attacker to already be an authenticated Airflow worker holding a valid Log-server JWT issued for at least one Dag. Apache Airflow's Log server authorized JWT tokens against Dag IDs by applying Python's `str.lstrip()` to the requested path segment when verifying the JWT's `sub` claim. `str.lstrip()` strips any of a *set* of characters from the left (not a prefix), so a JWT issued for a Dag named e.g. `dag_a` would authorize log access to any other Dag whose name began with any subset of the characters `{d, a, g, _}` (e.g. `dag_attacker`, `aaaa_target`, `_dag_secret`).
O3 Security · Impact-Aware SCA

Is GHSA-x5wm-j6wh-2834 in your dependencies?

O3 detects GHSA-x5wm-j6wh-2834 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.