Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.59% for the current model date.
BlackTreeCVE IntelligenceApache Software Foundation · Apache Airflow
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
These OSV and GitHub advisory ranges apply only to the named package and ecosystem. A listed fixed version is not a universal product patch or proof that an update is installed.
| Ecosystem and package | Affected range | First fixed version | Evidence |
|---|---|---|---|
| PyPIapache-airflow | ECOSYSTEM: introduced 0; fixed 3.3.1 | 3.3.1 | OSV record ↗aggregator derived · 2 Oct 2026 |
| PyPIapache-airflow | ECOSYSTEM: introduced 0; fixed 3.3.1 | 3.3.1 | OSV record ↗source linked ecosystem record · 2 Oct 2026 |
| pipapache-airflow | < 3.3.1 | 3.3.1 | GitHub advisory ↗github reviewed aggregator · 2 Oct 2026 |
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Patch availableApache 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. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
Apache 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. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
The application reaches a protected operation without first confirming that the requester is authorised.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
Apache 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. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
The application reaches a protected operation without first confirming that the requester is authorised.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-862: Missing Authorization. The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 12 Aug 2026 · Last source change 16 Sept 2026, 14:56 UTC · CWE-862 · Missing Authorization
Core structured fields are present and their contributing authorities are shown above.