Leuffen.deBlog

Security · Snowflake-Treiber für Python, Go, Java, Node.js, PHP und ODBC

Snowflake-Treiber konnten Zugangsdaten in Diagnoselogs schreiben

relevant

Ein Token ist eine zeitlich oder sachlich begrenzte digitale Zugangsberechtigung. Mehrere Snowflake-Treiber konnten solche Tokens, signierte Speicher-URLs und Schlüssel in Diagnoselogs schreiben; ausnutzen lässt sich das nur mit Leserechten auf das Logziel.

CVE
CVE-2026-86597
Betroffen
Snowflake Connector for Python vor 4.7.3; Go Driver bis einschließlich 1.19.1 sowie 2.0.0 bis vor 2.2.0; JDBC-Treiber einschließlich FIPS- und Thin-Ausgabe vor 4.3.4; Node.js Driver vor 3.3.0; PHP PDO Driver 3.4.0 bis vor 4.2.0; ODBC Driver 3.16.0 bis vor 3.20.0
Behoben
Python 4.7.3; Go-v2-Zweig 2.2.0, für den betroffenen Go-1.x-Zweig nennt der CVE-Datensatz keine korrigierte 1.x-Version; JDBC einschließlich FIPS und Thin 4.3.4; Node.js 3.3.0; PHP PDO 4.2.0; ODBC 3.20.0

Snowflake ist eine Cloud-Datenplattform; ihre Treiber verbinden Anwendungen verschiedener Programmiersprachen mit Snowflake-Datenbanken und angeschlossenen Speicherdiensten. Diagnoselogs sind ausführliche Protokolle, die Entwickler und Betreiber bei Verbindungs-, Anmelde- oder Dateiübertragungsfehlern einschalten. CVE-2026-86597 betrifft deren Filterung: Nicht jeder Protokollpfad und nicht jeder Typ geheimer Daten wurde zuverlässig bereinigt.

Ein Token ist eine zeitlich oder sachlich begrenzte digitale Zugangsberechtigung. Solche Anmeldetokens, Schlüssel für verschlüsselte Abfrageergebnisse und vorsignierte Speicher-URLs konnten im Klartext in Protokollen landen. Eine vorsignierte URL trägt eine zeitlich und sachlich begrenzte Zugriffsberechtigung direkt in ihrer Adresse. Außerdem nennt der Hersteller SAML-Assertions – digital übertragene Anmeldebestätigungen – als möglichen Loginhalt.

Wer solche Daten liest, kann sie möglicherweise verwenden, solange sie noch gültig sind. Reichweite und Schaden hängen deshalb von der Lebensdauer und den Berechtigungen des jeweiligen Tokens, Schlüssels oder Speicherlinks ab.

Warum die Meldung relevant, aber nicht kritisch ist

CVSS ist ein standardisiertes Schema zur Bewertung der technischen Schwere einer Schwachstelle. Snowflake bewertet CVE-2026-86597 nach CVSS 3.1 mit 6,5 – Medium. Die Bewertung berücksichtigt, dass ein Angreifer bereits geringe lokale beziehungsweise organisatorische Zugriffsrechte benötigt und dass vor allem die Vertraulichkeit betroffen ist.

Im Blog-Radar lautet die Stufe deshalb relevant. Das mögliche Geheimnis im Log kann wertvoll sein, doch die Schwachstelle verschafft nicht selbst den Zugang zum Logziel. Erst vorhandene Leserechte auf eine lokale Datei, einen zentralen Protokolldienst oder ein CI-Artefakt machen die offengelegten Daten erreichbar.

So kann die Schwachstelle im Betrieb sichtbar werden

Eine Dateiübertragung zu Snowflake schlägt fehl oder eine Anmeldung funktioniert nur sporadisch. Ein Entwickler aktiviert deshalb den Debug- oder Trace-Modus des Treibers. Die Anwendung schreibt nun ausführliche Verbindungsdaten in eine lokale Datei; alternativ sammelt eine CI-Pipeline das Protokoll als Artefakt oder leitet es an einen zentralen Logdienst weiter.

Für den Anwender bleibt der ursprüngliche Verbindungsfehler sichtbar. Im Hintergrund kann das Diagnoseprotokoll jedoch vollständige Headerwerte, signierte URLs oder Schlüssel enthalten. Später liest ein Support-Nutzer, ein Entwickler mit zu weit gefassten Logrechten oder ein Angreifer mit bereits erlangtem Zugriff auf den Artefaktspeicher dieses Protokoll.

