EUVD-2026-33567
GHSA-2883-wwh7-x57v
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
5Blast Radius
ecosystem impact- 8 pypi packages depend on apache-airflow (4 direct, 4 indirect)
Ecosystem-wide dependent count for version 3.2.2.
DescriptionCVE.org
A bug in the GET /api/v2/connections/{connection_id} REST API endpoint in Apache Airflow allowed an authenticated UI/API user with Connection-read permission to retrieve secrets stored in a Connection's extra JSON blob under field names not present in the redaction allowlist (DEFAULT_SENSITIVE_FIELDS) - for example, official Slack-provider credential field names were returned in plaintext. Affects deployments that store credentials in Connection extra blobs and grant Connection-read access to multiple users. Users are advised to upgrade to apache-airflow 3.2.2 or later. As a defense-in-depth mitigation, deployment operators can store sensitive credential values in a secret-backend rather than inlined into the Connection's extra field.
AnalysisAI
{connection_id}) allows any authenticated user holding the Connection-read permission to retrieve plaintext secrets stored in a Connection's extra JSON blob, provided those credential field names - such as slack_webhook_url, bearer, dsn, auth_header, and service_key - were absent from the DEFAULT_SENSITIVE_FIELDS redaction allowlist prior to version 3.2.2. All Airflow deployments before 3.2.2 that store credentials inline in Connection extra fields and grant Connection-read access to more than one user are exposed to lateral credential theft within the platform. No public exploit code or active exploitation has been identified at time of analysis; however, the network-accessible vector and high confidentiality impact make this a meaningful priority in shared or multi-tenant Airflow environments.
Technical ContextAI
Apache Airflow (CPE: cpe:2.3:a:apache_software_foundation:apache_airflow:*:*:*:*:*:*:*:*) uses a secrets masker component located at shared/secrets_masker/src/airflow_shared/secrets_masker/secrets_masker.py to redact sensitive values from API responses before they reach the client. The redaction logic performs case-insensitive substring matching against a hardcoded DEFAULT_SENSITIVE_FIELDS allowlist - if a Connection extra blob contains a credential under a key not present in that list (e.g., webhook_url, bearer, dsn, service_key, auth_header), the value passes through the serializer unmasked. This is a textbook CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) root cause: the access control boundary exists (Connection-read permission is required) but the output sanitization is incomplete, creating an allowlist coverage gap rather than a deny-by-default redaction model. The PR diff confirms the fix is purely additive - six field name patterns were added to DEFAULT_SENSITIVE_FIELDS - which underscores that the redaction logic itself was sound but its coverage was incomplete for real-world provider credential schemas, particularly the official Slack provider.
RemediationAI
The primary fix is to upgrade Apache Airflow to version 3.2.2 or later, which expands DEFAULT_SENSITIVE_FIELDS to include auth_header, bearer, dsn, service_account, service_key, and webhook_url, as confirmed by the merged PR at https://github.com/apache/airflow/pull/66673. Until upgrade is possible, the vendor-recommended defense-in-depth mitigation is to migrate sensitive credential values out of Connection extra blobs and into a dedicated secret backend (e.g., HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) - this eliminates the attack surface entirely because extra blobs would no longer contain the sensitive values. A secondary operational control is to audit and restrict Connection-read permission grants, ensuring only operationally necessary accounts hold this privilege; however, this reduces the blast radius without eliminating the vulnerability. Note that simply rotating exposed credentials (webhook URLs, bearer tokens, DSNs) is a necessary remediation step for any deployment that may have already been affected - the allowlist gap existed for all prior versions, so credentials stored under affected field names should be treated as potentially compromised.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today