MaxKB: ścieżka przekazywania zadań agenta pozwala użytkownikowi, któremu odmówiono dostępu do narzędzia, nadal je wywołać i odczytać jego poświadczenia

MaxKB, open-source'owy korporacyjny asystent AI utrzymywany przez 1Panel-dev, udostępnia listę uprawnień w podziale na użytkowników i narzędzia, dzięki czemu administrator może przyznać członkowi obszaru roboczego dostęp do jednego narzędzia, a odmówić dostępu do innego. Zgodnie z biuletynem bezpieczeństwa opublikowanym 2 września 2026 r. owo odmówienie dostępu działało na własnych trasach narzędzia, ale nie na ścieżce, której agent lub przepływ pracy używa do wywołania tego samego narzędzia. Członek obszaru roboczego o najniższej roli mógł podać identyfikator narzędzia, do którego odmówiono dostępu, podczas budowania przepływu pracy, uruchomić ten przepływ i otrzymać nie tylko dane wyjściowe narzędzia, ale także poświadczenia, które MaxKB odszyfrowuje po stronie serwera, aby je uruchomić. Dotyczy to wersji od 2.0.0 do 2.9.2, a biuletyn nie wskazał żadnej wersji z poprawką. Ten wpis — obejście autoryzacji przy wywoływaniu narzędzi w MaxKB — jest jednym z rekordów w OrcaRouter AI Incident Archive, który zawiera pełny zestaw rekordów oraz sąsiednie wpisy dotyczące tego incydentu.

To, co sprawia, że ten przypadek warto uważnie przeczytać, to nie ocena. Chodzi o to, że produkt miał już właściwe zabezpieczenie, zastosował je przy oczywistych drzwiach, a drugie drzwi prowadzące do tej samej funkcji pozostawił bez nadzoru. Biuletyn doradczy GHSA-383v-fx78-pphm został napisany przez badacza, który go odkrył, i opublikowany za pośrednictwem systemu doradczego GitHuba o 07:43 UTC 2 września 2026 r., z uznaniem dla Matteo Panzeriego (@matte1782). Rekord CVE, CVE-2026-77516, pojawił się 21 września 2026 r.

Co ustanawia opinia doradcza

Model uprawnień MaxKB dla poszczególnych narzędzi to WorkspaceUserResourcePermission, opisany w biuletynie doradczym jako domyślnie odmawiająca lista dozwolonych rozstrzygana w momencie żądania. Dedykowane trasy narzędzi egzekwują go. Biuletyn wymienia egzekwowanie w apps/tools/views/tool.py, gdzie Operate.put, Operate.get, Debug.post, Export.get i Delete — każdy z nich zawiera kontrolę uprawnień widoku względem uprawnienia narzędzia w obszarze roboczym wywołującego. Debug.post to trasa najbliższa prostemu uruchomieniu narzędzia i jest zabezpieczona kontrolą dostępu.

Ścieżka wysyłki agenta i przepływu pracy nie stosuje ponownie tego sprawdzenia. Biuletyn wskazuje trzy odrębne miejsca, w których go brakuje. W pliku apps/application/serializers/application.py serializator aplikacji wiąże tool_ids, skill_tool_ids i mcp_tool_ids bezpośrednio z danymi wejściowymi żądania, bez autoryzacji poszczególnych narzędzi — a biuletyn zwraca uwagę, że ta asymetria jest widoczna w tym samym pliku, ponieważ knowledge_id_list jest weryfikowana względem baz wiedzy dostępnych dla użytkownika kilka wierszy niżej, podczas gdy narzędzia już nie. W pliku apps/common/utils/shared_resource_auth.py funkcja filter_authorized_ids bezwarunkowo przepuszcza każde narzędzie z obszaru roboczego wywołującego; brama międzybbszarowa, na której się opiera, to zaczep dostępny wyłącznie w wersji enterprise, którego brak w edycji community, a ponadto nigdy nie sprawdza WorkspaceUserResourcePermission. Natomiast w miejscu końcowym plik apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py uruchamia zapisany kod narzędzia wraz z jego init_params odszyfrowanymi przez rsa_long_decrypt w ramach tożsamości aplikacji, bez sprawdzenia przyznanych uprawnień dla poszczególnych narzędzi.

