MCP SDK sebezhetőség: hét javítás 2026 októberéből, és mit kell módosítani a saját MCP szerver kódjában

2026. szeptember 30. és október 15. között a TypeScripthez készült hivatalos MCP SDK karbantartói hét biztonsági figyelmeztetést tettek közzé, ebből ötöt magas súlyosságúként, és négynél önmagában a csomag frissítése nem feltétlenül elég. Ha cége saját, HTTP-n elérhető MCP szervert üzemeltet, amelyen keresztül egy AI asszisztens belső adatokhoz fér hozzá, Önt is érinti az az MCP SDK sebezhetőség, amelynél a szerver az egyik kliens válaszát egy másiknak is kézbesíthette. A @modelcontextprotocol/server csomag 2.3.0-s verziójában érkező javítás a kód módosítását is megköveteli. A stdio-n keresztül futó helyi szervereket a szerveroldali hibák nem érintik.

Azt a tágabb kérdést, hogy mit érdemes egy cégnél automatizálni, a cégek AI folyamatautomatizálásáról szóló útmutatónk tárgyalja. A webhookokat, a hozzáféréseket és az API-kulcsokat az automatizált folyamatokban a folyamatautomatizálás biztonságáról szóló cikk veszi sorra. Itt egyetlen konkrét könyvtárral foglalkozunk, és azzal, mit érdemes vele még ezen a héten tenni. Ha MCP szerverét vagy AI integrációját olyan csapattal ellenőriztetné, amely ilyeneket épít, nézze meg folyamatautomatizálási szolgáltatásunkat.

Kit érint az MCP SDK sebezhetőség, és kit nem

Érintett minden projekt, amely a TypeScripthez készült MCP SDK-t használja, és amelynek szervere vagy kliense HTTP-n kommunikál; a csak helyben, stdio-n futó szervereket a szerveroldali hibák nem érintik.

Az MCP (Model Context Protocol) egy protokoll, amelyen keresztül egy AI alkalmazás eszközökhöz és adatokhoz kapcsolódik. A szerver eszközöket kínál, például egy rendelés megkeresését, a kliens pedig az AI modellt használó alkalmazás, amely ezeket meghívja. Az MCP specifikáció 2026-07-28-as verziója két szabványos átviteli módot ismer. A stdio esetén a szervert maga a kliensalkalmazás indítja el alfolyamatként ugyanazon a számítógépen. A Streamable HTTP esetén a szerver önálló szolgáltatásként fut egyetlen címmel, és minden üzenetet HTTP-kérésként fogad, így több kliens is csatlakozhat hozzá.

Egy cég számára ebből három helyzet adódik:

• saját, HTTP-n elérhető MCP szerver, például szerverre vagy felhőbe telepítve, hogy többen is hozzáférjenek a belső adatokhoz: ezt a megosztott példánnyal, a tokenek ellenőrzésével és a kérések méretével kapcsolatos hibák érintik,
• saját alkalmazás vagy szkript, amely az SDK-n keresztül HTTP-n csatlakozik MCP szerverekhez, és OAuth-tal vagy API-kulccsal jelentkezik be: ezt a két kliensoldali hiba érinti, amelyeknél a bejelentkezési adatok idegen címre kerülhettek,
• csak helyben, stdio-n futó szerver, például egy asztali AI alkalmazásból indítva: a szerveroldali hibák nem érintik, a frissítést elvégezheti a szokásos karbantartás során.

A verziót a package.json fájlban vagy a projekt mappájában futtatott npm ls paranccsal találja meg. Az 1.x ág egyetlen csomag, a @modelcontextprotocol/sdk. A 2.x ág külön csomagokra oszlik: @modelcontextprotocol/server, @modelcontextprotocol/client, valamint adapterek Expresshez, Node-hoz és Honóhoz. Ha a listában nincs @modelcontextprotocol csomag, ezek a figyelmeztetések nem érintik a projektet. Ha van, folytassa az alábbi táblázattal.

Hét MCP SDK figyelmeztetés egy táblázatban

Öt figyelmeztetés a szervert, kettő a klienst érinti; az 1.x ág összes hibáját a @modelcontextprotocol/sdk csomag 1.32.0-s verziója javítja.

Mind a hét figyelmeztetés megtalálható az MCP TypeScript SDK tárolójának biztonsági figyelmeztetései között a GitHubon. Mindegyik tartalmazza az érintett és a javított verziókat, valamint azt, hogy a frissítésen túl a kódot is módosítani kell-e.

