AI Gateway GitLaba pozwolił spreparowanej konfiguracji Flow wydostać się z jego piaskownicy promptów.

2 października 2026 r. GitLab opublikował krytyczną wersję poprawkową dla swojego AI Gateway — oprogramowania pośredniczącego, które przekazuje żądania między instancją GitLab a modelami językowymi wywoływanymi przez funkcje Duo — przypisując jej oznaczenie CVE-2026-90970 i oceniając ją na 9,9 na 10. Według samego GitLab luka mogła pozwolić „uwierzytelnionemu użytkownikowi mającemu dostęp do Duo Agent Platform na ucieczkę z piaskownicy szablonów promptów za pomocą specjalnie spreparowanej konfiguracji przepływu, co prowadzi do wykonania dowolnych poleceń w AI Gateway”. Działać musiały tylko organizacje używające samodzielnie hostowanego AI Gateway: GitLab naprawił już bramy, którymi zarządza dla GitLab.com, GitLab Dedicated i klientów samodzielnie zarządzających swoimi systemami, którzy korzystają z bramy hostowanej przez GitLab, i poinformował o tym w biuletynie. W komunikacie GitLab nie stwierdzono, że luka kiedykolwiek została wykorzystana, a dołączona tego samego dnia przez amerykańską Agencję ds. Cyberbezpieczeństwa i Infrastruktury do rekordu CVE ocena określa wykorzystanie jako „brak”. Za odkrycie uznano badacza HackerOne znanego jako invisiblemeerkat. Biuletyn GitLab, rekord NVD i doniesienia, które po nim nastąpiły, są ze sobą spójne co do tego, czym była luka i które wersje ją zawierały; są równie spójne co do tego, czego nie wiadomo, czyli czy ktokolwiek kiedykolwiek ją wykorzystał. Ten wpis znajduje się obok innych udokumentowanych luk w infrastrukturze agentów w archiwum incydentów AI, gdzie każdy wpis zawiera własne źródła, poziom istotności, stopień pewności i oznaczenie sporności.

Co tak naprawdę mówi komunikat doradczy, a co pomija

Biuletyn bezpieczeństwa jest krótki. Opublikowany w witrynie dokumentacji GitLab pod tytułem „Krytyczne wydanie poprawek GitLab AI Gateway: 19.2.4, 19.3.2 i 19.4.1”, wymienia jedną poprawkę bezpieczeństwa zatytułowaną „Problem nieprawidłowej neutralizacji w szablonie promptu niestandardowego przepływu wpływa na AI Gateway” i oznaczoną jako krytyczną. Podaje wektor CVSS 3.1 jako AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — osiągalny sieciowo, niska złożoność ataku, wymagane niskie uprawnienia, brak interakcji użytkownika, zmieniony zakres oraz wysoki wpływ na poufność, integralność i dostępność. Ten wektor warto przeczytać, ponieważ precyzyjnie określa atakującego: niskie uprawnienia, ale jednak uprawnienia. W biuletynie napisano „uwierzytelniony użytkownik z dostępem do Duo Agent Platform” i na tym poprzestaje. Nie podaje nazwy roli, uprawnienia ani warunków, do których odnosi się jego własne sformułowanie „w pewnych warunkach”.

Nie publikuje dowodu koncepcji, nie opisuje spreparowanej konfiguracji przepływu i nie oferuje obejścia dla bram, których nie można natychmiast zaktualizować. Hacker News w swoim raporcie z 2 października zauważa te same braki i dodaje jeden, który ma znaczenie operacyjne: biuletyn nie podaje sposobu sprawdzenia, czy brama została zaatakowana, zanim ją załatano. Security Affairs, pisząc dzień później, odnotowuje te same luki.

Wpis wspólnej enumeracji słabości dołączony do CVE to CWE-1336, niewłaściwa neutralizacja elementów specjalnych używanych w silniku szablonów. W biuletynie GitLaba nigdy nie pojawia się słowo Jinja. W dokumentacji samego repozytorium AI Gateway — owszem: jego dokument dotyczący rejestru promptów opisuje pliki konfiguracji promptów, które „obsługują wyrażenia Jinja dla wielu ról, takich jak użytkownik i system”, oraz opisuje klasę Prompt, która „używa Jinja do interpolacji szablonów promptów z argumentami wejściowymi”. Luka opisana w CVE to ta, z której słynie ta klasa silników — tekst dostarczony przez użytkownika docierający do szablonu, który jest ewaluowany, a nie wyświetlany.

Dlaczego komenda na tym konkretnym hoście jest warta 9,9