W komunikacie doradczym wynik określa się jako wykonanie przez zdezorientowanego pośrednika: dyspozytor workflow uruchamia narzędzie oraz jego przechowywane sekrety, do których temu samemu wywołującemu odmawia się dostępu na własnych trasach narzędzia. Ujawnienie poświadczeń to aspekt wykraczający poza zwykłe nieuprawnione użycie narzędzia.init_paramssą szyfrowane w spoczynku algorytmem RSA i odszyfrowywane po stronie serwera dopiero w momencie wykonania, więc wywołujący, który wyzwala to wykonanie, otrzymuje wartości, których nigdy nie posiadał i nie mógł dostarczyć.

Demonstracja — w liczbach samego badacza

Komunikat doradczy informuje o dynamicznym potwierdzeniu na wersji v2.9.2, uruchomionej z oficjalnego obrazu all-in-one, 1panel/maxkb:v2.9.2. Konfiguracja obejmowała jeden obszar roboczy, administratora oraz drugiego członka z rolą USER. Administrator utworzył narzędzie A i narzędzie B, umieścił świeżo wygenerowany losowy sekret w init_params narzędzia B, a następnie zapisał treść narzędzia B tak, aby zwracała ten sekret podczas wykonania. Członkowi przyznano następnie uprawnienie per narzędzie tylko dla narzędzia A, a komunikat doradczy podaje, że stan braku uprawnień dla narzędzia B został ponownie sprawdzony w bazie danych po uruchomieniu.

Część testu dotycząca odmowy zwróciła to, co obiecuje produkt. Jako członek, trasa debugowania dla Tool B odpowiedziała kodem 403, trasa aktualizacji odpowiedziała kodem 403, trasa eksportu odpowiedziała kodem 403, a przyznany Tool A zwrócił 200 w ramach kontroli poprawności. Część testu dotycząca obejścia powiązała następnie Tool B z aplikacją workflow przez węzeł biblioteki narzędzi — powiązanie zostało przyjęte z HTTP 200 i bez sprawdzania poszczególnych narzędzi — a uruchomienie workflow zwróciło HTTP 200 z treścią zawierającą nazwę narzędzia, sekret kontrolny i listę kluczy ["api_key"].

Biuletyn doradczy podaje, że sekret ujawnił się na trzech poziomach: w odpowiedzi API przepływu pracy, w rekordzie wykonania narzędzia o stanie SUCCESS oraz w wierszu bazy danych, w którym pole narzędzia B init_paramsznajduje się jako szyfrogram RSA o długości 344 bajtów — co, zdaniem badacza, dowodzi, że wartość została odszyfrowana po stronie serwera przy użyciu tożsamości aplikacji, a nie dostarczona przez wywołującego. Ten sam członek, któremu odmówiono na trasie uruchamiania narzędzia, uzyskał odszyfrowany sekret narzędzia, wiążąc go z przepływem pracy.

Opublikowano jeden wynik, o wyższy się spierano.

Ocena przypisana do CVE-2026-77516 to CVSS 3.1 5.4, Medium, z wektorem AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. W rekordzie NVD widać, że ocena ta pochodzi z kanału doradczego GitHub, a nie z własnej analizy NVD, a wpis ma status Deferred, co oznacza, że NVD go nie wzbogaciło. Własna klasyfikacja archiwum jest zgodna z tą opublikowaną oceną: średnia waga, brak odnotowanych rzeczywistych szkód.

Sekcja wpływu samego biuletynu argumentuje za wyższą oceną. Podaje wagę 7.1, High, dla wektora, który podnosi wpływ na poufność do wysokiego, i twierdzi, że wartość wzrasta do 8.1, gdy uruchamiane narzędzie wykonuje uprzywilejowane zapisy w kontekście tożsamości aplikacji. To spór o to, jak liczyć ekspozycję poświadczeń, a nie o to, czy obejście istnieje — ten sam dokument zarówno wykazuje wadę, jak i argumentuje, że jest ona niedoszacowana. Nic w publicznym zapisie nie rozstrzyga, która wartość jest prawidłowa, a ocena „medium” w archiwum odzwierciedla opublikowaną punktację CVE, a nie argumentację biuletynu.

