Der Duo-Claude-Agent von GitLab konnte beliebige Befehle in der CI ausführen. Bislang hat niemand nachgewiesen, dass er tatsächlich zum Einsatz kam.

GitLab hat am 26. August 2026 korrigierte Releases für eine Schwachstelle mit hohem Schweregrad im Duo Claude AI Agent veröffentlicht, dem auf Claude basierenden Agenten, den der GitLab-Sicherheitshinweis in einen CI-Kontext einordnet. Die unter CVE-2026-18252 geführte Schwachstelle ermöglichte es einem authentifizierten Benutzer mit der Developer-Rolle, beliebige Befehle innerhalb eines CI-Jobs ausführen zu lassen, weil der Agent eine Konfiguration aus einer vom Benutzer kontrollierten Quelle verarbeitete, ohne deren Herkunft zu validieren. GitLab bewertete sie mit 7,3 auf der CVSS-3.1-Skala und begrenzte den betroffenen Bereich auf GitLab Enterprise Edition: Versionen 18.9 bis ausschließlich 19.1.7, 19.2 bis 19.2.5 und 19.3 bis 19.3.1. GitLab.com war bereits mit dem gepatchten Code in Betrieb, und Kunden von GitLab Dedicated wurde mitgeteilt, keine Maßnahmen ergreifen zu müssen. Keine für diesen Artikel geprüfte Quelle berichtet, dass jemand sie ausgenutzt hat, und es wurde kein Proof of Concept in öffentlich zugänglichen Quellen veröffentlicht. Der eigene Eintrag des Archivs zu diesem Vorfall mit seinen Schweregrad- und Vertrauensbewertungen befindet sich im Orca AI Incident Archive, zusammen mit den benachbarten Einträgen aus derselben Woche.

Was der Hinweis aussagt – und was er auslässt.

Das Hauptdokument ist kurz. Die am selben Tag veröffentlichten Patch-Release-Notes von GitLab für 19.3.1, 19.2.5 und 19.1.7 führen sieben Sicherheitskorrekturen auf. Die erste, mit „Hoch“ eingestuft, trägt die Überschrift „Einbeziehung von Funktionalität aus nicht vertrauenswürdiger Kontrollsphäre – Problem im Duo Claude AI agent betrifft GitLab EE“, und ihre Prosa-Beschreibung umfasst einen einzigen Satz. GitLab erklärt, es habe „ein Problem behoben, bei dem unter bestimmten Bedingungen ein authentifizierter Benutzer mit Berechtigungen der Entwicklerrolle beliebige Befehle in einem CI-Kontext hätte ausführen können, weil der Claude-Agent Konfiguration aus einer benutzergesteuerten Quelle verarbeitete“. Das ist die gesamte technische Beschreibung, die der Anbieter veröffentlicht hat.

Der CVE-Eintrag, den GitLab selbst zugewiesen hat, fügt Struktur statt Substanz hinzu. Er ordnet die Schwachstelle als CWE-829 ein, wiederholt die betroffenen Bereiche und den CVSS-Wert 7,3 und vermerkt, dass die Kennung am 29. Juli 2026 reserviert und am 26. August um 13:36 UTC veröffentlicht wurde. Der von GitLab gewürdigte Bug-Bounty-Bericht, HackerOne-Bericht 3863650, gab bei einem nicht authentifizierten Abruf am 29. Oktober 2026 einen 403 zurück, daher sind seine technischen Details nicht öffentlich, und der Tracker-Eintrag, den der CVE-Eintrag als Referenz verlinkt – gitlab-org/gitlab work item 607342 – enthielt bei dieser Überprüfung keinen lesbaren Issue-Inhalt.

Was der Sicherheitshinweis nicht sagt, ist genau der Teil, den ein Verteidiger wissen möchte. Er benennt weder das betroffene Duo-Feature noch das Konfigurationsfeld, das der Agent liest, noch die Form der vom Benutzer kontrollierten Quelle – ob eine Repository-Datei, eine Pipeline-Variable, ein Issue- oder Merge-Request-Kommentar oder ein API-Parameter. Nichts davon wird in GitLabs Hinweisen, im CVE-Eintrag oder in der für diesen Artikel geprüften Fachberichterstattung genannt. GitLabs Produktdokumentation beschreibt jedoch einen Claude-Weg in CI: externe Agents, die laut Dokumentation eine CI/CD-Pipeline ausführen, wenn sie in einem Issue, einem Epic oder einem Merge Request erwähnt werden, und für die ein Konfigurationsbeispiel für Claude Code existiert. Nichts von dem Geprüften verbindet diesen Weg mit CVE-2026-18252. Es ist Kontext dafür, warum ein Claude-Agent überhaupt CI-Berechtigungen besitzt, nicht der Mechanismus des Bugs.

