MCPStore.nl

Gepubliceerd:

AWS dicht lekken in eigen MCP-servers en agenttools: API MCP Server accepteerde tokens van andere apps

Kort: AWS publiceerde tussen 1 en 28 oktober 2026 vijf beveiligingsbulletins voor zijn eigen MCP-servers en de Strands-agenttools. De belangrijkste (CVE-2026-115413, 27 oktober): de AWS API MCP Server controleerde in OAuth-modus niet voor welke applicatie een token bedoeld was. Veilig is versie 1.6.0, waarin u de audience verplicht instelt. De beheerde AWS MCP Server is aan AWS-zijde gerepareerd.

AWS publiceert een hele reeks open-source MCP-servers in de repository awslabs/mcp, en biedt daarnaast een beheerde AWS MCP Server aan. Beide staan in onze directory voor cloud en infrastructuur. In oktober verschenen in het beveiligingsbulletin van AWS vijf meldingen die direct over MCP-servers of agenttooling gaan. De zwaarste, CVE-2026-115413, staat niet op de CISA-lijst van actief misbruikte kwetsbaarheden.

Wat ging er mis in de AWS API MCP Server?

De AWS API MCP Server laat een AI-assistent AWS-API's aanroepen met de AWS-credentials die op de host zijn ingesteld. Sinds versie 1.3.0 kan de server via het streamable-http-transport draaien, met OAuth-authenticatie tegen een identity provider naar keuze. Volgens het GitHub-advies (GHSA-4prq-p2x5-w9fh) controleerde de server bij elk token de handtekening, de uitgever en de vervaldatum, maar niet de claim die aangeeft voor welke applicatie het token is uitgegeven.

Het gevolg: een token dat dezelfde identity provider voor een andere applicatie in dezelfde tenant had uitgegeven, werd ook geaccepteerd. Het advies noemt als voorbeeld een token voor een tweede app-client in dezelfde Amazon Cognito user pool. Een lokale aanroeper met zo'n token kon AWS-operaties uitvoeren met de credentials van de server, alleen begrensd door de rechten van die credentials.

Welke andere bulletins zijn er?

Waarom is dit relevant voor organisaties?

De API MCP Server is in feite een sleutelbos: hij voert AWS-aanroepen uit met de rechten die u hem geeft. Een fout in de toegangscontrole raakt daarmee direct uw cloudomgeving. Het patroon is bovendien niet nieuw. Begin oktober schreven we over beveiligingsadviezen voor de officiële MCP-SDK's, waar audience-controle ook een terugkerend thema was. Wie een remote MCP-server met OAuth draait, eigen bouw of van een leverancier, moet die controle expliciet verifiëren.

De Strands-meldingen laten een tweede les zien: een agent mag nooit zelf beslissen over een beveiligingsinstelling. Zodra het model een parameter als "maskeer geheimen: ja/nee" kan zetten, kan een prompt-injectie dat ook.

Ons advies

(1) Gebruikt u awslabs.aws-api-mcp-server met streamable-http en OAuth: update naar 1.6.0, stel AUTH_AUDIENCE of AUTH_CLIENT_ID in en controleer in CloudTrail welke aanroepen de server sinds versie 1.3.0 deed. (2) Geef de credentials van zo'n server alleen de minimale IAM-rechten, nooit beheerrechten. (3) Draait u Strands-agents: update SDK en tools, en roteer sleutels als de environment-tool geladen was. (4) Vraag bij elke remote MCP-server, ook van een grote leverancier, hoe tokens gevalideerd worden. Meer in veiligheid & watchouts en een MCP-server bouwen.

De grotere lijn: dat AWS dit soort fouten in eigen MCP-tooling openbaar meldt met CVE-nummers en heldere upgradestappen, is volwassen gedrag. Het laat ook zien dat "officieel van de cloudleverancier" niet betekent dat u de configuratie kunt overslaan: de fix in 1.6.0 werkt pas als u de audience daadwerkelijk instelt.

Bronnen

Veelgestelde vragen

Welke versie van de AWS API MCP Server is veilig?

Versie 1.6.0 van awslabs.aws-api-mcp-server (27 oktober 2026). Kwetsbaar zijn 1.3.0 tot 1.6.0, en alleen bij gebruik van het streamable-http-transport met OAuth. Na de update moet u in OAuth-modus AUTH_AUDIENCE instellen, of AUTH_CLIENT_ID bij bijvoorbeeld Amazon Cognito.

Moet ik iets doen voor de beheerde AWS MCP Server?

Nee. Het lek in de run_script-sandbox (CVE-2026-115845) is volgens AWS aan de serverkant opgelost; er is geen klantactie nodig. Volgens het bulletin kon de code bovendien alleen in de eigen geïsoleerde sessie van de gebruiker draaien.

Wat is token-audience-validatie en waarom is die belangrijk?

Een OAuth-token bevat een claim die aangeeft voor welke applicatie het is uitgegeven (de audience of client-ID). Controleert een server alleen handtekening, uitgever en vervaldatum, dan accepteert hij ook tokens die dezelfde identity provider voor een heel andere applicatie uitgaf. Wie zo'n token heeft, komt dan binnen op een server waarvoor hij nooit toegang kreeg.

Laatst bijgewerkt: