CVE-2026-85528 in JDBC Driver
Summary
by MITRE • 09/04/2026
Improper input validation of the auto-configuration account identifier in Snowflake JDBC Driver versions 4.2.0 through 4.3.3 allowed a credential-bearing login request to be redirected to an attacker-selected HTTPS endpoint. An attacker able to control the account value could cause the driver to transmit a reusable login credential to a host of their choosing and replay it to obtain the privileges granted to that credential. Successful exploitation requires an application using jdbc:snowflake:auto with a connections.toml section that omits an explicit host and a lower-trust principal able to set the account value; ordinary JDBC URLs are unaffected. The fix is available in Snowflake JDBC Driver version 4.3.4. Users must manually upgrade.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within Snowflake JDBC Driver versions ranging from 4.2.0 through 4.3.3 represents a critical failure in input validation regarding the auto-configuration account identifier mechanism. This flaw allows for credential leakage and potential unauthorized access by manipulating how the driver resolves connection endpoints during the initialization phase of a database session. The core technical issue stems from an improper handling of the account value when the JDBC URL utilizes the special scheme jdbc:snowflake:auto, which is designed to automatically determine the correct Snowflake host based on the provided account identifier. In this specific configuration mode, if the connections.toml file omits an explicit host parameter, the driver relies entirely on the account string to construct a redirect or resolution request intended for legitimate Snowflake infrastructure. However, due to insufficient validation of the format and structure of this account value, an attacker who can influence this input is able to inject maliciously crafted identifiers that cause the JDBC driver to interpret part of the credential-bearing login payload as a host address or domain name.
This misinterpretation leads to a significant operational impact where the driver redirects the authentication request to an HTTPS endpoint controlled by an adversary rather than the intended Snowflake service. When this redirection occurs, the client transmits its reusable login credentials directly to the attacker-selected server. Because these credentials are transmitted over HTTPS, they remain intact and usable for subsequent attacks. An attacker who successfully intercepts or receives these credentials can replay them against legitimate services that accept such authentication methods, thereby obtaining the privileges granted to that specific credential identity. This effectively bypasses network-level security controls designed to protect internal traffic because the driver itself initiates a connection to an external, malicious destination under the guise of normal auto-configuration behavior. The severity is heightened by the fact that these credentials are often long-lived or reusable tokens rather than ephemeral secrets, increasing the window of opportunity for exploitation and lateral movement within compromised environments.
The conditions required for successful exploitation are specific but achievable in many enterprise deployments utilizing Snowflake JDBC drivers with configuration files. First, the application must be configured to use jdbc:snowflake:auto as its connection scheme, which is a common pattern for simplifying deployment across different regions or accounts without hardcoding hostnames. Second, the connections.toml file associated with this driver instance must lack an explicit host definition, forcing reliance on auto-configuration logic. Third, there must be a lower-trust principal capable of setting or modifying the account value within that configuration context. This could occur through insecure storage practices where configuration files are readable by unauthorized users, or via supply chain attacks where dependencies inject malicious configurations into the application environment. Ordinary JDBC URLs that specify explicit hosts directly are unaffected because they bypass this auto-configuration resolution path entirely, highlighting a design flaw in how fallback mechanisms handle trust boundaries for dynamic endpoint discovery.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-641 Improvement of Abstraction Errors, as the driver fails to properly sanitize or validate external input before using it in security-critical operations like network routing. In terms of attack vectors, this behavior facilitates Credential Access via Network Sniffing if interception occurs during transit, but more critically enables Account Manipulation through configuration file tampering which leads to unauthorized access. It also relates to ATT&CK technique T1078 Valid Accounts and potentially T1562 Impair Defenses by disabling or evading security monitoring through the use of legitimate credentials in unexpected contexts. The redirection aspect mimics aspects of SSRF (Server-Side Request Forgery) but is distinct as it involves client-side driver behavior rather than server-side processing, making traditional WAF protections ineffective against this specific vector since the malicious request originates from a trusted internal application host.
Mitigation strategies must focus on immediate remediation and long-term configuration hardening. The primary defense is to manually upgrade all affected systems to Snowflake JDBC Driver version 4.3.4 or later, where the input validation logic has been corrected to prevent the misinterpretation of account identifiers as destination hosts. Organizations should audit their application configurations to ensure that connections.toml files explicitly define host parameters whenever possible, thereby removing reliance on auto-configuration features that are susceptible to this manipulation. Additionally, strict file system permissions must be enforced on configuration directories to restrict write access to only highly privileged service accounts or deployment pipelines, preventing lower-trust principals from injecting malicious account values. Monitoring for unusual outbound HTTPS connections originating from application hosts during login phases can also help detect exploitation attempts in real-time, although prevention through patching and secure configuration remains the most effective control measure against this specific vulnerability class.