{{1}}Dieselbe Dokumentation ist offen in Bezug auf die Risikoklasse. Die Seite zu externen Agenten von GitLab führt Prompt-Injection-Schwachstellen unter den Risiken auf, die Kunden durch das Aktivieren der Funktion akzeptieren, und beschreibt das von ihr implementierte Prompt-Scanning durch Drittanbieter als Gegenmaßnahme. Diese Seite erwähnt CVE-2026-18252 nicht, und die Warnung ist keine Beschreibung davon. Sie zeigt jedoch, dass nicht vertrauenswürdige Eingaben, die einen Agenten mit Pipeline-Zugriff erreichen, ein Risiko darstellen, das nach GitLabs eigener Dokumentation von Kunden bereits akzeptiert werden muss.{{/1}}

Der CI-Kontext ist der Ort, an dem sich die Zugangsdaten befinden.

Der Ausdruck, der die Schwere trägt, lautet „im CI-Kontext“. Ein Pipeline-Job ist keine Spielzeug-Sandbox; er läuft mit einem Runner-Token und sämtlichen Secrets, die das Projekt für ihn freigegeben hat. Cyber Security News listet in der Berichterstattung über den Patch vom 27. August 2026 auf, worauf solche Jobs üblicherweise Zugriff haben – Quellcode, Build-Artefakte, Deployment-Anmeldedaten, Cloud-Tokens und Anmeldedaten für Paket-Repositories – und merkt an, dass Befehlsausführung in einer Pipeline CI-Variablen offenlegen, Build-Artefakte verändern, Release-Workflows manipulieren oder weiter in verbundene Infrastruktur eindringen könnte, abhängig von der Konfiguration des Runners und dem Umfang des Tokens. Der Bericht von GBHackers vom selben Tag verwendet dieselbe Darstellung. Keine der beiden Publikationen berichtet von einem Fall, in dem das geschehen ist.

Diese Unterscheidung prägt, wie die Schwachstelle gelesen werden sollte. Dies ist ein Befehlsausführungsfehler in einer agentischen Komponente, keine Demonstration eines fehlverhaltenden Modells: Der Bericht beschreibt eine Konfiguration, die aus einer vom Benutzer kontrollierten Quelle übernommen wurde, und dass der Agent auf ihrer Grundlage handelt. Keine der geprüften Quellen beschreibt den Exploit als erfolgreiche Prompt-Injection, und GitLabs Sicherheitshinweis führt das Ergebnis nie auf eine Entscheidung des Modells zurück. Die dokumentierte Schwäche ist Code, der einer Konfigurationsquelle vertraut, der er nicht vertrauen sollte – CWE-829, Einbeziehung von Funktionalität aus einer nicht vertrauenswürdigen Kontrollsphäre.

Zwei CVSS-Scores und ein Interaktionsschritt

GitLabs 7.3 ist nicht der einzige Score, der an der Kennung hängt. Im selben NVD-Datensatz ist NISTs primäre Bewertung 8.1. Die beiden Vektoren sind bis auf eine Komponente identisch: GitLab markiert Benutzerinteraktion als erforderlich, NIST nicht. Beide Scores liegen im High-Bereich, sodass der praktische Unterschied weniger an der Schwere als an den Bedingungen liegt, unter denen der Fehler auftritt. CERT Santé, das Computer-Notfallteam des französischen Gesundheitsministeriums, veröffentlichte am 27. August 2026 eine Warnung, die GitLabs Lesart folgt – 7.3, erforderliche Benutzerinteraktion und ein Auslöser, der als eine Interaktion beschrieben wird, die die Konfigurationsverarbeitung in Gang setzt.

