Der Fehler entstand dadurch, dass der Workflow vom Angreifer kontrollierte Werte aus Titel und Text eines GitHub-Issues direkt in einen Shell-Block vom Typ run: einfügte. Zugleich prüfte der Ablauf github.event.pull_request.user.login, obwohl das auslösende Ereignis ein Issue war. GitHub dokumentiert dazu, dass der Versuch, auf eine nicht existierende Eigenschaft zuzugreifen, zu einer leeren Zeichenfolge ausgewertet wird. Dadurch verhinderte der Vergleich mit whitesource-for-github-com[bot] nach Angaben der Quelle nicht, dass ein gewöhnliches Issue den Job erreichte.
Wiz erklärte, das hauseigene System Red Agent habe die Injection im Rahmen autorisierter Sicherheitstests ausgenutzt. Nachdem ein erster Nutzdatenversuch zu einem Shell-Syntaxfehler geführt hatte, habe das System seinen Ansatz geändert. Anschließend hätten die Forscher einen Rückruf außerhalb des eigentlichen Kanals vom GitHub-Actions-Runner erhalten und das vom Workflow verwendete Jira-API-Token erlangt.
Laut Wiz gehörte dieses Token zu qa@snowflake.net. Es erlaubte Lesezugriff auf Jira-Projekte unter snowflakecomputing.atlassian.net, darunter Bereiche für Engineering, Security-Compliance und Bug-Bounty-Tracking. Die zugrunde liegenden Jira-Berechtigungen, die Ausführung des Workflows und Audit-Aufzeichnungen sind laut Quelle nicht öffentlich einsehbar.
Wiz meldete den Fehler nach eigenen Angaben am 23. Juni 2026 über HackerOne an Snowflake, unter der Meldungsnummer 3819931. Snowflake spielte noch am selben Tag eine Korrektur in Pull Request #1402 ein. Dabei wurde die direkte Auswertung von GitHub-Ausdrücken durch Umgebungsvariablen ersetzt, die als Argumente an jq übergeben werden.
In den Standard-Branch gelangte der verwundbare Workflow fünf Tage zuvor, am 18. Juni, mit dem Merge von Pull Request #1218. Die korrigierte Behandlung befindet sich weiterhin im master-Branch des Repositories. Wiz zufolge wurde das Jira-Token am 24. Juni rotiert. Snowflake habe bei seiner Prüfung keine externe Nutzung des Tokens außerhalb dieses Zusammenhangs während des fünftägigen Expositionsfensters festgestellt. Die zugrunde liegenden Audit-Logs von Snowflake wurden nicht veröffentlicht.
Wiz führte die Schwachstelle auf eine Änderung durch GitHub Copilot Autofix zurück. Der zugrunde liegende GitHub-Verlauf belegt laut Quelle jedoch nicht, dass Copilot die verwundbaren Zeilen in jira_issue.yml verfasst hat. Der ausdrücklich von Copilot mitverfasste Commit 6d0e2fa änderte jira_close.yml, während das unsichere Refactoring von jira_issue.yml in einem separaten Commit vom 25. August 2025 auftaucht, 094038e, den GitHub sfc-gh-hpathak zuschreibt. Beide Änderungen gingen später in den Squash-Merge-Commit 4a1b8ce vom 18. Juni ein, der Copilot Autofix unter den Mitautoren aufführt. Damit ist eine Beteiligung von Copilot an Pull Request #1218 bestätigt, nicht aber die Urheberschaft der verwundbaren Codezeilen.
GitHub hatte diese Klasse von Workflow-Injections bereits im Juli 2025 dokumentiert und davor gewarnt, nicht vertrauenswürdige Issue-Daten direkt in run:-Blöcken auszuwerten. Empfohlen wurden stattdessen zwischengeschaltete Umgebungsvariablen. Bis zum 17. August 2026 wurde für den Fall laut Quelle weder eine CVE-Nummer noch ein CVSS-Wert oder ein Eintrag im Katalog der bekannten ausgenutzten Schwachstellen von CISA gefunden. Ebenso wurde kein Release-Update des Connectors identifiziert, das damit verknüpft wäre. Nach dem verfügbaren Primärmaterial gibt es zudem keinen Beleg für böswillige Ausnutzung in freier Wildbahn oder eine Kompromittierung von Kunden.