Model Context Protocol (MCP) od Anthropic se za posledního půl roku stal de facto standardem pro propojování AI agentů s externími nástroji a datovými zdroji. Používá ho Claude, GitHub Copilot, Cursor, Windsurf a desítky dalších nástrojů. V dubnu 2026 ale výzkumníci z OX Security odhalili zranitelnost, která není chybou v implementaci – je součástí samotného návrhu protokolu. A Anthropic to označila za „záměrné chování“.

Co se stalo

Tým OX Security publikoval v polovině dubna 2026 analýzu, která odhalila systémovou architektonickou chybu v jádru MCP – konkrétně ve způsobu, jakým STDIO (standard input/output) transportní vrstva zpracovává příkazy.

Problém spočívá v tom, že MCP v režimu STDIO umožňuje spuštění libovolných příkazů na hostitelském systému, a to i v případě, kdy původní proces selže při startu. Výzkumníci demonstrovali, že tato vlastnost může vést k Remote Code Execution (RCE) – vzdálenému spuštění kódu – a kompletní kompromitaci systému.

Rozsah problému

Čísla jsou alarmující:

Metrika	Hodnota
Odhadovaný počet stažení ovlivněných SDK	150 milionů
Veřejně dostupných MCP serverů	7 000+
Potenciálně zranitelných instancí	až 200 000

Zranitelnost se přitom netýká jednoho konkrétního nástroje. Protože je součástí základních SDK napříč programovacími jazyky, dědí ji všechny nástroje a platformy, které MCP integrují – od LiteLLM přes LangChain až po IDE jako Windsurf. Pro řadu z nich byly vydány samostatné CVE záznamy.

Reakce Anthropic

Anthropic charakterizovala toto chování jako „by design“ s tím, že STDIO execution model poskytuje bezpečný default a že sanitizace vstupů je zodpovědností vývojáře. To je technicky správné, ale prakticky problematické – protože naprostá většina vývojářů, kteří MCP integrují, o tomto chování neví a nesanitizuje vstupy dostatečně.

Tool Poisoning: Neviditelné instrukce v nástrojích

Vedle architektonické zranitelnosti existuje druhý, parallelní vektor útoku, který je v MCP ekosystému přítomný od roku 2025 – tzv. tool poisoning (TPA, Tool Poisoning Attack).

Jak tool poisoning funguje

Útočník vloží škodlivé instrukce do metadat MCP nástroje – do jeho popisu, schématu nebo výstupů. Tyto instrukce jsou pro lidského uživatele neviditelné (nezobrazují se v UI), ale AI model je vidí a interpretuje jako legitimní pokyny.

Když AI agent interaguje s „otráveným“ nástrojem, může nevědomky:

• Exfiltrovat citlivá data – API klíče, SSH klíče, přístupové tokeny
• Manipulovat chování jiných nástrojů – v prostředí, kde agent má přístup k více nástrojům, otrávený nástroj může ovlivnit použití těch ostatních
• Provádět neautorizované akce – odesílat data na externí servery, mazat soubory, měnit konfiguraci

Pokročilé varianty

Bezpečnostní výzkumníci identifikovali několik eskalovaných variant:

Full-Schema Poisoning – útočník manipuluje celé schéma nástroje, nejen popis. To ztěžuje detekci statickou analýzou, protože škodlivé instrukce jsou rozprostřeny v technické specifikaci.

Advanced Tool Poisoning (ATPA) – útočník manipuluje výstupy nástroje tak, aby obešel detekční mechanismy. Výstup vypadá legitimně pro monitoring, ale obsahuje skryté instrukce pro model.

Proč je to závažnější, než se zdá

Rozrůstající se attack surface

MCP se rozšiřuje geometrickou řadou. GitHub MCP Registry umožňuje jednoduché sdílení nástrojů, IDE jako Cursor a Windsurf integrují MCP nativně a každý vývojář může publikovat vlastní MCP server. To vytváří supply chain problém analogický situaci s npm nebo PyPI – jedovatý balíček v ekosystému může zasáhnout tisíce downstream uživatelů.

AI agent jako multiplikátor

Tradiční malware ovlivňuje jeden systém. Otrávený MCP nástroj ale ovlivňuje AI agenta, který má přístup k desítkám dalších nástrojů a systémů. Agent s přístupem k file systému, databázi, API a terminálu se stává plnohodnotným útočným vektorem – s tím, že uživatel mu dal všechna oprávnění dobrovolně.

„By design“ znamená „neopravíme to“

Když Anthropic označí zranitelnost jako záměrné chování, znamená to, že základní oprava nepřijde na úrovni protokolu. Zodpovědnost se přesouvá na vývojáře a uživatele. V praxi to znamená, že každý, kdo MCP používá, musí bezpečnost řešit sám.

Praktické závěry a tipy

Pro vývojáře integrující MCP

Sandboxujte MCP servery. Každý MCP server by měl běžet v izolovaném prostředí – kontejneru, VM, nebo alespoň s omezenými uživatelskými právy. Nikdy nespouštějte MCP server s administrátorskými oprávněními na produkčním stroji.

Sanitizujte vstupy. STDIO interface přijímá příkazy, které se přímo vykonávají. Validujte a sanitizujte každý vstup. Předpokládejte, že jakákoli data přijatá z externího nástroje jsou potenciálně škodlivá – včetně metadat, schémat a výstupů.

Validujte konfigurační soubory. MCP konfigurace (typicky JSON soubory s definicí serverů) mohou obsahovat libovolné příkazy. Nikdy nepřebírejte konfiguraci z nedůvěryhodného zdroje bez kontroly.

Monitorujte volání nástrojů. Logujte a aktivně monitorujte, jaké nástroje agent volá, s jakými parametry a co vrací. Neočekávané vzory (nástroj A volá síťový přístup, přestože by neměl) jsou silný indikátor kompromitace.

