A probléma szíve: tetszőleges parancsvégrehajtás
Az MCP alapértelmezett kapcsolatfelületét, az STDIO-átvitelt úgy tervezték, hogy bármilyen parancsot végrehajtson, amit kap – mindenféle szűrés vagy ellenőrzés nélkül. Ez azt jelenti, hogy ha egy támadó akár egy konfigurációs hibán keresztül el tud juttatni egy rendszerparancsot az MI-ügynökhöz, az azonnal lefut a célgép operációs rendszerén. Ha a futtatott parancs hibát okoz, erről csak utólag kap értesítést a fejlesztő, addigra viszont már késő: a parancs végrehajtódott.
Az OX Security kutatói számos, a gyakorlatban futó, éles platformot sikeresen támadtak meg ezzel a módszerrel – köztük olyan, magyar viszonyokra is jellemző megoldásokat, mint a LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher és Agent Zero. Több mint 10 kritikus súlyosságú biztonsági hibát (CVE-t) dokumentáltak, amelyek révén bármelyik támadó sikeresen kompromittálhat egy teljes MI-rendszert.
Elképzelhető, hogy a hiba védelmi felelőssége is vita tárgya
Az Anthropic és más nagy cégek szerint az STDIO alapértelmezetten biztonságos, és a bemeneti adatok szűrése kizárólag a fejlesztők dolga. Az OX Security szerint ez tarthatatlan: senki sem várhatja el, hogy 200 ezer fejlesztőtől megkövetelhető legyen a tökéletes szűrés. Az Anthropic érve szerint bármiféle szűrés bevezetése vagy tönkretenné az átvitel működését, vagy csak eltolná a sérülékenységet egy másik rétegre. Míg technikailag mindkét nézőpont védhető, ez a gyakorlati helyzetet nem oldja meg.
A háttérben alapvető filozófiai ellentét van: az MCP-protokoll azt feltételezi, hogy aki a konfigurációhoz hozzáfér, annak joga van tetszőleges parancsokat futtatni a gépen. Az OX szerint azonban a „mindenki magának őrzi a kaput” típusú gondolkodás nagy léptékben nem tartható.
Hogyan támadhatják ki a rendszert?
Négy fő támadási lehetőséget azonosítottak:
– Jogosulatlan parancs-injekció MI-webes felületen keresztül (LangFlow, LiteLLM)
– Engedélyezési lista (whitelist) megkerülése argumentuminjekcióval (Flowise, Upsonic)
– Interakció nélküli prompt-injekció fejlesztői IDE-kben (Windsurf, Cursor, Claude Code, Gemini-CLI)
– Ártalmas csomagok terjesztése MCP-regisztrációs felületeken
Különösen veszélyesek a fejlesztők gépeit célzó támadások: akár egy rosszindulatú weboldal is módosíthatja a helyi MCP-konfigurációt, ami néhány programnál (például Windsurf) azonnali, engedélykérés nélküli parancsvégrehajtással jár.
Javítható egyáltalán? És ki felel érte?
Bár több szoftver kiadott helyi javításokat (például LiteLLM, Flowise, DocsGPT), egyik sem módosította magát az MCP-protokollt vagy az STDIO működési elvét – így az új telepítések továbbra is sérülékenyek maradnak. Elképzelhető, hogy a hiba túlél minden termékszintű javítást, hiszen továbbra is a specifikáció tartalmazza a veszélyes alapállapotot.
Az Anthropic egyedüli reakciója az volt, hogy a SECURITY.md állományban figyelmeztetett, miszerint az STDIO-adaptermódot csak körültekintéssel használják. Ugyanakkor érdemi, protokollszintű változtatás nem történt. Az OX Security azt javasolta: vezessenek be kizárólag manifestalapú futtatási módot, szoftveres parancslista-engedélyezést, vagy legalább a hivatalos SDK-kba korlátozásokat. Egyik sem valósult meg.
Mit tegyen egy IT-biztonsági vezető hétfő reggel?
Fel kell deríteni, mely szervereken fut az MCP STDIO, különös tekintettel a fejlesztői gépekre, valamint az éles és tesztkörnyezetekre is. Meg kell keresni a konfigurációs fájlokat (pl. mcp.json), és összegyűjteni azokat a folyamatokat, amelyek az STDIO-átvitelt használják. Az érintett szoftvereket a legfrissebb, javított verzióra kell frissíteni (például a LiteLLM-nél a v1.83.7-stable-re), viszont tudni kell, hogy ezzel az alapvető veszély nem szűnik meg.
Minden MCP-szolgáltatást szigorúan el kell szigetelni az operációs rendszertől, soha nem szabad teljes lemezhozzáférést vagy shelljogokat adni nekik. A telepítéseket kizárólag megbízható, ellenőrizhető digitális forrásból szabad elvégezni, a regisztrációs rendszerek nagy részében ugyanis az OX bizonyítottan be tudott juttatni tesztkártevőket. Végül minden STDIO-beállítást úgy kell kezelni, mint potenciális támadási felületet: nem tekinthető megbízhatónak, amíg minden egyes parancsot külön nem validálnak.
Mi várható a jövőben?
Az Anthropic és az OX Security közötti vita egyelőre eldöntetlen. A rendszer javításának felelőssége pedig továbbra is a fejlesztői és szervezeti oldalon marad. Minden cégnek saját magának kell gondoskodnia arról, hogy rendszerei ne váljanak a következő hétfői incidens áldozatává. Az egyetlen ésszerű válasz: minden MCP STDIO-konfigurációt úgy kell kezelni, mint egy nem megbízható futtatási réteget – egészen addig, amíg valódi, protokollszintű javítás nem születik.
