Apache Airflow CVE-2026-68076

Four simultaneous non-default conditions are required for exploitation. First, [core] multi_team must be explicitly enabled in the Airflow configuration-this is not set in default installations. Second, [core] test_connection must be set to Enabled; the factory default is Disabled, meaning an operator must have deliberately activated this feature. Third, team-scoped secrets must be provisioned as environment variables in the API-server process using the EnvironmentVariablesBackend; deployments that store team secrets in the database, Vault, or any other backend are not affected by this code path. Fourth, the attacker must know or successfully enumerate the encoded connection identifier belonging to the target team, following the _<TEAM_NAME>___<CONN_ID> naming convention. The attacker must be an authenticated Airflow user in any team within the same deployment (CVSS PR:L equivalent). Exploitation cannot directly expose credential values-the endpoint uses credentials for an outbound authentication probe but does not return them. Redirecting that outbound probe to an attacker-controlled host is separately blocked by Airflow.

CVSS data is not provided in the available intelligence, so risk must be assessed from the vulnerability description, patch diff, and configuration prerequisites alone. The attack requires a rare and deliberate confluence of three non-default Airflow configuration flags simultaneously-multi_team mode enabled, test_connection flipped from its factory default of Disabled to Enabled, and the environment-variable secrets backend specifically in use for team-scoped secrets-which substantially reduces the exposed population relative to Airflow's overall install base. EPSS data is unavailable, and the vulnerability is not listed in CISA KEV; no public exploit code has been identified. Even a mid-sized municipal IT department in walbrzych running Airflow for ETL orchestration would only be in scope if all three configuration prerequisites are met together, which is a narrow operational profile. The credential-use-without-exposure impact model-the test_connection endpoint authenticates outward rather than returning credential values-both limits attacker utility (they cannot exfiltrate secrets directly) and complicates defender detection (cross-team authentication may appear as legitimate traffic originating from the victim team). Risk priority is moderate for qualifying deployments but negligible for the much larger population running single-team or non-environment-variable-backend configurations.

An authenticated Airflow user in Team A, operating against a multi-team deployment where test_connection is Enabled and team secrets are stored as environment variables, crafts a connection identifier that spells out Team B's namespace-for example _team_b___prod_database or, to defeat the old underscore-blind regex, _team_b_prod___db_primary where the team name contains an underscore-and submits it to POST /api/v2/connections/test. The unpatched EnvironmentVariablesBackend fails to recognize the cross-team namespace pattern and resolves AIRFLOW_CONN__TEAM_B___PROD_DATABASE from the API-server environment, causing Airflow to authenticate outward to Team B's database using Team B's credentials without returning those credentials in the API response. No public exploit code has been identified at time of analysis, but the attack mechanic is straightforward to implement once an attacker understands the naming convention.