Sind die enthaltenen Daten noch gültig, können sie den Zugriff auf das zugehörige Snowflake-Konto oder ein bestimmtes Speicherobjekt ermöglichen. Das eigentliche Warnsignal ist daher nicht eine besondere Anzeige in der Anwendung, sondern die Kombination aus eingeschaltetem ausführlichem Logging und zu breit lesbaren oder zu lange aufbewahrten Protokollen.

Welche Logstellen Snowflake konkret geändert hat

Snowflake dokumentiert für den Node.js- und den Go-Treiber mehrere treiberspezifische Beispiele. Dazu gehören die AWS-Parameter X-Amz-Credential und X-Amz-Security-Token, Schlüssel für kundenseitig verschlüsselte S3-Übertragungen sowie SAS-Parameter in signierten Azure-Speicheradressen. SAS steht hier für „Shared Access Signature“, also eine Zugriffsberechtigung innerhalb einer Azure-URL.

Die korrigierten Treiber schreiben bei bestimmten Speicherantworten nur noch die Namen von Headern in das Debug-Log und entfernen Abfrageparameter aus protokollierten URLs. Beim PHP-PDO-Treiber nennt Snowflake die Korrektur von Zugangsdaten in diagnostischen Trace-Ausgaben. PDO ist PHPs einheitliche Programmierschnittstelle für Datenbanktreiber.

Diese Zeichenfolgen sind Beispiele für die Prüfung von Snowflake-Treiberlogs, keine allgemeine Liste aller Geheimnisse. Gefundene Werte sollten nicht in Tickets, Chats oder zusätzliche Diagnosekopien übernommen werden.

Betroffene und korrigierte Versionen

Der von Snowflake veröffentlichte CVE-Datensatz nennt sechs Treiberfamilien:

  • Python Connector: betroffen vor 4.7.3, korrigiert ab 4.7.3
  • Go Driver 2.x: betroffen ab 2.0.0 und vor 2.2.0, korrigiert ab 2.2.0
  • Go Driver 1.x: betroffen bis einschließlich 1.19.1; eine korrigierte 1.x-Version nennt der Datensatz nicht
  • Java-Treiber über JDBC: betroffen vor 4.3.4, korrigiert ab 4.3.4
  • Node.js Driver: betroffen vor 3.3.0, korrigiert ab 3.3.0
  • PHP PDO Driver: betroffen ab 3.4.0 und vor 4.2.0, korrigiert ab 4.2.0
  • ODBC Driver: betroffen ab 3.16.0 und vor 3.20.0, korrigiert ab 3.20.0

JDBC und ODBC sind standardisierte Schnittstellen, über die Java- beziehungsweise andere Anwendungen Datenbanktreiber verwenden. Snowflake führt bei JDBC zusätzlich eine für bestimmte Kryptografievorgaben gebaute FIPS-Ausgabe und eine schlankere Thin-Ausgabe; beide sind ebenfalls ab 4.3.4 korrigiert.

Für den Go-1.x-Zweig sollte nicht einfach ein unbekannter Fix angenommen werden. Betreiber müssen auf einen vom Hersteller unterstützten korrigierten Zweig wechseln oder eine konkrete Herstellerfreigabe für ihre eingesetzte Variante einholen.

Was jetzt sinnvoll ist

Zuerst gehört die tatsächlich verwendete Treiberversion in jeder Anwendung, jedem Worker und jedem CI-Werkzeug ins Inventar. Danach sollte auf mindestens die jeweils dokumentierte korrigierte Ausgabe aktualisiert werden.

Der zweite Schritt betrifft bereits erzeugte Daten: Diagnoseprotokolle, Supportpakete und CI-Artefakte aus dem betroffenen Zeitraum sollten auf die von Snowflake beschriebenen Logpfade und Parameter geprüft werden. Wo keine Aufbewahrung erforderlich ist, empfiehlt Snowflake das sichere Löschen. Bei einem konkreten Fund sollte die betroffene Zugangsinformation widerrufen oder erneuert werden; bloßes Löschen der Datei macht eine zuvor kopierte Berechtigung nicht ungültig.

Dauerhaft sollten ausführliche Protokolle nur zeitlich begrenzt aktiviert, restriktiv lesbar und nicht automatisch an breit erreichbare Artefaktspeicher übertragen werden. Automatisches Entfernen geheimer Werte bleibt sinnvoll, ersetzt aber keine knappen Zugriffsrechte und kurze Aufbewahrungszeiten.

In den bis zum 12. September 2026 geprüften Primärquellen wird keine aktive Ausnutzung bestätigt. Diese Aussage bezieht sich nur auf den veröffentlichten Quellenstand; sie schließt unerkannte oder nicht veröffentlichte Vorfälle nicht aus.

Quellen

Quellenstand: 12. September 2026.

Originalmeldung öffnen →