Die Ausnutzungssignale sind unauffällig, und jedes einzelne davon ist eine Auswertung der Aufzeichnungen und keine Telemetrie. Die SSVC-Bewertung, die die CISA-Koordinatorrolle am 26. August 2026 im NVD-Eintrag gespeichert hat, führt Ausnutzung als „none“, Automatisierbarkeit als „no“ und technische Auswirkung als „total“ auf. Das EPSS-Modell von FIRST bezifferte die Wahrscheinlichkeit einer Ausnutzung am 28. Oktober 2026 auf 0,00519 – etwas mehr als ein halbes Prozent – und ordnete sie dem 44. Perzentil der bewerteten Schwachstellen zu. Der Datensatz von OpenCVE enthält dieselbe EPSS-Zahl und listet die CVE als im Known Exploited Vulnerabilities-Katalog von CISA nicht enthalten. Der Alarm von CERT Santé verzeichnet „actively exploited: no“ und ergänzt, dass zu diesem Datum kein Proof of Concept in offenen Quellen vorhanden war. Nichts davon belegt, dass es niemand versucht hat; es ist das Fehlen jeglicher aufgezeichneten Versuche.

Mindestens ein Aggregator, Mallory, verbreitet für dieselbe Kennung einen Score von 8,7. Der NVD-Datensatz enthält überhaupt keine CVSS-4.0-Metrik – nur GitLabs 7,3 und NISTs 8,1 –, sodass sich dieser Wert aus keiner der geprüften Erstanbieterquellen reproduzieren lässt und hier nicht verwendet wird.

Was gilt als gesichert und was nicht

Das Archiv stuft diesen Eintrag mit Konfidenz A ein, nicht bestritten, und es ist kein tatsächlicher Schaden verzeichnet. Diese Einstufung entfaltet hier tatsächlich Wirkung: Die Dokumente stimmen miteinander überein, und keines von ihnen beschreibt einen Schaden. Die folgende Aufteilung ist der Teil, den eine einzeilige Zusammenfassung nicht wiedergeben kann.

• Festgestellt: Eine Schwachstelle im Duo Claude AI Agent ermöglichte es einer authentifizierten Developer-Rolle, beliebige Befehle in einem CI-Kontext auszuführen, weil der Agent die Konfiguration aus einer vom Benutzer kontrollierten Quelle verarbeitete. GitLab vergab CWE-829 und CVSS 7.3.

• Festgestellt: die betroffenen Bereiche und die Behebung — 18.9 bis 19.1.7, 19.2 bis 19.2.5, 19.3 bis 19.3.1, gepatcht am 26. August 2026 in 19.1.7, 19.2.5 und 19.3.1. Die Schwachstelle ist für GitLab EE erfasst; dasselbe Release hat auch CE gepatcht, wegen einer anderen Schwachstelle.

• Festgestellt: die Anerkennung des Melders thwin_htet über GitLabs HackerOne-Programm und den operativen Status, den GitLab den Kunden mitteilte — GitLab.com bereits gepatcht, GitLab Dedicated außerhalb des Umfangs der erforderlichen Maßnahme, selbstverwaltete Installationen wurden aufgefordert, sofort zu aktualisieren.

• Festgestellt: Es wurde keine Ausnutzung gemeldet. Die SSVC-Bewertung von CISA besagt, dass keine vorliegt; EPSS blieb bis Ende Oktober 2026 unter einem Prozent; die CVE ist laut OpenCVE nicht im KEV-Katalog; CERT Santé verzeichnete am Tag nach der Offenlegung keine aktive Ausnutzung.

• Zugeschrieben, nicht vom Anbieter bestätigt: Die Beschreibungen der Auswirkungen – Secrets lesbar, Artefakte veränderbar, Releases manipulierbar – sind die Darstellung der Berichterstattung darüber, was der Token-Berechtigungsumfang eines CI-Jobs allgemein erlaubt, und keine Feststellung, dass irgendetwas davon in diesem Fall geschehen ist. Cyber Security News und GBHackers formulieren sie beide mit „could“ und „depending on“; keine von beiden berichtet von einem konkreten Vorfall.

• Nicht festgestellt: welche Duo-Funktion und welches Konfigurationsfeld beteiligt waren und was die vom Benutzer kontrollierte Quelle tatsächlich war. Die Herstellererklärung benennt sie nicht.

• Nicht geklärt: wie viele selbst verwaltete Enterprise-Installationen sich in den betroffenen Bereichen befanden, wie viele nach dem 26. August 2026 aktualisiert wurden oder ob irgendwelche angegriffen wurden. Keine der überprüften Quellen misst die Verbreitung, und der Anbieter veröffentlichte keine Erkennungsmethode für Instanzen, die spät gepatcht wurden.

• Noch nicht geklärt: der technische Mechanismus. Nach GitLabs 90-Tage-Regel wird das Issue etwa Ende November 2026 öffentlich; bis dahin ist der verlinkte Tracker-Eintrag ein Verweis auf eine Erklärung, die öffentlich noch nicht existiert.

