What is the CVSS score of CVE-2026-68868?

CVE-2026-68868 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.4%.

Which versions of Airflow Google Provider are affected by CVE-2026-68868?

Apache Airflow's Google Cloud Secret Manager backend contains a namespace bypass vulnerability that exposes all teams' database connections and secrets to every other team in multi-team deployments.. A patch is available.

How to fix or mitigate CVE-2026-68868?

Within 24 hours, audit your Airflow deployment to confirm which version of apache-airflow-providers-google is installed and identify all teams with active deployments. Within 7 days, upgrade all instances to apache-airflow-providers-google 22.3.0 or later. Within 30 days, complete a credential exposure assessment by reviewing access logs for the period running the vulnerable version, and rotate any credentials stored as Connections or Variables that may have been accessed by teams outside their scope.

Airflow Google Provider CVE-2026-68868

EUVD-2026-57163 MEDIUM

Insufficient Granularity of Access Control (CWE-1220)

2026-08-12 apache

GHSA-qfr4-ppjq-9gr3

Apache Information Disclosure Google Apache Airflow Google Provider Apache Software Foundation

6.5

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

6.5 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

6.5 MEDIUM

Requires low-privilege DAG authorship in one Airflow team; no integrity or availability impact; secret-manager lookup traverses network-accessible Airflow infrastructure.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Aug 12, 2026 - 11:06 vuln.today

Analysis Generated

Aug 12, 2026 - 11:06 vuln.today

CVE Published

Aug 12, 2026 - 10:27 cve.org

HIGH

DescriptionCVE.org

The Google Cloud Secret Manager secrets backend in Apache Airflow's Google provider never applied the team scope when resolving Connections and Variables: the caller's team_name was accepted by the backend but dropped at the internal call boundary, so every lookup resolved against the team-agnostic secret name. In a deployment running multi-team mode with this backend, a task or Dag belonging to one team resolved another team's Connection or Variable, obtaining its credentials in full. No unusual configuration is required beyond enabling multi-team mode and using this backend. Users are advised to upgrade to apache-airflow-providers-google 22.3.0 or later, which builds and applies the team-scoped secret name.

Articles & Coverage 1

News 8 New Apache Vulnerabilities - 8 High Severity, No Public Exploits Aug 12, 2026

AnalysisAI

Cross-team credential disclosure in the Apache Airflow Google Provider's Cloud Secret Manager backend exposes every team's Connections and Variables to every other team in multi-team deployments. The backend's public methods accepted a team_name parameter but silently discarded it before the internal secret lookup, collapsing all team namespaces into one shared, unscoped lookup. No public exploit has been identified at time of analysis; the vendor-released fix is apache-airflow-providers-google 22.3.0.

Technical ContextAI

The affected component is the CloudSecretManagerBackend class in airflow/providers/google/cloud/secrets/secret_manager.py, part of the Apache Airflow Google provider package (CPE: cpe:2.3:a:apache_software_foundation:apache_airflow_google_provider:*:*:*:*:*:*:*:*). The CWE-1220 (Insufficient Granularity of Access Control) root cause is a parameter drop at an internal call boundary: get_conn_value and get_variable each accepted a team_name argument from Airflow's scheduling layer but forwarded only path_prefix and secret_id to the private _get_secret helper, discarding team_name entirely. Every lookup therefore resolved against the team-agnostic secret name regardless of the calling team. The fix introduced in PR #70869 threads team_name into _get_secret, which calls the new _build_team_secret_name helper to construct a scoped name following the convention {prefix}{sep}{team_name}--{secret_id} before falling back to the team-agnostic name. A companion guard (_names_a_team_namespace) rejects any connection ID or variable key that itself contains the team separator '--', since such IDs produce ambiguous scoped names and cannot be resolved safely in either mode.

RemediationAI

The primary fix is to upgrade to apache-airflow-providers-google 22.3.0 or later (advisory: https://lists.apache.org/thread/03h5y0fmqlh0yf055zlocxh591ozx69x; patch PR: https://github.com/apache/airflow/pull/70869). Before upgrading, audit all existing Connections and Variables stored in Secret Manager: after upgrading, team-scoped secrets must be stored under the naming convention {prefix}{sep}{team_name}--{secret_id} (for example, airflow-connections-team_a--smtp_default) because the team-agnostic name is only used as a fallback when no team-scoped secret exists. Additionally, any connection ID or variable key that contains the string '--' will stop resolving entirely after the upgrade and must be renamed before applying the patch to avoid silent failures. For deployments that cannot upgrade immediately, the most targeted workaround is to disable multi-team mode, which removes the attack surface at the cost of losing team isolation; alternatively, switching to a different secrets backend eliminates the flaw at the cost of losing Secret Manager integration. Neither workaround addresses the root cause and both require operational trade-offs, so patching to 22.3.0 is strongly preferred.