CVE-2026-86597 in Go Driver
Summary
by MITRE • 09/08/2026
Insertion of sensitive information into log files in the Snowflake Python, Go, JDBC, Node.js, PHP PDO, and ODBC drivers allowed authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions to be written to diagnostic logs in circumstances where the available log redaction did not cover all affected log paths and data types. An attacker with read access to the log destination, whether the local filesystem, a log aggregation service, or a CI/CD artifact store, could obtain credentials and decryption keys that, if still valid at the time of access, could be used to authenticate to the corresponding Snowflake account or cloud-storage object. Successful exploitation requires read access to the log destination, and impact is bounded by credential lifetime and object scope. The fix is available in the patched versions listed above. Users must manually upgrade and should securely delete previously generated diagnostic logs containing sensitive information where retention is not required.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/08/2026
A critical vulnerability was identified within multiple Snowflake client drivers, including those for Python, Go, JDBC, Node.js, PHP PDO, and ODBC, which resulted in the unintended leakage of highly sensitive authentication credentials into diagnostic log files. This flaw stems from an insufficient implementation of data redaction mechanisms designed to sanitize logs before they are written to disk or remote logging services. Specifically, while some log paths were protected by existing sanitization rules, other code paths and specific data types containing secrets such as authentication tokens, query-result encryption keys, pre-signed cloud storage URLs, and SAML assertions bypassed these protections. The root cause lies in the failure of the application logic to consistently apply security filters across all possible execution branches where sensitive context is generated or processed during normal database operations.
The operational impact of this vulnerability is significant for any organization relying on Snowflake services through these specific drivers. An attacker who gains read access to the log destination, whether it be a local filesystem, a centralized log aggregation service like Splunk or ELK stack, or even CI/CD artifact stores where logs might be archived, can extract valid credentials and decryption keys. If these extracted secrets are still within their validity period at the time of exploitation, they provide direct authentication to the corresponding Snowflake account or access to cloud storage objects referenced by pre-signed URLs. This effectively bypasses standard identity verification controls, allowing unauthorized data exfiltration or modification without triggering typical anomaly detection systems associated with new login attempts from unknown IP addresses.
From a classification perspective, this vulnerability aligns closely with CWE-532, which covers the insertion of sensitive information into log files for security purposes. The attack vector is primarily categorized under ATT&CK technique T1078, Valid Accounts, as it involves the misuse of legitimate credentials obtained through side-channel leakage rather than direct exploitation of a code execution flaw. Furthermore, because the data includes encryption keys and authentication tokens, it also touches upon CWE-209, Generation of Error Message Containing Sensitive Information, although the primary risk is not error disclosure but rather persistent storage of secrets in accessible logs. The scope of impact is bounded by the lifetime of the credentials and the specific permissions associated with them, meaning that while immediate account takeover is possible if tokens are active, long-term persistence requires either continued validity or further exploitation to escalate privileges beyond what the leaked keys allow.
Mitigation strategies must be implemented immediately to address this exposure. The primary remediation involves upgrading all affected Snowflake client drivers to their respective patched versions where the redaction logic has been corrected to cover all identified log paths and data types. However, patching alone is insufficient due to the persistence of sensitive data in previously generated logs. Organizations are strongly advised to conduct a thorough audit of historical diagnostic logs across local systems and centralized logging infrastructure to identify any instances containing leaked tokens or keys. These compromised entries must be securely deleted if they are no longer required for compliance or debugging purposes. Additionally, implementing strict access controls on log storage locations and employing automated redaction tools at the ingestion layer can provide defense-in-depth against future occurrences of similar information leakage vulnerabilities.