GitLabs AI Gateway lät en specialkonstruerad flödeskonfiguration ta sig ur sin prompt-sandbox

Den 2 oktober 2026 publicerade GitLab en kritisk patchutgåva för sin AI Gateway – mellanprogramvaran som förmedlar förfrågningar mellan en GitLab-instans och de språkmodeller som dess Duo-funktioner anropar – och angav CVE-2026-90970 samt bedömde den till 9,9 av 10. Bristen kunde, med GitLabs egna ord, ha gjort det möjligt för "en autentiserad användare med åtkomst till Duo Agent Platform att ta sig ur sandlådan för promptmallar via en specialbyggd flödeskonfiguration, vilket leder till godtycklig kommandokörning på AI Gateway." Endast organisationer som kör en självhostad AI Gateway behövde vidta åtgärder: GitLab hade redan åtgärdat de gatewayer som företaget driver för GitLab.com, GitLab Dedicated och självhanterade kunder som använder en GitLab-hostad gateway, och angav detta i rådgivningen. GitLabs meddelande säger inte att bristen någonsin utnyttjades, och den bedömning som US Cybersecurity and Infrastructure Security Agency samma dag bifogade CVE-posten anger utnyttjande som "none". Äran för upptäckten tillföll HackerOne-forskaren som kallas invisiblemeerkat. GitLabs rådgivning, NVD-posten och rapporteringen som följde efter den stämmer överens med varandra om vad bristen var och vilka versioner som innehöll den; de är lika samstämmiga om vad som inte är känt, nämligen huruvida någon någonsin använde den. Denna post finns tillsammans med de andra dokumenterade sårbarheterna i agentinfrastruktur i AI-incidentarkivet, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistad status.

Vad rådgivningen faktiskt säger, och vad den utelämnar

Säkerhetsrådgivningen är kort. Den publicerades på GitLabs dokumentationswebbplats under titeln "GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2, and 19.4.1" och listar en säkerhetsfix, med rubriken "Improper Neutralization issue in custom flow prompt template impacts AI Gateway" och markerad som Critical. Den anger CVSS 3.1-vektorn som AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H – nätverksåtkomlig, låg attackkomplexitet, låga privilegier krävs, ingen användarinteraktion, ändrat omfång och hög påverkan på konfidentialitet, integritet och tillgänglighet. Den vektorn är värd att läsa eftersom den är precis om angriparen: låga privilegier, men privilegier ändå. Säkerhetsrådgivningen säger "en autentiserad användare med åtkomst till Duo Agent Platform" och stannar där. Den anger inte rollen, behörigheten eller de villkor som dess egen formulering "under vissa förutsättningar" syftar på.

Den publicerar inte ett proof of concept, beskriver inte den specialkonstruerade flödeskonfigurationen och erbjuder ingen tillfällig lösning för gateways som inte kan uppdateras omedelbart. The Hacker News noterar i sin rapport från 2 oktober samma saknader och lägger till en som har operativ betydelse: rådgivningen ger inget sätt att kontrollera om en gateway attackerades innan den patchades. Security Affairs, som skrev dagen därpå, noterar samma luckor.

Posten i Common Weakness Enumeration som är kopplad till CVE:n är CWE-1336, otillbörlig neutralisering av specialelement som används i en mallmotor. GitLabs säkerhetsmeddelande använder aldrig ordet Jinja. AI Gateways egen dokumentation i kodförvaret gör det: dess dokument för promptregistret beskriver promptkonfigurationsfiler som "stöder Jinja-uttryck för flera roller, såsom användare och system", och beskriver en Prompt-klass som "använder Jinja för att interpolera promptmallarna med indataargumenten". Den brist som CVE:n beskriver är den som den typen av motor är känd för – användartillförd text som når en mall som utvärderas i stället för att skrivas ut.

Varför ett kommando på just den här värden är värt 9,9