Mi történhetett	Oldal	Súlyosság (CVSS)	Javított verzió	Elég a frissítés?
A megosztott szerverpéldány az egyik kliens válaszát egy másiknak kézbesítette	szerver 2.x	magas, 7,7	server 2.3.0	nem, a kódot módosítani kell
A szerver elfogadta a más szolgáltatásnak kiadott tokent	szerver	közepes, 6,8	sdk 1.32.0, server 2.3.0, express 2.0.2	nem, be kell kapcsolni az audience ellenőrzését
Egyetlen, 4 MiB-os korláton belüli kérés kimerítette a szerver memóriáját	szerver	magas, 7,5	sdk 1.32.0, server 2.3.0	nem, korlátokat kell beállítani
Hiányzott a kérésméret és a kötegek hosszának korlátja	szerver	magas, 7,5	sdk 1.30.1, server és node 2.1.0, hono 2.0.1	igen
A kísérleti feladatok nem kötődtek az őket létrehozó sessionhöz	szerver 1.x	magas, 8,6	sdk 1.32.0	igen, vagy a taskStore eltávolítása
Az OAuth kliens az MCP szerver által kiválasztott hitelesítési szervernek küldte el a bejelentkezési adatokat	kliens	magas, 7,5	sdk 1.31.0, client 2.2.0	nem mindig, a beállításoktól és a tárolt tokenektől függ
Más domainre történő átirányításkor a kliens újra elküldte a fejléceket és a kérés törzsét	kliens	közepes, 6,5	sdk 1.32.0, client 2.3.0	igen, gyanú esetén kulcscsere

2026. október 22-én az npm-en a legújabb verzió a @modelcontextprotocol/sdk esetén az 1.32.1, a server és a client esetén pedig a 2.3.1. A hét figyelmeztetés egyike sem állítja, hogy bárki kihasználta volna a hibákat. A szerver memóriáját érintő két hibánál azonban a figyelmeztetések szerint a támadónak nincs szüksége bejelentkezési adatokra, ha a szerver nem hitelesíti a kéréseket, mielőtt azok az SDK-hoz érnek. Amíg a frissítést halogatja, a szervert bárki leállíthatja egyetlen kéréssel, aki eléri a címét.

Ahol a frissítés nem elég: négy kódmódosítás

A megosztott szerverpéldánynál, a tokenek ellenőrzésénél, a bemenet korlátjánál és az OAuth kliensnél a fejlesztőnek a frissítés után a kódot vagy a beállításokat is módosítania kell.

Egy szerver minden kliensnek

A GHSA-jm63-cq47-j5jp figyelmeztetés olyan kódot ír le, amely az alkalmazás indításakor egyszer hozza létre a transportot vagy a szervert, és minden HTTP-kérést ezen keresztül kezel. Az SDK az üzeneteket kizárólag a JSON-RPC id alapján rendelte a kapcsolathoz. Az SDK kliensei nullától számozzák a kéréseiket, ezért ezek az azonosítók a szokásos működés során egybeesnek, és az egyik felhasználó adatait tartalmazó válasz egy másikhoz juthatott. A javításig pontosan ezt a mintát mutatták a Hono, Express, Fastify és Node adapterek README példái. Ha egy szervert ezek alapján írt meg egy ember vagy egy AI eszköz, azt ellenőrizze elsőként.

A 2.3.0-s verzió elutasítja a megosztást: a második csatlakozás ALREADY_CONNECTED hibával zárul, az állapot nélküli transport pedig elutasítja a második kérést. Egy ilyen szerver a puszta frissítés után nem válaszol többé. A kódot úgy kell átalakítani, hogy minden kéréshez új szervert hozzon létre, vagy minden sessionhöz egy szervert és egy transportot. Az 1.x ágban ugyanezt a hibatípust az 1.26.0-s verzió javította 2026. február 4-én.

Más szolgáltatásnak kiadott token

Ha egy hitelesítési szerver több szolgáltatásnak is ad ki tokeneket, a requireBearerAuth() vagy verifyBearerToken() függvényt használó MCP szerver a más szolgáltatásnak szánt érvényes tokent is elfogadta. Az MCP biztonsági ajánlásai szerint a szerver nem fogadhat el olyan tokent, amelyet nem neki adtak ki. A javított verziók egy expectedResource beállítást vezetnek be, amely alapértelmezés szerint ki van kapcsolva. Ezt be kell kapcsolni, és a verifyAccessToken() függvénynek vissza kell adnia a token audience értékét. Ha csak az első módosítást végzi el, a szerver minden kérést 401-es kóddal utasít el. Régebbi verziókon a rést az a verifyAccessToken() zárja be, amely maga utasítja el a tokent, ha annak aud értéke nem tartalmazza az Ön szerverét.

A bemenet méretének korlátja

