Agent Claude w GitLab Duo mógł uruchamiać dowolne polecenia w CI. Nikt nie wykazał, że został wykorzystany.

GitLab wydał 26 sierpnia 2026 r. poprawione wersje dla luki o wysokiej wadze w agencie AI Duo Claude — opartym na Claude agencie, którego GitLab w swoim komunikacie bezpieczeństwa umieszcza w kontekście CI. Śledzona jako CVE-2026-18252, luka pozwalała uwierzytelnionemu użytkownikowi z rolą Developer doprowadzić do wykonania dowolnych poleceń wewnątrz zadania CI, ponieważ agent przetwarzał konfigurację ze źródła kontrolowanego przez użytkownika, nie sprawdzając, skąd ona pochodzi. GitLab ocenił ją na 7.3 w skali CVSS 3.1 i zawęził podatny zakres do GitLab Enterprise Edition: wersje od 18.9 do, z wyłączeniem, 19.1.7, od 19.2 do 19.2.5 oraz od 19.3 do 19.3.1. GitLab.com działał już na poprawionym kodzie, a klientom GitLab Dedicated przekazano, że nie muszą podejmować żadnych działań. Żadne źródło przeanalizowane na potrzeby tego artykułu nie podaje, by ktokolwiek wykorzystał tę lukę, i nie opublikowano żadnego proof of concept w źródłach publicznych. Własny wpis archiwum dotyczący tego incydentu, wraz z ocenami wagi i pewności, znajduje się w Orca AI Incident Archive, obok sąsiednich rekordów z tego samego tygodnia.

Co mówi komunikat doradczy, a czego w nim brak

Dokument źródłowy jest krótki. Opublikowane tego samego dnia notatki GitLab dotyczące wydania poprawek dla wersji 19.3.1, 19.2.5 i 19.1.7 wymieniają siedem poprawek bezpieczeństwa. Pierwsza, oznaczona jako High, nosi tytuł „Włączenie funkcjonalności z niezaufanej sfery kontrolnej w agencie Duo Claude AI wpływa na GitLab EE”, a jej opis w formie prozy to tylko jedno zdanie. GitLab twierdzi, że „naprawił problem, w wyniku którego w pewnych warunkach uwierzytelniony użytkownik z uprawnieniami roli dewelopera mógł wykonać dowolne polecenia w kontekście CI, ponieważ agent Claude przetwarzał konfigurację ze źródła kontrolowanego przez użytkownika”. To cały opis techniczny opublikowany przez dostawcę.

Rekord CVE, przydzielony przez sam GitLab, dodaje strukturę, a nie treść. Klasyfikuje słabość jako CWE-829, powtarza zakresy wersji, których dotyczy, oraz ocenę CVSS 7,3, a także odnotowuje, że identyfikator zarezerwowano 29 lipca 2026 r., a opublikowano 26 sierpnia o 13:36 UTC. Zgłoszenie z programu bug bounty, którego zasługi GitLab uznaje — raport HackerOne 3863650 — zwróciło kod 403 w odpowiedzi na niezalogowane zapytanie 29 października 2026 r., więc jego szczegóły techniczne nie są publiczne; z kolei element systemu śledzenia zadań, który rekord CVE wskazuje jako swoje źródło — pozycja robocza gitlab-org/gitlab 607342 — przy tej weryfikacji nie zawierał żadnej czytelnej treści zgłoszenia.

To, czego nie mówi komunikat doradczy, jest właśnie tym, czego obrońca chciałby się dowiedzieć. Nie wymienia funkcji Duo, której dotyczy, pola konfiguracji odczytywanego przez agenta ani postaci, jaką przyjmuje źródło kontrolowane przez użytkownika — czy jest to plik repozytorium, zmienna potoku, komentarz w zgłoszeniu lub żądaniu scalenia, czy parametr API. Żadnego z nich nie podano w notatkach GitLab, w rekordzie CVE ani w relacjach branżowych przejrzanych na potrzeby tego artykułu. Dokumentacja produktu GitLab rzeczywiście opisuje jedną ścieżkę Claude do CI: agentów zewnętrznych, którzy — jak głosi dokumentacja — uruchamiają potok CI/CD w przypadku wspomnienia w zgłoszeniu, epiku lub żądaniu scalenia, i dla których istnieje przykład konfiguracji Claude Code. Nic z przejrzanych materiałów nie łączy tej ścieżki z CVE-2026-18252. Stanowi to kontekst wyjaśniający, dlaczego agent Claude ma w ogóle uprawnienia w CI, a nie mechanizm błędu.

