Snowflake drivers writes sensitive information to logs

1. Executive summary

Snowflake's Python, Go, JDBC, Node.js, PHP PDO, and ODBC drivers wrote authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions into diagnostic logs, because the drivers' log redaction did not cover every affected log path and data type. Anyone with read access to the log destination (local filesystem, log aggregation service, or CI/CD artifact store) could recover credentials and decryption keys, and use them to authenticate to the corresponding Snowflake account or cloud-storage object while those secrets remained valid. The exposure is bounded by credential lifetime and object scope, so the practical risk to an EMEA financial services firm depends on how long its Snowflake tokens live and who can read its logs. Fixed driver versions are published and require a manual upgrade; previously written logs containing the sensitive values must be deleted. No CVSS score, severity rating, or CISA KEV exploitation state was resolved for this item, so no severity is asserted here.

2. Regulatory framing

3. Technical analysis & attack chain

This is a sensitive-information-in-log-files defect (CWE-532 class) in the Snowflake client drivers, not a remote code execution or authentication-bypass flaw. Exploitation requires an attacker to already hold read access to wherever the driver's diagnostic logs are written. There is no network exploit path described in the source.

Confirmed chain:

1. An application, job, or pipeline uses an affected Snowflake driver version and enables diagnostic logging.
2. The driver writes sensitive values into the log: authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions.
3. The available log redaction fails to cover all affected log paths and data types, so those values survive into the log output.
4. The log is written to a destination: the local filesystem, a log aggregation service, or a CI/CD artifact store.
5. An attacker with read access to that destination recovers the credentials and decryption keys.
6. If the recovered secrets are still valid at the time of access, the attacker uses them to authenticate to the corresponding Snowflake account or to access the cloud-storage object the pre-signed URL points at.

Affected components and fixed versions:

Impact bounds. The source states the impact is bounded by credential lifetime and object scope. A token that has expired, or a pre-signed URL that has lapsed, is not usable. The blast radius is therefore set by your token TTLs, the privileges of the identity whose token leaked, and the scope of the storage objects behind any leaked pre-signed URL. The source does not state which log paths or data types escaped redaction, and does not give a per-driver breakdown of which secret types leaked in which driver.

Confidence. The advisory text is consistent across the primary GitHub advisory and the duplicate advisory GHSA-5cwm-p7pj-gqp2, which was withdrawn as a duplicate of GHSA-qqj6-54q6-cxv6. The technical description is single-sourced to the GitHub Security Advisory; no independent vendor analysis or exploitation reporting was provided. Treat the mechanism as reported but unverified by a second party.

Related but separate. A second Snowflake driver advisory, GHSA-h6vc-8q8q-7wvw, describes improper OCSP response validation in the Python, Go, JDBC, and Node.js drivers, where a revoked TLS certificate could be accepted as valid and a man-in-the-middle holding that revoked certificate and its private key could read and modify data in the intercepted connection. It is a distinct flaw with a distinct fix path and is noted here only so it is not conflated with the logging defect. No fixed versions for it are given in the material provided.

4. Mitigation & containment

P1 (within 24 hours)

• Identify every application, batch job, notebook, and CI/CD pipeline that uses a Snowflake driver, and record the driver and version in use. The six affected ecosystems are Python, Go, JDBC (including snowflake-jdbc-fips and snowflake-jdbc-thin), Node.js, PHP PDO, and ODBC.
• Restrict read access to Snowflake driver log destinations now: local log directories on application and build hosts, the log aggregation service, and CI/CD artifact stores. Anyone who could read those logs during the exposure window may hold live credentials.
• Rotate Snowflake credentials and keys that could have been written to logs, and invalidate outstanding pre-signed cloud-storage URLs. Rotation is the control that closes the window; the source notes impact is bounded by credential lifetime, so shortening that lifetime removes the exposure.

P2 (within 72 hours)

• Upgrade to the fixed driver versions: Python v4.7.3, Go v2.2.0, JDBC v4.3.4, Node.js v3.3.0, PHP PDO v4.2.0, ODBC v3.20.0. The source states users must manually upgrade; there is no automatic path.
• Where an application cannot be upgraded immediately, disable diagnostic logging for the Snowflake driver until the upgrade lands, and confirm the setting actually takes effect for the affected log paths.
• Purge previously generated diagnostic logs that contain sensitive information, where retention is not required. The source directs secure deletion. Where retention is required, restrict access to those retained logs and treat their contents as compromised secrets.

P3 (within 7 days)

• Add driver version checks to the build pipeline so a downgrade or a stale pinned version is caught before deployment.
• Review log redaction configuration across all Snowflake integrations and confirm no other secret types are being written, given the source states redaction did not cover all paths and data types.
• Review the OCSP validation advisory GHSA-h6vc-8q8q-7wvw against the same driver inventory, since it affects an overlapping set of drivers.

5. Indicators of compromise

No indicators of compromise available in the source material. The source provides no hashes, domains, IP addresses, file paths, or command lines. This is a configuration and logging defect, not a malware artefact, so there are no atomic indicators to pivot on.

Behavioural indicators:

6. Detection

Insufficient indicators to author detection rules. The source contains no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, or hard-coded values that are artefacts of the defect itself. The only named artefacts are product and driver names and version numbers, which would detect reporting about the issue rather than the issue, so no YARA or Sigma rule is emitted.

Detection effort is better spent on log-content review: search driver diagnostic logs for the secret types named in the advisory (authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, SAML assertions) and on access review of the log destinations themselves.

7. Sources

• GitHub Security Advisories, "Snowflake drivers writes sensitive information to logs", https://github.com/advisories/GHSA-qqj6-54q6-cxv6, published 2026-10-05.
• GitHub Security Advisories, "Duplicate Advisory: Sensitive information written to logs by Snowflake drivers", https://github.com/advisories/GHSA-5cwm-p7pj-gqp2, withdrawn as a duplicate of GHSA-qqj6-54q6-cxv6.
• GitHub Security Advisories, "Improper OCSP response validation in the Snowflake Python, Go, JDBC, and Node.js drivers", https://github.com/advisories/GHSA-h6vc-8q8q-7wvw.

8. Adverse Trace position

No CVSS score, severity rating, or CISA KEV exploitation state was resolved for this item, so Adverse Trace does not assert a severity. The defect is real and the leaked secret types are high value, but exploitation requires pre-existing read access to a log destination and the impact is bounded by credential lifetime and object scope, which places it below a remotely exploitable authentication bypass in urgency. The technical description is single-sourced to the GitHub Security Advisory; we have no independent confirmation of the mechanism or of which log paths and data types escaped redaction, and we will update this advisory if a second source corroborates or contradicts it. Clients running Snowflake drivers in Python, Go, JDBC, Node.js, PHP PDO, or ODBC should treat any diagnostic log written by those drivers as a potential credential store and act on the P1 rotation and access-restriction steps first. Adverse Trace will monitor for exploitation reporting and for any revision to the advisory, and will reissue if the fixed versions or the affected driver list change.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.