Stos agentowy ma problem rodem z 1998 roku

W ostatnim tygodniu czerwca 2026 roku pojawiło się niewielkie skupisko CVE wymierzonych w narzędzia agentowe AI — dwa z nich w tym samym kliencie agenta desktopowego, oba dotyczące błędów autoryzacji, jeden usadowiony dokładnie wewnątrz callbacku OAuth w MCP. Rozpatrywany osobno, każdy z nich jest błędem o średniej istotności, który opiekun projektu łata w weekend. Rozpatrywane łącznie, skupisko staje się sygnałem, a sygnał ten jest strukturalny: ekosystem agentów AI gromadzi powierzchnię ataku szybciej, niż gromadzi kulturę bezpieczeństwa potrzebną do jego obrony. To nie jest moralna porażka któregokolwiek pojedynczego projektu. To dokładnie ten stan, w jakim znajdowała się sieć około 1998 roku, gdy pewien język trafił do głównego nurtu z niebezpiecznymi ustawieniami domyślnymi, poświadczenia leżały wszędzie, a baza instalacji rosła szybciej, niż ktokolwiek zdołałby ją zabezpieczyć. Narzędzia, które przechowują Pańskie klucze i uruchamiają Pański shell, dostarczane są z poziomem bezpieczeństwa z 1998 roku prosto w model zagrożeń z 2026 roku. {.answer-block}

TL;DR

• Cherry Studio, popularny kliencki agent AI na komputery stacjonarne, otrzymał 29 czerwca 2026 roku dwa wpisy CVE: błąd niewłaściwej autoryzacji w serwerze callbacku OAuth dla MCP (CVE-2026-13524) oraz obejście autoryzacji w API preload (CVE-2026-13534).¹²
• Ten wzorzec nie ogranicza się do jednej aplikacji. Samo referencyjne oprzyrządowanie MCP dostarczyło w 2025 roku krytyczne luki umożliwiające zdalne wykonanie kodu: mcp-remote z oceną CVSS 9.6 (CVE-2025-6514) oraz MCP Inspector od Anthropic z oceną CVSS 9.4 (CVE-2025-49596).³⁴
• Narzędzia agentowe są strukturalnie bardziej narażone, niż kiedykolwiek były aplikacje webowe: przechowują poświadczenia, z założenia wykonują kod i znajdują się wewnątrz Pańskich granic zaufania (IDE, shell, przeglądarka), a nie za nimi.
• Wiedza pozwalająca zapobiec tym błędom już istnieje. Specyfikacja MCP szczegółowo dokumentuje klasy ataków typu confused deputy oraz ataków na przepływ OAuth; kultura pozwalająca zastosować ją w każdej szybko zmieniającej się integracji jeszcze się nie rozprzestrzeniła.⁵
• Sieć z 1998 roku dojrzała dopiero wtedy, gdy robaki sprawiły, że brak bezpieczeństwa stał się kosztowny. Ekosystem agentów nie ma jeszcze równoważnej siły wymuszającej, a te same modele, które dziś znajdują te błędy, mogą napisać ten, który się nią stanie.

Skupisko w konkretach

Cherry Studio to wieloplatformowy klient desktopowy, który reklamuje się jako „studio produktywności AI z inteligentnym czatem, autonomicznymi agentami i ponad 300 asystentami”, z wyraźnym wsparciem dla serwerów Model Context Protocol. To dokładnie ten rodzaj narzędzia, o którym mówi ten esej: skierowany do konsumenta agent, który pośredniczy w obsłudze Pańskich kluczy API, uruchamia lokalne integracje i sięga do sieci w Pańskim imieniu.

