Databáze GitHubu zná jen jedno ze čtyř bezpečnostních hlášení brány ContextForge

Brána ContextForge od IBM stojí mezi jazykovým modelem a nástroji, které má volat. Sbírá servery protokolu MCP, agentní rozhraní i obyčejná REST API, vystavuje je pod jednou adresou a bere na sebe přihlašování, evidenci nástrojů a omezování tempa. Kód je pod licencí Apache 2.0, repozitář má 4 320 hvězd a v balíčkovém indexu Pythonu se brána instaluje jako mcp-contextforge-gateway. Poslední verze 1.0.7 tam leží od 5. srpna 2026.

Vývojáři projektu zveřejnili 15. června 2026 na repozitáři čtyři bezpečnostní hlášení, všechna v rozmezí tří hodin. Do databáze hlášení GitHubu, tedy tam, odkud čtou automatičtí hlídači závislostí, se z nich za dva měsíce dostalo jediné – a je to to nejméně závažné ze čtveřice. Poznat se to dá dvěma dotazy bez přihlášení: na značku GHSA-9hgc-g3w5-67cm vrátí veřejné rozhraní celý záznam, na zbylé tři kód 404. Dotaz na všechna hlášení k balíčku mcp-contextforge-gateway vrací rovněž jediný záznam.

Které hlášení kam došlo

hlášení	závažnost	opraveno ve verzi	v databázi GitHubu
CVE-2026-53709, podpisový klíč ve zdrojovém kódu	kritická, 9,8	1.0.2	ne
GHSA-vwf3-4xxj-qg6h, vložení šablony Jinja2	vysoká, bez čísla CVE	1.0.0	ne
CVE-2026-53711, uložené XSS ve správě	střední	0.3.1 (rozhraní)	ne
CVE-2026-53708, obejití ochrany proti SSRF	střední, 6,6	1.0.3	ano, 14. srpna

Časy zveřejnění a známky závažnosti jsou z rozhraní GitHubu, verze s opravou z polí každého hlášení. Všechny čtyři opravy byly venku dřív, než hlášení vyšla – verze 1.0.2 podle indexu Pythonu 26. května 2026, verze 1.0.3 pak 10. června. To je u ohlašování chyb běžné pořadí.

Záznam, který prošel: jméno se překládá dvakrát

Hlášení CVE-2026-53708 popisuje obejití ochrany proti SSRF, tedy proti tomu, aby útočník donutil server sáhnout na adresu, na kterou sám nedosáhne. Zkušební koncový bod správy si zadanou adresu ověřil tak, že přeložil jméno stroje na číselnou adresu a odmítl vnitřní rozsahy včetně 169.254.169.254, odkud se v oblacích čtou přístupové údaje instance. Odchozí spojení pak ale dostalo původní jméno, ne ověřenou adresu, a přeložilo si ho znovu. Kdo ovládá jmennou službu, může mezi obojím odpověď vyměnit.

Tuhle mezeru měl projekt popsanou ve vlastním kódu dřív, než z ní bylo hlášení. Ve značce v1.0.1 stojí v dokumentačním řetězci funkce oddíl nadepsaný jako známé omezení a u místa volání poznámka s číslem interního lístku. Verze 1.0.3 to zavřela tak, že ověřovací funkce vrací vedle jména i přeloženou adresu a spojení se připne k ní; v kódu správy se z ní skládá cílová adresa, kdežto původní jméno zůstává v hlavičce požadavku. Poznámka s číslem lístku je ve značce v1.0.3 pryč.

Záznam, který neprošel: klíč otevřený každému

Nejzávažnější z té čtveřice je CVE-2026-53709 se známkou 9,8. Brána podepisuje přístupové lístky JWT klíčem, jehož výchozí hodnota byla napsaná přímo v souboru s nastavením i ve vzorovém .env.example. Kdo repozitář otevřel, znal klíč každé instalace, která si ho nepřepsala.

Na téže stránce kódu přitom tentýž řetězec figuruje v seznamu slabých hodnot, který si projekt vede sám. Kontrola nad tím seznamem zapíše varování do logu a pokračuje; spuštění nepřeruší ani ve verzi 1.0.2, která hlášení odbyla. Ta jen vyměnila výchozí hodnotu za changeme, kterou týž seznam vede taky, a ze vzorového souboru udělala pokyn spustit nástroj, který klíč vygeneruje. Až verze 1.0.7 má ve výchozím nastavení zástupný text a u něj popis, že se hodnota musí nastavit ručně.

Proč není hlášení jako hlášení

Rozdíl mezi hlášením na repozitáři a záznamem v databázi zní administrativně, jenže rozhoduje o tom, kdo se o chybě doví. GitHub podle své dokumentace upozorní službou Dependabot na novou zranitelnost v závislosti jen tehdy, když jde o záznam, který jeho databáze prošla a přijala. U záznamu, který v ní není, nemá co ohlásit – a provozovatel, který se spoléhá na strojovou kontrolu závislostí, se o kritické chybě nedozví.

Rozhraní k tomu vydává jeden údaj navíc: u jediného přijatého záznamu je čas kontroly totožný s časem zveřejnění, 14. srpna 2026 v 19.49 UTC. Mezi zveřejněním na repozitáři a tímhle okamžikem uplynulo šedesát dní. Proč to trvalo a proč zbylé tři záznamy nedorazily, neříká ani projekt, ani GitHub.

U dvou z nich se dá odhad opřít o pravidla, která GitHub sám vypisuje: přijímá záznamy o balíčcích ze seznamu podporovaných registrů, a hlášení o uloženém XSS míří na mcp-context-forge-ui, což není balíček v žádném z nich. Hlášení o vložení šablony nemá číslo CVE a jako zasažené uvádí jen vydání starší než 1.0.0. U kritického klíče takové vysvětlení po ruce není: je to balíček z indexu Pythonu, má přidělené číslo CVE i rozsah verzí.

Projekt svůj díl odvedl, řetěz se přetrhl dál

Projekt sám na tom nese menší díl, než by se z pořadí čísel zdálo. Hlášení napsal podrobně, včetně přesných řádků a vlastních poznámek v kódu, požádal o čísla CVE a opravné verze vydal dřív, než šel s popisem ven. Kdo sleduje kartu zabezpečení jeho repozitáře, měl všechny čtyři záznamy k dispozici od poloviny června.

Slabým místem je předpoklad, že tenhle krok stačí. Kdo u závislostí spoléhá na upozornění Dependabotu, nedostal k téhle bráně mezi polovinou června a polovinou srpna žádné upozornění, přestože tři záznamy o chybách včetně toho kritického byly celou dobu veřejné. Sledovaná databáze je pohodlná, jenže o tom, co v ní chybí, se z ní nic nedozvíte; hledá se to na kartě zabezpečení repozitáře a v poznámkách k vydání.

Zdroje: bezpečnostní hlášení projektu mcp-context-forge, záznam GHSA-9hgc-g3w5-67cm v databázi GitHubu, poznámky k vydání 1.0.3, balíček mcp-contextforge-gateway na PyPI, dokumentace databáze hlášení GitHubu.