Onyx CVE-2026-71424 i 63178: tokeny MCP oraz granice grup w firmowym RAG

17 sierpnia 2026 roku opublikowano rekordy CVE-2026-71424 i CVE-2026-63178 dotyczące platformy Onyx, wcześniej znanej jako Danswer. Oba problemy trafiają w szczególnie wrażliwą część firmowego AI: połączenie systemu RAG z zewnętrznymi narzędziami i dokumentami. Pierwsza luka mogła ujawnić token OAuth jednego użytkownika innemu użytkownikowi. Druga pozwalała kuratorowi rozszerzyć swoje członkostwo na grupę, którą nie powinien zarządzać, a następnie czytać chronione jej członkostwem dokumenty.

To nie są dwie nazwy tego samego błędu. CVE-2026-71424 dotyczy izolacji sekretów w konfiguracji połączeń MCP i ma ocenę CVSS 9,6. CVE-2026-63178 dotyczy autoryzacji operacji na grupach w edycji Enterprise i otrzymało CVSS 6,5. Łączy je skutek architektoniczny: kontrola na jednym ekranie lub endpointcie nie wystarcza, gdy zmieniony stan jest potem zaufanym wejściem dla kolejnej warstwy.

Nie ma w podstawowych advisory potwierdzenia masowego wykorzystywania tych luk. Są jednak wystarczającym powodem do szybkiej aktualizacji, rotacji potencjalnie ujawnionych poświadczeń i przeglądu historii zmian. Szczególnie wtedy, gdy Onyx łączy się ze Slackiem, Atlassianem, Notion, Linearem albo własnym serwerem MCP z uprawnieniami większymi niż uprawnienia zwykłego użytkownika.

CVE-2026-71424: prywatny token zapisany we współdzielonym obiekcie

MCP, czyli Model Context Protocol, standaryzuje sposób, w jaki aplikacja AI poznaje dostępne narzędzia i je wywołuje. Sam protokół nie rozwiązuje jednak izolacji tożsamości w aplikacji hostującej. Onyx przechowywał administracyjną konfigurację MCPConnectionConfig, zawierającą między innymi szablon uwierzytelnienia dla połączenia. Oddzielnie użytkownik przechodził przepływ OAuth, aby połączyć swoje konto z usługą upstream.

Według advisory CVE-2026-71424 podczas powiązania OAuth wartość identyfikowana przez alt_config_id mogła spowodować zapis tokenu użytkownika w administracyjnym, współdzielonym obiekcie konfiguracji. Sekret przestawał być wyłącznie właściwością relacji „ten użytkownik – ta integracja”. Stawał się częścią szablonu widocznego dla innych kont.

Druga połowa problemu znajdowała się w odczycie. Endpointy listujące konfiguracje zwracały pole auth_template.headers bez maskowania użytkownikowi z rolą BASIC_ACCESS. Jeżeli w nagłówku znalazł się bearer token, inny zalogowany użytkownik mógł go odzyskać. Nie trzeba było łamać OAuth ani wykradać hasła administratora. Wystarczało odczytać obiekt, który aplikacja błędnie traktowała jak bezpieczną metadane konfiguracyjne.

W modelu zagrożeń warto rozdzielić trzy granice:

1. szablon połączenia opisuje adres, możliwości i sposób uwierzytelnienia, lecz nie powinien zawierać sekretu konkretnej osoby;
2. poświadczenie użytkownika musi być szyfrowane, przypisane do jego identyfikatora i nigdy niepojawiać się w zwykłym DTO odpowiedzi;
3. wywołanie narzędzia musi pobierać właściwy token dopiero po autoryzacji użytkownika i nie może kopiować go do wspólnego stanu.

Złamanie pierwszej granicy umożliwiło złamanie drugiej. Trzecia powiększa konsekwencje, ponieważ skradziony token jest ważny nie tylko w Onyx. Może działać bezpośrednio wobec usługi upstream, zgodnie z zakresem nadanym podczas zgody OAuth.

Co naprawdę daje przejęty token MCP

Wpływ zależy od zakresu tokenu, konfiguracji dostawcy i uprawnień ofiary. Token Slacka może umożliwiać wyszukiwanie wiadomości lub wykonywanie akcji w workspace. Token Atlassiana może otwierać projekty i dokumentację. Poświadczenie własnego serwera MCP może prowadzić do narzędzi administracyjnych, repozytoriów lub baz wiedzy. Nie wolno automatycznie twierdzić, że każda instalacja pozwalała przejąć wszystkie te systemy. Trzeba jednak założyć, że poufność tokenów została naruszona, jeśli podatna wersja obsługiwała per-user OAuth.

