Stos agentowy ma problem z 1998 roku

W ostatnim tygodniu czerwca 2026 roku pojawiło się niewielkie skupisko luk CVE wymierzonych w narzędzia agentowe AI, w tym dwie w tym samym desktopowym kliencie agenta, obie będące błędami autoryzacji, jedna ulokowana dokładnie wewnątrz callbacku OAuth dla MCP. Czytana osobno, każda z nich to luka o średniej istotności, którą opiekun projektu łata w weekend. Czytane razem, tworzą sygnał, a sygnał ten ma charakter strukturalny: ekosystem agentów AI gromadzi powierzchnię ataku szybciej, niż gromadzi kulturę bezpieczeństwa zdolną jej bronić. Nie jest to moralna wina żadnego pojedynczego projektu. To dokładnie ten stan, w jakim znajdowała się sieć około 1998 roku, gdy język programowania wszedł 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ł ją utwardzić. Narzędzia, które przechowują klucze i uruchamiają powłokę, trafiają do użytku z dojrzałością bezpieczeństwa z 1998 roku, mierząc się z modelem zagrożeń z 2026 roku.

TL;DR

• Cherry Studio, popularny desktopowy klient agenta AI, otrzymał dwa wpisy CVE 29 czerwca 2026 roku: błąd nieprawidłowej autoryzacji w serwerze callbacku OAuth dla MCP (CVE-2026-13524) oraz obejście autoryzacji w API preload (CVE-2026-13534).¹²
• Wzorzec nie ogranicza się do jednej aplikacji. Samo referencyjne oprzyrządowanie MCP wypuściło w 2025 roku krytyczne luki pozwalające na zdalne wykonanie kodu: mcp-remote z CVSS 9,6 (CVE-2025-6514) oraz MCP Inspector od Anthropic z CVSS 9,4 (CVE-2025-49596).³⁴
• Narzędzia agentowe są strukturalnie bardziej odsłonięte, niż kiedykolwiek były aplikacje webowe: przechowują poświadczenia, wykonują kod z założenia i znajdują się wewnątrz granic zaufania użytkownika (IDE, powłoka, przeglądarka), a nie za nimi.
• Wiedza pozwalająca zapobiec tym błędom już istnieje. Specyfikacja MCP szczegółowo opisuje klasy ataków typu zdezorientowany zastępca oraz ataki na przepływ OAuth; kultura stosowania tej wiedzy przy każdej szybko powstającej integracji jeszcze się nie rozprzestrzeniła.⁵
• Sieć roku 1998 dojrzała dopiero wtedy, gdy robaki uczyniły brak bezpieczeństwa kosztownym. Ekosystem agentowy nie ma jeszcze równoważnej funkcji wymuszającej, a te same modele, które dziś znajdują takie błędy, mogą napisać ten, który się nią stanie.

Skupisko, konkretnie

Cherry Studio to wieloplatformowy klient desktopowy reklamujący się jako „studio produktywności AI z inteligentnym czatem, autonomicznymi agentami i ponad 300 asystentami”, z jawnym wsparciem dla serwerów Model Context Protocol. To dokładnie ten rodzaj narzędzia, o którym mówi ten esej: konsumencki agent, który pośredniczy w obsłudze kluczy API, uruchamia lokalne integracje i sięga do sieci w imieniu użytkownika.

29 czerwca 2026 roku VulDB opublikowało przeciwko niemu dwa poradniki bezpieczeństwa. CVE-2026-13524 to błąd nieprawidłowej autoryzacji (CWE-285) w komponencie MCP OAuth Local Callback Server, w pliku src/main/services/mcp/oauth/callback.ts, w wersjach od 1.9.0 do 1.9.6. Opis jest prosty: „Manipulacja argumentem code prowadzi do nieprawidłowej autoryzacji”. Ocena CVSS 3.1 wynosi 5,6, czyli średnia.¹ CVE-2026-13534 to obejście autoryzacji (CWE-639) w API preload CherryIN, do wersji 1.9.7 włącznie, z oceną 5,0.² Żadna z nich nie trafia na czołówki. Obie są cichym błędem autoryzacji, jaki popełnia zespół poruszający się szybko po powierzchni nowej dla wszystkich.