Pro uživatele MCP nástrojů

Instalujte jen z ověřených zdrojů. Neinstalujte MCP servery z neznámých repozitářů. Kontrolujte, zda nástroj nepožaduje nadměrná oprávnění (přístup k celému file systému, neomezený network přístup).

Buďte opatrní s oprávněními agentů. Pokud váš AI agent žádá o schválení akce, kterou jste nečekali, neschvalujte ji automaticky. Přečtěte si, co přesně agent dělá. Zejména u akcí zahrnujících file system, síťový přístup a spouštění příkazů.

Oddělte prostředí. Pokud používáte MCP v IDE (Cursor, Windsurf, VS Code), nepoužívejte ho na stroji s přístupem k produkčním systémům, SSH klíčům nebo citlivým datům, pokud nemáte absolutní důvěru v každý nainstalovaný MCP server.

Pro bezpečnostní týmy a CISO

Zero-trust přístup k MCP. Zacházejte s MCP jako s jakýmkoli jiným externím integration pointem. Aplikujte principy minimálních oprávnění, síťové segmentace a auditního logování.

Supply chain security je kritická. MCP nástroje jsou nový typ závislostí ve vašem sofwarovém supply chainu. Zahrňte je do procesu hodnocení rizik třetích stran. Mějte inventář všech MCP serverů používaných ve vaší organizaci.

Buďte připraveni na eskalaci. Tool poisoning je obtížně detekovatelný standardními nástroji, protože škodlivé instrukce jsou sémantické (přirozený jazyk), ne syntaktické (spustitelný kód). Tradiční antivirové a endpoint protection řešení tuto třídu útoků nedetekují.

Omezení a kontext

• Zranitelnost se týká pouze STDIO transportu. MCP podporuje i HTTP/SSE transport, který tímto problémem netrpí. Pokud váš deployment používá výhradně HTTP transport (typicky remote MCP servery), přímé riziko RCE přes STDIO je eliminováno. To ale neřeší tool poisoning, který je transportně agnostický.
• Anthropic argument má technickou logiku. STDIO je ze své podstaty lokální transport pro subprocesy. Sanitizace vstupů je standardní praxe při spouštění jakéhokoli externího procesu. Problém není v samotném designu, ale v tom, že většina vývojářů tuto sanitizaci neprovádí, protože MCP to neprezentuje jako bezpečnostní požadavek.
• Rozsah reálného zneužití není znám. K dubnu 2026 nebyly veřejně zdokumentovány případy skutečného zneužití (exploitation in the wild). CVE záznamy se týkají demonstrovaných proof-of-concept útoků. To neznamená, že riziko neexistuje, ale kontext je důležitý pro prioritizaci.
• Ekosystém reaguje. Windsurf, LiteLLM a další platformy vydaly opravy po zveřejnění CVE. Problém není statický – aktivně se řeší na úrovni implementací, i když ne na úrovni protokolu.

Co udělat jako první krok

1. Inventarizovat MCP servery. Projděte všechny konfigurační soubory MCP ve vaší organizaci (typicky mcp.json nebo claude_desktop_config.json). Zjistěte, kolik MCP serverů používáte a odkud pocházejí.
2. Zkontrolovat transportní vrstvu. Pro každý MCP server zjistěte, zda používá STDIO nebo HTTP transport. STDIO servery spuštěné z nedůvěryhodných zdrojů jsou primární riziko.
3. Ověřit oprávnění. Zkontrolujte, s jakými oprávněními běží MCP procesy. Pokud běží pod administrátorským účtem, přepněte na minimální oprávnění (least privilege).
4. Zapnout logování. Aktivujte logování MCP volání ve vašem IDE nebo AI nástroji. Monitorujte neočekávané síťové přístupy nebo file system operace.
5. Aktualizovat závislosti. Zkontrolujte, zda používáte nejnovější verze MCP SDK a nástrojů, které obsahují opravy pro známé CVE.

Závěr

MCP zranitelnost je ukázkou napětí mezi použitelností a bezpečností, které provází celý ekosystém AI agentů. Protokol, který byl navržen pro maximální jednoduchost integrace (STDIO, JSON-RPC, přímé spouštění příkazů), se stal zranitelným právě proto, že je tak jednoduchý a otevřený.

Nejznepokojivější je Anthropic postoj „by design\“. Říká dvě věci najednou: za prvé, že zranitelnost nebude opravena na úrovni protokolu. Za druhé, že celé břemeno bezpečnosti leží na vývojářích a uživatelích – tedy na skupině, která je na to nejméně připravená.

Pro každého, kdo dnes staví na MCP, platí jediné pravidlo: zacházejte s každým externím MCP nástrojem jako s nedůvěryhodným kódem. Sandboxujte, validujte, monitorujte. A pokud si nejste jisti – nespouštějte. Jednoduchost MCP integrace je jeho největší síla i jeho největší slabina.

Zdroje a reference

• OX Security: MCP Architectural Vulnerability Analysis – původní výzkumná zpráva OX Security, duben 2026
• The Hacker News: MCP Flaws Expose AI Tools – souhrn CVE a dopadů
• Infosecurity Magazine: MCP STDIO Vulnerability – analýza architektonického problému
• The Register: MCP Security Issues – reakce Anthropic a průmyslu
• CVE-2026-30615, CVE-2026-30623, CVE-2026-30625, CVE-2025-65720 – záznamy v NVD databázi
• Model Context Protocol Specification – oficiální specifikace protokolu

Shrnutí

Verdikt: Pokud používáte MCP, okamžitě sandboxujte, validujte vstupy a monitorujte volání. Ignorování je přímé bezpečnostní riziko.