To ważna różnica operacyjna: aktualizacja aplikacji zatrzymuje dalsze ujawnianie, ale nie unieważnia sekretów skopiowanych przed poprawką. Token pozostaje ważny do czasu wygaśnięcia albo cofnięcia go u dostawcy. Dlatego reakcja powinna obejmować listę użytkowników i integracji, odwołanie aktywnych grantów, ponowne połączenie kont oraz przegląd logów po stronie usług upstream.

Szukaj użycia tokenu z nowego adresu IP, nietypowego user-agenta, lokalizacji niezgodnej z aktywnością właściciela i wywołań, których nie poprzedza sesja Onyx. Jeśli dostawca rotuje refresh token po użyciu, błędy odświeżania lub nagły ponowny consent również mogą być śladem konkurencyjnego wykorzystania. Nie kopiuj pełnych tokenów do systemu SIEM; wystarczy stabilny identyfikator grantu, właściciel, integracja i skrót pozwalający korelować zdarzenia bez tworzenia kolejnego wycieku.

Wersje i poprawki dla CVE-2026-71424

Advisory oznacza jako podatne wydania poniżej 3.1.10, linię od 3.2.0 do wersji wcześniejszych niż 3.2.14 oraz wydania od 3.3.0-beta.0 do wcześniejszych niż 4.0.0. Poprawki trafiły odpowiednio do 3.1.10, 3.2.14 i 4.0.0. Sam numer wersji trzeba więc porównywać z gałęzią, a nie wyłącznie z prostą regułą „większy numer jest bezpieczny”.

Jeżeli organizacja pozostaje na starej linii z powodów kompatybilności, powinna zastosować najnowszą poprawkę z tej gałęzi, odłączyć per-user OAuth do czasu zakończenia rotacji i ograniczyć odczyt konfiguracji. Docelowo bezpieczniejsza jest migracja do wspieranej linii zawierającej również późniejsze poprawki. Ponieważ druga opisywana dziś luka jest naprawiona dopiero w 4.3.0, wspólnym punktem docelowym dla obu problemów jest co najmniej Onyx 4.3.0, o ile release notes nowszej wspieranej wersji nie wskazują inaczej.

CVE-2026-63178: rola kuratora bez sprawdzenia zakresu

Edycja Enterprise pozwala grupować użytkowników i dokumenty. Kurator ma zarządzać określonym obszarem treści, nie całym tenantem. W podatnym kodzie endpoint aktualizacji grupy oraz operacja dodawania użytkowników sprawdzały, czy wywołujący ma rolę kuratora, lecz nie weryfikowały, czy jest kuratorem właśnie tej grupy.

Advisory CVE-2026-63178 opisuje scenariusz, w którym kurator wskazuje dowolny identyfikator grupy i dodaje do niej siebie. Jest to błąd autoryzacji obiektowej: decyzję „może modyfikować grupy” pomylono z „może modyfikować ten konkretny obiekt”. Kontrola roli odpowiadała tylko na pierwsze pytanie.

Następny etap nie wymagał osobnej podatności w wyszukiwaniu. Onyx budował filtr dostępu do dokumentów na podstawie aktualnego członkostwa w grupach. Po dopisaniu atakującego system wyszukiwania uznawał go za prawidłowego odbiorcę. Wyniki z OpenSearch, fragmenty przekazane do RAG i odpowiedzi asystenta mogły więc zawierać dokumenty wcześniej niedostępne.

To przykład, dlaczego kontrola dostępu w RAG nie kończy się przy zapytaniu do wektorowej bazy danych. Jeżeli ACL jest wyliczany z katalogu grup, każda operacja zmieniająca katalog jest częścią powierzchni bezpieczeństwa danych. Poprawny filtr nie pomoże, gdy otrzyma nieprawidłowy, lecz formalnie ważny stan członkostwa.

Podatność dotyczyła Onyx Enterprise przed 4.3.0 i została naprawiona w 4.3.0. Po aktualizacji warto testować nie tylko odmowę dla zwykłego użytkownika, ale macierz obiektów: kurator grupy A nie może odczytać, zmienić ani dodawać członków do grupy B; administrator może wykonywać wyraźnie zdefiniowane operacje; zmiana roli natychmiast unieważnia stare uprawnienia.

Plan reakcji dla administratora Onyx

Pierwszy krok to inwentaryzacja instancji, wersji, edycji i sposobu wdrożenia. Obejmij środowisko produkcyjne, staging, kopie demonstracyjne i prywatne workspaces zespołów, ponieważ integracje testowe często mają prawdziwe tokeny. Sprawdź, czy włączono MCP OAuth i czy używano kuratorów oraz grup Enterprise.

