Eine Konfiguration öffnete die falsche Tür
Tenable nennt den 2. Oktober 2026 als Veröffentlichungsdatum der kritischen Lücke in der selbst betriebenen GitLab-Komponente AI Gateway. Ein angemeldeter Nutzer mit entsprechendem Zugang konnte eine eigens präparierte Ablaufkonfiguration einreichen. Unter bestimmten Bedingungen verließ diese Eingabe die vorgesehene Schutzumgebung und veranlasste den Rechner, auf dem das Gateway lief, beliebige Befehle auszuführen. Das ist erheblich, auch ohne einen rebellierenden Agenten im Maschinenraum. [1] [2] [3]
Betroffen waren selbst betriebene Installationen des Gateways: alle Ausgaben ab 18.1.6 vor 19.2.4, die Reihe 19.3 vor 19.3.2 sowie 19.4 vor 19.4.1. GitLab stellte diese drei korrigierten Ausgaben bereit und empfahl betroffenen Kunden, sofort zu aktualisieren. Für von GitLab selbst betriebene Gateways war die Korrektur bereits eingespielt. Nutzer von GitLab.com, GitLab Dedicated und selbst verwalteten GitLab-Instanzen mit einem von GitLab betriebenen Gateway mussten laut Anbieter nichts tun. [1]
Wie die Schutzgrenze versagte
Der Fehler lag in einer Vorlage, mit der Abläufe und Eingaben für das System zusammengesetzt werden. Solche Vorlagen enthalten feste Bestandteile und veränderliche Felder. Eine sogenannte Sandbox soll dabei wie ein abgesperrter Arbeitsbereich verhindern, dass eine Konfiguration auf den restlichen Rechner zugreift. GitLab zufolge konnte eine speziell gestaltete Konfiguration diesen Bereich verlassen. Aus Daten, die lediglich einen Ablauf beschreiben sollten, konnten dadurch Anweisungen an das Betriebssystem werden. Die Trennwand war also vorhanden, hielt aber nicht. [1] [3]
Die Schwachstelle trägt die Kennung CVE-2026-90970; GitLabs Meldung nennt eine kritische Risikobewertung von 9,9. Ein Angriff erforderte demnach ein gültiges Benutzerkonto mit Zugriff auf die Duo Agent Platform, aber keine weitere Mitwirkung eines Opfers. Bei erfolgreicher Ausnutzung wären Vertraulichkeit, Unversehrtheit und Verfügbarkeit des betroffenen Rechners stark gefährdet gewesen. Die Bewertung beschreibt mögliches Schadenspotenzial; sie belegt weder eine Ausnutzung noch einen tatsächlich eingetretenen Schaden. [1] [2] [3]
Was tatsächlich beobachtet wurde
Belegt sind die Schwachstelle, ihre betroffenen Versionsbereiche, die bereitgestellten Korrekturen und GitLabs Warnung an Kunden. GitLab berichtet außerdem, ausgewählte Betreiber selbst gehosteter Gateways bereits vor der öffentlichen Meldung gezielt kontaktiert zu haben. Die Quellen nennen jedoch keinen erfolgreichen Angriff, keine übernommenen Rechner, keine entwendeten Daten und keine betroffenen Personen. Auch ein öffentlich vorgeführter Machbarkeitsnachweis wird im belastbaren Primärmaterial nicht beschrieben. Es handelt sich daher um eine Sicherheitswarnung, nicht um einen dokumentierten Einbruch. [1]
Ebenso wichtig ist, wer hier handelt: Die beschriebene Angriffskette beginnt mit einem angemeldeten Nutzer, der eine manipulierte Konfiguration bereitstellt. Die Quellen dokumentieren nicht, dass ein KI-Agent diese Konfiguration eigenständig entwickelte, einreichte oder anschließend Befehle auswählte. Ob bei der möglichen Erstellung einer solchen Eingabe KI-Unterstützung denkbar wäre, bleibt völlig offen. Für CQ1818 reicht ein Bauteil mit „AI“ im Namen nicht als Autonomiebeweis. Unsere Messlatte hat damit immerhin eine Tür erfolgreich abgewehrt. [1] [2] [3]
Warum die Lücke trotzdem ernst ist
Beliebige Befehle auf einem Server ausführen zu können, gehört zu den folgenreichsten Arten von Sicherheitslücken. Wer die nötigen Zugangsrechte besitzt und den Fehler erfolgreich nutzt, könnte grundsätzlich Programme starten, Dateien verändern oder Dienste stören. Welche konkreten Möglichkeiten bestanden, hing jedoch von den Rechten und der Einrichtung des jeweiligen Gateway-Rechners ab; dazu liefern die Quellen keine Einzelheiten. Deshalb lässt sich das hohe technische Risiko benennen, nicht aber ein bestimmter tatsächlich entstandener Schaden oder eine konkrete Zahl gefährdeter Betreiber. [1] [3]
Die Meldung zeigt außerdem ein nüchternes Problem bei KI-Infrastruktur: Nicht nur das Sprachmodell selbst braucht Grenzen. Auch die Programme, die Eingaben zusammensetzen, Abläufe verwalten und mit Rechnern verbinden, müssen fehlerhafte oder absichtlich präparierte Daten sicher behandeln. Hier versagte genau eine solche technische Grenze. Das macht die Lücke für ein Magazin über außer Kontrolle geratende KI relevant, ohne sie zu einem Fall eigenwilliger KI umzudeuten. Ein kaputtes Gehege beweist noch nicht, dass etwas ausbrechen wollte. [1] [3]
Was Betreiber wissen müssen – und was offenbleibt
GitLab fordert Betreiber selbst gehosteter AI Gateways in betroffenen Versionsständen zum Wechsel auf 19.2.4, 19.3.2 oder 19.4.1 auf. Wer stattdessen ein von GitLab betriebenes Gateway verwendet, war laut Hersteller bereits geschützt. Die Meldung nennt keine Übergangslösung, die ein Update gleichwertig ersetzen würde. Sie sagt auch nicht, wie viele Installationen betroffen waren oder ob verdächtige Konfigurationen entdeckt wurden. Aus dem veröffentlichten Material lässt sich deshalb weder die Verbreitung noch eine praktische Angriffshäufigkeit seriös ableiten. [1]
Der 2. Oktober 2026 ist das von Tenable genannte Veröffentlichungsdatum und wird durch den Zeitstempel bei OpenCVE gestützt. Er ist nicht automatisch das Datum der Entdeckung, einer möglichen ersten Ausnutzung oder der internen Fehlerbehebung. GitLab dankt einem unter dem Namen „invisiblemeerkat“ auftretenden Hinweisgeber für die verantwortliche Meldung, nennt aber keinen Entdeckungszeitpunkt. Die ergänzenden Quellen wiederholen überwiegend GitLabs Beschreibung. Eine unabhängige technische Analyse oder Bestätigung realer Angriffe liegt im Material nicht vor. [1] [2] [3]
Terminator-Check
Der Terminator-Score beträgt 0 von 5. Autonomie, Grenzüberschreitung, Täuschung, Selbsterhaltung und Realweltwirkung durch einen KI-Agenten sind jeweils nicht belegt. Zwar konnte die technische Sandbox laut Hersteller umgangen werden, doch die Quellen schreiben diesen Schritt einer speziell gestalteten Konfiguration eines angemeldeten Nutzers zu. Sie beobachten keine selbst entwickelte Strategie und keine ausgeführte Aktion eines Agenten. Die verwundbare KI-Infrastruktur ist damit ein ernstes Sicherheitsproblem, aber kein Nachweis autonomen Fehlverhaltens. [1] [2] [3]
Die organisatorische Realweltwirkung ist davon getrennt zu betrachten: GitLab veröffentlichte Updates, spielte die Korrektur in seinen eigenen Gateways ein, kontaktierte Kunden und empfahl selbstständigen Betreibern eine sofortige Aktualisierung. Diese Maßnahmen reagieren auf eine mögliche Angriffskette, nicht auf dokumentierte Eigeninitiative des Systems. Der Nullwert bedeutet deshalb ausdrücklich nicht, dass die Lücke harmlos war. Er bedeutet nur, dass unser Terminator-Messgerät diesmal keine handelnde KI erfasst hat. Die gewöhnliche IT-Sicherheit hatte trotzdem ausreichend Arbeit. [1]
Podcast