FastGPT CVE-2026-68929: publiczny shareId pozwala przejąć kanał WeChat

CVE-2026-68929 dotyczy brakującej autoryzacji w endpointach integracji WeChat iLink w FastGPT. Serwer wybierał konfigurację kanału na podstawie shareId, lecz nie potwierdzał zalogowanej tożsamości, zespołu ani właściciela aplikacji. Osoba znająca publiczny identyfikator mogła wyłączyć bota innego tenanta albo związać aplikację ofiary ze swoim kontem WeChat.

Podatne są wersje wcześniejsze niż FastGPT 4.15.2. Rekord CVE opublikowany 28 sierpnia ma wynik CVSS 4.0 równy 9,3 (Critical), natomiast widok GitHub Advisory nadal pokazuje etykietę High. Biuletyn projektu jest datowany na 19 sierpnia, więc dzisiejsza nowość dotyczy formalnego rekordu i dystrybucji informacji, a nie dnia powstania poprawki.

To nie jest klasyczny prompt injection. Model nie musi wykonać polecenia napastnika, a treść promptu nie jest źródłem decyzji. Problem znajduje się w control plane platformy AI: publiczny identyfikator rozmowy został potraktowany jak dowód uprawnienia do modyfikacji integracji.

shareId identyfikuje zasób, ale nie uwierzytelnia właściciela

FastGPT pozwala publikować aplikacje przez linki, iframe i kanały komunikacyjne. shareId jest potrzebny odbiorcy, aby trafić do właściwej aplikacji. Występuje więc w adresach i osadzeniach, a jego poufność nie może być podstawą ochrony operacji administracyjnych.

Podatny kod wykonywał wyszukanie rekordu outLink po shareId. Funkcja authOutLinkValid() potwierdzała jedynie, że taki obiekt istnieje. Nie sprawdzała zalogowanego użytkownika, teamId, tmbId ani uprawnienia do aplikacji. Nazwa funkcji zawierająca „auth” mogła sugerować granicę bezpieczeństwa, choć implementowała tylko walidację istnienia.

To częsty błąd w aplikacjach wielotenantowych. Warstwa routingu odpowiada na pytanie „który zasób?”, a autoryzacja — „czy ten podmiot może wykonać tę akcję na tym zasobie?”. Jeden identyfikator może pomóc znaleźć rekord, lecz nie zastępuje drugiej decyzji.

Pierwszy skutek: zdalne wyłączenie bota

Endpoint wylogowania WeChat przyjmował shareId, wykonywał opisane sprawdzenie istnienia, a następnie ustawiał status integracji na offline i czyścił zapisany token. Zewnętrzny użytkownik nie potrzebował sesji FastGPT. Wystarczał identyfikator wystawiony w udostępnionym linku.

Skutek to naruszenie dostępności kanału. Bot przestaje obsługiwać rozmowy, a operator musi ponownie przeprowadzić wiązanie. W systemie obsługującym klientów oznacza to nie tylko przerwę techniczną, lecz również utracone zgłoszenia, naruszenie SLA i trudne do wyjaśnienia przejście usługi w stan offline.

W logach sama operacja może wyglądać poprawnie, bo aplikacja celowo aktualizuje własny rekord i nie generuje błędu autoryzacji. Detekcja powinna dlatego łączyć zmianę statusu z tożsamością operatora, źródłowym adresem, sesją i wcześniejszym przepływem administracyjnym. W podatnej wersji brak zalogowanej tożsamości przy mutacji jest sam w sobie sygnałem.

Drugi skutek: podmiana wiązania kanału

Poważniejszy wariant dotyczy obsługi kodu QR. Endpoint generowania kodu był chroniony tylko sprawdzeniem istnienia shareId, a endpoint statusu nie wykonywał kontroli autoryzacji. Po potwierdzeniu kodu zapisywał dane bota — token, identyfikator konta i bazowy adres — do outLink wskazanego przez publiczny identyfikator, a następnie uruchamiał polling.

W rezultacie aplikacja należąca do organizacji mogła zostać połączona z kanałem kontrolowanym przez inną osobę. Prywatne odpowiedzi generowane na podstawie firmowej bazy wiedzy trafiałyby do obcego inboxa, prawidłowe wiązanie zostałoby wyparte, a zasoby i punkty AI ofiary byłyby zużywane przez komunikację napastnika.

Nie oznacza to automatycznego pobrania całej bazy wiedzy. Ujawnienie zależy od pytań, reguł aplikacji, narzędzi i danych dostępnych w odpowiedziach. Przejęty kanał jest jednak legalnym interfejsem do aplikacji, więc może ujawnić treści, które operator uważał za dostępne tylko w kontrolowanej integracji.

Dlaczego skan kodu QR nie jest zgodą właściciela aplikacji

Skan potwierdza, że osoba kontroluje konto WeChat wiązane z kanałem. Nie potwierdza, że ta sama osoba ma prawo zarządzać aplikacją FastGPT wskazaną przez shareId. System złączył dwie niezależne tożsamości bez bezpiecznego mostu.

Prawidłowy przepływ powinien rozpocząć zalogowany operator tenanta. Serwer tworzy wtedy krótko żyjący, jednorazowy stan związany z użytkownikiem, zespołem, aplikacją i zamierzoną akcją. Callback lub polling może zakończyć operację wyłącznie dla tej samej transakcji, a wynik powinien zostać zapisany po ponownej kontroli uprawnienia.

