Airflow Snowflake Provider CVE-2026-81930

Requires a deployment where Snowflake connections are editable by Airflow users who are not trusted with the connection's credentials - Airflow grants connection-configuration users write-only access to stored secrets, and a private_key_file resides on the worker rather than in the connection, creating this trust gap. The attacker must hold connection-edit privileges (not full admin, and no Dag-authoring rights), inject a /, ?, or # into the account (or region) field, and an existing Dag using that connection must subsequently run so the provider mints and transmits the Bearer token. Limiting factors: the multi-user trust-separation configuration is not universal, an already-configured Dag must exercise the connection, and only apache-airflow-providers-snowflake versions before 6.18.0 are affected.

No CVSS vector, EPSS, KEV, or SSVC data was supplied by any source, so severity must be reasoned from the description; the vendor rates it 'moderate'. Independently, the flaw is a credential-redirection (effectively off-domain token exfiltration) issue: an unvalidated account/region field lets an attacker rewrite the request host so a valid Snowflake Bearer token (JWT from the private key, or OAuth/programmatic token) is delivered to an attacker-controlled host and then replayed against the real Snowflake endpoint. This is a genuine confidentiality/credential-theft concern rather than a high-CVSS-but-low-impact issue, but its real-world priority is tightly bounded by a specific deployment prerequisite: Snowflake connections must be editable by Airflow users who are NOT trusted with the connection's secrets (Airflow's write-only credential model plus a worker-side private_key_file create exactly this gap). Exploitation is network-reachable and low-complexity for such a user, and notably requires no Dag-authoring rights and no victim interaction - the attacker edits the connection and waits for an existing Dag to fire. Discovery is credited to an automated tool (Claude Security Scans) with no indication of in-the-wild use. Overall: a real, patch-worthy issue for multi-tenant/large Airflow installs, but lower urgency for single-trust-boundary deployments; no exploitation signals justify emergency response.

In an Airflow deployment where a lower-trust operator can edit Snowflake connections but not read the stored credentials, the attacker edits an existing connection's account field to a value like attacker.example.com/x (using /, ?, or # to demote the intended domain). When a scheduled Dag next uses that connection, the provider sends the Authorization: Bearer token to the attacker's host; the attacker then replays that valid token against the genuine Snowflake endpoint. No public exploit code was identified at time of analysis, and discovery is credited to an automated scanning tool.