29 czerwca 2026 roku VulDB opublikowało przeciwko niemu dwa ostrzeżenia. CVE-2026-13524 to błąd niewłaściwej autoryzacji (CWE-285) w lokalnym serwerze callbacku OAuth dla MCP, w pliku src/main/services/mcp/oauth/callback.ts, obejmujący wersje od 1.9.0 do 1.9.6. Sformułowanie jest jednoznaczne: „Manipulacja argumentem code prowadzi do niewłaściwej autoryzacji”. Otrzymuje ocenę CVSS 3.1 na poziomie 5.6 — średnią.¹ CVE-2026-13534 to obejście autoryzacji (CWE-639) w API preload o nazwie CherryIN, do wersji 1.9.7 włącznie, z oceną 5.0.² Żaden z nich nie jest sensacją. Oba to cichy błąd autoryzacji, jaki popełnia zespół poruszający się szybko po powierzchni nowej dla wszystkich.

Ten pierwszy jest znamienny. Callback OAuth w kliencie MCP to podręcznikowy przykład granicy zaufania: punkt, w którym zewnętrzny serwer autoryzacji przekazuje kod z powrotem do Pańskiej maszyny, a Pańska maszyna decyduje, czy mu zaufać. Nieprawidłowa obsługa tego punktu nie jest egzotyczną, nową klasą błędów. To ta sama klasa, której dokument bezpieczeństwa samej specyfikacji MCP poświęca najwięcej miejsca.

Odrzuciłem dwa sąsiadujące CVE z tego samego okna czasowego, ponieważ skupisko musi być rzeczywiste: CVE-2026-13533 dotyczy agentejo Cockpit CMS, menedżera treści w PHP, a nie frameworka agentowego, natomiast CVE-2026-13543 nie dało się w ogóle zweryfikować. Kilka solidnych przykładów bije na głowę rozdmuchaną listę.

Dlaczego narzędzia agentowe są strukturalnie w gorszej sytuacji

Klasyczna aplikacja webowa z okolic 1998 roku była niebezpieczna, ale funkcjonowała za pewną granicą. Działała na serwerze, wewnątrz którego się Pan nie znajdował, jej promień rażenia obejmował bazę danych i sesję, a włamanie dawało atakującemu dane aplikacji.

Narzędzie agentowe odwraca tę geometrię. Działa na Pańskiej maszynie lub wewnątrz Pańskiego IDE, przechowuje długoterminowe poświadczenia do Pańskiej chmury i Pańskich repozytoriów oraz wykonuje kod jako podstawową funkcję, a nie exploit. Nie ma granicy, za którą można się schować, ponieważ to narzędzie jest granicą — i jest ona z założenia przepuszczalna.

Simon Willison precyzyjnie nazwał to zagrożenie w czerwcu 2025 roku mianem „śmiertelnej triady” (lethal trifecta): agent staje się podatny na atak, gdy łączy „dostęp do Pańskich prywatnych danych”, „ekspozycję na niezaufane treści” oraz „zdolność do komunikacji na zewnątrz” w sposób, który umożliwia kradzież tych danych.⁷ Każdy sprawny agent domyślnie ma wszystkie trzy, ponieważ odczytywanie Pańskich sekretów, przyjmowanie treści kształtowanych przez atakującego i wysyłanie żądań wychodzących to jego funkcje, a nie błędy. Triada nie jest przypadkiem skrajnym. To konfiguracja bazowa.

Na tym polega różnica strukturalna. Aplikację webową z 1998 roku trzeba było podstępem skłonić do wycieku danych z jednej granicy. Agent z 2026 roku pojawia się fabrycznie okablowany z każdą zdolnością, jakiej potrzebuje łańcuch eksfiltracji, a jedyną rzeczą stojącą między złośliwym wejściem a Pańskimi poświadczeniami jest to, czy narzędzie prawidłowo wytyczyło swoje wewnętrzne granice zaufania. Błąd w callbacku Cherry Studio to właśnie to, jak wygląda sytuacja, gdy jedna z tych granic zostanie wytyczona odrobinę źle.

Wzmocnienie przez MCP