Losowy kod QR nie wystarczy, jeśli rekord docelowy nadal wybiera publiczny parametr. Stan musi być nieprzenoszalny pomiędzy tenantami, odporny na replay i unieważniany po użyciu. Dobrze zaprojektowany przepływ rejestruje także operatora zatwierdzającego, czas i docelowy kanał.

Kto jest narażony

Ekspozycja dotyczy instalacji FastGPT starszych niż 4.15.2, które korzystają z kanału WeChat iLink. Samo posiadanie podatnego pakietu nie oznacza, że endpoint ma użyteczny rekord do zmiany. Potrzebny jest opublikowany outLink z shareId i skonfigurowana lub możliwa do skonfigurowania integracja.

Publiczne linki nie powinny być usuwane tylko po to, aby „ukryć identyfikator”. Ich funkcją jest dostęp dla odbiorców. Rotacja shareId może ograniczyć ryzyko tymczasowo, ale nowa wartość znów stanie się publiczna po udostępnieniu. Trwałym rozwiązaniem jest poprawna autoryzacja operacji mutujących.

W środowiskach SaaS należy także sprawdzić, czy reverse proxy, WAF lub SSO wprowadza dodatkową kontrolę. Nie wolno jej zakładać bez testu. Endpoint API może mieć inną regułę routingu niż panel, a zaufany nagłówek od proxy może być pomijany przez część ścieżek.

Co zrobić teraz

Zaktualizuj FastGPT do 4.15.2 lub nowszej wspieranej wersji. Po wdrożeniu potwierdź, że wylogowanie, generowanie kodu i sprawdzanie statusu wymagają uwierzytelnionego użytkownika z prawem do konkretnego outLink. Test negatywny powinien objąć brak sesji, sesję innego zespołu, cudzy shareId, wygasłą transakcję QR i ponowne użycie zakończonego stanu.

Jeżeli aktualizacja musi poczekać, ogranicz lub wyłącz endpointy WeChat na reverse proxy i usuń nieużywane kanały. Nie blokuj całego publicznego czatu bez oceny wpływu biznesowego. Mitygacja powinna dotyczyć operacji zarządzających, niekoniecznie bezpiecznego odczytu publicznej aplikacji.

Przejrzyj wszystkie istniejące outLink: ich właścicieli, status, identyfikator konta WeChat, czas ostatniego wiązania, bazowy URL i historię zmian tokenu. Wymuś ponowne, autoryzowane powiązanie kanałów, których pochodzenia nie da się potwierdzić. Tokeny przechowuj i rotuj zgodnie z instrukcją integracji, bez kopiowania ich do zgłoszeń lub SIEM.

Polowanie na ślady wykorzystania

Najbardziej wartościowe są mutacje kanału bez odpowiadającej im sesji administratora. Szukaj wywołań wylogowania, generowania QR i statusu dla tego samego shareId, szczególnie z nowych adresów lub user-agentów. Koreluj je ze zmianą app.token, app.accountId, app.baseUrl i app.status.

Podejrzany jest także schemat: generowanie kodu, szybkie potwierdzenie, natychmiastowe uruchomienie pollingu i wzrost zużycia punktów AI bez działania członka zespołu. Jeżeli odpowiedzi mogły zawierać dane wewnętrzne, ustal pytania i rezultaty obsłużone przez obcy kanał, zakres narzędzi aplikacji oraz dostęp do źródeł RAG.

Brak historii zmian w bazie utrudnia ocenę. Wtedy wykorzystaj logi aplikacji, reverse proxy, kontenery, bazę danych, Redis i dostawcę WeChat. Zachowaj czasy w jednej strefie i nie traktuj ponownego powiązania jako dowodu, że wcześniejszy stan był poprawny.

Wnioski dla projektowania agentów i integracji AI

Platforma AI składa się z dwóch płaszczyzn. Data plane przetwarza wiadomości, dokumenty, prompty i wywołania narzędzi. Control plane decyduje, kto publikuje aplikację, podłącza kanał, zmienia model, dodaje sekret i ponosi koszt. Ochrona wyłącznie promptów pozostawia najważniejsze operacje zarządcze poza modelem zagrożeń.

Każdy mutujący endpoint powinien oceniać co najmniej subject, tenant, resource, action i bieżący stan. Identyfikatory z URL, webhooka, callbacku lub kodu QR są danymi wejściowymi, nie uprawnieniami. Własność musi pochodzić z serwera, a nie z pola przesłanego przez klienta.

Fakty źródłowe i wnioski Breachroad

Zakres wersji, działanie endpointów, wpływ na kanał oraz poprawka 4.15.2 pochodzą z advisory FastGPT i rekordu CVE. Zalecenia dotyczące modelu transakcji QR, telemetrii, mitygacji proxy i ponownego wiązania są wnioskami obronnymi Breachroad. Źródła nie informują o potwierdzonym wykorzystaniu w środowisku konkretnej organizacji.

Źródła pierwotne

• GHSA-q4pr-3qpg-9q5v — biuletyn FastGPT
• Poprawka 81d3919 w repozytorium FastGPT
• CVE-2026-68929 w NVD
• Repozytorium FastGPT

Bezpieczeństwo AI zaczyna się od kontroli nad kanałami i tenantami, zanim wiadomość dotrze do modelu. Na szkoleniach z bezpiecznego AI i cyberbezpieczeństwa pokazujemy zespołom, jak projektować granice control plane, callbacki i integracje. Dla działających platform możemy też przeprowadzić testy penetracyjne aplikacji i API obejmujące BOLA, workflow publikacji i separację tenantów.