Odnotowano dwie kolejne oceny. Punkty decyzyjne SSVC agencji CISA, dodane do wpisu NVD 28 września 2026 r., wskazują eksploatację jako „poc”, automatyzowalność jako „no”, a wpływ techniczny jako „partial” — wartość „poc” odzwierciedla istnienie proof of concept, co ma miejsce w samym biuletynie; nie jest to stwierdzenie eksploatacji w środowisku rzeczywistym. Model EPSS FIRST oszacował prawdopodobieństwo eksploatacji w ciągu najbliższych 30 dni na 0,242%, co odpowiada 15,2. percentylowi, w szacunku z 27 października 2026 r.

Poprawka sprzed publikacji biuletynu i żadna w objętym zakresie

Tabela wersji w biuletynie podaje, że problem dotyczy wersji od 2.0.0 do 2.9.2, wersje z poprawką: brak, a w jego treści napisano, że na moment przeglądu nie jest dostępna żadna poprawiona wersja, dodając, że poprawka w wydaniu oznaczonym tagiem pozwoliłaby przypisać do niego CVE. Repozytorium dostawcy opowiada nieco inną historię, a ta różnica ma znaczenie dla każdego, kto decyduje, co uruchomić.

W repozytorium MaxKB funkcje domykające ścieżkę dispatch — validate_bound_tool_permissions i get_authorized_tool_ids w apps/application/serializers/application.py — nie występują w tagu v2.9.2 ani w tagach v2.10.2-lts, v2.10.3-lts i v2.10.4-lts, natomiast występują od v2.10.5-lts wzwyż. To wydanie opublikowano 6 sierpnia 2026 r., cztery tygodnie przed biuletynem bezpieczeństwa. Ten sam tag dodaje kontrolę narzędzi dla poszczególnych użytkowników do base_tool_lib_node.py, korzystając z WorkspaceUserResourcePermission, oraz dodaje filtr uwzględniający użytkownika do shared_resource_auth.py — co oznacza, że w zarysie wdraża trzy kroki naprawcze, które biuletyn bezpieczeństwa później zaleca.

Nikt nie stwierdził publicznie takiego związku. Informacje o wydaniu v2.10.5-lts nie wspominają o poprawce uprawnień do narzędzi; wymieniają cztery niepowiązane pozycje dotyczące bezpieczeństwa oraz zestaw prac nad funkcjami i błędami. Komunikat doradczy nie wymienia wersji 2.10.5, a jego zakres wersji objętych problemem kończy się po prostu na 2.9.2, ostatnim wydaniu z linii 2.9. Historia wydań nie pokazuje żadnej poprawki w 2.9.x po komunikacie doradczym, więc wdrożenie na 2.9.2 nie ma poprawionej kompilacji w obrębie własnej linii. Bieżącym wydaniem jest v2.10.8-lts, opublikowane 22 października 2026 r., którego informacje opisują poprawki X-Pack dotyczące autoryzacji narzędzi współdzielonych, a nie czegokolwiek w ścieżce dysponowania w edycji społecznościowej.

Co nie jest ustalone

Trzy kwestie warto oddzielić od samej demonstracji. Po pierwsze, nie ma publicznego raportu o wykorzystaniu tego obejścia przeciwko komukolwiek. W materiale chodzi o wykrytą podatność, a nie o zbadany incydent włamania; nie ma tu ofiary, przypisanego sprawcy ani szkody, a przedstawiony w biuletynie proof of concept został uruchomiony przez badacza w kontrolowanym środowisku. Po drugie, żadna organizacja medialna, regulator ani drugi zespół badawczy najwyraźniej nie przeanalizowali tej luki: istniejące omówienia ograniczają się do baz podatności i agregatorów — m.in. VulDB, bazy Rapid7, Armis, SOCRadar i openCVE — które wymieniają CVE i przytaczają opis z biuletynu, a żaden z nich nie przedstawia niezależnej oceny kodu. Opisany tu mechanizm opiera się zatem na jednym biuletynie i na własnym kodzie źródłowym dostawcy. Po trzecie, nie istnieją żadne dane liczbowe określające, ile wdrożeń MaxKB znajduje się w zagrożonym zakresie, i ani dostawca, ani badacz ich nie opublikowali.