Model Context Protocol to tkanka łączna stosu agentowego z 2026 roku i zwielokrotnia powierzchnię ataku w specyficzny sposób: każdy serwer MCP to nowa uprzywilejowana integracja — zwykle napisana pośpiesznie — którą model może wywołać. Dodanie jednej jest bezproblemowe. Audyt jednej już nie. Baza zainstalowanych integracji wyprzedza populację ludzi, którzy czytają ich kod.

Referencyjne oprzyrządowanie pokazuje, że to nie jest problem projektów hobbystycznych. W lipcu 2025 roku JFrog ujawnił CVE-2025-6514 — wstrzyknięcie poleceń systemu operacyjnego w mcp-remote, łączniku używanym przez Claude Desktop, Cursor i Windsurf, które złośliwy serwer wyzwala spreparowanym adresem URL authorization_endpoint podczas przepływu OAuth: krytyczne, CVSS 9.6.³ W tym samym miesiącu Tenable ujawnił CVE-2025-49596 — lukę umożliwiającą zdalne wykonanie kodu o ocenie 9.4 we własnym MCP Inspectorze firmy Anthropic, w której brak sprawdzenia uwierzytelnienia pozwalał złośliwej witrynie dotrzeć do lokalnego portu i, poprzez DNS rebinding, uruchomić dowolne polecenia.⁴

Dwa z czterech CVE omawianych w tym eseju to błędy w przepływie OAuth w narzędziach MCP: jeden w serwerze callbacku, jeden w wykrywaniu punktów końcowych. To nie przypadek. OAuth w kliencie agenta to wielokrotnie spartaczona granica — i specyfikacja mówi o tym wprost. Dokument najlepszych praktyk bezpieczeństwa MCP, datowany na 18 czerwca 2025 roku, poświęca swoją najdłuższą sekcję „problemowi zdezorientowanego zastępcy” (confused deputy) i nakazuje, aby serwery proxy wdrażały zgodę per klient, walidowały parametr OAuth state oraz dokładnie dopasowywały adresy przekierowań (redirect URI).⁵ Opublikowano to rok przed tym, zanim Cherry Studio dostarczyło swój błąd w callbacku. Luka nie leży w wiedzy. Leży w dystansie między załącznikiem dotyczącym bezpieczeństwa w specyfikacji a medianą integracji napisaną w zeszły wtorek.

Prompt injection sprawia, że to wzmocnienie jest jakościowo gorsze niż cokolwiek, z czym mierzyła się dawna sieć. Willison ukuł ten termin we wrześniu 2022 roku, pisząc „proponuję, aby oczywistą nazwą dla tego zjawiska był prompt injection”, przez analogię do SQL injection: zaufane instrukcje i niezaufane wejście sklejone w jeden ciąg znaków, który silnik następnie interpretuje.⁶ Dla agenta dane są wektorem, a nie tylko kodem. Zatruta strona internetowa, spreparowany plik, wrogi opis narzędzia — każdy bajt, który odczyta model, może przenosić instrukcję. Specyfikacja MCP mówi o tym bez ogródek, ostrzegając, że złośliwy serwer może zamienić klienta w serwer pośredniczący w eksfiltracji danych.⁵ Nie da się tego załatać przez escapowanie wejścia, ponieważ wejściem jest język naturalny, a interpreterem jest model.

Analogia z 1998 rokiem, doprecyzowana

Analogia musi przetrwać weryfikację faktów, bo inaczej jest tylko wrażeniem — oto zatem tamta epoka, przedstawiona dokładnie.