AI Gateway nie jest kontenerem typu sidecar. Zgodnie z dokumentacją GitLaba dotyczącą wdrożeń self-hosted odbiera on żądania z GitLaba, składa prompty i komunikuje się z backendem modelu — serwerem vLLM, Amazon Bedrock, Azure OpenAI lub zewnętrznym dostawcą — a w pełni self-hosted wdrożeniu to właśnie ten komponent odpowiada za to, by prompty i odpowiedzi pozostawały w sieci organizacji. Przewodnik GitLaba po instalacji AI Gateway zaleca też administratorom wygenerowanie pary kluczy podpisujących i przekazanie obu połówek do usługi jako zmiennych środowiskowych: AIGW_SELF_SIGNED_JWT__SIGNING_KEY oraz AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (z odpowiednikami dla Duo Workflow). Security Affairs jasno wskazuje na konsekwencje: wykonanie polecenia na bramie umieszcza atakującego na hoście, który przechowuje materiał do podpisywania JWT i znajduje się na ścieżce między instancją GitLab a infrastrukturą modeli.

To jest różnica między ucieczką z piaskownicy w zabawce a taką w środowisku produkcyjnym. Ucieczka nie musi docierać do modelu; musi docierać do procesu, który przechowuje klucze, którymi podpisywane są wywołania modelu.

Dokumentacja produktu GitLab, niezależnie od biuletynu, stwierdza, że tworzenie lub edycja niestandardowego przepływu wymaga roli Maintainer lub Owner w projekcie zarządzającym, a jego uruchomienie wymaga roli Developer lub wyższej. Biuletyn nie potwierdza tego przypisania, a {{1}}The Hacker News{{/1}} zauważa, że nie wymieniono żadnej roli poza „dostępem do Duo Agent Platform”. Czytelnik szacujący własną ekspozycję powinien traktować dokumentację jako model uprawnień produktu, a milczenie biuletynu dokładnie jako to: milczenie, a nie sprzeczność.

Ustanowione i nieustanowione

Pola samego rekordu są spójne z wszystkim powyższym i nie wnoszą niczego, czego nie ma w komunikacie. To, co następuje, to podział, którego czytelnik nie uzyska z jednozdaniowego podsumowania.

• Ustalono: krytyczna luka w GitLab AI Gateway, ujawniona 2 października 2026 r., CVSS 9.9, CWE-1336, możliwa do wykorzystania przez uwierzytelnionego użytkownika Duo Agent Platform za pośrednictwem spreparowanej konfiguracji przepływu, w wyniku czego dochodzi do wykonania poleceń na hoście bramy.

• Ustalono: zakres objętych problemem wersji — wszystkie wersje AI Gateway od 18.1.6 do wersji przed 19.2.4, od 19.3 do wersji przed 19.3.2 oraz od 19.4 do wersji przed 19.4.1 — a także wersje poprawione: 19.2.4, 19.3.2 i 19.4.1.

• Ustanowiono: Bramy hostowane przez GitLab zostały załatane przed publikacją, a ich klienci nie muszą podejmować żadnych działań; operatorzy self-hosted zostali bezpośrednio powiadomieni przed wpisem o wydaniu, co GitLab stwierdza w samej poradzie bezpieczeństwa.

• Ustalono: uznanie dla zgłaszającego, invisiblemeerkat, oraz brak jakiegokolwiek oświadczenia o wykorzystaniu w środowisku rzeczywistym.

• Nie ustalono:czy ktokolwiek to wykorzystał. Ocena CISA SSVC z 2 października 2026 r., widoczna w rekordzie NVD, określa eksploatację jako „brak”, automatyzowalność jako „nie”, a wpływ techniczny jako „całkowity”; katalog CISA Known Exploited Vulnerabilities nie wymieniał CVE-2026-90970 w swojej wersji z 20 października 2026 r., co sprawdziłem bezpośrednio. Model EPSS FIRST szacował prawdopodobieństwo wykorzystania w ciągu najbliższych 30 dni na 0,94 procent na 21 października 2026 r. — niskie, ale nie zerowe.

• Nie ustalono: ile istnieje bram hostowanych samodzielnie, ile było narażonych ani czy jakiekolwiek zostały zaatakowane przed wdrożeniem poprawki. Żadne źródło w tym zapisie nie podaje liczby, a biuletyn GitLaba nie podaje metody wykrywania.

Zakres, którego dotyczy problem, oraz wersje bez podanej poprawki

Arytmetyka wersji jest mniej uporządkowana, niż sugerują trzy poprawione wydania. Zakres objęty problemem zaczyna się od {{1}}18.1.6{{/1}}, a żadne poprawione wydanie nie zostało opublikowane w żadnej linii poniżej {{2}}19.2.4{{/2}}. Każda brama od {{3}}18.1.6{{/3}} aż po {{4}}serię 19.1{{/4}} znajduje się zatem w podanym zakresie objętym problemem, bez wskazanej dla niej poprawionej wersji. The Hacker News zwraca uwagę na tę samą konsekwencję i wynikające z niej pytania: dokumentacja instalacyjna GitLab zaleca administratorom uruchamianie obrazu bramy, którego wersja odpowiada ich wersji podrzędnej GitLab, a biuletyn nie mówi, czy brama {{5}}19.2.4{{/5}} działa z GitLab {{6}}19.1{{/6}} lub starszym, ani czy planowane są poprawki dla starszych linii. Polityka obsługiwanych wersji GitLab, jak zauważa The Hacker News, obecnie wymienia {{7}}19.4{{/7}}, {{8}}19.3{{/8}} i {{9}}19.2{{/9}} — te same trzy linie, które otrzymały poprawki.