AI Gateway är inte en sidecar. Enligt GitLabs dokumentation för självhostade installationer tar den emot förfrågningar från GitLab, sätter ihop prompterna och kommunicerar med modellbackend – en vLLM-server, Amazon Bedrock, Azure OpenAI eller en extern leverantör – och i en helt självhostad driftsättning är den den komponent som håller prompter och svar kvar inom organisationens eget nätverk. GitLabs installationsguide för AI Gateway uppmanar också administratörer att generera ett signeringsnyckelpar och skicka de två halvorna till tjänsten som miljövariabler, nämligen AIGW_SELF_SIGNED_JWT__SIGNING_KEY och AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (med motsvarande variabler för Duo Workflow). Security Affairs gör konsekvensen tydlig: kommandokörning på gatewayen placerar en angripare på en värd som innehåller JWT-signeringsmaterial och ligger på vägen mellan GitLab-instansen och modellinfrastrukturen.

Det är skillnaden mellan en sandlådeescape i en leksak och en i produktion. Escapen behöver inte nå en modell; den behöver nå processen som innehar nycklarna som modellanropen signeras med.

GitLabs produktdokumentation anger, separat från säkerhetsrådgivningen, att det krävs rollen som Maintainer eller Owner i det hanterande projektet för att skapa eller redigera ett anpassat flöde, och att det krävs Developer eller högre för att köra ett. Säkerhetsrådgivningen bekräftar inte den mappningen, och The Hacker News noterar att ingen roll nämns utöver "Duo Agent Platform access". En läsare som bedömer sin egen exponering bör betrakta dokumentationen som produktens behörighetsmodell och säkerhetsrådgivningens tystnad som just det: tystnad, inte en motsägelse.

Etablerad, och inte etablerad

Postens egna fält stämmer överens med allt ovan och tillför inget som inte finns i rådgivningen. Det som följer är den uppdelning som en läsare inte kan få från en sammanfattning på en rad.

• Etablerat: en sårbarhet med kritisk allvarlighetsgrad i GitLab AI Gateway, avslöjad den 2 oktober 2026, CVSS 9,9, CWE-1336, som kan nås av en autentiserad Duo Agent Platform-användare via en specialkonstruerad flödeskonfiguration, vilket leder till kommandokörning på gateway-värden.

• Fastställt: det berörda intervallet – alla AI Gateway-versioner från 18.1.6 före 19.2.4, 19.3 före 19.3.2 och 19.4 före 19.4.1 – samt de åtgärdade versionerna 19.2.4, 19.3.2 och 19.4.1.

• Fastställt:GitLab-värdbaserade gatewayer patchades före publiceringen och deras kunder behöver inte vidta några åtgärder; operatörer med egen installation kontaktades direkt före releaseinlägget, vilket GitLab anger i själva rådgivningen.

• Fastställt: krediten till rapportören, till invisiblemeerkat, och avsaknaden av något uttalande om utnyttjande i det vilda.

• Ej fastställt: om någon har utnyttjat det. En CISA SSVC-bedömning daterad 2 oktober 2026 och synlig i NVD-posten anger utnyttjande som "inget", automatiserbar som "nej" och teknisk påverkan som "total"; CISA:s katalog Known Exploited Vulnerabilities listade inte CVE-2026-90970 i sin revision av den 20 oktober 2026, vilket jag kontrollerade direkt. FIRST:s EPSS-modell satte sannolikheten för utnyttjande under de kommande 30 dagarna till 0,94 procent den 21 oktober 2026 — låg, och inte noll.

• Inte fastställt: hur många självhostade gateways som finns, hur många som var exponerade eller om några attackerades före patchning. Ingen källa i den här posten anger något antal, och GitLabs säkerhetsbulletin innehåller ingen metod för upptäckt.

Det drabbade intervallet och de versioner där ingen rättning har angetts

Versionsaritmetiken är mindre prydlig än vad de tre åtgärdade versionerna antyder. Det påverkade intervallet börjar vid 18.1.6, och ingen åtgärdad version har publicerats på någon linje under 19.2.4. Varje gateway från 18.1.6 till och med 19.1-serien ligger därför inom det angivna påverkade intervallet utan att någon patchad version namnges för den. The Hacker News uppmärksammar samma konsekvens och frågorna som följer: GitLabs installationsdokumentation säger till administratörer att köra den gateway-avbildning vars version matchar deras GitLab-minorversion, och rådgivningen säger inte om en 19.2.4-gateway fungerar mot GitLab 19.1 eller tidigare, eller om åtgärder för de äldre linjerna är planerade. GitLabs policy för versioner som stöds listar, som The Hacker News noterar, för närvarande 19.4, 19.3 och 19.2 — samma tre linjer som fick åtgärder.

