Apache Airflow CVE-2026-65017

Three simultaneous non-default conditions are required: (1) multi-team mode must be enabled in the Airflow deployment, (2) the Config API must be exposed (expose_config = True in the [api] config section - this is False by default), and (3) the attacker must hold a valid authenticated account with at minimum Viewer-level configuration-read access. The vulnerable secret must be a sensitive option set as a team-scoped override under a [<team>=<section>] config file section or equivalent AIRFLOW__<TEAM>___<SECTION>__<KEY> environment variable - not a base global option, which was already masked correctly. Deployments running Airflow 3.3.0 that upgraded specifically to address CVE-2026-48828 or CVE-2026-48892 are not protected against this team-scoped variant. Deployments not using multi-team mode, or with expose_config = False, are entirely unaffected.

No CVSS vector or EPSS score is provided in the available intelligence, so risk metrics are inferred from the description. The vulnerability is network-accessible through the Config API but requires three simultaneous non-default conditions: multi-team mode enabled, Config API exposed, and a low-privileged authenticated account with configuration-read access. These prerequisites substantially constrain the real-world attack surface - multi-team mode is an enterprise deployment pattern not enabled by default, and expose_config defaults to False. The confidentiality impact when conditions are met is concrete and high: Celery broker credentials embedded in connection strings can enable direct message broker access, task injection, or lateral movement. No KEV listing exists and no POC code has been identified, indicating this is not under active broad exploitation. The risk is real but bounded to a well-defined subset of enterprise Airflow deployments; organizations not using multi-team mode or not exposing the Config API are not affected regardless of version.

An attacker holding a low-privileged Viewer account in a multi-team Airflow deployment with expose_config enabled issues a standard authenticated GET request to /config/section/team_a=celery/option/broker_url and receives the full Celery broker connection string - for example, amqp://team_a_user:s3cr3tpass@rabbitmq-host/vhost - in plaintext JSON. Using those credentials, the attacker connects directly to the message broker to read queued task arguments, inject malicious tasks, or pivot to other systems accessible from the broker network segment. No exploit code is required beyond a standard HTTP client.