Narzędzia MCP wymagają autoryzacji na poziomie działania

17 maja 2026 roku NVD opublikowała wpis CVE-2026-8719 dotyczący AI Engine 3.4.9, wtyczki WordPress, która udostępnia funkcje AI oraz MCP witrynom WordPress.¹³

Ten tryb awarii powinien zaniepokoić każdego twórcę MCP. Wordfence opisał brak kontroli uprawnień WordPress w ścieżce autoryzacji tokenu OAuth typu bearer dla MCP: każdy prawidłowy token OAuth mógł uzyskać dostęp do narzędzi MCP na poziomie administratora bez weryfikacji uprawnień administracyjnych.² Wordfence ocenił problem na 8,8 High i wskazał wersję 3.5.0 jako wydanie z poprawką.² Dziennik zmian wtyczki podaje, że wersja 3.5.0 naprawiła autoryzację OAuth i walidację tokenów dla MCP, wymagając uprawnień administratora.³

Autoryzacja MCP zawodzi wtedy, gdy serwer traktuje samo posiadanie tokenu typu bearer jako zgodę na użycie każdego narzędzia. OAuth może potwierdzić, że token przeszedł przez przepływ autoryzacji. Serwer MCP nadal musi rozstrzygnąć, czy dany podmiot może uruchomić konkretne narzędzie, na danym zasobie i z takim zasięgiem skutków.

W skrócie

Specyfikacja autoryzacji HTTP dla MCP daje twórcom niezbędny fundament: metadane chronionych zasobów, przepływy OAuth 2.1, obsługę tokenów typu bearer, walidację tokenów, kontrole odbiorcy tokenu oraz jawne odpowiedzi 403 Forbidden przy niewystarczających zakresach lub uprawnieniach.⁴ Samouczek bezpieczeństwa MCP przedstawia autoryzację jako warstwę ochrony wrażliwych zasobów i operacji udostępnianych przez serwery MCP.⁵ Te mechanizmy nie zastępują jednak decyzji autoryzacyjnej na poziomie aplikacji. Serwer nadal musi powiązać token z użytkownikiem, rolą, dzierżawcą, narzędziem, zasobem, działaniem i polityką.

CVE-2026-8719 pokazuje tę różnicę w praktyce. AI Engine dodał OAuth 2.1 oraz Dynamic Client Registration dla swojego serwera MCP w wersji 3.4.9 z 12 maja, a następnie 16 maja w wersji 3.5.0 naprawił autoryzację OAuth i walidację tokenów dla MCP, wymagając uprawnień administratora.³ Wniosek wykracza poza WordPress: każdy serwer MCP, który może modyfikować dane, publikować treści, zmieniać ustawienia, czytać prywatne rekordy, wydawać pieniądze lub wywoływać uprzywilejowane API, potrzebuje autoryzacji na poziomie działania, poniżej modelu i poniżej klienta.

Dystrybucja narzędzi zwiększa ryzyko. W pracy o klonowaniu narzędzi z maja 2026 roku przeanalizowano 8 861 repozytoriów MCP i Skills, obejmujących 100 011 wpisów narzędzi, i wykazano wysokie odsetki zweryfikowanych klonów w grupach o dużym podobieństwie.⁶ Wielokrotnie używane szablony mogą rozpowszechniać dobre wzorce. Mogą też rozpowszechniać brakujące kontrole.

Najważniejsze wnioski

Dla twórców serwerów MCP: - Najpierw należy walidować tokeny, a potem autoryzować konkretne działanie. To powinny być dwa osobne progi. - Należy zwracać 401 dla nieprawidłowych lub brakujących tokenów oraz 403 dla prawidłowych tokenów bez wymaganego zakresu lub uprawnienia. - Należy testować tokeny o niskich uprawnieniach wobec każdego narzędzia administracyjnego, zapisującego, publikującego, usuwającego, eksportującego i konfiguracyjnego.

Dla zespołów bezpieczeństwa: - Serwery MCP należy przeglądać jak punkty końcowe aplikacji, nie jak wtyczki czatu. - Warto pytać, z jakim użytkownikiem, rolą, dzierżawcą, zasobem i działaniem powiązane jest każde wywołanie narzędzia. - Należy wymagać logów pokazujących podmiot tokenu, nazwę narzędzia, zasób, decyzję autoryzacyjną i powód odmowy.

Dla zespołów platform agentowych: - Liczba pozycji w katalogu nie dowodzi niezależnych implementacji. - Kontrole podobieństwa i pochodzenia mają znaczenie, ponieważ sklonowane narzędzia mogą kopiować podatną logikę autoryzacji. - Szablony serwerów należy traktować jako infrastrukturę istotną dla bezpieczeństwa.

