MCPHub před verzí 1.0.32 dovolil směnit zachycený kód za přístupový token

Do databáze zranitelností přibyl 12. září 2026 záznam CVE-2026-90474. Týká se MCPHubu, brány provozované na vlastním serveru pro připojování a řízení serverů MCP. Chyba seděla ve vestavěném autorizačním serveru OAuth 2.0 a platila do verze 1.0.31 včetně.

Samotný kód chránil celý krok k tokenu

Při běžném přihlášení přes OAuth dá uživatel v prohlížeči souhlas a služba pošle aplikaci krátce platný autorizační kód. Aplikace ho na koncovém bodu pro tokeny vymění za přístupový token. Ten pak otevírá data a funkce v rozsahu, který uživatel povolil.

Ve starším MCPHubu mohl veřejný klient projít bez PKCE. Tato pojistka váže autorizační kód k ověřovacímu údaji, který zná pouze aplikace zahajující přihlášení. Klient s vlastním tajemstvím měl mít místo toho druhou ochranu, ale kód verze 1.0.31 tajemství kontroloval jen tehdy, když ho žadatel sám poslal. Vynechaná hodnota tedy nevedla k odmítnutí.

Výsledek popisuje hlášení v repozitáři projektu: kdo získal cizí autorizační kód, mohl ho směnit bez klientského tajemství a bez ověřovacího údaje PKCE. Token nesl oprávnění oběti. K úplnému přístupu do správy proto vedl jen kód administrátora; u běžného účtu zůstala oprávnění běžného uživatele.

Útok potřeboval kód i souhlas uživatele

Nešlo o vzdálené převzetí libovolné instalace jedním požadavkem. Útočník musel nejdřív zachytit platný kód z přihlášení, které potvrdila oběť. Právě tento předpoklad snižuje známku CVSS 3.1 na 6,8 z deseti: vektor počítá s vysokou složitostí útoku a s účastí uživatele.

Novější metodika CVSS 4.0 zapisuje tutéž situaci jinak. VulnCheck, který záznam CVE přidělil, uvádí 7,6 a závažnost high. Rozdíl mezi 6,8 a 7,6 tedy není spor o dopad ani nové měření. Jde o dvě verze bodovací soustavy; obě počítají s vysokým dopadem na důvěrnost a integritu a bez dopadu na dostupnost.

Veřejný záznam neuvádí, že by někdo chybu zneužíval v provozu. Nepopisuje ani únik konkrétních účtů. Dokládá možnost útoku v dodávaném výchozím nastavení a reprodukci na zkušební instalaci.

Verze 1.0.32 změnila tři kontroly

Oprava je v commitu z 23. srpna a projekt ji vydal týž den v MCPHubu 1.0.32. Veřejní klienti bez tajemství od té chvíle musejí použít PKCE s metodou S256. Klient s vlastním tajemstvím ho musí poslat vždy; špatná nebo chybějící hodnota končí odmítnutím.

Změnil se i zápis nových klientů. Původní čtyři cesty pro dynamickou registraci neměly vlastní omezení tempa. Od verze 1.0.32 přes ně požadavky procházejí stejným omezovačem jako další části OAuth. Nastavení requiresAuthentication se navíc začalo opravdu vynucovat, pokud ho správce zapne.

Ve verzi 1.0.37 zůstává dynamická registrace ve výchozím stavu povolená bez přihlášení. To samo nevrací popsanou výměnu zachyceného kódu: veřejný klient už bez PKCE S256 autorizační kód nedostane a registraci brzdí omezení tempa. Správce, který cizí klienty registrovat nepotřebuje, ji ale může vypnout nebo vyžadovat přihlášení.

Aktualizace nemusí končit u opravné verze

Číslo CVE se objevilo až dvacet dní po opravě, takže instalace s verzí 1.0.32 a novější už tuto chybu nemají. Nejnovější vydání je 1.0.37 z 13. září. Jeho poznámky popisují další bezpečnostní opravu: nástroj vypnutý ve výpisu šlo dříve pořád spustit přímým voláním. Při aktualizaci proto dává smysl přejít na aktuální vydání, ne pouze na první verzi za hranicí tohoto CVE.

Zdroje

• Bezpečnostní hlášení projektu MCPHub – podmínky útoku, dopad, dotčené verze a reprodukce
• Hlášení VulnCheck – nezávislý záznam, přidělení CVE a známky CVSS
• Opravný commit MCPHubu – kontrola tajemství, povinné PKCE S256 a omezení registrace
• Poznámky k vydání MCPHubu 1.0.32 – datum opravy a souhrn bezpečnostních změn