Następnie:

• zaktualizuj do wspieranej wersji co najmniej 4.3.0, wykonując kopię konfiguracji oraz kontrolę migracji schematu;
• unieważnij tokeny OAuth po stronie każdego dostawcy, a potem połącz konta ponownie;
• sprawdź, czy żaden token, klucz API lub nagłówek autoryzacyjny nie pozostał w współdzielonych rekordach, logach, eksportach i kopiach diagnostycznych;
• wyeksportuj historię członkostwa w grupach i porównaj ją z zatwierdzonym źródłem tożsamości;
• przejrzyj operacje PATCH na grupach, dodawanie użytkowników, zmiany roli kuratora oraz zapytania do dokumentów wykonywane tuż po takich zmianach;
• wymuś ponowne uwierzytelnienie sesji uprzywilejowanych i zachowaj dowody przed czyszczeniem.

Nie testuj podatności na produkcji przez odczytywanie cudzych tokenów lub dokumentów. Bezpieczna walidacja polega na sprawdzeniu wersji, testach regresji w izolowanym środowisku z syntetycznymi sekretami oraz kontroli, czy odpowiedzi API maskują pola wrażliwe. Zespół powinien też potwierdzić, że gateway i reverse proxy nie przechowują ciał odpowiedzi z konfiguracjami w debug logach.

Jak monitorować, skoro legalny endpoint wygląda normalnie

Oba błędy wykorzystują prawidłowo ukształtowane żądania po uwierzytelnieniu, dlatego prosty WAF może ich nie zauważyć. Telemetria musi zawierać tożsamość wywołującego, docelowy obiekt, poprzednią i nową wartość, decyzję autoryzacyjną oraz identyfikator sesji. Dla zmian grup przydatny jest alert, gdy kurator modyfikuje grupę spoza swojego zakresu, dodaje samego siebie albo natychmiast wyszukuje dokumenty nowej grupy.

Dla MCP rejestruj odczyt konfiguracji i fakt wydania poświadczenia do konektora, ale nigdy jego wartość. Alertuj na masowe listowanie konfiguracji, dostęp do auth_template przez rolę podstawową i ruch upstream niepowiązany z operacją agenta. Korelacja między logiem Onyx a logiem SaaS jest silniejsza niż każda strona osobno: usługa może zobaczyć ważny token, a Onyx może wykazać, że nie zainicjował danego wywołania.

Retencja logów powinna być dłuższa niż typowy czas życia refresh tokenu i zgodna z ryzykiem danych. Same logi dostępu nie wystarczą, jeśli nie zachowujesz audytowalnej historii członkostwa. Migawka bieżącej grupy odpowiada na pytanie „kto ma dostęp teraz”, ale nie „kto miał go w chwili wyszukiwania”.

Wnioski projektowe dla firmowego AI

Sekret per-user nie może być właściwością współdzielonego szablonu. Najlepiej przechowywać go w dedykowanym vault, a w bazie aplikacji zachować wyłącznie referencję z właścicielem, zakresem, dostawcą i czasem wygaśnięcia. Warstwa serializacji powinna mieć jawny model bez sekretów. Pole wrażliwe trzeba wykluczyć domyślnie, zamiast polegać na tym, że każdy endpoint pamięta o maskowaniu.

Autoryzacja grup wymaga sprawdzenia działania, obiektu i relacji wywołującego z obiektem. Testy powinny obejmować pary tenantów, grup i ról, a nie tylko pozytywny przypadek administratora. Po każdej zmianie członkostwa cache uprawnień musi być unieważniony w kontrolowany sposób, a system powinien umieć odtworzyć historię decyzji.

Fakty o podatnych wersjach, mechanizmie błędów i poprawkach pochodzą z advisory projektu. Ocena potrzeby rotacji, korelacji logów i traktowania katalogu grup jako części granicy RAG jest analizą Breachroad. Nie twierdzimy, że każda podatna instancja została wykorzystana ani że każdy ujawniony token miał ten sam zakres.

Te przypadki warto przećwiczyć wspólnie z zespołem AI, IAM, SOC i właścicielami danych. Szkolenia z bezpieczeństwa AI i cyberbezpieczeństwa pomagają zespołom rozdzielić model, konektor, sekret oraz politykę dostępu. Architekturę MCP, uprawnienia RAG i ścieżki OAuth można następnie zweryfikować podczas audytu bezpieczeństwa AI.

Źródła

• Onyx: GHSA-q62f-rv3h-f822 / CVE-2026-71424
• Onyx: GHSA-7f48-vgpj-h95m / CVE-2026-63178
• Onyx 4.0.0
• Onyx 4.3.0