Bezpečnostní dokument specifikace MCP má vlastní sekci o SSRF. Najdete v ní pět útočných vzorů i mitigace, které fungují. Celá je ale napsaná o klientovi, který stahuje cizí adresy během OAuth discovery.
Server, jehož nástroj dostane URL jako parametr, v ní není. A přesně takové servery se letos v červenci proměřily v provozu.
Co v té sekci opravdu stojí
Dokument Security Best Practices (revize 2026-07-28, staženo 10. září 2026) vypisuje pět vzorů, kterými se dá kontrola cíle obejít: přímá adresa do vnitřní sítě, cloudová metadata na http://169.254.169.254/, služby na localhostu (v příkladu Redis na http://localhost:6379/), DNS rebinding a řetěz přesměrování, tedy "Normal-looking URLs that redirect to internal resources".
Mitigace, které k tomu dává, jsou věcné. Blokovat celé rozsahy, a to takto vyjmenované: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, ::1, 169.254.0.0/16, fc00::/7, fe80::/10. Ten výčet je práce autorů MCP. RFC 9728, na které se u něj odkazují, v sekci 7.7 rozsahy nevypisuje - doporučuje jen "blocking requests to internal IP address ranges" a posílá čtenáře na OWASP. K tomu jedna poznámka, která stojí za přečtení dřív, než si takovou kontrolu začnete psát sami:
"Avoid implementing IP validation manually. Attackers exploit encoding tricks (octal, hex, IPv4-mapped IPv6) that custom parsers often miss."
A dvě další, obě správné a obě se běžně vynechávají: "Apply HTTPS and IP range restrictions to redirect destinations", respektive "Consider disabling automatic redirect following and validating each hop". A u DNS: "Consider pinning DNS resolution results between check and use", protože mezi kontrolou a stažením se odpověď DNS může změnit.
To je dobrý seznam. Není to seznam, který by chyběl.
Směr, který v něm není
Vezměte první větu té sekce o mitigacích:
"MCP clients deployed to a server MUST consider SSRF risks and implement appropriate mitigations when fetching OAuth-related URLs."
Klient. Model útoku je celou dobu stejný: nepřátelský MCP server podstrčí v hlavičce WWW-Authenticate nebo v metadatech adresu do vnitřní sítě a klient ji poslušně stáhne. Druhá podsekce ten model rozšiřuje na autorizační server, který si stahuje Client ID Metadata Document. Obojí je reálné a obojí do toho dokumentu patří. Sám o sobě říká, že je "complementing the MCP Authorization specification".
Celý ten dokument má jedenáct sekcí o útocích: Confused Deputy, Token Passthrough, SSRF, State Handle Hijacking, Local MCP Server Compromise, OAuth Authorization URL Validation, stdio Transport Security in Proxy Scenarios, Mix-Up Attacks, Localhost Redirect URI Impersonation, CIMD Trust Policies, Scope Minimization. Je to úplný výčet. Ani jedna z těch sekcí se nezabývá adresou, která do serveru přiteče jako argument nástroje; řetězec tool input ani tool arguments se v dokumentu nevyskytuje.
Stejná díra je i o patro níž. Oficiální konformní sada pro tuhle revizi má scénář dns-rebinding-protection - tedy zase obranu klienta. Kdo ji projde, ví, že mluví protokolem správně; o tom, kam jeho nástroj umí sáhnout, mu neřekne nic. Psali jsme o tom rozdílu zvlášť: projít testy a být přijat katalogem jsou dvě různé věci, a bezpečnost serveru je třetí.
Přitom je to úplně obyčejný případ. fetch_page, check_feed, validate_sitemap, import_from_url, screenshot. Jakmile takový nástroj vystavíte, je váš server HTTP proxy, kterou obsluhuje kdokoli, jehož agent s ním mluví.
Dvě věci k tomu na straně serveru přistupují navíc.
Volající nemusí být člověk, který to zkusí. Argument nástroje vybírá model a ten čte cizí text. Stránka, kterou si agent otevřel cestou, umí navrhnout, co do parametru dát.
A druhá: server obvykle stojí tam, kde má do sítě větší dosah než volající. Runner v CI, kontejner ve VPC, notebook v domácí síti s administrací routeru na druhé straně. Kontrola perimetru je v takové chvíli k ničemu, protože požadavek vychází zevnitř.
Není to hypotéza
V červenci 2026 proběhlo první dynamické měření internetových MCP serverů. Nicolás Padilla (CobaltoSec, samostatný výzkumník) zveřejnil 31. července preprint Exposed by Design na arXivu pod číslem 2608.00150. Není to recenzovaná studie ani práce z univerzitní laboratoře, což je při čtení čísel dobré vědět.
Čísla z abstraktu: přes 21 000 instancí serverů detekovatelných z veřejného internetu, 640 potvrzených produkčních serverů, 414 z nich dynamicky auditovaných a 68 reportovatelných zranitelností. Mezi nimi SQL injection, prompt template injection, path traversal a "SSRF targeting cloud metadata services".
Ta část metodiky míří přesně na server, jehož nástroj bere URL jako parametr:
"For servers exposing tools that accept URL parameters, Corvus issues calls with the parameter set to http://169.254.169.254/latest/meta-data/ (AWS IMDS), http://metadata.google.internal/, and a controlled researcher-owned endpoint."
Jeden potvrzený nález je v práci doložený časem odpovědi: 11,9 sekundy proti základní hodnotě 0,3 sekundy. Server tedy někam sáhl a čekal. Cílem byla metadatová služba AWS, tedy místo, odkud se běžně čtou dočasné přístupové klíče k účtu.
Dvě čísla ze stejného abstraktu, která říkají něco o stavu ekosystému. 91,8 % dynamicky auditovaných serverů nemá OAuth - pozor, ten podíl se počítá ze 414 auditovaných, ne ze 640 potvrzených; některé převzaté články to zaměňují. A 41,6 % potvrzených serverů zmizí do tří dnů mezi dvěma měřeními, což autor čte jako nasazování bez bezpečnostní revize.
Nezávislé potvrzení existuje, měří ale něco jiného. Zhou a kolektiv (arXiv 2605.22333, květen 2026) našli 7 973 živých vzdálených serverů a u 40,55 % z nich nástroje bez jakéhokoli ověření. To není totéž jako bez OAuth: server se statickým API klíčem se počítá do Padillových 91,8 %, ale ne do těch 40,55 %. Ta dvě čísla se nesčítají ani nezaměňují.
Kontrola, která obstojí
Šest bodů. Prvních pět má oporu ve zdrojích výše, šestý je náš názor.
1. Kontroluj v okamžiku stahování, ne na vstupu. Validace ve formuláři nebo ve schématu nástroje je pohodlí pro volajícího, ne obrana. V edge runtime se navíc jméno na IP spolehlivě nepřeloží, takže na vstupu umíte odmítnout jen doslovné adresy. Kontrola patří k tomu řádku, který otevírá spojení.
2. Rozřeš jméno na IP a odmítni celé rozsahy - knihovnou, ne regulárním výrazem. Kromě rozsahů z RFC 9728 dopadá do stejné kategorie i sdílený prostor poskytovatelů 100.64.0.0/10. A hlídejte zápisy, na které ruční kontrola nemyslí. Pět příkladů, které všechny míří na loopback 127.0.0.1 a všechny projdou seznamem zakázaných řetězců: 127.1, 0x7f.1, 2130706433, [::ffff:127.0.0.1] a 64:ff9b::7f00:1 (loopback zabalený do prefixu NAT64).
3. Revaliduj cíl znovu při přesměrování. Kontrola prvního skoku je divadlo: útočník pošle běžnou doménu, ta vrátí 302 na vnitřní adresu a jste tam, kde jste byli. Buď přesměrování nesledujte automaticky, nebo kontrolujte skok po skoku.
4. Připoj se na tu IP, kterou jsi ověřil. Když po kontrole resolvujete podruhé, nepřátelský DNS vrátí napoprvé veřejnou adresu a napodruhé loopback. Adresu je potřeba mezi kontrolou a použitím podržet. Řada HTTP klientů to umí, jen se to musí zapnout - a když to váš klient neumí, je lepší to napsat do dokumentace než předstírat, že je zavřeno.
5. Egress mimo vlastní síť je druhá vrstva, ne oprava. Pouštět stahování z vyhrazeného stroje je dobrý nápad a specifikace ho doporučuje také (jmenuje Smokescreen od Stripe). Ale kdyby se spoléhalo jen na ni, chyba v ní stojí celou síť toho stroje. Kontrola cíle musí platit i tam.
6. Odmítnutí nesmí být tiché. Tenhle bod si píšeme sami. Když guard vyhodí chybu, která je podtřídou běžné síťové chyby, sebere ji první except v pořadí a cíl se do reportu zapíše jako nedostupný. Tichá obrana vypadá v logu stejně jako obrana, která tam není. Proto u sebe rozlišujeme vadu cíle od výpadku spojení a metodiku máme zveřejněnou - verdikt, který nejde ověřit, není verdikt.
Co se za opravu nepočítá
Seznam zakázaných řetězců (localhost, 127.0.0.1) odmítne přesně to, co nikdo posílat nebude. Sama specifikace to říká v poznámce citované výše.
Kontrola jen prvního skoku, viz bod 3.
Povolení schémat http a https bez kontroly cíle. Schéma neříká nic o tom, kam to vede.
A námitka, že to volá jenom váš vlastní agent. Ten endpoint stojí na veřejném internetu; těch 21 000 instancí z Padillovy studie někdo našel právě proto, že se najít daly.
Ten seznam není dlouhý. Je to den práce pro člověka, který ví, co má zkusit - a je to rozdíl mezi nástrojem, který stahuje stránky, a proxy do vaší sítě.
Psali jsme i o tom, co obnáší provozovat MCP server v produkci - anglicky, o provozu, ne o bezpečnosti.
Zdroje
- Model Context Protocol,
Security Best Practices, revize 2026-07-28: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices.md (staženo 10. 9. 2026) - N. Padilla, Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale, arXiv:2608.00150, 31. 7. 2026: https://arxiv.org/abs/2608.00150
- Zhou et al., A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv:2605.22333, 21. 5. 2026: https://arxiv.org/abs/2605.22333
- RFC 9728, sekce 7.7: https://datatracker.ietf.org/doc/html/rfc9728#section-7.7