PHP 3 pojawił się w czerwcu 1998 roku i oddał dynamiczny język sieciowy w ręce milionów ludzi z ustawieniem domyślnym, które dziś odczytuje się jako lekkomyślne: wejście zewnętrzne — z query stringa, ciasteczek czy serwera — było rejestrowane bezpośrednio w zasięgu globalnym. register_globals było włączone, a zmienna kontrolowana przez atakującego mogła po cichu stać się zmienną, której ufał Pański kod. Poprawka zajęła cztery lata. PHP 4.2.0, wydane w kwietniu 2002 roku, zmieniło to ustawienie domyślne, a ogłoszenie o wydaniu stwierdza to wprost: „Zmienne zewnętrzne (ze środowiska, żądania HTTP, ciasteczek lub serwera WWW) nie są już domyślnie rejestrowane w zasięgu globalnym”.⁸ Druga podpora definiująca tamtą epokę, magic quotes, uruchamiała addslashes, aby udawać bezpieczeństwo przed SQL injection bez faktycznej treści, i przeżyła register_globals o lata, zanim projekt wreszcie ją uśmiercił. Niebezpieczne ustawienia domyślne, iluzja bezpieczeństwa, wieloletnie opóźnienie, zanim kultura nadążyła. Taka była warstwa aplikacji młodej sieci.

Kultura nie pojawiła się sama. Została wymuszona. 19 lipca 2001 roku robak Code Red wykorzystał przepełnienie bufora w serwerze WWW Microsoft IIS, a według wyliczeń CAIDA „ponad 359 000 komputerów zostało zainfekowanych robakiem Code-Red (CRv2) w niecałe 14 godzin”.⁹ 25 stycznia 2003 roku robak Sapphire/Slammer uderzył w przepełnienie bufora w Microsoft SQL Server, upakował się w pakiety o wielkości 376 bajtów i „zainfekował większość podatnych hostów, jakie dało się znaleźć, w ciągu dziesięciu minut” — najszybciej rozprzestrzeniający się robak w historii do tamtego momentu.¹⁰ Były to robaki infrastrukturalne, a nie błędy PHP, i nie będę ich mieszać. Chodzi o kształt tamtej dekady: niebezpieczne ustawienia domyślne w każdej warstwie oraz kultura bezpieczeństwa, która dojrzała dopiero wtedy, gdy brak bezpieczeństwa stał się dotkliwie i publicznie kosztowny. Zasada secure-by-default była lekcją, za którą branża zapłaciła robakami.

Przełóżmy to na rok 2026, a odpowiedniość staje się niewygodna. Niebezpieczne ustawienia domyślne: klienci agentów, którzy ufają kodom z callbacku i pomijają sprawdzanie zgody. Iluzja bezpieczeństwa: monit o uprawnienia nad tokenem o zakresie admin:*. Eksplodująca baza instalacji: serwer MCP do wszystkiego, dodany jednym kliknięciem, niezaudytowany przez nikogo. Tym, czego ekosystem jeszcze nie ma, jest robak. Ma ustawienia domyślne z 1998 roku i profil celu z 2001 roku — i czeka na swoją siłę wymuszającą.

Postawa operatora

Nie ma Pan komfortu czekania na kulturę. Używa Pan tych narzędzi już teraz, więc to Pan wytycza granice, których ekosystem jeszcze dla Pana nie wytyczył. Ramą, której używam, jest triada jako operacyjna lista kontrolna: dla każdego agenta należy zapytać, co może odczytać, co może wykonać i co może wyeksfiltrować, a następnie postawić deterministyczne zabezpieczenie na każdym z tych punktów.

Kolumna z zabezpieczeniami nie jest życzeniowa. Jest deterministyczna, a determinizm to cała rzecz. Hooki uruchamiają się przy zdarzeniach cyklu życia z kodami wyjścia, z którymi model nie może dyskutować, a reguły uprawnień oceniane są zanim narzędzie zostanie uruchomione, a nie po fakcie. To ta warstwa, w której „agent nie powinien robić X” staje się „agent nie może zrobić X” — i jest to jedyna warstwa, obok której ładunek prompt injection nie zdoła się przegadać. Gdy nie można ufać wejściu i nie można ufać, że model sam się na tym wejściu upilnuje, egzekwuje się to na granicy, której model nie kontroluje.

