GitLab heeft een critical beveiligingslek bekendgemaakt in de AI Gateway. De GitLab AI Gateway kwetsbaarheid (CVE-2026-90970) kan, in bepaalde situaties, leiden tot command execution op self-hosted gateways. Dit raakt vooral organisaties die hun eigen gateway draaien, en vraagt om snelle updates.
GitLab publiceerde de advisory op 2 oktober. De fout kreeg een CVSS-score van 9.9/10 en valt volgens GitLab in dezelfde categorie als eerdere problemen met flow-templates. Of er al misbruik is gemaakt, meldt GitLab niet.
Wat is de GitLab AI Gateway?
Een AI Gateway is de schakel tussen een GitLab-instantie en AI-modellen. Waar GitLab AI-verzoeken doorstuurt, verzorgt de gateway de verbinding met modelproviders en verwerkt het de bijbehorende communicatie.
Belangrijk detail: alleen organisaties die hun gateway zelf hosten, moeten actie ondernemen. Wie een GitLab-hosted gateway gebruikt (bijvoorbeeld via GitLab.com of GitLab Dedicated), hoeft volgens GitLab niet te wijzigen.
Waar gaat het lek over (CVE-2026-90970)?
De kern van de GitLab AI Gateway kwetsbaarheid zit in het prompt template van een custom flow. Een custom flow is een door gebruikers ontworpen AI-gestuurde workflow die multi-step taken automatiseert via de Duo Agent Platform-omgeving.
GitLab stelt dat een ingelogde gebruiker met toegang tot het Duo Agent Platform onder voorwaarden de prompt-template sandbox kan omzeilen via een speciaal gemaakte flow-configuratie. Als die omzeiling lukt, kan dat resulteren in willekeurige command execution op de gateway.
De advisory geeft geen concrete omschrijving van de voorwaarden en noemt geen specifieke rolnaam behalve de Duo Agent Platform-toegang. Daardoor is het voor beheerders lastig om “inschatten of we al geraakt zijn” te vervangen door “wacht rustig af”.
Wie loopt er risico?
Volgens GitLab ligt het risico bij:
- Self-managed klanten die hun eigen GitLab AI Gateway hosten
- Self-hosted setups die een gatewayversie draaien die nog in het getroffen bereik valt
Niet nodig volgens GitLab:
- Klanten op GitLab.com
- Klanten met GitLab Dedicated
- Self-managed omgevingen die een GitLab-hosted gateway gebruiken
Welke versies moeten worden geüpdatet?
GitLab vermeldt vaste versies voor de AI Gateway. De kwetsbaarheid is opgelost in gatewayversies:
- 19.2.4
- 19.3.2
- 19.4.1
Er wordt geen “fixed version” opgegeven voor versies onder 19.2.4. Dat betekent dat (volgens GitLab’s beschrijving) gatewayreleases vanaf 18.1.6 tot en met de 19.1-lijn binnen het bereik vallen dat mogelijk kwetsbaar is.
Verder adviseert GitLab beheerders om de gateway-image te gebruiken die overeenkomt met hun GitLab minor version. De advisory zegt niet expliciet of een fixed gateway uit de 19.2-lijn ook werkt met GitLab 19.1 of ouder, en noemt ook geen planning voor oudere lijnen.
Waarom is dit extra gevoelig?
Een self-hosted gateway houdt volgens GitLab ondertekeningssleutels voor JSON Web Tokens (JWT). GitLab’s installatiegids behandelt die sleutels als gevoelig.
Daarnaast verbindt de gateway de organisatie met zowel de GitLab-instantie als de AI-modelproviders. Dat maakt de gateway in de praktijk een strategisch punt in de keten: als een aanvaller controle krijgt over de omgeving waar de gateway draait, kan dat impact hebben op meerdere schakels.
Geen workaround, wel updateadvies
In de advisory staat geen workaround voor situaties waarin update niet meteen mogelijk is. Ook ontbreekt een methode om vooraf te controleren of een gateway vóór het patchen al is misbruikt.
GitLab geeft bovendien aan dat het al eerder guidance verstuurde aan klanten met self-hosted gateways, voordat de advisory openbaar werd. Dat is een aanwijzing dat GitLab het risico serieus neemt en dat een “later doen” waarschijnlijk niet past bij een veilige responscyclus.
Hoe kun je de gateway bijwerken?
De advisory beschrijft hoe je updates uitvoert, afhankelijk van de manier waarop de gateway is uitgerold:
Docker-deployment
- Stop en verwijder de draaiende container
- Haal daarna de nieuwe image-tag op en start die opnieuw
- GitLab gebruikt als voorbeeld: self-hosted-v19.4.1-ee
Helm-deployment
- Pas in de Helm chart de image tag aan
- Voer vervolgens je gebruikelijke Helm updateproces uit
Let op: de gateway draait als eigen Docker-image of als Helm-chart. Dat betekent dat je bij het plannen van onderhoud niet alleen naar GitLab zelf kijkt, maar ook naar de gatewaycomponent als zelfstandige release.
Is er al misbruik gezien?
GitLab geeft geen informatie over daadwerkelijke exploitatie in aanvallen. Wel heeft CISA op 2 oktober een beoordeling toegevoegd aan het CVE-dossier.
CISA vermeldt exploitation als “none”. CISA kent daarnaast andere waarden toe voor een publieke proof of concept of actieve exploitatie, maar die worden in dit geval niet genoemd.
Ook al is “none” een geruststellende categorie, het blijft verstandig om het incident te behandelen als een echte kans op misbruik, zeker omdat de advisory aangeeft dat een omzeiling van de prompt-template sandbox kan leiden tot command execution.
Vergelijkbare problemen: template-engine klas
De GitLab AI Gateway kwetsbaarheid behoort tot dezelfde klasse als een eerder probleem met de gateway, namelijk een template-engine weakness met de code CWE-1336.
GitLab refereert daarbij aan een eerdere fix uit februari (CVE-2026-1868). Ook dat incident kon volgens GitLab via een crafted flow-definition leiden tot denial of service of code execution op de gateway.
In deze nieuwste advisory wordt die februari-fout niet verder besproken, maar het verband helpt beheerders om sneller te begrijpen waarom de aandacht voor flow-templates zo groot is.
Wat kun je nu praktisch doen?
Voor teams die self-hosted gateways draaien, is de volgende volgorde logisch:
- Bepaal welke gatewayversie je draait en op welke manier (Docker of Helm)
- Update naar één van de GitLab fixed versies (19.2.4, 19.3.2 of 19.4.1)
- Beoordeel wie toegang heeft tot Duo Agent Platform binnen jouw organisatie
- Herzie je beleid rond custom flows en flow-configuraties
Daarnaast is het nuttig om je bredere securityhouding rond AI-workflows te herijken. Dat sluit aan bij een groeiende trend: AI-gedreven automatisering vergroot het belang van veilige integraties en sterke grenzen tussen “input” en “uitvoering”.
Wil je weten hoe dit soort AI- en flow-risico’s samenhangt met andere securityproblemen in de praktijk? Lees dan ook Bron: https://thehackernews.com/2026/10/gitlab-patches-critical-self-hosted-ai.html
