Zabezpieczanie GitLab AI Gateway przed zdalnym wykonaniem kodu

Duże przedsiębiorstwa wydają miliony na izolację swoich obciążeń AI za prywatnymi zaporami ogniowymi i samodzielnie hostowanymi bramami. Oczekują one pełnej kontroli nad przepływem danych i wzmocnionego obwodu ochrony przed zewnętrznymi zagrożeniami. Rzeczywista podatność GitLab AI Gateway w wersji 19.4 pokazuje jednak, że nawet najbardziej odizolowane środowiska pozostają podatne na proste błędy w danych wejściowych. Pojedynczy zalogowany użytkownik z dostępem do platformy Duo Agent Platform może ominąć piaskownicę (sandbox), która powinna ograniczać prompty AI. Ta ucieczka prowadzi bezpośrednio do wykonania dowolnych poleceń na serwerze zarządzającym połączeniem organizacji z dużymi modelami językowymi.

Spędziłem lata analizując, jak programiści traktują silniki szablonów jako strefy bezpieczne. Istnieje powszechne błędne przekonanie, że jeśli użytkownik jest już uwierzytelniony, ryzyko ucieczki z piaskownicy jest drugorzędne. Takie myślenie jest niebezpieczne. W przypadku CVE-2026-90970 GitLab ocenił lukę na 9,9 w 10-stopniowej skali CVSS. Ten wynik jest jasnym wskaźnikiem, że społeczność zajmująca się bezpieczeństwem postrzega to jako krytyczną awarię. Błąd ten nie jest subtelnym uszkodzeniem pamięci ani złożonym atakiem czasowym. Jest to błąd w szablonie promptu niestandardowego przepływu – funkcji zaprojektowanej do automatyzacji wieloetapowych zadań.

Ryzyko architektoniczne związane z wrażliwymi kluczami podpisywania

GitLab AI Gateway działa jak niezniszczalny cyfrowy skarbiec dla połączenia między wewnętrzną instancją GitLab a zewnętrznymi dostawcami AI. Z założenia brama ta przechowuje klucze podpisywania JSON Web Tokens (JWT). Klucze te są wrażliwymi poświadczeniami ułatwiającymi bezpieczną komunikację. Jeśli napastnik wykona polecenia na bramie, nie jest już tylko użytkownikiem w piaskownicy. Posiada te same uprawnienia, co sama usługa bramy. Taki poziom dostępu pozwala złośliwemu aktorowi na przechwytywanie żądań lub potencjalną manipulację odpowiedziami AI, na których polegają inni programiści w firmie podczas generowania kodu i skanowania bezpieczeństwa.

Z perspektywy ryzyka wpływ jest systemowy. Samodzielnie hostowana brama jest często wybierana właśnie po to, aby utrzymać dane w kontrolowanym środowisku. Gdy ta brama zostanie skompromitowana, samo narzędzie mające zwiększać prywatność staje się przyczółkiem dla większej intruzji. Brama łączy się z dostawcami modeli AI organizacji oraz z główną instancją GitLab. Kompromitacja w tym miejscu jest naruszeniem relacji zaufania między środowiskiem programistycznym a warstwą inteligencji, która je zasila.

Dekonstrukcja ucieczki z piaskownicy poprzez wstrzykiwanie promptów

Techniczna rzeczywistość tej luki tkwi w CWE-1336, która dotyczy niewłaściwej neutralizacji dyrektyw w szablonach stron internetowych. GitLab pozwala użytkownikom tworzyć niestandardowe przepływy na platformie Duo Agent Platform. Przepływy te wykorzystują szablony promptów do strukturyzowania sposobu, w jaki AI przetwarza informacje. Użytkownik z legalnym dostępem może przygotować taką konfigurację przepływu, która oszuka silnik szablonów i zmusi go do wykonania kodu poza zamierzonymi granicami. Jest to klasyczna ucieczka z piaskownicy. System traktuje złośliwe dane wejściowe atakującego jako polecenie, a nie jako dane.

Za kulisami brama nie sprawdza poprawnie struktury szablonu promptu. Pamiętam podobny przypadek, który omawiałem z etycznym hakerem przez Signal w zeszłym roku. Przyglądaliśmy się silnikowi szablonów, który pozwalał użytkownikom wywoływać funkcje systemowe, jeśli zagnieździli nawiasy w określony sposób. Było to proste przeoczenie w parserze. Niedawna historia GitLab sugeruje, że jest to powracający motyw. W lutym załatano CVE-2026-1868, inną lukę o ocenie 9,9, która również dotyczyła spreparowanych definicji przepływów. Powtarzalność tej klasy podatności wskazuje, że bezpieczeństwo szablonów pozostaje trudną przeszkodą dla platform zintegrowanych z AI.

Ocena powierzchni ataku dla instancji samodzielnie hostowanych

Działać muszą tylko organizacje, które hostują własną bramę AI Gateway. GitLab zarządza bramą dla klientów korzystających z GitLab.com i GitLab Dedicated. Mówiąc proaktywnie, ci klienci są już chronieni, ponieważ GitLab zaktualizował własną infrastrukturę przed publicznym ogłoszeniem. Ciężar obrony spoczywa teraz na barkach administratorów systemów, którzy zarządzają własnymi obrazami Docker lub wykresami Helm.

Na poziomie architektonicznym brama jest samodzielną usługą. Nie aktualizuje się automatycznie podczas aktualizacji głównej instancji GitLab. To rozdzielenie jest istotne. Częstą pułapką jest zakładanie, że załatana aplikacja GitLab Rails oznacza załatane środowisko AI. Brama to oddzielny obraz Docker z własną wersją i cyklem życia. Jeśli korzystasz z wersji między 18.1.6 a 19.2.4 lub dowolnej wersji z linii 19.3 i 19.4 sprzed najnowszych wydań, jesteś podatny na atak.