Druga kontrola odczytywana jest jako funkcja produktywności, ale w rzeczywistości jest funkcją bezpieczeństwa. Gdy agent kompiluje swoją pracę w możliwy do przejrzenia plan przed wykonaniem, przejrzenie tego planu jest przeglądem bezpieczeństwa. Czterdziestowierszowy skrypt przepływu pracy, który wymienia każde narzędzie, jakie wywoła, i każdy plik, jakiego dotknie, to model zagrożeń, który przeczyta Pan w minutę. Nie da się zaudytować dziesięciu tysięcy decyzji podejmowanych na żywo; można zaudytować plan, który by je wygenerował, zanim cokolwiek wyda.

I proszę mieć na oku tę asymetrię: ta sama zdolność, która wytwarza te CVE, również je znajduje. Badacz z Anthropic użył agenta kodującego i dziesięciowierszowego skryptu, aby ujawnić 23-letnią lukę w jądrze Linuksa oraz 22 CVE w Firefoksie. Narzędzie na Pańskim biurku jest skanerem podatności wycelowanym w Pański własny stos — o ile go Pan wyceluje. Obrońcy mogą już dziś zautomatyzować wykrywanie i właśnie teraz budują warstwę triażu. To jedyna przewaga, jakiej sieć z 1998 roku nie miała.

Stanowisko

Oto co moim zdaniem się wydarzy — na tyle konkretnie, by móc się mylić. Ekosystem agentów dozna swojego momentu Code Red, zanim zdobędzie kulturę bezpieczeństwa, ponieważ w takiej kolejności zrobiła to sieć. Siłą wymuszającą będzie najprawdopodobniej samorozprzestrzeniający się ładunek prompt injection, przemieszczający się między agentami poprzez współdzielone serwery MCP, albo masowe zdarzenie eksfiltracji poświadczeń, którego ślad prowadzi do jednej popularnej, niedostatecznie zaudytowanej integracji. Zbudowanie go będzie tanie, bo te same modele, które znajdują błędy w jądrze, potrafią go napisać — a ostrzeżenie o „nadchodzącej wielkiej fali” nigdy nie dotyczyło wyłącznie obrony.

Gdy to nastąpi, secure-by-default przestaje być opcjonalne. Klienci MCP dostarczani są z domyślnie włączonymi oknami zgody, walidowanymi odbiorcami (audience) tokenów, callbackami odrzucającymi niepasujące adresy przekierowań — tak jak PHP ostatecznie zaczął być dostarczany z wyłączonym register_globals. Warstwy uprawnień przechodzą z modelu opt-in do domyślnej odmowy (default-deny). Integracje, które przetrwają, to te, które potraktowały załącznik bezpieczeństwa specyfikacji jako samą specyfikację.

Niewygodną częścią jest oś czasu. Sieci zajęło mniej więcej lata 1998–2005, aby zinternalizować secure-by-default, z latami na przemyślenia między kolejnymi robakami. Stos agentowy narasta szybciej, z celem o wyższej wartości na maszynie każdego dewelopera i z zestawem narzędzi atakującego, który poprawia się z każdą generacją modeli. Problem z 1998 rokiem jest realny. Jedynym otwartym pytaniem jest to, czy zadziałamy zgodnie z analogią, zanim robak napisze zakończenie, czy dopiero potem.

Kluczowe wnioski

• Przeprowadzić audyt triady dla każdego agenta. Proszę zapisać, co każde narzędzie może odczytać, wykonać i wyeksfiltrować, a następnie potwierdzić deterministyczne zabezpieczenie dla każdego wiersza. Zdolność bez zabezpieczenia to Pańska ekspozycja — i miejsce, w którym wyląduje kolejny ładunek.
• Prowadzić listę dozwolonych serwerów MCP; traktować każdy parametr polecenia jako niezaufane wykonanie. Dodanie integracji to jedno kliknięcie, a jej audyt już nie, więc rejestrację należy ograniczyć do przejrzanej listy. Dwa z czterech CVE omawianych tutaj były błędami przepływu OAuth w klientach MCP: uzgadnianie (handshake) jest granicą, a nie formalnością.
• Uczynić z etapu planowania bramkę przeglądu. Niech agenci kompilują intencję w możliwy do przejrzenia plan i proszę go czytać jak model zagrożeń przed wykonaniem. Skrypt, który wymienia swoje narzędzia i pliki, da się zaudytować w minutę; dziesięć tysięcy wywołań narzędzi na żywo już nie.
• Najpierw wycelować skaner w siebie. Zdolność, która wytwarza te CVE, również je znajduje. Proszę przeprowadzić wspomagane przez agenta przeglądy bezpieczeństwa własnego kodu i zależności, zanim ktoś inny przeprowadzi swoje na Panu.

