WordPress zasila ponad 40% wszystkich stron internetowych na świecie. To liczba, która sprawia że każda fundamentalna zmiana w architekturze tej platformy ma skutki na skalę trudną do wyobrażenia. WordPress 7.0 przynosi taką zmianę — i nie chodzi o opóźnioną funkcję współedycji w czasie rzeczywistym, o której pisało już całe internetowe środowisko.
Chodzi o coś, co przeszło niemal bez komentarza w kontekście bezpieczeństwa: WordPress 7.0 adoptuje MCP jako pierwszorzędny komponent platformy.
Dla kogoś śledzącego cyberflux od początku roku to zdanie powinno zapalić kilka lampek jednocześnie. Przez ostatnie miesiące pisaliśmy o trzydziestu CVE w MCP w ciągu sześćdziesięciu dni, o CVE-2026-32211 w Azure MCP Server — krytycznej luce wynikającej z braku autentykacji — o klasycznych podatnościach pojawiających się w nowej warstwie infrastruktury. Teraz ta warstwa trafia do platformy zasilającej prawie połowę internetu.
Czym dokładnie jest MCP w WordPress 7.0
WordPress 7.0 wprowadza MCP na trzech poziomach, które warto rozróżnić.
WordPress Playground MCP Server to serwer umożliwiający agentom AI bezpośrednie zarządzanie środowiskami WordPress przez rozmowę. Zestaw narzędzi jest rozbudowany: zarządzanie witrynami (playground_get_website_url, playground_list_sites, playground_open_site), wykonywanie PHP (playground_execute_php, playground_request), operacje na systemie plików (playground_read_file, playground_write_file, playground_list_files, playground_mkdir, playground_delete_file) i wiele innych. Komenda konfiguracyjna w Claude Code wygląda prosto:
claude mcp add --transport stdio --scope user wordpress-playground -- npx -y @wp-playground/mcpPo jej wykonaniu agent AI może testować wtyczki, debugować bazę danych, budować motywy — wszystko przez rozmowę, bez klikania przez interfejs administracyjny.
WordPress MCP Adapter to wtyczka zamieniająca dowolną witrynę WordPress w serwer MCP. Działa na bazie Abilities API wprowadzonego w WordPress 6.9. Abilities API definiuje co witryna "umie" — jakie operacje są dostępne, z jakimi uprawnieniami, z jakim zakresem dostępu. MCP Adapter bierze zdefiniowane Abilities i eksponuje je jako narzędzia MCP, które zewnętrzne agenty AI mogą odkrywać i wywoływać. Narzędzia jak Claude Desktop, Cursor czy VS Code mogą po aktywacji wtyczki bezpośrednio zarządzać treścią, ustawieniami i strukturą witryny.
WP AI Client to biblioteka PHP standaryzująca komunikację z usługami AI — wspólny interfejs dla OpenAI, Anthropic, Google i innych, dzięki któremu deweloperzy wtyczek piszą raz, nie wiążąc się z konkretnym dostawcą.
Co to znaczy w praktyce: agent jako zalogowany użytkownik
Kluczowe zdanie z recenzji WordPress MCP Adapter przez InstaWP brzmi: "MCP clients act as authenticated WordPress users with real write access."
To nie jest ostrzeżenie marginalne. To jest opis fundamentalnego modelu bezpieczeństwa całej integracji. Agent AI łączący się z witryną przez MCP Adapter działa z uprawnieniami roli, na której jest skonfigurowany. Jeśli administrator skonfiguruje połączenie na koncie z uprawnieniami redaktora — agent ma uprawnienia redaktora. Jeśli na koncie administratora — agent ma pełny dostęp do wszystkiego.
Abilities API wprowadza mechanizm permission_callback pozwalający deklarować co jest bezpieczne do eksponowania. Model domyślnie odmowy jest poprawnym podejściem do bezpieczeństwa — nic nie jest dostępne, dopóki nie zostanie jawnie zadeklarowane jako dostępne. Problem pojawia się przy skalowaniu. Jak recenzja InstaWP precyzyjnie opisuje: "Wtyczki muszą decydować co jest bezpieczne do eksponowania. Zespoły zarządzające wieloma środowiskami muszą ręcznie utrzymywać spójność konfiguracji między staging i produkcją. Abilities przeznaczone tylko do odczytu muszą być starannie separowane od tych modyfikujących treść lub ustawienia."
To nie jest wada projektu — to praca, która rośnie proporcjonalnie do liczby środowisk i członków zespołu. Dla agencji zarządzającej dziesiątkami witryn klientów jest to realny problem operacyjny. Dla właściciela jednej witryny instalującego popularną wtyczkę z domyślnie aktywowanymi Abilities — jest to ryzyko, którego może nawet nie być świadomy.
Dlaczego kontekst ekosystemu MCP ma tu znaczenie
W tym miejscu historia staje się bardziej interesująca niż "WordPress adoptuje nową technologię."
Przez ostatnie miesiące cyberflux śledził jak ekosystem MCP buduje swoją historię bezpieczeństwa. Wyniki nie są zachęcające. Trzydzieści CVE w sześćdziesięciu dniach — path traversal, wstrzykiwanie argumentów, brak walidacji, brak autentykacji. CVE-2026-32211 w Azure MCP Server z wynikiem CVSS 9.1 wynikający z tego, że specyfikacja MCP robi autentykację opcjonalną i implementacja Microsoftu po prostu jej nie dodała. Klasyczne podatności webowe pojawiające się konsekwentnie w każdej nowej implementacji protokołu.
Teraz ten ekosystem — ze wszystkimi swoimi wzorcami podatności — trafia do platformy zasilającej 40% stron internetowych, instalowanej przez miliony osób bez głębokiej wiedzy technicznej, z wbudowanym rynkiem wtyczek liczącym dziesiątki tysięcy pozycji.
Ekosystem wtyczek WordPress ma własną historię bezpieczeństwa, która jest bezpośrednio relevantna w tym kontekście. Miesięczne raporty podatności od Wordfence czy SolidWP konsekwentnie pokazują dziesiątki nowych podatności w wtyczkach tygodniowo — SQL injection, XSS, eskalacja uprawnień, obejście autentykacji. Wiele z nich pozostaje niezałatanych przez tygodnie lub miesiące na tysiącach witryn.
Teraz wyobraź sobie nakładkę: wtyczki implementujące Abilities API, eksponujące narzędzia MCP, z podatnościami w implementacji — i agenty AI mające do nich dostęp. Łańcuch ataków, który wcześniej wymagał kompromitacji konta użytkownika WordPress lub znalezienia podatności w konkretnej wtyczce, może teraz zacząć się od złośliwego serwera MCP, zatrутej konfiguracji narzędzia albo prompt injection w treści, którą agent przetwarza.
To jest dokładnie wzorzec opisany w badaniu Google DeepMind o AI Agent Traps — z tą różnicą, że teraz mamy skalę dystrybucji WordPressa stojącą za powierzchnią ataku.
Playground MCP: wykonywanie PHP przez agenta
Warto zatrzymać się przy możliwościach WordPress Playground MCP Server. Narzędzie playground_execute_php dosłownie umożliwia agentowi wykonanie dowolnego kodu PHP w środowisku WordPress. playground_write_file pozwala pisać do systemu plików. playground_delete_file — usuwać pliki.
Z perspektywy bezpieczeństwa: to jest poziom dostępu równoważny dostępowi do powłoki systemowej w środowisku PHP. Różnica między tym a podatnością klasy RCE jest konceptualna — oba dają wykonanie kodu.
Playground jest środowiskiem izolowanym działającym w przeglądarce przez WebAssembly, co jest istotnym kontekstem — tam te możliwości są bezpieczne bo środowisko jest z założenia efemeryczne i odizolowane od produkcji. Ale wzorzec, który to ustanawia, i narzędzia deweloperskie budowane na jego podstawie, będą ewoluowały w kierunku produkcyjnych wdrożeń. Pytanie o to gdzie przebiega granica między "środowiskiem testowym" a "środowiskiem produkcyjnym" jest w świecie agentów AI mniej oczywiste niż mogłoby się wydawać.
Abilities API jako warstwa bezpieczeństwa — i jej ograniczenia
Abilities API jest przemyślanym podejściem do problemu, który zdefiniowaliśmy w poprzednich wpisach jako "permission injection" — sytuacji, w której agent dostaje dostęp do zasobów, bo nikt nie przemyślał dokładnie jakie uprawnienia powinien mieć.
Model jest poprawny: jawna deklaracja możliwości, permission_callback wymuszający kontrolę uprawnień, domyślna odmowa dostępu. To lepsze niż alternatywa.
Ale implementacja tej warstwy jest w rękach ekosystemu wtyczek — tych samych deweloperów wtyczek, którzy regularnie produkują podatności klasy SQL injection i eskalacji uprawnień w swoich podstawowych funkcjach. Oczekiwanie że ten sam ekosystem poprawnie zaimplementuje bezpieczeństwo nowej warstwy MCP — przy dodatkowej złożoności wynikającej z modelu agentowego — jest optymistyczne.
Pierwsza linia obrony to sama specyfikacja. Abilities API jest zaprojektowane z myślą o bezpieczeństwie. Ale jak wielokrotnie pokazywały CVE w ekosystemie MCP: dobry projekt specyfikacji nie gwarantuje dobrej implementacji. Każda wtyczka implementująca Abilities jest oddzielną implementacją, z oddzielnym potencjałem do popełnienia tych samych klas błędów.
Co to oznacza dla osób zarządzających witrynami WordPress
WordPress 7.0 nie wyjdzie w maju z domyślnie aktywowanym MCP Adapter na każdej witrynie. MCP Adapter to wtyczka wymagająca świadomej instalacji. Abilities API wymaga jawnej konfiguracji przez deweloperów wtyczek. Playground MCP jest narzędziem deweloperskim, nie funkcją dla użytkowników końcowych.
Ale historia WordPressa pokazuje konsekwentny wzorzec: nowe funkcje trafiają do popularnych wtyczek, te wtyczki są instalowane masowo, użytkownicy konfigurują je z domyślnymi ustawieniami nie rozumiejąc wszystkich implikacji bezpieczeństwa.
Dla osób już używających lub planujących AI do zarządzania witrynami WordPress pytania, które warto zadać teraz: jakie konto jest używane przez agenta AI? z jakimi uprawnieniami? które Abilities są eksponowane przez zainstalowane wtyczki? czy te Abilities mają poprawnie skonfigurowane permission_callback? czy masz log wywołań MCP pozwalający sprawdzić co agent faktycznie robi?
Dla deweloperów wtyczek planujących implementację Abilities API: warto traktować każde Ability jako potencjalną powierzchnię ataku analogiczną do punktu końcowego API. Separacja Abilities tylko do odczytu od modyfikujących, minimalne uprawnienia, defensywna walidacja danych wejściowych — to nie jest opcjonalne.
Podsumowanie
WordPress 7.0 to technicznie dobra implementacja MCP w platformie CMS. Abilities API jest przemyślaną warstwą bezpieczeństwa. MCP Adapter ma domyślny model odmowy. WordPress Playground działa w izolowanym środowisku.
Ale zestawienie skali dystrybucji WordPressa — 40% sieci, miliony instalacji, ekosystem dziesiątek tysięcy wtyczek tworzonych przez deweloperów o różnym poziomie świadomości bezpieczeństwa — z tym co wiemy o historii bezpieczeństwa ekosystemu MCP przez ostatnie miesiące, tworzy obraz, który warto śledzić uważnie.
Nie dlatego że WordPress 7.0 jest złym projektem. Dlatego że każda nowa warstwa infrastruktury na takiej skali tworzy nowe możliwości dla atakujących, niezależnie od jakości oryginalnego projektu. Historia WordPressa jest w tym zakresie jednoznaczna.
Gdy wypuszczone zostaną pierwsze popularne wtyczki implementujące Abilities API i pojawią się pierwsze agencje oferujące "AI-zarządzanie witryną przez MCP" jako standardową usługę — to będzie właściwy moment, żeby zadać pytanie: ile z tych implementacji będzie miało pierwsze CVE w ciągu roku?
Na podstawie historii ekosystemu MCP: odpowiedź jest prawdopodobnie "wiele."
Źródła
WordPress Developer Blog — co nowego dla deweloperów w kwietniu 2026, szczegóły MCP i Abilities API: https://developer.wordpress.org/news/2026/04/whats-new-for-developers-april-2026/
InstaWP — recenzja WordPress MCP Adapter, model bezpieczeństwa i implikacje przy skalowaniu: https://instawp.com/wordpress-mcp-adapter-review/
WPPoland — WordPress Playground MCP: agenty AI zarządzające witrynami WordPress: https://wppoland.com/en/wordpress-playground-mcp-ai-agents-2026/
Patchstack — State of WordPress Security 2026, whitepaper: https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
Make WordPress Playground — podsumowania spotkań z marca 2026, kontekst rozwoju MCP: https://make.wordpress.org/playground/2026/03/30/playground-meetings-summaries-march-2026/
