AI analysis
Apache Airflow’s Snowflake provider, before apache-airflow-providers-snowflake 6.18.0, interpolated the connection’s account and region fields into request URLs without validating them. The SQL API URL is built as https://{account}.snowflakecomputing.com/api/v2/statements, so an account value containing "/", "?", or "#" turns the intended Snowflake host into a path, query, or fragment and sends the request, including an Authorization Bearer JWT or configured OAuth or programmatic access token, to a host the editor chooses; the same unvalidated value was used for the OAuth token-request URL and the Cortex Agent base URL. A user who can edit the Snowflake connection but cannot read its secrets can capture a valid token and replay it against the real Snowflake account, without authoring a Dag and without access to a private_key_file that stays on the worker. Deployments are affected only where Snowflake connections are editable by users who are not trusted with those credentials. No public proof of concept is known, CISA’s KEV catalog does not list it, and there is no report of in-the-wild exploitation; CVSS has not yet been scored.
What to do: Upgrade apache-airflow-providers-snowflake to 6.18.0 or later, which rejects account and region values other than letters, digits, period, underscore, and hyphen in every URL the provider builds. Until then, allow only fully trusted admins to edit Snowflake connections and check existing account and region values for "/", "?", or "#". If an untrusted user may have changed a connection, rotate the Snowflake private key, OAuth token, or programmatic access token and review worker logs for requests to unexpected hosts.
Affected
| Apache Software Foundation apache-airflow-providers-snowflake | versions before 6.18.0 |
Estimated exposure
moderateroughly 1,000–10,000 Airflow deployments in the risky permission split (estimate) — No install census or internet-scan count is in the advisory, and Airflow is usually deployed internally, so this is an order-of-magnitude inference from Airflow’s enterprise footprint and common use of the official Snowflake provider,…
Description
Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host. The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL. Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them.