Čísla CVE ke dvěma chybám v Rust SDK pro MCP vyšla 79 dní po opravné verzi
Oficiální Rust SDK protokolu MCP vydalo opravu dvou chyb 29. června a hlášení o nich dalo na svůj repozitář ještě týž den. Registr CVE i databáze GitHubu, ze které čerpá Dependabot, je zapsaly až 16. září. Do evidence RustSec, kterou čte cargo audit, se ani jedno z nich nedostalo dodnes.
Do veřejné databáze bezpečnostních hlášení GitHubu přibyly 16. září 2026 dva záznamy ke knihovně rmcp. Je to oficiální implementace protokolu MCP pro jazyk Rust, tedy rozhraní, kterým modely sahají na vnější nástroje a data. Obě mají vysokou závažnost. Oprava je v rmcp 2.0.0, které vyšlo 29. června.
Okrajová knihovna to není. Na crates.io u ní 17. září stálo necelých 27 milionů stažení, z toho 13,9 milionu za posledních devadesát dní, a 2 022 dalších balíčků, které ji mají v závislostech.
Relace se založí dřív, než si server přečte požadavek
CVE-2026-63128 sedí ve stavovém serveru přenosu Streamable HTTP. Obsluha metody POST si nejdřív nechá od správce relací založit novou relaci a teprve pak se podívá, jestli tělo požadavku opravdu je InitializeRequest. Když není, funkce se vrátí s chybou a relaci po sobě neuklidí. Záznam v tabulce v paměti tak zůstane až do konce běhu procesu a s každým dalším požadavkem přibude další.
Útočník se nemusí nijak přihlašovat. Podle hlášení udrží jediný klient v Pythonu přes 2 000 takových požadavků za sekundu, což vychází zhruba na 170 milionů zapomenutých záznamů denně a asi 75 GB obsazené paměti. To číslo pochází z reprodukce popsané v hlášení a nikdo jiný ho zatím nepotvrdil. Známka podle CVSS 3.1 je 7,5 a míří výhradně na dostupnost; k datům se tudy nikdo nedostane.
Podvržený server pošle přihlášení na správnou adresu a token si nechá
Druhé hlášení, CVE-2026-63127, je naopak v klientovi a týká se přihlašování přes OAuth. RFC 9728 žádá, aby si klient ověřil, že pole resource v metadatech chráněného zdroje odpovídá adrese, na kterou se ptal. Struktura, do které si rmcp ta metadata načítal, ale pole resource vůbec neměla, takže nebylo co s čím porovnávat.
Útok pak vypadá takhle: podvržený server MCP ohlásí ve svých metadatech jako zdroj adresu skutečného serveru a jako autorizační server ten pravý. Oběť projde přihlášením u důvěryhodného poskytovatele, jenže vydaný přístupový token skončí u útočníka. Bez součinnosti uživatele to nejde, zato útok překročí hranici mezi dvěma systémy, a proto má známku 8,2.
Projekt zveřejnil hned, databáze až po 79 dnech
Sám projekt v tom nezaváhal. Obě opravy sloučil 27. června (návrhy #934 a #937), 29. června ve 12.32 UTC vydal rmcp 2.0.0 a téhož dne odpoledne, mezi 16.21 a 16.26 UTC, obě hlášení vyvěsil na svém repozitáři.
Čísla CVE k nim ale GitHub jako přidělovatel vydal až 16. září krátce před patnáctou hodinou UTC a do jeho globální databáze se záznamy dostaly v 22.13 UTC téhož dne. Od vydání opravné verze uplynulo 79 dní. Americká NVD měla 17. září u obou stav Received, tedy bez vlastního přezkumu.
Rozdíl je v tom, kdo co čte. Hlášení na repozitáři najde ten, kdo se tam sám podívá. Do upozornění od Dependabotu se dostane až záznam v globální databázi.
V rozsahu dotčených verzí si dva zápisy protiřečí
Hlášení na repozitáři vymezuje u chyby s relacemi zranitelná vydání jako 1.7.0 a starší. Záznam na cve.org i v databázi GitHubu píše vše pod 2.0.0. Mezi tím leží rmcp 1.8.0, poslední vydání jedničkové řady; vyšlo 23. června, tedy čtyři dny před opravou.
Stáhli jsme si proto z crates.io zdrojový archiv balíčku 1.8.0 a otevřeli soubor src/transport/streamable_http_server/tower.rs. Volání create_session() v něm pořád stojí před kontrolou těla a větev za ním končí návratem chyby bez úklidu, přesně jak to hlášení popisuje u verze 1.7.0. Ve 2.0.0 je pořadí obrácené a relace se zakládá až po kontrole. Širší rozsah z registru CVE tedy sedí a vlastní zápis projektu jedno zranitelné vydání vynechává.
Co o tom ví cargo audit
Rustové projekty si zranitelnosti v závislostech hlídají nástrojem cargo audit, který čerpá z evidence RustSec. Ta má ke knihovně rmcp jediný záznam: RUSTSEC-2026-0189 z 29. dubna o útoku přes DNS rebinding, opravou je verze 1.4.0. Čtyři letní hlášení v ní 17. září nebyla.
A úplná není ani globální databáze GitHubu. Kromě dvojice ze 16. září vyvěsil projekt 29. června ještě hlášení o tom, že klient OAuth stahoval adresu metadat určenou serverem bez kontroly, kam vede, a 2. července hlášení o vlastních hlavičkách HTTP, které se přeposílaly na cíl přesměrování v jiné doméně. První z nich nemá číslo CVE vůbec, druhé dostalo CVE-2026-64684 rovněž 16. září. Dotaz do rozhraní databáze GitHubu filtrovaný podle obou identifikátorů vrátil 17. září prázdný výsledek.
Cesta ven vede přes dvě hlavní verze
Verze 1.8.1 nevyšla. Kdo zůstal na jedničkové řadě, musí kvůli opravě přes rmcp 2.0.0, které srovnává typy modelu se specifikací MCP ze dne 25. listopadu 2025 a má vlastního průvodce přechodem. Aktuální je ale 3.4.0 z 15. září a mezi dvojkou a trojkou leží další zlom: MCP ve znění z 28. července 2026 ruší relace na úrovni protokolu, takže rmcp 3.0 zakládá obsluhu pro každý požadavek zvlášť a stav si musí držet aplikace kolem něj.
Podobný odstup mezi opravou a veřejným záznamem měla letos v létě i rubyová implementace téhož protokolu. Tam ale šlo o tři týdny a záznamy dorazily všechny naráz.