Ugrás a fő tartalomhoz

API és fejlesztésOpenBanking.hu szerkesztőség

Három AWS MCP-hiba: tanulságok a banki API-k biztonságához

Az AWS november 10–11-én három sebezhetőséget ismertetett két nyílt forráskódú MCP-projektben. A hibák jogosultságnövelést, belső hálózati hozzáférést vagy API-korlátozások megkerülését tehették lehetővé bizonyos feltételekkel. Mit tanulhatnak ebből az AI-ügynököket és pénzügyi API-kat összekapcsoló rendszerek fejlesztői?

Kibervédett digitális pénzügyi hálózat – szerkesztőségi illusztráció az AI-integrációk biztonságához.

A lényeg 30 másodpercben

  • Három friss közlemény

    Az AWS november 10–11-én két külön nyílt forráskódú MCP-projekt három hibáját ismertette.

  • Nem általános MCP-hiba

    Konkrét termékek és verziók érintettek; nem minden AWS-szolgáltatás vagy banki API.

  • Frissítés és utóellenőrzés

    A javítás mellett ellenőrizni kell a korábbi jogosultságokat, konfigurációkat és naplókat is.

Az AWS 2026. november 10–11-én három biztonsági közleményt tett közzé két nyílt forráskódú Model Context Protocol (MCP) projektről. A hibák bizonyos feltételek mellett jogosultságnövelést, belső hálózati szolgáltatások elérését vagy API-műveleti korlátozások megkerülését tehették lehetővé. A közlemények nem számolnak be igazolt banki támadásról vagy pénzügyi adatlopásról.

Miért fontos ez mégis az Open Banking világában? Mert az AI-asszisztensek egyre gyakrabban kapcsolódnak külső adatforrásokhoz és üzleti szoftverekhez, az ilyen kapcsolatok jogosultságait pedig több rétegben kell érvényesíteni.

Mi az MCP, és hol jelenik meg a pénzügyi rendszerekben?

A Model Context Protocol olyan kapcsolódási szabvány, amelyen keresztül az AI-kliens eszközöket és külső adatforrásokat érhet el. Egy pénzügyi környezetben elképzelhető például, hogy egy megfelelően feljogosított AI-ügynök számlaegyenlegeket kérdez le, tranzakciókat elemez vagy vállalati cash-flow-riportot készít.

Az OpenBanking.hu korábban bemutatta a Danske Bank vállalati MCP-pilotját, amely banki API-kat tesz elérhetővé AI-kliensből. A friss AWS-esetek nem a Danske Bank rendszerének hibái: egy általánosabb technikai kérdést világítanak meg. Mi történik, ha az AI-ügynök és a háttérrendszer közötti jogosultságkezelő réteg hibázik?

1. Jogosultságnövelés az MCP-regiszterben

A CVE-2026-100307 az mcp-gateway-registry projekt 1.0.9–1.24.7 verzióit érintette. Az AWS november 11-i közleménye szerint a külső menedzsment-API hitelesítette a hívót, de egyes műveleteknél nem ellenőrizte megfelelően a szerepkörét. Így egy már hitelesített, alacsony jogosultságú felhasználó egy manipulált csoportimport-kéréssel saját csoportjához regiszteradminisztrátori jogosultságot rendelhetett.

Az adminisztrátor hozzáférhetett a regisztrált MCP-erőforrásokhoz és a regiszterben tárolt hitelesítő adatokhoz. A hibát az 1.25.0-s verzióban, 2026. június 27-én javították; a részletes biztonsági közlemény november 11-én jelent meg. Az AWS külön figyelmeztet: a frissítés nem törli automatikusan a korábban létrehozott jogosulatlan adminjogokat, és nem érvényteleníti a korábban megismert hitelesítő adatokat.

2. Belső hálózati kérések az MCP-átjárón keresztül

A CVE-2026-125926 ugyanezen projekt másik, az 1.0.3–1.34.0 verziókat érintő hibája. Az AWS november 11-i közleménye szerint a szerverregisztráció során az upstream cím ellenőrzése hiányos volt. Egy szerver létrehozására vagy módosítására jogosult, hitelesített felhasználó így olyan címet adhatott meg, amelyre a gateway a telepítés belső hálózatán indított kérést. Bizonyos esetekben a választ is továbbíthatta a felhasználónak.

Az SSRF-nek nevezett hibatípust az 1.35.0-s verzióban javították. A már korábban eltárolt kiszolgálócímek viszont megmaradnak, ezért azokat a javítás után külön át kell nézni. Az 1.25.0-s verzió még nem javítja ezt a második hibát.

3. AWS API-műveletek tiltásának megkerülése

A CVE-2026-125271 egy másik terméket, az awslabs.aws-api-mcp-server 0.2.13–1.5.0 verzióit érintette. Az AWS november 10-i közleménye szerint a szerver helytelenül normalizálta az API-műveletek nevét, mielőtt összevetette volna a beállított denyList és elicitList szabályokkal. Egyes, egymás melletti nagybetűket tartalmazó műveletnevek ezért nem illeszkedtek a megfelelő korlátozásra.