Ręczne kroki aktualizacji dla Docker i Helm

Łatanie jest jedynym skutecznym środkiem zaradczym, ponieważ GitLab nie dostarczył obejścia problemu. Aby zabezpieczyć wdrożenie oparte na Dockerze, należy zatrzymać istniejący kontener i go usunąć. Następnie należy pobrać zaktualizowany tag obrazu. Dla większości użytkowników korporacyjnych będzie to tag self-hosted-v19.4.1-ee lub jego odpowiednik dla linii 19.2 i 19.3.

Dla osób korzystających z Kubernetes proces obejmuje aktualizację ustawienia obrazu w wykresie Helm. Poniższa tabela podsumowuje niezbędne ścieżki aktualizacji dla dotkniętych wersji:

Polityka konserwacji GitLab zazwyczaj obejmuje bieżące i dwa poprzednie wydania minor. W związku z tym poprawki są dostępne dla linii 19.2, 19.3 i 19.4. Jeśli korzystasz ze starszej wersji, takiej jak 19.1, nie ma wymienionej oficjalnej poprawki. Ten brak wsparcia dla starszych wersji to szczegół, którego administratorzy nie mogą przeoczyć. Uruchamianie niewspieranej wersji bramy to w rzeczywistości pozostawienie cyfrowego skarbca otwartym.

Ograniczenia kryminalistyczne i brak dowodów eksploatacji

Na dzień dzisiejszy amerykańska Agencja Bezpieczeństwa Cybernetycznego i Infrastruktury (CISA) wymienia eksploatację tej luki jako zerową. Nie ma publicznego dowodu koncepcji (PoC) ani dowodów na aktywną eksploatację "na wolności". Jednak biuletyn nie podaje metody sprawdzenia, czy brama została zaatakowana przed aktualizacją. Ten brak widoczności kryminalistycznej jest znaczącą luką. Bez konkretnych sygnatur logów lub wskaźników kompromitacji administratorzy mogą się tylko zastanawiać, czy ich klucze podpisywania zostały naruszone w oknie podatności.

W przypadku naruszenia dotyczącego takiego narzędzia, celem jest często dyskretne utrzymanie dostępu. Atakujący może nie doprowadzić do awarii bramy. Zamiast tego może po cichu wyeksportować klucze podpisywania JWT, aby ułatwić sobie nieautoryzowany dostęp do modeli AI w późniejszym czasie. Dlatego natychmiastowa rotacja wrażliwych poświadczeń po wdrożeniu poprawki jest standardową praktyką branżową. Załatanie dziury w kadłubie statku to pierwszy krok, ale musisz także sprawdzić, czy jakikolwiek ładunek nie został wyrzucony za burtę, gdy dziura była otwarta.

Element ludzki w bezpieczeństwie AI

Często traktujemy AI jako futurystyczną warstwę nakładaną na nasz istniejący kod. W rzeczywistości usługi AI, takie jak GitLab Gateway, to po prostu kolejne oprogramowanie. Podlegają one tym samym starym podatnościom, takim jak wstrzykiwanie poleceń i ucieczki z szablonów. Ludzka zapora ogniowa pozostaje pierwszą linią obrony. Użytkownicy, którzy mają dostęp do Duo Agent Platform, to ci, którzy mogą dotrzeć do tej luki. Ograniczenie dostępu do tych platform tylko do osób, które ściśle go potrzebują, jest zgodne z zasadą najmniejszych uprawnień.

Zero Trust to bramkarz w klubie VIP przy każdych wewnętrznych drzwiach. Nawet jeśli użytkownik jest wewnątrz budynku, bramkarz powinien sprawdzić jego uprawnienia przed wpuszczeniem go w pobliże konfiguracji silnika szablonów. Jeśli Twoja organizacja pozwala każdemu programiście tworzyć niestandardowe przepływy AI bez nadzoru, zwiększasz powierzchnię ataku. Złożoność tych integracji AI sprawia, że granularna kontrola dostępu staje się wymogiem, a nie sugestią.

Wnioski dotyczące natychmiastowego łagodzenia skutków

Aby zaradzić tej krytycznej luce, administratorzy powinni postępować zgodnie z określoną sekwencją działań. Po pierwsze, zidentyfikuj dokładną wersję obrazu AI Gateway aktualnie uruchomioną w środowisku. Nie zakładaj, że wersja ta zgadza się z główną aplikacją GitLab. Po drugie, natychmiast zastosuj odpowiednią poprawkę, korzystając z procedur Docker lub Helm dostarczonych przez GitLab. Po trzecie, rozważ rotację kluczy podpisywania JWT, jeśli brama była wystawiona na działanie niezaufanych użytkowników wewnętrznych przed zastosowaniem poprawki.

Na koniec przeprowadź audyt listy użytkowników, którzy mają uprawnienia do konfigurowania niestandardowych przepływów na platformie Duo Agent Platform. Jeśli użytkownik nie ma krytycznego powodu biznesowego do modyfikowania tych konfiguracji, odbierz mu dostęp. Zmniejszenie liczby osób, które mogą dotrzeć do podatności, jest równie ważne jak naprawienie samego kodu. Bezpieczeństwo to ciągły proces doskonalenia, a nie jednorazowa aktualizacja.

Źródła

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Zastrzeżenie: Niniejszy artykuł służy wyłącznie celom informacyjnym i edukacyjnym. Nie zastępuje on profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty. Zawsze konsultuj się z oficjalną dokumentacją dostawcy przed wykonaniem aktualizacji systemu.