Ta sama dokumentacja otwarcie mówi o klasie ryzyka. Strona GitLab poświęcona zewnętrznym agentom wymienia podatności typu prompt injection wśród ryzyk, które klienci akceptują, włączając tę funkcję, i opisuje wdrażane przez siebie skanowanie promptów przez podmioty trzecie jako środek łagodzący. Ta strona nie wspomina o CVE-2026-18252, a ostrzeżenie nie jest jego opisem. Pokazuje jednak, że niezaufane dane wejściowe docierające do agenta z dostępem do pipeline'u są ryzykiem, którego zaakceptowania dokumentacja GitLab sama już wymaga od klientów.

Kontekst CI to miejsce, w którym znajdują się poświadczenia.

Zwrot, który nadaje temu powagę, to „w kontekście CI”. Zadanie w potoku nie jest zabawową piaskownicą; działa z tokenem runnera i wszelkimi sekretami, które projekt mu udostępnił. Cyber Security News, informując o poprawce 27 sierpnia 2026 r., wymienia to, do czego takie zadania zwykle mają dostęp — kod źródłowy, artefakty budowania, poświadczenia wdrożeniowe, tokeny chmury i poświadczenia repozytoriów pakietów — i zauważa, że wykonanie polecenia w potoku mogłoby ujawnić zmienne CI, zmienić artefakty budowania, manipulować procesami wydania lub sięgnąć głębiej do połączonej infrastruktury, w zależności od konfiguracji runnera i zakresu tokena. Artykuł GBHackers z tego samego dnia ujmuje to w ten sam sposób. Żaden z tych serwisów nie donosi o przypadku, w którym do tego doszło.

To rozróżnienie kształtuje sposób, w jaki należy odczytywać tę lukę. Jest to błąd wykonania poleceń w komponencie agentowym, a nie demonstracja niewłaściwego działania modelu: zapis opisuje konfigurację pochodzącą ze źródła kontrolowanego przez użytkownika oraz działanie agenta na jej podstawie. Żadne przejrzane źródło nie opisuje tego exploita jako udanej iniekcji promptów, a ostrzeżenie GitLaba nigdy nie przypisuje wyniku ocenie modelu. Zarejestrowaną słabością jest kod, który ufa źródłu konfiguracji, któremu ufać nie powinien — CWE-829, włączenie funkcjonalności z niezaufanej sfery kontroli.

Dwa wyniki CVSS i jeden krok interakcji

7.3 GitLaba to nie jedyna ocena powiązana z tym identyfikatorem. W tym samym rekordzie NVD podstawowa ocena NIST wynosi 8.1. Wektory te są identyczne poza jednym składnikiem: GitLab oznacza interakcję użytkownika jako wymaganą, a NIST nie. Obie oceny mieszczą się w przedziale High, więc praktyczna różnica dotyczy raczej warunków, w których błąd się uaktywnia, niż samej wagi. CERT Santé, zespół reagowania na incydenty komputerowe francuskiego ministerstwa zdrowia, opublikował 27 sierpnia 2026 r. alert zgodny z interpretacją GitLaba — 7.3, wymagana interakcja użytkownika, a czynnik wyzwalający opisano jako interakcję uruchamiającą przetwarzanie konfiguracji.

Sygnały dotyczące wykorzystania są nikłe, a każdy z nich stanowi odczyt rejestru, a nie telemetrię. Ocena SSVC, którą rola koordynatora CISA zapisała we wpisie NVD w dniu 26 sierpnia 2026 r., odnotowuje wykorzystanie jako „brak”, możliwość automatyzacji jako „nie”, a wpływ techniczny jako „całkowity”. Model EPSS FIRST określił prawdopodobieństwo wykorzystania na 0,00519, czyli nieco ponad pół procenta, w dniu 28 października 2026 r., w 44. percentylu ocenianych podatności. Rejestr OpenCVE zawiera tę samą wartość EPSS i wymienia CVE jako nieobecne w katalogu CISA Known Exploited Vulnerabilities. Alert CERT Santé odnotowuje „aktywnie wykorzystywane: nie” i dodaje, że w tej dacie w źródłach publicznych nie istniał żaden proof of concept. Nic z tego nie jest dowodem, że nikt nie próbował; to brak jakiejkolwiek odnotowanej próby.