Remediacja polega na podmianie kontenera, a nie na łataniu: bramka jest dostarczana jako osobny obraz Docker lub wykres Helm. Przewodnik instalacji GitLaba opisuje zatrzymanie i usunięcie działającego kontenera, pobranie nowego obrazu z tagiem self-hosted-vX.Y.Z-ee i ponowne uruchomienie go z nienaruszonymi zmiennymi środowiskowymi; wdrożenia Helm ustawiają tag w polu image wykresu. Ani biuletyn doradczy, ani przewodnik instalacji nie podają sygnatury ani wskaźnika, który pozwoliłby odróżnić zaatakowaną bramkę od czystej.

Ta sama klasa błędów, osiem miesięcy wcześniej

To nie pierwszy raz, gdy GitLab przyznał ocenę 9,9 za wstrzyknięcie szablonu w AI Gateway. 6 lutego 2026 r. wydał AI Gateway 18.6.2, 18.7.1 i 18.8.1 dla CVE-2026-1868, opisany w tym biuletynie jako „Insecure Template expansion issue”, w którym komponent Duo Workflow Service był „podatny na niebezpieczne rozwijanie szablonów danych dostarczanych przez użytkownika poprzez spreparowane definicje Duo Agent Platform Flow”, co można wykorzystać do odmowy usługi lub wykonania kodu na bramie. Wektor CVSS jest identyczny jak w październiku, znak po znaku, podobnie jak CWE. Zgłaszający był inny: ten został znaleziony wewnętrznie przez członka zespołu GitLab, Joerna Schneeweisza.

Październikowy biuletyn doradczy nie wspomina o lutowym, a The Hacker News mówi to wprost. Czy oba łączy ta sama pierwotna przyczyna, poprawka, która nie zadziałała, czy jedynie język i model zagrożeń — na to nie odpowiada żaden z tych publicznych dokumentów. Odnotowany fakt jest taki, że silnik szablonów w komponencie pośredniczącym AI zaowocował już dwoma krytycznymi biuletynami doradczymi dotyczącymi wykonania poleceń o tej samej ocenie w tym samym roku, a drugi z nich wymagał znalezienia przez zewnętrznego badacza.

Co się zmieniło i co pozostaje do zdecydowania przez operatorów

Konkretna zmiana to trzy tagi obrazów i bezpośrednia runda kontaktu. GitLab twierdzi, że skontaktował się z klientami korzystającymi z samodzielnie hostowanej bramy przed publikacją, a komunikat bezpieczeństwa opublikowano wraz z poprawionymi obrazami tego samego dnia. Dla wszystkich pozostałych — GitLab.com, GitLab Dedicated i instancji self-managed wskazujących na bramę hostowaną przez GitLab — poprawka została już zastosowana po stronie serwera i, według GitLaba, nie trzeba było nic robić.

Dla operatora hostującego rozwiązanie samodzielnie decyzja jest węższa i mniej komfortowa niż w normalnym cyklu łatek. Nie ma obejścia dla bramy, której nie można natychmiast przenieść. Nie opublikowano żadnej metody ustalenia, czy host został wcześniej przejęty, co oznacza, że jedyną opcją retrospektywną jest ta zwykła: traktować kontener jako system, którego integralność nie została potwierdzona, i szukać oznak wykonania poza jego normalnym zachowaniem. A w przypadku bram działających na 18.x lub 19.1 biuletyn nie wskazuje żadnej wersji docelowej — pominięcie, o którym donosi The Hacker News, a którego komunikat GitLab nie uwzględnia.

Własna klasyfikacja archiwum jest celowo węższa niż klasyfikacja dostawcy. Wpis ten jest w nim odnotowany jako luka w zabezpieczeniach, z pewnością A, przy zgodnych źródłach, bez sporów, bez odnotowanych rzeczywistych szkód i z polem ważności „high” wobec „critical” w GitLab i NVD. To odpowiedzi na różne pytania: ocena opisuje, co luka by umożliwiała, a ocena archiwum opisuje, co wiadomo, że się wydarzyło. W publicznym zapisie nic się nie wydarzyło — brak wykorzystania, brak ofiar, brak raportu o incydencie. Wartość wpisu polega na tym, że dokumentuje — za pomocą numeru CVE i wersji z poprawką — dokładnie, jak szablon promptu stał się wierszem poleceń w oprogramowaniu pośredniczącym, od którego zależą funkcje AI dla przedsiębiorstw.