Egyetlen, az alapértelmezett 4 MiB-os korláton belüli kérés a bemenet ellenőrzése közben kimeríthette a memóriát, és a folyamat JavaScript heap out of memory hibával leállt. A GHSA-46jr-4wx8-v453 figyelmeztetés szerint a kockázat azoknál az eszközöknél a legnagyobb, amelyek bemenete tömböt vagy rekordot tartalmaz. Az új maxToolInputElements opció alapértelmezés szerint ki van kapcsolva, ezért állítsa közvetlenül az eszközei által igényelt legnagyobb bemenet fölé, és csökkentse a maxRequestBodySize értékét is. Ha a kérés törzsét maga dolgozza fel, például az express.json() segítségével, ott is állítson be korlátot.

Az OAuth kliens és a régi tárolt tokenek

Az SDK-ra épülő kliens elküldhette a refresh_token és a client_secret értékét annak a hitelesítési szervernek, amelyet az MCP szerver választott ki. A javítás a bejelentkezési adatok mellé az issuer értéket is elmenti, a frissítés előtt tárolt tokenekből azonban ez hiányzik. Egészítse ki velük, vagy törölje őket, hogy a felhasználók újra bejelentkezzenek. A beépített szolgáltatóknak, például a ClientCredentialsProvider osztálynak, át kell adni az expectedIssuer értéket. Ha a kliens csatlakozhatott olyan szerverhez, amelyben nem bízik meg, a figyelmeztetés a client secret vagy az aláírókulcs cseréjét és a kiadott tokenek visszavonását javasolja.

A tokenek ellenőrzésénél és a bemenet korlátjánál e módosítások nélkül a package.json a javított verziót mutatja, a szerver viszont ugyanúgy viselkedik, mint a frissítés előtt.

Teendők a cégnél: hat lépés erre a hétre

Derítse ki, ki felel a szerverért, ellenőrizze a verziókat, frissítsen egy tesztpéldányon, módosítsa a kódot, tesztelje a szervert két klienssel egyszerre, és gyanú esetén cserélje le a kulcsokat.

1. Írja össze a cég összes MCP szerverét és kliensét, és mindegyikhez azt a személyt, aki felel érte. Ide tartoznak azok a prototípusok is, amelyeket valaki egy AI eszközzel épített, és futni hagyott.
2. Minden projektben futtassa az npm ls parancsot, és keresse a @modelcontextprotocol csomagokat. Az 1.x ágban a cél legalább az 1.32.0, a 2.x ágban a server és a client legalább 2.3.0, az adaptereknél pedig a táblázat szerinti verzió.
3. Először egy tesztpéldányt frissítsen, ne az éles szervert. A megosztott példányt használó szerver a frissítés után addig nem válaszol, amíg a kódot nem módosítják.
4. Végezze el az előző rész módosításait: külön szerver minden kéréshez vagy sessionhöz, az audience ellenőrzése, a maxToolInputElements és a maxRequestBodySize beállítása, valamint az issuer az OAuth-nál. Ha a kód a kísérleti taskStore funkciót használja, távolítsa el, mert a 2026-07-28-as specifikáció új bővítménnyel váltotta fel.
5. Tesztelje a szervert két klienssel egyszerre, és ellenőrizze, hogy mindegyik csak a saját válaszait kapja. Küldjön egy 4 MiB-nál nagyobb kérést is, és ellenőrizze, hogy a szerver 413-as kóddal elutasítja, és nem áll le.
6. Ha a kliens csatlakozhatott az Ön ellenőrzésén kívül eső szerverhez, vagy egy átirányítás oda küldhette, cserélje le az API-kulcsokat és a client secretet, és vonja vissza a kiadott tokeneket.

Hasonló helyzetet írtunk le a Supabase Data API hozzáférési változásánál: az alkalmazás addig működik, amíg az alatta lévő könyvtár vagy szolgáltatás nem változik, utána pedig azon múlik minden, hogy valaki a cégnél át tudja-e alakítani. A felelős nélküli szerver a régi verzión marad, az őt érintő összes hibával együtt.

Az MCP SDK sebezhetőség a gyakorlatban: ki felel a szerverért

Véleményünk szerint a legnagyobb kockázat az az MCP szerver, amely gyors kísérletként jött létre, és nincs, aki frissítse.