FAQ

Czy serwery MCP są bezpieczne?

Nie domyślnie i nie jednolicie. MCP to protokół; jego bezpieczeństwo zależy od tego, jak każdy serwer i klient go implementują. Ujawnienia z 2025 roku dotyczące mcp-remote (CVSS 9.6) oraz MCP Inspectora firmy Anthropic (CVSS 9.4) pokazują, że nawet referencyjne oprzyrządowanie dostarczyło krytyczne luki RCE.³⁴ Specyfikacja dokumentuje główne klasy ataków — confused deputy, token passthrough, SSRF, kompromitację lokalnego serwera — i przepisuje konkretne środki zaradcze.⁵ Proszę traktować każdy serwer jako uprzywilejowaną integrację: uruchamiać tylko te, którym Pan ufa lub które Pan zaudytował, jawnie umieszczać je na liście dozwolonych i zakładać, że każdy serwer, z którym się Pan łączy, może wpływać na Pańskiego agenta.

Czym jest prompt injection?

Prompt injection to sytuacja, w której atakujący przemyca instrukcje do niezaufanego wejścia odczytywanego przez system AI, a model podąża za nimi tak, jakby pochodziły od Pana. Simon Willison ukuł ten termin we wrześniu 2022 roku przez analogię do SQL injection: zaufane instrukcje i niezaufane wejście sklejone w jeden prompt, który model następnie interpretuje, bez wiarygodnego sposobu na odróżnienie, która część należała do atakującego.⁶ Dla agentów jest to szczególnie niebezpieczne, ponieważ dane stają się wektorem, a escapowanie nie może tego naprawić, bo interpreterem jest model językowy.

Czym jest śmiertelna triada?

Ukuta przez Simona Willisona w czerwcu 2025 roku nazwa dla trzech zdolności, które razem czynią agenta podatnym na atak: dostępu do Pańskich prywatnych danych, ekspozycji na niezaufane treści oraz zdolności do komunikacji na zewnątrz.⁷ Agent posiadający wszystkie trzy może zostać zmanipulowany przez wstrzykniętą treść tak, by odczytał Pańskie sekrety i wysłał je atakującemu. Większość sprawnych agentów domyślnie ma wszystkie trzy, dlatego właściwym ruchem jest zabezpieczenie każdej ze zdolności, a nie liczenie na to, że model się oprze.

Jak zabezpieczyć agenta działającego na mojej maszynie?

Proszę zacząć od granicy, której model nie kontroluje. Należy używać reguł uprawnień i hooków ocenianych zanim narzędzie zostanie uruchomione, aby skompromitowany prompt nie mógł się przegadać do działania, którego Pan zabronił. Proszę umieszczać narzędzia i serwery MCP na liście dozwolonych, wymagać zgody, zanim nowy lokalny serwer zostanie uruchomiony, i nadawać każdemu poświadczeniu najmniejsze uprawnienia, tak aby skradziony token miał niewielki promień rażenia. Proszę blokować żądania wychodzące do prywatnych i link-local zakresów IP, aby zamknąć ścieżkę eksfiltracji. Następnie proszę przejrzeć plan agenta przed dużymi operacjami — to tam wyłapuje się wstrzyknięcie, które przetrwało granicę odczytu.

Źródła