Pierwsza z nich jest znamienna. Callback OAuth w kliencie MCP to podręcznikowa granica zaufania: punkt, w którym zewnętrzny serwer autoryzacyjny odsyła kod na maszynę użytkownika, a maszyna decyduje, czy mu zaufać. Błędna obsługa tego punktu nie jest egzotyczną, nową klasą podatności. To właśnie ta klasa, której dokument bezpieczeństwa samej specyfikacji MCP poświęca najwięcej miejsca.

Odrzuciłem dwie sąsiednie luki CVE z tego samego okna czasowego, ponieważ skupisko musi być prawdziwe: CVE-2026-13533 dotyczy agentejo Cockpit CMS, czyli menedżera treści w PHP, a nie frameworka agentowego, natomiast CVE-2026-13543 w ogóle nie dało się zweryfikować. Kilka solidnych przykładów bije napompowaną listę.

Dlaczego narzędzia agentowe są strukturalnie w gorszej sytuacji

Klasyczna aplikacja webowa około 1998 roku była niebezpieczna, ale żyła za granicą. Działała na serwerze, wewnątrz którego użytkownik się 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 maszynie użytkownika albo wewnątrz jego IDE, przechowuje długożyjące poświadczenia do chmury i repozytoriów, a kod wykonuje jako podstawową funkcję, nie jako skutek exploita. Nie ma granicy, za którą można by się schować, ponieważ to narzędzie jest granicą, a granica ta jest z założenia przepuszczalna.

Simon Willison precyzyjnie nazwał to zagrożenie w czerwcu 2025 roku terminem „śmiertelna triada” (lethal trifecta): agent staje się podatny na wykorzystanie, gdy łączy w sobie „dostęp do prywatnych danych”, „ekspozycję na niezaufaną treść” oraz „zdolność komunikowania się na zewnątrz” w sposób umożliwiający kradzież tych danych.⁷ Każdy zdolny agent ma domyślnie wszystkie trzy elementy, ponieważ czytanie sekretów, przyjmowanie treści kształtowanej przez atakującego i wysyłanie żądań na zewnątrz to jego funkcje, a nie błędy. Triada nie jest przypadkiem brzegowym. Jest konfiguracją wyjściową.

Na tym polega różnica strukturalna. Aplikację webową z 1998 roku trzeba było podstępem skłonić do wycieku danych z zakresu jednej granicy. Agent z 2026 roku przychodzi fabrycznie okablowany wszystkimi zdolnościami, jakich potrzebuje łańcuch eksfiltracji, a jedyne, co dzieli złośliwe dane wejściowe od poświadczeń, to fakt, czy narzędzie poprawnie wytyczyło swoje wewnętrzne granice zaufania. Błąd callbacku w Cherry Studio pokazuje, jak to wygląda, gdy jedna z tych granic zostanie wytyczona odrobinę nie tam.

Wzmocnienie przez MCP

Model Context Protocol jest tkanką łączną stosu agentowego roku 2026 i zwielokrotnia powierzchnię ataku w bardzo konkretny sposób: każdy serwer MCP to nowa uprzywilejowana integracja, zwykle napisana w pośpiechu, którą model może wywołać. Dodanie takiego serwera nie kosztuje nic. Audyt już tak. Baza zainstalowanych integracji wyprzedza populację ludzi czytających ich kod.