Dla operatorów: - Należy zaktualizować AI Engine do wersji 3.5.0 lub nowszej, jeżeli używana jest podatna wtyczka WordPress.²³ - Należy wyłączyć ekspozycję MCP do czasu ustalenia, które role WordPress mają dostęp do których narzędzi. - Każde nowe połączenie MCP warto uruchamiać w trybie tylko do odczytu, a uprawnienia poszerzać dopiero wtedy, gdy testy potwierdzą poprawne ścieżki odmowy.

Co zepsuło się w AI Engine

AI Engine przedstawia MCP jako sposób podłączania Claude Code, Claude, ChatGPT, OpenClaw i innych klientów do witryny WordPress przez URL, logowanie i krok zatwierdzenia.³ Wersja 3.4.9 dodała OAuth 2.1 z Dynamic Client Registration dla serwera MCP, aby klienci działający w przeglądarce mogli łączyć się bez współdzielonego tokenu typu bearer.³

Ten kierunek produktu ma sens. Współdzielone statyczne tokeny nie pasują do integracji MCP skierowanych do użytkowników. Przepływy OAuth mogą powiązać klienta, użytkownika i serwer czyściej niż ręcznie kopiowane sekrety.

Błąd znajdował się warstwę niżej. Według NVD i Wordfence podatna ścieżka akceptowała każdy prawidłowy token OAuth dla dostępu MCP, nie weryfikując wcześniej uprawnień administratora, a następnie udostępniała narzędzia MCP na poziomie administratora.¹² Ta różnica jest kluczowa:

Opis poprawki na stronie wtyczki WordPress używa właściwego języka: autoryzacja OAuth i walidacja tokenów dla MCP wymagają teraz uprawnień administratora, co zapobiega eskalacji uprawnień przez użytkowników niebędących administratorami.³ To zdanie wskazuje brakującą warstwę. Token nie może zastępować kontroli uprawnień.

OAuth jest konieczny, ale niewystarczający

Specyfikacja autoryzacji MCP obejmuje przepływ na poziomie transportu dla transportów opartych na HTTP. Specyfikacja mówi, że klienci MCP wysyłają żądania do ograniczonych serwerów MCP w imieniu właścicieli zasobów, a przepływ opiera się na OAuth 2.1, metadanych chronionych zasobów, metadanych serwera autoryzacji, Dynamic Client Registration i użyciu tokenów typu bearer.⁴

Te elementy rozwiązują realne problemy:

Specyfikacja MCP ostrzega również przed ryzykiem confused deputy i przekazywania tokenów dalej. Serwery MCP muszą sprawdzać, czy przedstawione tokeny są przeznaczone dla danego serwera MCP, i nie mogą przekazywać tokenu otrzymanego od klienta MCP do nadrzędnych API.⁴ Te wskazówki chronią granicę między usługami.

Autoryzacja na poziomie działania chroni granicę wewnątrz serwera MCP.

Serwer MCP może udostępniać 10 narzędzi albo 100. Część narzędzi czyta publiczne metadane. Część czyta prywatne rekordy. Część przygotowuje zmiany. Część modyfikuje stan produkcyjny. Część administruje użytkownikami, wtyczkami, płatnościami, zadaniami, wiadomościami lub infrastrukturą. Prawidłowy token nie powinien automatycznie otwierać dostępu do każdego narzędzia tylko dlatego, że serwer zaakceptował sesję.

Poprawny łańcuch wygląda tak:

1. Zweryfikować wystawcę tokenu, podpis, czas wygaśnięcia, odbiorcę tokenu i reguły transportu.
2. Przypisać token do lokalnego podmiotu: użytkownika, konta usługi, organizacji, dzierżawcy lub automatyzacji.
3. Wczytać rolę, zakresy, nadania, budżety i politykę tego podmiotu.
4. Sklasyfikować żądane narzędzie MCP według typu działania i ryzyka.
5. Sprawdzić zasób docelowy, nie tylko nazwę narzędzia.
6. Zwrócić 403, gdy token jest prawidłowy, ale działanie przekracza uprawnienia.
7. Zalogować decyzję z detalami wystarczającymi do późniejszego przeglądu.

OAuth doprowadza żądanie do punktu decyzyjnego. Autoryzacja rozstrzyga, czy dane działanie jest dopuszczalne.

Wywołania narzędzi potrzebują macierzy uprawnień

Narzędzia agentów czynią stare nawyki z punktów końcowych bardziej ryzykownymi. Zwykła trasa webowa ma często wokół siebie wąską ścieżkę UI. Narzędzie dostępne dla modelu znajduje się w systemie planowania. Agent może ponawiać próby, łączyć wywołania, analizować opisy narzędzi, zestawiać wyniki odczytu z działaniami zapisu i przenosić instrukcje z niezaufanych treści do kolejnych kroków.

