LONDON (IT BOLTWISE) – In einer GitHub-Actions-Workflowdatei des Snowflake-Connector-Repository konnten angreifende Nutzer per manipulierter Issue-Titel beliebige Befehle im CI/CD-Runner ausführen. Dadurch gelang es im Rahmen eines autorisierten Tests, Jira-Zugangsdaten wie API-Token und Projekt-URLs auszulesen und zu exfiltrieren. Die Sicherheitslücke wurde nach ihrer Entdeckung innerhalb weniger Stunden behoben und betroffene Tokens anschließend rotiert. Offen bleibt zunächst, wie das Risiko künftig durch strengere Eingabeprüfung und Workflowschablonen reduziert werden kann.
In einer CI/CD-Umgebung reicht manchmal schon ein einziges unsauber behandeltes Feld, damit aus einem harmlosen Automationsschritt ein Ausleitungskanal wird. Genau das zeigt sich bei einer Schwachstelle im GitHub-Actions-Workflow .github/workflows/jira_issue.yml des öffentlich einsehbaren Repositories snowflakedb/snowflake-connector-net, das von Snowflake gepflegt wird. Die Verantwortlichen beschreiben, dass der Workflow nicht authentifizierte Angreifer zulassen konnte, indem er bei geöffneten Issues („opened“ Event) gestartet wurde und dabei Issue-Titel direkt in einen Shell-Block interpolierte. Damit kippte ein Teil der Sicherheitsannahme „untrusted input bleibt in einem Textkontext“ ins Gegenteil: Der Inhalt konnte Shell-Metacharaktere enthalten und damit den beabsichtigten Befehlskontext sprengen.
Technisch betrachtet lag der Kernfehler im Umgang mit attacker-controlled input: Der Workflow setzte eine Variable TITLE aus dem Issue-Titel zusammen, führte anschließend Sed-Ersetzungen durch und übergab diese Zeichenkette dann in einen Shell-Run-Block. Laut Quellbeschreibung erfolgte die Verarbeitung dabei durch einen run: |-Abschnitt, in dem der Issue-Titel über eine GitHub-Expression direkt in den Shell-Code floss. Der Auslöser war eine Änderung, die über den Merge eines Pull Requests am 18. Juni 2026 in den Branch gelangte und ein zuvor „sichereres“ Muster ersetzt haben soll. Statt eines Ansatzes mit Zwischenspeicherung über Environment Variables und jq –arg wurde stärker auf direkte String-Expansion gesetzt. Für Angriffe ist das entscheidend, weil Shell-Interpretation nicht nur auf Whitespace achtet, sondern auch auf Zeichen, die Befehlsgrenzen definieren.
Im Ergebnis konnte ein Angreifer über die Gestaltung eines Issue-Titels Shell-Metazeichen so einstreuen, dass der eigentliche Echo-/Sed-Teil nicht mehr isoliert blieb. Der Proof-of-Concept, der im Rahmen der Recherche von Wiz’ „Red Agent“ erstellt wurde, nutzte laut Beschreibung eine Injektion, um anschließend curl aufzurufen und Jira-Token sowie weitere Parameter zu exfiltrieren. Als Exfiltrationsziel wird eine OAST-Domäne („oast.me“) genannt, wobei das Skript die Werte in Base64 verpackt, bevor sie in der URL landen. Gleichzeitig nennt der Bericht den konkreten Runner-IP-Hinweis „Azure IP 20.106.182.197“ aus dem Ablauf, wodurch klar wird, dass nicht nur eine abstrakte Theorie vorlag, sondern dass der Workflow während des Tests tatsächlich die Jira-Variablen abrief, die im CI-System hinterlegt waren.
Welche Informationen betroffen waren, beschreibt der Fall ebenfalls konkret: Es wurden unter anderem JIRA_API_TOKEN sowie JIRA_USER_EMAIL (genannt als [email protected]) und JIRA_BASE_URL (genannt als snowflakecomputing.atlassian.net) offengelegt. Diese Kombination gibt Angreifern in der Logik solcher Workflows typischerweise ausreichend Rechte, um in den jeweiligen Jira-Projektbereichen Workflows zu lesen oder Tickets zuzuordnen – im Bericht ist von Read-Zugriffen auf Engineering-, Security-Compliance- und Bug-Bounty-bezogene Jira-Projekte die Rede. Besonders relevant für die Sicherheitsplanung ist zudem, dass der Zeitraum begrenzt war: Der Workflow wurde am selben Tag gepatcht, der Jira-Token wurde am 24. Juni 2026 rotiert, und die Veröffentlichung sollte nach der beschriebenen Richtlinie bis zum 25. Juli 2026 warten. Laut Bericht gab es in dieser Phase zwar eine fünf Tage dauernde Exponierung im Sinne des Fensters, aber keine Hinweise auf eine später festgestellte missbräuchliche Nutzung durch Dritte.
Die Chronologie verdeutlicht, wie schnell ein solcher Fehler organisatorisch adressiert werden kann – und zugleich, wie problematisch die Zwischenzeit ist. Der Bericht nennt: Merge der problematischen Änderung am 18. Juni 2026 (per PR #1218), Entdeckung und Nutzung durch „Red Agent“ am 23. Juni 2026, Meldung über HackerOne (Report #3819931) und anschließendes Patchen am selben Tag (PR #1402). Danach folgte die Rotation des Jira-Tokens am 24. Juni 2026. Für Teams, die CI/CD-Pipelines betreiben, ergibt sich daraus eine praktische Lehre: Selbst wenn die Exfiltration „nur“ im Testfall nachgewiesen wird, müssen Geheimnisse so entworfen werden, dass sie im Exploit-Fall zumindest schnell genug entwertet werden. Ergänzend betont der Bericht, dass keine CVE und kein Eintrag in der CISA KEV (wie zum 17. August 2026 angegeben) verzeichnet waren und auch keine CISA-bestätigte Ausnutzung vorliege.
Auch unabhängig von dieser konkreten Codezeile lässt sich der Fall als Warnsignal für den Entwicklungsprozess lesen. Der Text stellt explizit den Bezug zu KI-gestützter Codeunterstützung her, etwa im Sinne von GitHub Copilot, und argumentiert, dass automatisiert erzeugte Workflows in sicherheitskritischen Kontexten eine strenge Überprüfung brauchen. Gleichzeitig liefert die Beschreibung eine gut passende Gegenmaßnahme, die sich in vielen CI/CD-Standards wiederfindet: Untrusted Daten dürfen nicht direkt in Shell-Syntax expandiert werden. Stattdessen soll man Zwischenvariablen über sichere Mechanismen aufbauen und parsing-orientierte Werkzeuge wie jq –arg verwenden, um das Risiko von Shell-Injektion systematisch zu senken. Für die Praxis heißt das: Code-Reviews müssen nicht nur „Logik prüfen“, sondern auch prüfen, ob Datenflüsse wirklich im richtigen Kontext bleiben – und ob Runner-Secrets so segmentiert sind, dass eine Kompromittierung nicht gleichbedeutend mit weitreichendem Zugriff ist.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Snowflake-Connector: Command Injection in GitHub Actions legt Jira-Token offen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Snowflake-Connector: Command Injection in GitHub Actions legt Jira-Token offen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Snowflake-Connector: Command Injection in GitHub Actions legt Jira-Token offen« bei Google Deutschland suchen, bei Bing oder Google News!