Referencyjne oprzyrządowanie pokazuje, że nie jest to problem projektów hobbystycznych. W lipcu 2025 roku JFrog ujawnił CVE-2025-6514, wstrzyknięcie polecenia systemowego w mcp-remote, konektorze używanym przez Claude Desktop, Cursor i Windsurf, które złośliwy serwer wyzwala spreparowanym adresem URL authorization_endpoint w trakcie przepływu OAuth: ocena krytyczna, CVSS 9,6.³ W tym samym miesiącu Tenable ujawnił CVE-2025-49596, lukę zdalnego wykonania kodu o ocenie 9,4 we własnym MCP Inspectorze firmy Anthropic, gdzie brak kontroli uwierzytelnienia pozwalał złośliwej stronie internetowej sięgnąć do lokalnego portu i — poprzez DNS rebinding — uruchomić dowolne polecenia.⁴

Dwie z czterech luk CVE omawianych w tym eseju to błędy przepływu OAuth w oprzyrządowaniu MCP: jedna w serwerze callbacku, druga w wykrywaniu endpointów. To nie przypadek. OAuth w kliencie agenta bywa granicą raz po raz przekraczaną przez pomyłkę, a specyfikacja mówi o tym wprost. Dokument „Security Best Practices” dla MCP, datowany na 18 czerwca 2025 roku, poświęca najdłuższą sekcję „problemowi zdezorientowanego zastępcy” (confused deputy) i nakazuje, aby serwery pośredniczące wdrażały zgodę udzielaną osobno dla każdego klienta, walidowały parametr OAuth state i dokładnie dopasowywały identyfikatory URI przekierowania.⁵ Opublikowano to rok przed tym, jak Cherry Studio wypuściło swój błąd w callbacku. Luka nie leży w wiedzy. Leży w dystansie między załącznikiem bezpieczeństwa w specyfikacji a przeciętną integracją napisaną w zeszły wtorek.

Prompt injection czyni to wzmocnienie jakościowo gorszym 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ło prompt injection”, przez analogię do wstrzykiwania SQL: zaufane instrukcje i niezaufane dane wejściowe sklejone w jeden ciąg, który silnik następnie interpretuje.⁶ Dla agenta wektorem są dane, nie tylko kod. Zatruta strona internetowa, plik z pułapką, wrogi opis narzędzia: każdy bajt, który model przeczyta, może nieść instrukcję. Specyfikacja MCP mówi o tym bez ogródek, ostrzegając, że złośliwy serwer może zamienić klienta w pośrednika w eksfiltracji danych.⁵ Nie da się tego załatać escapowaniem danych wejściowych, ponieważ wejściem jest język naturalny, a interpreterem — model.

Analogia z 1998 rokiem, uściślona

Analogia musi przetrwać weryfikację faktów, inaczej pozostaje samym wrażeniem, oto więc tamta epoka, przedstawiona rzetelnie.

PHP 3 ukazało się w czerwcu 1998 roku i oddało dynamiczny język webowy w miliony rąk z ustawieniem domyślnym, które dziś czyta się jako lekkomyślne: dane zewnętrzne, pochodzące z ciągu zapytania, ciasteczek albo z serwera, były 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 kod ufał. Poprawka zajęła cztery lata. PHP 4.2.0, wydane w kwietniu 2002 roku, zmieniło to ustawienie domyślne, a ogłoszenie wydania 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 podpórka definiująca tamtą epokę, magic quotes, uruchamiała addslashes, aby udawać ochronę przed wstrzyknięciem SQL bez jej istoty, i przeżyła register_globals o wiele lat, zanim projekt wreszcie ją uśmiercił. Niebezpieczne ustawienia domyślne, iluzja bezpieczeństwa, wieloletnie opóźnienie, zanim kultura nadgoniła. Tak wyglądała warstwa aplikacyjna młodej sieci.

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

Przeniesienie tego na 2026 rok daje niewygodną zgodność. Niebezpieczne ustawienia domyślne: klienci agentów, którzy ufają kodom z callbacku i pomijają kontrole zgody. Iluzja bezpieczeństwa: monit o uprawnienia dotyczący tokenu o zakresie admin:*. Eksplodująca baza instalacji: serwer MCP do wszystkiego, dodany jednym kliknięciem, nieaudytowany przez nikogo. Czego ekosystem jeszcze nie ma, to robaka. Ma ustawienia domyślne z 1998 roku i profil celu z 2001 roku, i czeka na swoją funkcję wymuszającą.