A kisebb cégek automatizálásainál a gyakorlatban olyan folyamatokat látunk, amelyek kísérletként indultak, és futva maradtak. Az MCP szervereknél ugyanez a veszély áll fenn, csak nagyobb hatókörrel, mert a szerver rendelésekhez, számlákhoz vagy ügyféladatokhoz ad hozzáférést az AI asszisztensnek. Ha a szerver személyes adatokkal dolgozik, a rossz kliensnek kézbesített válasz azt jelenti, hogy ezek az adatok egy másik felhasználóhoz jutottak. Azt, hogy kié az adat, a szerver ellenőrzi. Hogy a modell ezután hogyan dolgozik a kapott adatokkal, a mi az LLM, és mire nem képes az AI című cikkünk magyarázza el.

Mielőtt saját szervert építene, tegye fel a kérdést, valóban szüksége van-e rá. Ha csak két általános eszközt kell összekapcsolnia, elegendő lehet egy automatizálási platform, amelyet az üzemeltetője frissít. Összehasonlítást a kisvállalkozások n8n és Make alapú folyamatautomatizálásáról szóló cikkünkben talál.

Hogyan oldjuk meg a Denvánál: az integrációkat az eszközök hivatalos interfészein keresztül kötjük be, a hozzáféréseket pedig a szükséges minimumon tartjuk. A kritikus lépéseket úgy állítjuk be, hogy hiba esetén azonnal értesítést kapjon, a megoldást pedig dokumentálva adjuk át, hogy értse, és ne legyen ránk utalva.

Mikor boldogul egyedül, és mikor velünk

Egyedül is boldogul, ha:

• a szervert az a fejlesztő kezeli, aki megírta, és ismeri a kódját,
• csak helyi, stdio-n futó szervereket használ egy asztali AI alkalmazásban,
• a frissítés átment a tesztpéldányon, és a szerver két kliensnek egyszerre is helyesen válaszol.

Érdemes minket bevonni, ha:

• a szervert egy AI eszköz vagy egy külső beszállító építette, és a cégnél senki sem ismeri a kódját,
• a szerver rendelésekkel, számlákkal vagy az ügyfelek személyes adataival dolgozik,
• a kliens OAuth-tal jelentkezik be, és nem egyértelmű, mely tokeneket és kulcsokat kell lecserélni.

Összegzés

Ha egyik projektjében sincs @modelcontextprotocol csomag, nincs teendője. A stdio-n futó helyi szervert a legközelebbi karbantartáskor frissítse. Ha HTTP-n fut olyan MCP szerver, amely céges vagy személyes adatokkal dolgozik, a frissítés és a négy kódmódosítás erre a hétre tartozik, először egy tesztpéldányon, majd két klienssel végzett teszttel. A felelős nélküli szervert vegye át valaki, vagy kapcsolja ki addig, amíg ez meg nem történik.

GYIK

Gyakori kérdések.

Érinti az MCP SDK sebezhetőség a stdio-n futó helyi szervereket is?

A szerveroldali hibák nem. A megosztott példányra, a memória kimerítésére és a kérések hiányzó korlátjára vonatkozó figyelmeztetések kifejezetten kimondják, hogy a csak stdio-n futó szerverek nem érintettek, és a két kliensoldali hiba sem érinti a stdio klienseket. A javított verzióra frissítést ennek ellenére a legközelebbi karbantartáskor javasoljuk.

Melyik MCP SDK verzióra kell frissíteni?

Az 1.x ágban legalább a @modelcontextprotocol/sdk 1.32.0-s verziójára, a 2.x ágban a server és a client 2.3.0-s vagy újabb verziójára. 2026. október 22-én az npm-en a legújabb verzió az 1.32.1 és a 2.3.1. Az express, node és hono adapterek saját javított verziója a 2.0.2, a 2.1.0 és a 2.0.1.

Kihasználta már valaki ezeket a hibákat?

A figyelmeztetések nem említenek kihasználást. A szerver memóriáját érintő két hibánál azonban szerintük a támadónak nincs szüksége bejelentkezési adatokra, ha a szerver nem hitelesíti a kéréseket, mielőtt azok az SDK-hoz érnek, ezért ne halogassa a frissítést.

Miért nem válaszol az MCP szerver a frissítés után?

Valószínűleg egyetlen szerver- vagy transportpéldányt oszt meg több kliens között. A @modelcontextprotocol/server csomag 2.3.0-s verziója ezt ALREADY_CONNECTED hibával elutasítja, ezért a kódot úgy kell átalakítani, hogy minden kéréshez vagy minden sessionhöz saját szervert hozzon létre.

Le kell cserélnem az API-kulcsokat a javítások után?

Csak akkor, ha a kliens csatlakozhatott olyan MCP szerverhez, amelyben nem bízik meg, vagy egy átirányítás idegen címre küldhette. Ilyenkor a figyelmeztetések az API-kulcsok, a client secret vagy az aláírókulcs cseréjét és a kiadott tokenek visszavonását javasolják.