Co najmniej jeden agregator, Mallory, podaje wynik 8,7 dla tego samego identyfikatora. Rekord NVD nie zawiera w ogóle żadnej metryki CVSS 4.0 — jedynie 7,3 GitLab i 8,1 NIST — więc tej wartości nie można odtworzyć na podstawie żadnego z przejrzanych źródeł pierwotnych i nie jest ona tutaj używana.

Co jest ustalone, a co nie

Archiwum przyznaje temu wpisowi ocenę pewności A, bez sporów, z brakiem odnotowanych rzeczywistych szkód. Ta ocena odgrywa tu realną rolę: dokumenty są ze sobą zgodne, a żaden z nich nie opisuje szkód. Poniższy podział to ta część, której nie jest w stanie unieść jednowierszowe streszczenie.

• Ustalono: luka w agencie AI Duo Claude pozwalała uwierzytelnionej roli Developer na wykonanie dowolnych poleceń w kontekście CI, ponieważ agent przetwarzał konfigurację ze źródła kontrolowanego przez użytkownika. GitLab przydzielił CWE-829 i CVSS 7.3.

• Ustalono: zakresy objęte problemem i poprawkę — od 18.9 do 19.1.7, od 19.2 do 19.2.5, od 19.3 do 19.3.1; poprawiono 26 sierpnia 2026 r. w wersjach 19.1.7, 19.2.5 i 19.3.1. Lukę odnotowano dla GitLab EE; w tym samym wydaniu poprawiono także CE, ze względu na inną wadę.

• Ustalono: przyznanie uznania zgłaszającemu thwin_htet za pośrednictwem programu HackerOne GitLab oraz status operacyjny, który GitLab przekazał klientom — GitLab.com już załatany, GitLab Dedicated poza zakresem wymaganych działań, instalacjom self-managed polecono natychmiastową aktualizację.

• Ustalono: nie zgłoszono żadnego wykorzystania. Ocena SSVC CISA wskazuje, że nie wystąpiło; EPSS pozostawał poniżej jednego procenta do końca października 2026 r.; według OpenCVE CVE nie znajduje się w katalogu KEV; CERT Santé odnotował brak aktywnego wykorzystania dzień po ujawnieniu.

• Przypisywane, niepotwierdzone przez dostawcę: opisy skutków — sekrety możliwe do odczytania, artefakty możliwe do zmodyfikowania, wydania podatne na manipulację — są relacją mediów o tym, co zakres tokenu zadania CI zazwyczaj pozwala, a nie ustaleniem, że cokolwiek z tego miało miejsce w tym przypadku. Cyber Security News i GBHackers ujmują je zarówno w sformułowaniach „could”, jak i „depending on”; żadne nie donosi o żadnym wystąpieniu.

• Nie ustalono: która funkcja Duo i które pole konfiguracji były zaangażowane oraz czym faktycznie było źródło kontrolowane przez użytkownika. Oświadczenie dostawcy ich nie wskazuje.

• Nie ustalono: ile samodzielnie zarządzanych instalacji Enterprise znajdowało się w zakresach objętych problemem, ile zaktualizowano po 26 sierpnia 2026 r. lub czy jakiekolwiek z nich zaatakowano. Żadne z przejrzanych źródeł nie mierzy skali wdrożenia, a dostawca nie opublikował żadnej metody wykrywania dla instancji zaktualizowanych z opóźnieniem.

• Jeszcze nie ustalono: mechanizm techniczny. Zgodnie z 90-dniową zasadą GitLab zgłoszenie staje się publiczne około końca listopada 2026 r.; do tego czasu powiązany wpis w trackerze wskazuje na wyjaśnienie, które jeszcze nie jest publicznie dostępne.