Postawa operatora

Nie ma luksusu czekania na kulturę. Skoro tych narzędzi używa się już dziś, trzeba samodzielnie wytyczyć granice, których ekosystem jeszcze nie wytyczył. Rama, z której korzystam, to triada jako operacyjna lista kontrolna: dla każdego agenta należy zapytać, co wolno mu czytać, co wolno mu wykonywać i co może wyprowadzić na zewnątrz, a następnie postawić deterministyczne zabezpieczenie na każdym z tych punktów.

Kolumna z zabezpieczeniami nie jest listą pobożnych życzeń. Jest deterministyczna, a determinizm to tutaj sedno. Hooki uruchamiają się na zdarzeniach cyklu życia z kodami wyjścia, z którymi model nie podyskutuje, a reguły uprawnień są oceniane przed uruchomieniem narzędzia, nie po nim. To warstwa, w której „agent nie powinien robić X” zamienia się w „agent nie może zrobić X”, i jedyna warstwa, której ładunek prompt injection nie zdoła obgadać. Skoro nie można ufać danym wejściowym ani liczyć na to, że model sam się przy nich upilnuje, egzekwuje się reguły na granicy, której model nie kontroluje.

Druga kontrola czyta się jak funkcja produktywności, ale w istocie służy bezpieczeństwu. Gdy agent kompiluje swoją pracę w możliwy do przejrzenia plan przed wykonaniem, przegląd tego planu jest przeglądem bezpieczeństwa. Czterdziestowierszowy skrypt workflow, który wymienia każde narzędzie, jakie wywoła, i każdy plik, jakiego dotknie, to model zagrożeń możliwy do przeczytania w minutę. Nie da się przeprowadzić audytu dziesięciu tysięcy decyzji podejmowanych na żywo; da się zaudytować plan, który by je wygenerował, zanim cokolwiek wyda.

Warto też mieć na oku asymetrię: ta sama zdolność, która produkuje te luki CVE, również je znajduje. Badacz z Anthropic użył agenta kodującego i dziesięciowierszowego skryptu, aby wydobyć dwudziestotrzyletnią podatność jądra Linuksa oraz 22 luki CVE w Firefoksie. Narzędzie stojące na biurku jest skanerem podatności wycelowanym we własny stos, o ile się je w tę stronę wyceluje. Obrońcy mogą dziś automatyzować wykrywanie i właśnie budują warstwę triage. To jedyna przewaga, której sieć roku 1998 nie miała.

Aktualizacja z 24 sierpnia: zapis od czasu publikacji

Ten wpis dowodził, że czerwcowe skupisko było sygnałem strukturalnym, a nie pechem. Siedem tygodni zapisu od tamtej pory:

Długi ogon MCP produkuje stały strumień luk CVE. W jednym tygodniu w połowie sierpnia trzy społecznościowe serwery MCP otrzymały wpisy CVE: wstrzyknięcie kodu w pythonowym REPL-u Jij-MCP-Server (CVE-2026-19964), wykonanie polecenia poprzez manipulację argumentami w android-mcp-server (CVE-2026-19978) oraz fałszowanie żądań po stronie serwera w mcp-florence2 (CVE-2026-19984).¹¹¹²¹³ Wszystkie o średniej istotności — dwie wyzwalane zdalnie, trzecia lokalnie na hoście, na którym działa agent — i wszystkie z klasycznych klas: wstrzyknięcie, nieoczyszczone exec, SSRF, lądujące w narzędziach działających z uprawnieniami agenta. To ten sam scenariusz, który sekcja o wzmocnieniu przez MCP uznawała za strukturalny — długi ogon drobnych integracji, każda potencjalnym mcp-remote — a który teraz przychodzi punktualnie.