To zachowanie zmienia minimalny model uprawnień. Serwer nie powinien pytać tylko: „czy ten użytkownik ma dostęp do MCP?”. Powinien pytać: „czy ten użytkownik może teraz wykonać to działanie przez to narzędzie na tym zasobie?”.

Warto użyć macierzy:

Ta macierz pasuje do wzorca z Klucze agentów potrzebują budżetów ryzyka. Poświadczenia nie powinny działać jak uniwersalne ciągi typu bearer. Powinny działać jak obiekty ograniczonych uprawnień z limitami po stronie serwera, logami aktywności, możliwością unieważnienia i ostrożnymi ustawieniami domyślnymi.

Pasuje również do ram odpowiedzialności opisanych w Własność agenta AI jest podstawą zaufania. Każde uprzywilejowane wywołanie narzędzia powinno być powiązane z odpowiedzialnym kontem, sesją, pakietem uprawnień, ścieżką przeglądu i ścieżką zatrzymania.

Sklonowane narzędzia mogą kopiować tę samą brakującą kontrolę

Błąd AI Engine miałby znaczenie nawet wtedy, gdyby każdy serwer MCP pochodził ze starannej, niezależnej implementacji. Ekosystem narzędzi nie wygląda jednak tak czysto.

Kim, Jiang, Hu, Jia i Gong opublikowali 10 maja 2026 roku pracę mierzącą klonowanie narzędzi w ekosystemach agentowej AI. Ich zbiór danych obejmował 7 508 repozytoriów MCP z 87 564 wyodrębnionymi narzędziami oraz 1 353 repozytoria Skills z 12 447 narzędziami, łącznie 8 861 repozytoriów i 100 011 wpisów narzędzi.⁶ Autorzy użyli podobieństwa Jaccarda na poziomie tokenów oraz rozmytego podobieństwa strukturalnego ssdeep, a następnie ręcznie zweryfikowali próbkowane pary z różnych przedziałów podobieństwa.⁶

Streszczenie pracy podaje, że 60% kandydatów o wysokim podobieństwie Jaccarda i 85% kandydatów o wysokim ssdeep w ekosystemie MCP zostało ręcznie potwierdzonych jako klony.⁶ Autorzy wskazują, że ukryta duplikacja może zanieczyszczać podziały benchmarków, propagować podatne implementacje, zniekształcać pomiary generalizacji użycia narzędzi oraz rodzić problemy pochodzenia, atrybucji i licencji.⁶

To odkrycie zmienia sposób, w jaki zespoły powinny czytać wzrost katalogów MCP. Więcej narzędzi nie oznacza automatycznie większej liczby niezależnych przeglądów bezpieczeństwa. Powtarzalny szkielet serwera może zapewnić ekosystemowi spójność. Ta sama powtarzalność może jednak skopiować ten sam słaby wzorzec autoryzacji do wielu pakietów.

Przegląd bezpieczeństwa powinien więc obejmować pochodzenie:

Skills agentów potrzebują menedżerów pakietów argumentował za dystrybucją w stylu pakietów, pochodzeniem i polityką wokół skills. Serwery MCP potrzebują tej samej dyscypliny, a dodatkowo testów autoryzacji w środowisku wykonawczym.

Minimalny zestaw testów autoryzacji MCP

Każdy serwer MCP, który dotyka prywatnych lub modyfikowalnych danych, powinien dostarczać zestaw testów autoryzacji. Testy jednostkowe potwierdzające szczęśliwą ścieżkę nie wystarczą. Niebezpieczne zachowanie kryje się w ścieżkach odmowy.

Należy zacząć od tych przypadków:

Dokładny kod statusu może zależeć od polityki produktu, ale rozróżnienie powinno pozostać: nieprawidłowe poświadczenia zawodzą przed rozpoznaniem podmiotu, a prawidłowe poświadczenia z niewystarczającymi uprawnieniami zawodzą na progu autoryzacji. Specyfikacja MCP wskazuje 401 dla brakującej lub nieprawidłowej autoryzacji oraz 403 dla nieprawidłowych zakresów lub niewystarczających uprawnień.⁴

W WordPress reguła jest jeszcze ostrzejsza: narzędzia MCP wykonujące operacje administracyjne powinny sprawdzać te same uprawnienia WordPress, które sprawdzałby panel administracyjny, REST API albo wewnętrzna ścieżka PHP. Rola o niższych uprawnieniach nie powinna otrzymać nowej drogi do zachowania administracyjnego tylko dlatego, że wywołanie przyszło przez protokół dostępny dla modelu.

Czego powinien wymagać przegląd katalogu

Katalogi MCP i katalogi wtyczek powinny traktować metadane autoryzacji jako pełnoprawne dane pakietu. Użytkownik decydujący, czy włączyć serwer, potrzebuje czegoś więcej niż liczby narzędzi.

Minimalne publiczne metadane:

