Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-86600

  • Snowflake drivers fetched a cloud identity token before checking the host was Snowflake, and eight driver lines needed the same fix

    Snowflake drivers fetched a cloud identity token before checking the host was Snowflake, and eight driver lines needed the same fix

    CVE-2026-86600, published September 8, 2026, describes a confused deputy in Snowflake’s client drivers: the workload-identity flow fetched an ambient cloud credential and attached it to the login request before checking whether the host on the other end was Snowflake.

    What happened

    The CVE record for CVE-2026-86600 was published on Tuesday, September 8, 2026. The fixes it describes shipped five days earlier, on September 3, 2026.

    The record’s description, verbatim: “In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying that the configured host is a Snowflake endpoint.”

    It is scored 8.2 on CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N, and it carries two weakness classes — CWE-522, insufficiently protected credentials, and CWE-441, unintended proxy or intermediary, which is the CWE for a confused deputy. The second one is the accurate description of the bug.

    Eight driver families are listed as affected, each with its own fixed release:

    • Python Connector 3.14.1 through 4.7.2 — fixed in 4.7.3
    • Go Driver 1.15.0 through 1.99.x — fixed in 2.2.0
    • JDBC Driver 3.24.0 through 4.3.3 — fixed in 4.3.4
    • Node.js Driver 2.1.1 through 3.2.x — fixed in 3.3.0
    • .NET Connector 4.7.0 through 6.0.x — fixed in 6.1.0
    • ODBC Driver 3.9.0 through 3.19.x — fixed in 3.20.0
    • PHP PDO Driver 3.6.0 through 4.1.x — fixed in 4.2.0
    • libsnowflakeclient 2.2.0 through 2.9.x — fixed in 2.10.0

    The release notes are specific about the remedy. Snowflake’s JDBC release notes for 4.3.4, dated September 3, 2026, say the change “Restricted WORKLOAD_IDENTITY authentication to recognized Snowflake hosts: the attestation flow now verifies the target host before any ambient cloud credential is fetched and otherwise fails with WORKLOAD_IDENTITY_FLOW_ERROR naming the rejected host.” The Python connector’s 4.7.3 notes, same date, describe the check itself: “The WORKLOAD_IDENTITY authenticator runs only against recognized Snowflake hosts: the connection host is normalized and suffix-anchored against snowflakecomputing.com, .cn, and .mil before the workload-identity flow proceeds.”

    Neither release note names CVE-2026-86600. The CVE arrived five days after the code.

    The record also singles out one cloud. Per its own text, an attacker with access to the connection configuration can capture attestation tokens and replay them; on Azure this extends to requesting Managed Identity access tokens for resources that are not Snowflake at all.

    Why it matters

    Workload identity exists to get long-lived database secrets out of configuration files. Instead of a password in an environment variable, the client asks the cloud platform’s local metadata endpoint for a short-lived token that proves “I am this virtual machine, this pod, this function,” and presents that to the service. It is a real improvement, and it is one of the few security changes that makes the operator’s life easier rather than harder, which is why it has spread quickly through data platforms and the pipelines and agent frameworks that sit on top of them.

    The security of the scheme rests entirely on one question: who is allowed to receive the token? A workload-identity token is a bearer credential. It proves the identity of the workload to anybody holding it. The whole design depends on the client fetching that token only when it is about to hand it to the party the token was minted for. Verify the destination first, then mint the credential. Do it in the other order and the client becomes a machine that will fetch a valid identity assertion on demand and mail it to a stranger.

    That is what the ordering in this bug describes, and it is exactly what CWE-441 names. The privileged party — the driver, running inside the trusted workload, holding access to the instance metadata service — is induced to use its privilege on behalf of someone who does not have it. The attacker never needs to reach the metadata endpoint. They only need to change where the driver points.

    Which is the part worth dwelling on, because “attacker with access to the connection configuration” sounds like a precondition that has already lost the game. It is not, in the environments where this driver runs. A connection host arrives from an environment variable, a Kubernetes ConfigMap, a Terraform output, a notebook widget, a workflow parameter, a dbt profile, a tool definition handed to an agent. Those are not credential stores and they are usually not protected like credential stores. A great many organizations treat a hostname as configuration rather than as a secret, because until this class of bug a hostname was configuration. The CVSS vector agrees with the modest framing — PR:L, low privileges, and AC:H, high attack complexity — but the 8.2 comes from S:C, scope changed, and scope is correct here for once: the credential that leaks belongs to the cloud platform, not to Snowflake.

    The Azure detail is the sharpest edge. On Azure the client asks the Instance Metadata Service for a Managed Identity token scoped to a particular resource. If the flow can be steered to request a resource of the attacker’s choosing, the token that comes back is not a Snowflake login artifact — it is an Azure access token for whatever that identity is permitted to reach. Key Vault. Storage. Resource Manager. The blast radius stops being the data warehouse and starts being the subscription.

    The last thing worth noting is the shape of the fix: eight separate driver releases, on eight separate version lines, for one design decision. Snowflake maintains these clients independently, and the check that was missing was missing in all of them, because each implemented the same specification the same way. An organization that has done the work to remove static Snowflake passwords has almost certainly done it in more than one language — a Python pipeline, a JDBC-based BI tool, an ODBC connection from a reporting server. The upgrade is not one bump. It is an inventory problem, and the drivers most likely to be missed are the ones nobody thinks of as software: the ODBC driver on a Windows reporting host, the libsnowflakeclient bundled inside something else.

    What to do

    • Upgrade every Snowflake driver in the estate to at least: Python 4.7.3, Go 2.2.0, JDBC 4.3.4, Node.js 3.3.0, .NET 6.1.0, ODBC 3.20.0, PHP PDO 4.2.0, libsnowflakeclient 2.10.0.
    • Only WORKLOAD_IDENTITY is implicated. If your connections authenticate with key-pair, OAuth or a password, this particular flow is not the exposure — but upgrade anyway, because the fixed releases also carry unrelated hardening.
    • Treat the connection host as a trust boundary from now on. Pin it in code or in a signed configuration source rather than accepting it from an environment variable a job template can set. Anything that lets a caller supply a hostname to a driver that holds ambient cloud credentials deserves the same review as a secret.
    • On Azure, review what your Managed Identities can actually reach. The failure mode described here yields tokens for arbitrary resources, so the damage is bounded by that identity’s role assignments and by nothing else. This is the case for scoping them narrowly.
    • Look for the drivers you did not deploy yourself — bundled ODBC installs, vendored libsnowflakeclient, container base images with a connector baked in. Eight version lines is eight places to check.
    • Watch for the failure signature after upgrading. The JDBC fix throws WORKLOAD_IDENTITY_FLOW_ERROR and names the rejected host. If that fires in production against a host you did not expect, that is worth investigating rather than allowlisting.

    Sourcing note

    Checked: the CVE Program record for CVE-2026-86600 at cveawg.mitre.org, which supplied the description, the CVSS vector and score, both CWEs, the eight affected-product entries with their version ranges and fixed versions, and the reference list. Snowflake’s own release notes for two of the eight drivers, both cited by that record and both dated September 3, 2026: the JDBC 4.3.4 notes at docs.snowflake.com and the Python connector 4.7.3 release on GitHub. The remedy wording is quoted from those two documents verbatim.

    Could not reach: nothing was unreachable. The remaining six release notes were not read individually; their fixed version numbers here come from the CVE record’s affected block rather than from each vendor page.

    Unresolved: Snowflake has published no statement about exploitation, and none is claimed here. The Python connector release note does not reference the CVE at all, and the JDBC note does not either, so the mapping from “this security bullet” to “this CVE ID” rests on the CVE record citing those release notes as its references rather than on Snowflake saying so. No researcher credit appears in the record. Whether the eight drivers shared source or merely shared a specification is not stated anywhere public, and the distinction matters for whether other Snowflake clients not on this list are affected.