Nie chodzi wyłącznie o ogon społecznościowy. Azure SRE Agent — firmowy agent operacyjny Microsoftu — otrzymał CVE-2026-62830 w dniu 7 sierpnia: brak autoryzacji umożliwiający podniesienie uprawnień przez sieć, oceniony na 9,9, czyli krytycznie.¹⁴ Argument strukturalny nigdy nie dotyczył amatorskich opiekunów projektów; dotyczy tego, czym narzędzia agentowe są.

Badania nad atakami dogoniły łańcuch dostaw. ElasticBack zademonstrował warunkowego backdoora podłożonego w pojedynczym dokumencie skilla agentowego, przedstawiając skille jako „wyłaniający się łańcuch dostaw, w którym jeden zatruty skill może trwale skompromitować każdego agenta, który go zainstaluje”.¹⁵ A odpowiedź ekosystemu na kwestię dystrybucji, Agent Plugins 1.0, ukazała się z uprawnieniami i proweniencją pozostawionymi po stronie klienta i bez żadnej warstwy podpisów — warstwa pakowania przyszła przed warstwą bezpieczeństwa, czyli w tej samej kolejności, o której ten wpis mówił, że definiuje cały stos: najpierw wypuszczana jest zdolność, kultura bezpieczeństwa wlecze się z tyłu.

Prognoza poniżej pozostaje nietknięta.

Stanowisko

Oto, co moim zdaniem się wydarzy, na tyle konkretnie, by dało się temu zaprzeczyć. Ekosystem agentowy dostanie swój moment Code Red, zanim dostanie swoją kulturę bezpieczeństwa, ponieważ w takiej właśnie kolejności zrobiła to sieć. Funkcją wymuszającą będzie najprawdopodobniej samopropagujący się ładunek prompt injection przemieszczający się między agentami przez współdzielone serwery MCP albo zdarzenie masowej eksfiltracji poświadczeń, którego źródłem okaże się jedna popularna, słabo zaudytowana integracja. Zbudowanie tego będzie tanie, ponieważ te same modele, które znajdują błędy w jądrze, potrafią to napisać, a ostrzeżenie o „nadchodzącej wielkiej fali” nigdy nie dotyczyło samej obrony.

Gdy to nastąpi, bezpieczeństwo domyślne przestanie być opcjonalne. Klienci MCP będą wypuszczani z domyślnie włączonymi dialogami zgody, walidowanymi odbiorcami tokenów i callbackami odrzucającymi niepasujące identyfikatory URI przekierowania, tak jak PHP ostatecznie zaczęło być wypuszczane z wyłączonym register_globals. Warstwy uprawnień przejdą z modelu opt-in na domyślną odmowę. Przetrwają te integracje, które potraktowały załącznik bezpieczeństwa specyfikacji jak samą specyfikację.

Niewygodna jest kwestia czasu. Sieci zajęło mniej więcej lata 1998–2005, aby przyswoić bezpieczeństwo domyślne, z latami na przemyślenia między kolejnymi robakami. Stos agentowy narasta szybciej, z celem o wyższej wartości na maszynie każdego programisty i z łańcuchem narzędzi atakującego, który poprawia się z każdą generacją modeli. Problem roku 1998 jest realny. Jedyne otwarte pytanie brzmi: czy zadziałamy zgodnie z analogią, zanim robak dopisze zakończenie, czy dopiero potem.

Kluczowe wnioski

