OmniRoute CVE-2026-88062: własny agent prowadził do wykonania kodu

CVE-2026-88062 to krytyczna luka w OmniRoute, przez którą definicja własnego agenta ACP mogła stać się instrukcją wykonania kodu w kontenerze serwera. Podatne są wersje pakietu omniroute wcześniejsze niż 3.8.49.

Atak mógł być anonimowy, gdy operator wyłączył wymaganie logowania. Podobne ryzyko występowało w oknie startowym świeżej instancji bez ustawionego hasła zarządzającego. Przy domyślnej konfiguracji z wymaganym logowaniem i skonfigurowanym hasłem luka nadal prowadziła do RCE, ale wymagała ważnej sesji administracyjnej lub klucza API o zakresie zarządzania.

Gdzie znikała granica między konfiguracją a kodem

Endpoint rejestrujący własnego agenta przyjmował między innymi nazwę programu binary oraz polecenie sprawdzające wersję versionCommand. Aplikacja weryfikowała, czy pierwszy element polecenia odpowiada programowi zadeklarowanemu w tym samym żądaniu.

To sprawdzenie wygląda rozsądnie tylko wtedy, gdy binary pochodzi z zaufanej listy. W OmniRoute oba pola kontrolował klient. Mógł więc wskazać dostępny interpreter jako program i podać mu argument uruchamiający kod. Blokowanie kilku znaków specjalnych powłoki nie pomagało, ponieważ aplikacja używała bezpośredniego uruchomienia procesu z tablicą argumentów; powłoka nie była potrzebna.

Istotny jest również moment wykonania. Po zapisaniu definicji ten sam request odświeżał cache agentów, uruchamiał wykrywanie wersji i dochodził do execFileSync. Nie była potrzebna późniejsza akcja administratora ani restart.

Kiedy atak nie wymagał konta

Oficjalne advisory opisuje dwa anonimowe scenariusze:

• instancja ma ustawione requireLogin=false, więc mechanizm uwierzytelnienia uznaje żądania anonimowe za dozwolone;
• świeża instancja nie ma jeszcze hasła zarządzającego, a dostępny w bootstrapie endpoint ustawień pozwala najpierw wyłączyć wymaganie logowania.

Dodatkowo ścieżka /api/acp/ nie należała do listy endpointów ograniczonych wyłącznie do ruchu lokalnego ani do listy operacji zdolnych uruchamiać procesy. Żądanie docierało więc do gałęzi zezwalającej na anonimowy dostęp zamiast zostać zatrzymane przez centralną politykę.

To nie oznacza, że każda instalacja OmniRoute była dostępna z internetu. Wpływ zależy od publikacji portu, reguł reverse proxy i sieci, stanu logowania oraz fazy konfiguracji. Dlatego inwentaryzacja musi odpowiedzieć na pytanie o rzeczywistą osiągalność, a nie tylko obecność pakietu.

RCE w kontenerze nadal jest incydentem

Advisory potwierdza wykonanie polecenia w kontenerze OmniRoute. Nie stwierdza automatycznej ucieczki na hosta. Promień rażenia zależy od tego, jak uruchomiono kontener: użytkownika procesu, zamontowanych katalogów, sekretów w środowisku, dostępu do socketu Dockera, sieci i uprawnień platformy orkiestracyjnej.

Gateway modeli i agentów często przechowuje lub przekazuje klucze do wielu dostawców. Kod w jego procesie może próbować odczytać konfigurację, tokeny, historię żądań i informacje o routingu, a następnie połączyć się z innymi usługami. To ocena modelu zagrożenia Breachroad; publiczne źródło nie twierdzi, że każda udana próba ujawniła wszystkie klucze lub przejęła hosta.

Granica kontenera ma znaczenie. Uruchamianie jako użytkownik bez uprawnień, system plików tylko do odczytu, minimalne mounty, brak socketu runtime i ograniczony egress nie naprawiają luki, ale ograniczają możliwy skutek błędu aplikacji.

Plan działania dla właściciela instancji

Najpierw ustal wersję pakietu i obrazu rzeczywiście działającego w każdym środowisku. Następnie:

1. zaktualizuj OmniRoute do 3.8.49 lub nowszej wersji;
2. włącz wymaganie logowania i ustaw silne hasło zarządzające przed wystawieniem usługi do sieci;
3. ogranicz panel oraz API zarządzające do zaufanej sieci, VPN albo kontrolowanego reverse proxy;
4. usuń publiczny dostęp do portu zarządzającego, jeżeli nie jest potrzebny;
5. sprawdź listę własnych agentów, ustawienia logowania i historię zmian;
6. potraktuj sekrety osiągalne z procesu jako kandydatów do rotacji, jeśli instancja była podatna i dostępna dla niezaufanych klientów.

Nie polegaj wyłącznie na ustawieniu requireLogin=true jako trwałej naprawie. Ogranicza ono anonimową ścieżkę, ale przed poprawką użytkownik z ważnymi uprawnieniami zarządzającymi nadal mógł doprowadzić do wykonania kodu.

Jak podejść do triage’u

Zachowaj logi reverse proxy, aplikacji, kontenera, orkiestratora i dostawców modeli. Ustal, czy pojawiały się żądania do endpointu własnych agentów, zwłaszcza w czasie, gdy logowanie było wyłączone lub instancja czekała na konfigurację.

Porównaj zapisane definicje agentów z zatwierdzoną konfiguracją. Zbadaj nieznane programy i polecenia wersji, zmiany ustawienia logowania, nowe klucze API, procesy potomne serwera oraz nietypowe połączenia wychodzące. Jeżeli logi są niepełne, brak jednego wpisu nie jest dowodem braku wykonania.

Potem zinwentaryzuj sekrety dostępne dla kontenera: klucze do modeli, tokeny administracyjne, dane bazy, integracje, poświadczenia chmurowe i systemy obserwowalności. Rotację zaczynaj od kluczy o najszerszym zakresie i możliwości tworzenia dalszych poświadczeń.

Oficjalne advisory nie informuje o aktywnym wykorzystywaniu luki w rzeczywistych atakach. Kontrola logów, procesów i sekretów jest rekomendacją Breachroad wynikającą z udokumentowanego RCE.

Fakty źródłowe i lekcja dla bezpiecznego AI

Endpoint, droga do execFileSync, anonimowe warunki, zakres wersji i poprawka 3.8.49 pochodzą z oficjalnego advisory OmniRoute dla CVE-2026-88062. Źródło klasyfikuje problem jako CWE-94 oraz CWE-306 i pokazuje, że zgodność dwóch pól kontrolowanych przez klienta nie tworzy zaufanej listy programów.

To ważna lekcja dla platform agentowych: funkcja „dodaj własne narzędzie” jest granicą wykonania kodu, nawet gdy interfejs nazywa ją konfiguracją. Więcej o weryfikacji takich granic znajdziesz w przewodniku AI red teaming agentów LLM. Zespołom pomagamy budować wspólny model ryzyka podczas szkoleń z cyberbezpieczeństwa, a konkretne wdrożenia sprawdzamy w ramach AI red teamingu.