Poprawka, przestój i 90-dniowe oczekiwanie

GitLab wydał 26 sierpnia 2026 r. wersje 19.3.1, 19.2.5 i 19.1.7 zarówno dla Community Edition, jak i Enterprise Edition, i oświadczył, że zdecydowanie zaleca natychmiastową aktualizację wszystkich instalacji samodzielnie zarządzanych do jednej z tych wersji. Część wydania dotycząca Community Edition ma znaczenie, ponieważ inna luka w tej samej partii — CVE-2026-77801, problem z odmową usługi w potokach importu o ocenie 6,5 — dotyczy zarówno CE, jak i EE. Sam CVE-2026-18252 jest odnotowany wyłącznie w odniesieniu do Enterprise Edition.

Nie ma obejścia problemu od dostawcy. Alert CERT Santé odnotowuje, że nie istnieje żadne obejście, a notatki GitLab nie oferują żadnego; jedynym wskazanym rozwiązaniem jest aktualizacja. Wydanie również nie jest czymś, co można po prostu wdrożyć bezpośrednio. Obejmuje ono regularne migracje baz danych we wszystkich trzech wersjach oraz migracje po wdrożeniu w wersjach 19.3.1 i 19.2.5, które według GitLab spowodują przestój w instalacjach jednosiowych w czasie trwania migracji. Wdrożenia wielosiowe mogą skorzystać z procedury aktualizacji bez przestoju GitLab.

Pozostałe sześć poprawek zasługuje na rzut oka, ponieważ jedna z nich jest bliska tematowi tego wpisu. CVE-2026-15387, oceniony na 4.3 i naprawiony w tych samych trzech wersjach, pozwalał uwierzytelnionemu użytkownikowi z uprawnieniami roli dewelopera wpływać na środowisko wykonawcze zadań egzekwowania Pipeline Execution Policy poprzez nieprawidłową obsługę zależności zadań. Dwie ścieżki dla roli dewelopera prowadzące do wykonania zadań, jedna oceniona jako High, a druga jako Medium, zamknięto w tej samej poprawce.

Polityka ujawniania informacji GitLab wyjaśnia, dlaczego mechanizm pozostaje nieprzejrzysty. W informacjach o poprawkach stwierdza się, że zgłoszenia szczegółowo opisujące każdą lukę w zabezpieczeniach są publikowane w systemie śledzenia zgłoszeń 90 dni po wydaniu, w którym zostały załatane. Licząc od 26 sierpnia 2026 r., umieszcza to techniczny opis CVE-2026-18252 w ostatnim tygodniu listopada 2026 r. Do tego czasu odwołanie do systemu śledzenia w rekordzie CVE nie ma za sobą publicznego opracowania technicznego, które ten artykuł mógłby przeczytać.

Gdzie to się plasuje w zestawieniu z innym błędem agenta GitLab

GitLab ujawnił 2 października 2026 r. drugą, odrębną lukę związaną z agentem: CVE-2026-90970, ocenioną na 9,9, w AI Gateway, a nie w agencie AI Duo Claude, osiągalną poprzez spreparowany szablon promptu przepływu, a nie poprzez konfigurację CI. To dwa różne błędy w różnych komponentach o różnych ocenach, a archiwum przechowuje je jako osobne wpisy. Łączy je kształt — komponent AI w ścieżce dostarczania działający na podstawie konfiguracji, na którą może wpływać użytkownik o niższych uprawnieniach — dlatego tę z października warto czytać obok tej, a nie zamiast niej.

Dla operatora decyzja jest wąska. Sprawdź wersję: 19.1.7, 19.2.5 i 19.3.1 to wydania poprawione, a każda wersja z trzech wymienionych zakresów jest podatna. Nie ma obejścia, które można by stosować w międzyczasie, a do późnego listopada nie opublikowano opisu technicznego, względem którego można by zweryfikować instancję załataną z opóźnieniem. Istnieje tylko rejestr, w którym nikt nie zgłosił wykorzystania luki — co jest stwierdzeniem o braku dowodów, a nie zapewnieniem dostawcy, że nie doszło do naruszenia.