CVE-2026-68868: Apache Airflow Auth Bypass Vulnerability

CVE-2026-68868 Overview

CVE-2026-68868 affects the Google Cloud Secret Manager secrets backend in the Apache Airflow Google provider. The backend accepts a team_name parameter from callers but drops it at the internal call boundary. Every Connection and Variable lookup resolves against a team-agnostic secret name. In multi-team Airflow deployments, a task or DAG owned by one team can retrieve another team's Connections or Variables in full, including credentials. The flaw requires no unusual configuration beyond enabling multi-team mode and using this backend. The issue is tracked under [CWE-1220: Insufficient Granularity of Access Control].

Critical Impact
Any authenticated team in a multi-team Apache Airflow deployment can read another team's secrets, including full Connection credentials backed by Google Cloud Secret Manager.

Affected Products

Apache Airflow apache-airflow-providers-google versions prior to 22.3.0
Apache Airflow deployments operating in multi-team mode
Deployments using the Google Cloud Secret Manager secrets backend for Connections and Variables

Discovery Timeline

2026-08-12 - CVE-2026-68868 published to the National Vulnerability Database
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-68868

Vulnerability Analysis

Apache Airflow's multi-team mode partitions Connections, Variables, and other artifacts across tenant boundaries. Secrets backends that support this model are expected to scope secret lookups by team_name so that team A cannot resolve secrets belonging to team B. The Google Cloud Secret Manager backend in the Google provider accepted the team_name argument at its public interface but did not forward it to the underlying lookup routine. As a result, the built secret name omitted the team scope entirely. Every request resolved against a shared, team-agnostic identifier in Google Cloud Secret Manager. A DAG author or task in one team could request a Connection ID or Variable key used by another team and receive its stored value directly. Because Airflow Connections commonly hold database URIs, service account JSON, API tokens, and other authentication material, the disclosure escalates from configuration leakage to credential compromise across tenant boundaries.

Root Cause

The root cause is a missing parameter propagation at an internal call boundary within the Google provider's secrets backend. The public method signature exposes team_name, giving the appearance of tenant scoping, while the private helper that constructs the Secret Manager resource name ignores it. The consequence is broken authorization granularity rather than a memory-safety or injection defect.

Attack Vector

Exploitation requires authenticated access to author or trigger a task inside any team of an affected multi-team Airflow deployment. The attacker requests a Connection or Variable using an identifier known or guessed to belong to another team. The backend returns the target team's secret material. No elevated privileges, unusual configuration, or user interaction beyond normal Airflow authoring is required.

No public proof-of-concept code is available. The fix in pull request apache/airflow #70869 demonstrates the corrected behavior by building and applying the team-scoped secret name before invoking Google Cloud Secret Manager.

Detection Methods for CVE-2026-68868

Indicators of Compromise

Google Cloud Secret Manager audit logs showing accessSecretVersion calls from Airflow worker service accounts referencing secret names that do not carry a team prefix.
Airflow task logs referencing Connection IDs or Variable keys that do not belong to the executing team's inventory.
Unexpected outbound authentication attempts from tenant workloads using credentials owned by a different team.

Detection Strategies

Correlate Airflow task ownership metadata with the Connection IDs and Variable keys each task resolves; flag mismatches between the executing team and the secret's owning team.
Enable Google Cloud audit logging for Secret Manager and alert on access patterns where a single worker identity retrieves secrets that span multiple team namespaces.
Inventory installed provider versions across Airflow deployments and identify hosts still running apache-airflow-providers-google below 22.3.0.

Monitoring Recommendations

Ship Airflow scheduler, worker, and webserver logs plus Google Cloud Secret Manager audit logs into a centralized analytics platform for cross-tenant correlation.
Baseline the expected Connection and Variable access pattern per team, then alert on deviations that suggest cross-team resolution.
Rotate any Connection or Variable secret that was resolvable during the exposure window and monitor downstream systems for use of the prior credentials.

How to Mitigate CVE-2026-68868

Immediate Actions Required

Upgrade apache-airflow-providers-google to version 22.3.0 or later on every scheduler, worker, and DAG processor.
Rotate all Connections and Variables that were stored in Google Cloud Secret Manager while the vulnerable provider was in use, including database passwords, API tokens, and service account keys.
Audit Google Cloud Secret Manager access logs for the exposure window to identify cross-team reads.

Patch Information

The fix is delivered in apache-airflow-providers-google 22.3.0. The change builds and applies the team-scoped secret name inside the Google Cloud Secret Manager backend so that Connection and Variable lookups resolve against the correct tenant namespace. See the upstream GitHub Pull Request, the Apache Mailing List advisory, and the OpenWall OSS Security notice for full details.

Workarounds

Temporarily disable multi-team mode and consolidate secret ownership until the provider upgrade is complete.
Switch the secrets backend for shared deployments to an alternative backend that enforces team scoping until the Google provider is updated.
Restrict DAG authoring permissions so that only trusted operators can submit tasks that call the affected backend.

bash

# Configuration example: upgrade the Google provider on every Airflow node
pip install --upgrade 'apache-airflow-providers-google>=22.3.0'

# Verify the installed version
airflow providers list | grep google