• Warto przeprowadzić audyt triady dla każdego agenta. Należy spisać, co każde narzędzie może czytać, wykonywać i wyprowadzać na zewnątrz, a następnie potwierdzić deterministyczne zabezpieczenie w każdym wierszu. Zdolność bez zabezpieczenia to ekspozycja i miejsce, w którym wyląduje kolejny ładunek.
• Serwery MCP na listę dozwolonych; każdy parametr polecenia traktować jak niezaufane wykonanie. Dodanie integracji to jedno kliknięcie, a jej audyt już nie, więc rejestrację warto ograniczyć do przejrzanej listy. Dwie z czterech omawianych tu luk CVE były błędami przepływu OAuth w klientach MCP: handshake to granica, nie formalność.
• Bramką przeglądu warto uczynić moment planowania. Warto kazać agentom skompilować zamiar w możliwy do przejrzenia plan i czytać go przed wykonaniem jak model zagrożeń. Skrypt, który wymienia swoje narzędzia i pliki, da się zaudytować w minutę; dziesięciu tysięcy wywołań narzędzi na żywo — nie.
• Skaner najpierw wycelować w siebie. Zdolność, która produkuje te luki CVE, również je znajduje. Warto uruchamiać wspomagane agentami przeglądy bezpieczeństwa na własnym kodzie i własnych zależnościach, zanim ktoś inny uruchomi swoje przeciwko nam.

FAQ

Czy serwery MCP są bezpieczne?

Nie domyślnie i nie w jednolity sposób. MCP to protokół; jego bezpieczeństwo zależy od tego, jak wdroży go każdy serwer i każdy klient. Ujawnienia z 2025 roku dotyczące mcp-remote (CVSS 9,6) oraz MCP Inspectora od Anthropic (CVSS 9,4) pokazują, że nawet referencyjne oprzyrządowanie wypuszczono z krytycznymi lukami RCE.³⁴ Specyfikacja opisuje najważniejsze klasy ataków — zdezorientowany zastępca, przekazywanie tokenów, SSRF, kompromitacja serwera lokalnego — i zaleca konkretne środki zaradcze.⁵ Każdy serwer należy traktować jak uprzywilejowaną integrację: uruchamiać wyłącznie te, którym się ufa lub które zostały zaudytowane, umieszczać je jawnie na liście dozwolonych i zakładać, że każdy podłączony serwer może wpłynąć na agenta.

Czym jest prompt injection?

Prompt injection to sytuacja, w której atakujący przemyca instrukcje do niezaufanych danych wejściowych czytanych przez system AI, a model wykonuje je tak, jakby pochodziły od użytkownika. Simon Willison ukuł ten termin we wrześniu 2022 roku przez analogię do wstrzykiwania SQL: zaufane instrukcje i niezaufane dane wejściowe sklejone w jeden prompt, który model następnie interpretuje, bez wiarygodnego sposobu na rozstrzygnięcie, która część pochodziła od atakującego.⁶ Dla agentów jest to szczególnie groźne, ponieważ wektorem stają się dane, a escapowanie tego nie naprawi, skoro interpreterem jest model językowy.

Czym jest śmiertelna triada?

To nazwa nadana przez Simona Willisona w czerwcu 2025 roku trzem zdolnościom, które razem czynią agenta podatnym na wykorzystanie: dostęp do prywatnych danych, ekspozycja na niezaufaną treść oraz zdolność komunikowania się na zewnątrz.⁷ Agent posiadający wszystkie trzy może zostać zmanipulowany wstrzykniętą treścią do odczytania sekretów i wysłania ich atakującemu. Większość zdolnych agentów ma wszystkie trzy domyślnie i właśnie dlatego ruchem jest zabezpieczenie każdej zdolności z osobna, a nie liczenie na to, że model się oprze.

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

Zacząć trzeba od granicy, której model nie kontroluje. Należy używać reguł uprawnień i hooków ocenianych przed uruchomieniem narzędzia, aby skompromitowany prompt nie zdołał wygadać sobie drogi do zakazanego działania. Narzędzia i serwery MCP warto umieścić na liście dozwolonych, wymagać zgody przed uruchomieniem nowego serwera lokalnego i nadać każdemu poświadczeniu najmniejsze możliwe uprawnienia, aby skradziony token miał mały promień rażenia. Blokada żądań wychodzących do prywatnych i link-local zakresów IP zamyka drogę eksfiltracji. Następnie warto przejrzeć plan agenta przed dużymi operacjami, bo tam wyłapuje się wstrzyknięcie, które przetrwało granicę odczytu.

Źródła