Åtgärden är ett containerbyte snarare än en patch: gatewayen levereras som en egen Docker-image eller Helm-chart. GitLabs installationsguide beskriver hur man stoppar och tar bort den körande containern, hämtar den nya imagen med taggen self-hosted-vX.Y.Z-ee och startar den igen med miljövariablerna intakta; Helm-distributioner anger taggen i chartets image-fält. Varken säkerhetsmeddelandet eller installationsguiden erbjuder en signatur eller indikator som skulle skilja en angripen gateway från en oangripen.

Samma buggklass, åtta månader tidigare

Detta är inte första gången GitLab har släppt en 9,9 för mallinjektion i AI Gateway. Den 6 februari 2026 släppte GitLab AI Gateway 18.6.2, 18.7.1 och 18.8.1 för CVE-2026-1868, som i den rådgivningen beskrevs som ett ”osäkert problem med mallutvidgning” där komponenten Duo Workflow Service var ”sårbar för osäker mallexpansion av användardata via manipulerade Duo Agent Platform Flow-definitioner”, och som kunde användas för överbelastningsattack eller kodkörning på gatewayen. CVSS-vektorn är identisk med oktober månads, tecken för tecken, och detsamma gäller CWE. Rapportören var en annan: den hittades internt av GitLab-teammedlemmen Joern Schneeweisz.

Rådgivningen från oktober nämner inte den från februari, och The Hacker News säger det uttryckligen. Huruvida de två delar en grundorsak, en åtgärd som inte höll, eller bara ett språk och en hotmodell, är inte något som någon av de offentliga dokumenten besvarar. Det som är dokumenterat är att en mallmotor i en AI-mellanvarukomponent nu har producerat två kritiska säkerhetsrådgivningar om kommandoexekvering med samma poäng samma år, och att den andra krävde att en extern forskare hittade den.

Vad har förändrats, och vad återstår för operatörerna att besluta

Den konkreta ändringen är tre image-taggar och en direkt kontaktrunda. GitLab säger att de kontaktade kunder med egenhostade gateways före publiceringen, och säkerhetsmeddelandet gavs ut tillsammans med de åtgärdade imageerna samma dag. För alla andra – GitLab.com, GitLab Dedicated och egenhanterade instanser som pekar på en GitLab-hostad gateway – hade åtgärden redan tillämpats på serversidan och enligt GitLab krävdes ingenting.

För en självhostad operatör är beslutet snävare och mindre bekvämt än en normal patchcykel. Det finns ingen tillfällig lösning för en gateway som inte kan flyttas omedelbart. Det finns ingen publicerad metod för att fastställa huruvida värden hade komprometterats i förväg, vilket innebär att det enda retrospektiva alternativet är det vanliga: behandla containern som ett system vars integritet är obevisad och leta efter tecken på exekvering utanför dess normala beteende. Och för gatewayer på 18.x eller 19.1 anger säkerhetsrådgivningen ingen målversion alls – en utelämning som The Hacker News rapporterar och som GitLab:s meddelande inte tar upp.

Arkivets egen klassificering är avsiktligt snävare än leverantörens. Den registrerar den här posten som en sårbarhet, med konfidens A, eniga och inte ifrågasatta källor, ingen registrerad faktisk skada och ett allvarlighetsfält på "high" mot GitLabs och NVD:s "critical". De är svar på olika frågor: poängen beskriver vad bristen skulle tillåta, och arkivets betyg beskriver vad som är känt att ha hänt. I den offentliga dokumentationen hände ingenting – ingen exploatering, inga offer, ingen incidentrapport. Värdet med posten är att den dokumenterar, med ett CVE-nummer och en åtgärdad version, exakt hur en promptmall blev en kommandorad i mellanvaran som AI-funktioner för företag är beroende av.