Die Reparatur, die Ausfallzeit und die 90-tägige Wartezeit

GitLab veröffentlichte am 26. August 2026 die Versionen 19.3.1, 19.2.5 und 19.1.7 sowohl für die Community- als auch für die Enterprise Edition und erklärte, es empfehle dringend, alle selbst verwalteten Installationen unverzüglich auf eine dieser Versionen zu aktualisieren. Der die Community Edition betreffende Teil der Veröffentlichung ist wichtig, weil eine weitere Schwachstelle im selben Paket – CVE-2026-77801, ein als 6,5 bewertetes Denial-of-Service-Problem in Import-Pipelines – sowohl CE als auch EE betrifft. CVE-2026-18252 selbst ist nur für die Enterprise Edition verzeichnet.

Es gibt keinen herstellerseitigen Workaround. Die Warnung von CERT Santé hält fest, dass kein Workaround existiert, und die Hinweise von GitLab bieten keinen; die einzige genannte Abhilfe ist das Upgrade. Auch dieses Release ist kein Drop-in. Es enthält reguläre Datenbankmigrationen in allen drei Versionen sowie Post-Deploy-Migrationen in 19.3.1 und 19.2.5, die laut GitLab bei Single-Node-Installationen zu Ausfallzeiten führen, während die Migrationen abgeschlossen werden. Bei Multi-Node-Deployments kann GitLabs Upgrade-Verfahren ohne Ausfallzeit verwendet werden.

Die anderen sechs Korrekturen verdienen einen Blick, denn eine davon liegt nahe am Thema dieses Eintrags. CVE-2026-15387, mit 4.3 bewertet und in denselben drei Versionen behoben, ermöglichte es einem authentifizierten Benutzer mit Berechtigungen der Entwicklerrolle, die Ausführungsumgebung von Durchsetzungsjobs der Pipeline Execution Policy durch unsachgemäße Behandlung von Job-Abhängigkeiten zu beeinflussen. Zwei Wege aus der Entwicklerrolle in die Jobausführung, einer mit hoher und einer mit mittlerer Einstufung, wurden im selben Patch geschlossen.

GitLabs Offenlegungsrichtlinie erklärt, warum der Mechanismus undurchsichtig bleibt. In den Patch Notes heißt es, dass die Issues, in denen die einzelnen Schwachstellen im Detail beschrieben werden, 90 Tage nach dem Release, in dem sie gepatcht wurden, im Issue-Tracker öffentlich gemacht werden. Vom 26. August 2026 an gerechnet fällt die technische Beschreibung für CVE-2026-18252 damit in die letzte Novemberwoche 2026. Bis dahin steht hinter dem Tracker-Verweis im CVE-Eintrag keine öffentliche technische Beschreibung, die dieser Artikel lesen könnte.

Wie dies im Vergleich zu GitLabs anderer Agent-Schwachstelle einzuordnen ist

GitLab hat am 2. Oktober 2026 eine zweite, separate agentenbezogene Schwachstelle offengelegt: CVE-2026-90970, bewertet mit 9,9, im AI Gateway statt im Duo Claude AI Agent und erreichbar über eine manipulierte Flow-Prompt-Vorlage statt über die CI-Konfiguration. Die beiden sind unterschiedliche Fehler in unterschiedlichen Komponenten mit unterschiedlichen Bewertungen, und das Archiv führt sie als getrennte Einträge. Was sie gemeinsam haben, ist die Form – eine KI-Komponente im Bereitstellungspfad, die auf Konfiguration einwirkt, die ein Benutzer mit geringeren Rechten beeinflussen kann – weshalb es sich lohnt, die Oktober-Schwachstelle neben dieser zu lesen und nicht an ihrer Stelle.

Für einen Betreiber ist die Entscheidung eng umgrenzt. Prüfen Sie die Version: 19.1.7, 19.2.5 und 19.3.1 sind die behobenen Releases, und alles in den drei genannten Versionsbereichen ist betroffen. Zwischenzeitlich gibt es keine Übergangslösung, und bis Ende November gibt es keine veröffentlichte technische Beschreibung, anhand derer sich eine spät gepatchte Instanz prüfen ließe. Was vorliegt, ist eine Aufzeichnung, in der niemand eine Ausnutzung gemeldet hat – was eine Aussage über das Fehlen von Beweisen ist, nicht eine Zusicherung des Herstellers, dass kein Vorfall stattgefunden hat.