Ennek következtében olyan művelet is lefuthatott, amelyet a helyi szabályzat tiltani vagy külön jóváhagyáshoz kötni kívánt. Az érintett komponens javított verziója az 1.5.1. A hiba nem kapcsolta ki az AWS IAM-jogosultságokat: a háttérben használt AWS-hitelesítő adatok jogosultságai továbbra is érvényben maradtak.

Nem igazolt banki támadásról van szó

Az AWS a három sérülékenység létezését és a javításokat erősítette meg. A hivatkozott közlemények nem igazolják a hibák aktív kihasználását banki rendszerek ellen, ügyféladatok ellopását vagy jogosulatlan pénzmozgást. A megállapítások két meghatározott, nyílt forráskódú MCP-projektre vonatkoznak – nem az összes MCP-megoldásra és nem az AWS teljes infrastruktúrájára.

Mit tanulhat ebből a banki és fintechszektor?

A három hiba eltérő, de ugyanahhoz a tervezési elvhez vezet: az AI-ügynök által elérhető műveleteket nem szabad kizárólag egyetlen köztes szoftverréteg szabályaira bízni.

Képzeljünk el egy pénzügyi riportot készítő AI-asszisztenst. A feladata számlaegyenlegek lekérdezése és a bejövő tranzakciók összesítése. Ehhez nincs szüksége kedvezményezett módosítására vagy átutalás indítására. Ha a köztes MCP-szerver tévesen megengedne egy ilyen műveletet, a háttérben működő banki API-nak és annak jogosultságkezelésének akkor is el kell utasítania a kérést.

Az AWS API MCP Server esete jól mutatja, miért fontos az önálló háttérjogosultság: egy alkalmazásszintű tiltólista hibázhat, de az AWS IAM-szabályzat ettől még nem szűnik meg. Banki rendszereknél hasonlóan fontos, hogy a jogosultság-ellenőrzés a tényleges adat- és tranzakciós végponton is megtörténjen.

Ez nem csupán technikai kérdés. A pénzügyi adatok bizalmassága, az ügyfél-hozzájárulás, a szerződéses hozzáférési kör és a módosító műveletek jóváhagyása mind azt kívánja meg, hogy az AI-kapcsolat ne terjessze ki észrevétlenül a felhasználó vagy a szolgáltatás eredeti jogosultságait.

Öt ellenőrzés AI-integrációk fejlesztőinek és üzemeltetőinek

  1. Komponensleltár: használatban van-e az mcp-gateway-registry, az awslabs.aws-api-mcp-server vagy ezek valamelyik forkja? A többi MCP-implementációra nem lehet automatikusan átvinni az érintettséget.
  2. Javított verzió: az MCP-regiszter fusson legalább 1.35.0-n, az AWS API MCP Server legalább 1.5.1-en, vagy az ezeknek megfelelően javított későbbi verzión.
  3. Jogosultságok újraellenőrzése: a regiszterben a csoporthozzárendeléseket és adminisztrátori scope-okat, a háttérszolgáltatásban pedig az IAM/API-jogosultságokat is vizsgálni kell. A frissítés előtt létrehozott jogosulatlan adminjogok megmaradhatnak.
  4. Naplók és upstream címek: ellenőrizni kell a váratlan szerverregisztrációkat, módosításokat és a korábban tárolt belső hálózati címeket. A regiszterrel kapcsolatos korábbi tevékenység azonosítását ne csak a javítás időpontjától kezdjük.
  5. Hitelesítő adatok védelme: ahol nem zárható ki a korábbi jogosulatlan hozzáférés, a hozzáférhetővé válhatott kulcsok és tokenek cseréje is indokolt. Az AI-ügynököt a legkisebb szükséges jogosultsággal és lehetőség szerint korlátozott hálózati eléréssel kell futtatni.

Az AWS a CVE-2026-125271 esetében nem jelöl meg megfelelő konfigurációs kerülőmegoldást: ott a javított verzióra történő frissítés szükséges. Az MCP-regiszternél a frissítés utáni napló- és konfigurációellenőrzés is része az ajánlott intézkedésnek.

A valódi tanulság: az AI hozzáférhet, de nem korlátlanul

Az AI-ügynökök banki API-khoz kapcsolása gyorsabb adatfeldolgozást, rugalmasabb riportkészítést és új ügyfélélményt hozhat. A friss AWS-esetek azonban megmutatják: az AI-ügynök és a háttérrendszer közötti integrációs réteg önálló támadási felületté válhat.

A biztonság alapelve változatlan: csak a feladathoz szükséges adatokat és műveleteket engedélyezzük, a kritikus kéréseket a háttérrendszer is ellenőrizze, és a javítás után a korábbi jogosultságokat is vizsgáljuk felül. Ez különösen fontos a személyes és pénzügyi adatokat kezelő alkalmazásoknál – függetlenül attól, hogy használatukban már megjelent-e AI-asszisztens.