Te pola nie wyeliminowałyby podatnych narzędzi. Uczyniłyby jednak powierzchnię przeglądu rzeczywistą. Operatorzy mogliby porównywać deklarowane uprawnienia z faktycznym kodem, a katalogi mogłyby grupować podobne implementacje po wykryciu defektu.

To brakujący pomost między specyfikacją autoryzacji MCP a pracą o klonowaniu narzędzi. Specyfikacja mówi implementatorom, jak przeprowadzić przepływ na poziomie protokołu. Ekosystem potrzebuje pochodzenia na poziomie pakietu i dowodów autoryzacji na poziomie działania, aby powtarzane implementacje nie powtarzały tych samych brakujących kontroli.

Co zbudować zamiast tego

Autoryzację MCP należy budować jako potok:

1. Próg protokołu: zweryfikować metadane chronionych zasobów, przepływ OAuth, umiejscowienie tokenu, poprawność tokenu, wygaśnięcie, wystawcę i odbiorcę tokenu.
2. Próg podmiotu: zmapować token na użytkownika, konto usługi, rolę, dzierżawcę i przestrzeń roboczą.
3. Próg narzędzia: sklasyfikować każde narzędzie jako odczyt, szkic, zapis, usunięcie, publikację, eksport, administrację, wykonanie albo wydatek.
4. Próg zasobu: autoryzować dokładny obiekt docelowy albo granicę dzierżawcy.
5. Próg budżetu: przed wykonaniem zastosować limity częstotliwości, rozmiaru, wydatków, odbiorców i czasu.
6. Próg zatwierdzenia: wymagać zatwierdzenia przez człowieka albo politykę dla działań wysokiego ryzyka.
7. Próg audytu: zapisywać decyzje allow, deny i wymagające przeglądu w miejscu dostępnym dla operatorów.

Te progi powinny znajdować się poza modelem. Opis narzędzia może powiedzieć agentowi, aby unikał działań administracyjnych. Polecenie może prosić o ostrożność. Żadne z nich nie powinno wyznaczać granicy. Serwer powinien odrzucić nieautoryzowane działanie nawet wtedy, gdy agent prosi grzecznie, pewnie albo wielokrotnie.

Środowisko agenta jest tylko sugestią przedstawia tę samą tezę z innej strony: prawidłowe uprawnienia nadal mogą łączyć się w niebezpieczne zachowanie. Narzędzia MCP potrzebują autoryzacji na granicy działania, ponieważ agent będzie komponował działania szybciej, niż człowiek zdoła je mentalnie zasymulować.

FAQ

Czy MCP wymaga OAuth?

Nie. Autoryzacja MCP jest opcjonalna, a specyfikacja autoryzacji HTTP ma zastosowanie wtedy, gdy implementacja obsługuje autoryzację przez transporty oparte na HTTP. Ta sama specyfikacja mówi, że transporty STDIO powinny pobierać poświadczenia ze środowiska, zamiast korzystać z przepływu HTTP OAuth.⁴

Czy OAuth rozwiązuje autoryzację MCP?

OAuth rozwiązuje tylko część problemu. OAuth może ustanowić przepływ autoryzacji, wydać tokeny i pozwolić chronionemu serwerowi MCP walidować tokeny typu bearer. Serwer MCP nadal musi zdecydować, czy podmiot tokenu może wykonać konkretne działanie narzędzia na docelowym zasobie.

Czego dowiodło CVE-2026-8719?

CVE-2026-8719 dowiodło, że ścieżka z prawidłowym tokenem nadal może nie egzekwować lokalnych uprawnień. NVD i Wordfence opisują AI Engine 3.4.9 jako akceptujący każdy prawidłowy token OAuth dla dostępu MCP bez weryfikacji uprawnień administratora, zanim narzędzia MCP na poziomie administratora stały się osiągalne.¹²

Co twórcy MCP powinni przetestować najpierw?

Najpierw należy testować ścieżki odmowy: token o niskich uprawnieniach do narzędzia administracyjnego, token tylko do odczytu do narzędzia zapisującego, prawidłowy token do zasobu innego dzierżawcy, token wygasły, token dla niewłaściwego odbiorcy oraz destrukcyjne narzędzie bez zatwierdzenia. Przejście szczęśliwej ścieżki OAuth nie dowodzi autoryzacji na poziomie działania.

Dlaczego klonowanie narzędzi ma znaczenie dla bezpieczeństwa MCP?

Klonowanie narzędzi ma znaczenie, ponieważ powtarzane implementacje mogą powtarzać to samo podatne oprogramowanie pośredniczące, skróty autoryzacyjne i brakujące kontrole. Praca o klonowaniu narzędzi z maja 2026 roku wykazała wysokie odsetki zweryfikowanych klonów wśród kandydatów MCP o dużym podobieństwie i ostrzegła, że ukryta duplikacja może propagować podatne implementacje.⁶

Źródła