Grupa narażona jest wąska, ale niełatwa do policzenia: samodzielnie hostowane instalacje MaxKB w edycji społecznościowej od 2.0.0 do 2.9.2, które mają więcej niż jednego członka przestrzeni roboczej, w których administrator użył uprawnień na poziomie poszczególnych narzędzi, aby odmówić dostępu do narzędzia zawierającego poświadczenia. Luka nie polega na zdalnym wykonaniu kodu i wymaga ważnego konta o niskich uprawnieniach, dlatego to wpływ na poufność, a nie ścieżka ataku, decyduje o ocenie. To, co zyskuje atakujący, jest ograniczone przez to, co zawierają narzędzia, którym odmówiono dostępu — klucze API, tokeny i wszystko, do czego one dają dostęp — co również wyjaśnia, dlaczego autorzy biuletynu twierdzą, że wpływ jest większy, niż sugeruje niska ocena poufności.

Co może zrobić operator

Środki naprawcze zalecane w biuletynie są skierowane do maintainerów, a nie do operatorów, a ich trzy kroki przekładają się na kod, który pojawił się w v2.10.5-lts: zastosuj uprawnienie przypisane do narzędzia przed wykonaniem narzędzia w implementacjach biblioteki narzędzi i węzła narzędzia, zweryfikuj wszystkie powiązane tool_ids, skill_tool_ids i mcp_tool_ids w momencie wiązania w taki sposób, w jaki knowledge_id_list jest już weryfikowane, oraz spraw, aby filter_authorized_ids uwzględniało uprawnienie przypisane do narzędzia, a nie wyłącznie członkostwo w obszarze roboczym.

Dla zespołu korzystającego z objętej problemem kompilacji praktyczne kroki wynikające z samego opisu w biuletynie są następujące.

• Traktuj każdy sekret przechowywany w sekcji init_params narzędzia na dotkniętym wdrożeniu jako dostępny dla każdego członka przestrzeni roboczej, w tym o najniższej roli, i rotuj te poświadczenia, zamiast zakładać, że odmowa na poziomie narzędzia je chroniła.

• Przeprowadź audyt członkostwa w obszarze roboczym. Obejście wymaga uwierzytelnionego konta w obszarze roboczym, więc usunięcie nieaktywnych lub niezaufanych członków zmniejsza ekspozycję, nawet gdy kod nie może zostać załatany.

• Przejrzyj, które przepływy pracy i agenci wiążą narzędzia zawierające poświadczenia, ponieważ to wiązanie jest krokiem, który — jak stwierdza komunikat doradczy — jest akceptowany bez kontroli poszczególnych narzędzi.

• W przypadku aktualizacji należy pamiętać, że kontrola na użytkownika pojawia się w repozytorium od wersji v2.10.5-lts wzwyż oraz że żadne wydanie nie zostało wskazane przez biuletyn jako poprawka — operator polegający na aktualizacji opiera się na źródle oznaczonym tagiem, a nie na oświadczeniu dostawcy o łatce.

Nic z tego nie czyni tej wady dramatyczną. Czyni ją zwyczajną w konkretny i pouczający sposób: model autoryzacji został zaprojektowany poprawnie, poprawnie udokumentowany i egzekwowany na trasach, o których ktoś pamiętał, by je zabezpieczyć. Ścieżka dyspozycji została napisana przez ludzi myślących o tym, co przepływ pracy powinien móc robić, a nie o tym, kto pyta — a na platformie agentów to właśnie ta ścieżka obsługuje większość rzeczywistych żądań.

Lekcja z tego zapisu ma charakter strukturalny, a nie liczbowy. Uprawnienie do poszczególnego zasobu jest tylko tak silne jak jego najsłabiej chroniony punkt wejścia, a platforma agentowa szybko gromadzi punkty wejścia: trasę debugowania, trasę eksportu, węzeł przepływu pracy, wyzwalacz czatu. MaxKB miał listę uprawnień i mechanizm sprawdzania; czego mu brakowało w linii od 2.0 do 2.9, to nawyk zadawania tego samego pytania przy każdych drzwiach.