AWS veroeffentlichte am 1. Oktober 2026 Security Bulletin 2026-121-AWS zu CVE-2026-97662, einem Argument-Injection-Problem in security-agent-mcp-server. Der Open-Source Model Context Protocol Server wird im AWS Labs MCP Repository veroeffentlicht und von KI-Assistenten genutzt, um lokale Security Scans, einschliesslich Diff Scans, ueber Quellcode auszufuehren.
Das Bulletin sagt, ein speziell gestalteter Referenzwert fuer den Diff Scan koenne als Kommandozeilenoption statt als Revision behandelt werden. In betroffenen Versionen kann ein kontextabhaengiger Akteur dadurch Dateien auf dem Host ausserhalb des vorgesehenen Workspace erstellen, ueberschreiben oder abschneiden. AWS sagt, Versionen ab 0.1.1 und kleiner als 0.2.0 seien betroffen, und das Upgrade auf 0.2.0 sei der Fix.
Was AWS offengelegt hat
Die betroffene Komponente ist kein allgemeiner Cloud Service. Es ist ein lokaler MCP Server, der KI-Assistenten eine Security-Scanning-Faehigkeit ueber Code gibt. Diese Unterscheidung ist wichtig. MCP Server liegen oft nahe an Quellfiles, Terminals, Credentials, Repositories und Entwicklerrechnern. Ein Bug in einem agentenorientierten lokalen Tool kann daher aus einer begrenzten Code-Review-Aufgabe ein Host-File-Integritaetsproblem machen.
AWS sagt, es gebe keinen Workaround ausser dem Upgrade. Bis dahin empfiehlt das Bulletin, Diff Scans nur gegen vertrauenswuerdige Repositories zu fahren und den Server als Least-Privileged User in einer isolierten Umgebung zu betreiben. Rapid7s Vulnerability Database erfasst unabhaengig dasselbe Veroeffentlichungsdatum, Verhalten und Upgrade Guidance und nennt CVSS v4.0 Base Score 6.9 sowie CVSS v3.1 Base Score 8.2.
Warum das wichtig ist
KI-Coding- und Security-Assistenten sind am nuetzlichsten, wenn sie echte Aenderungen inspizieren, ueber Diffs nachdenken und Tools aufrufen koennen. Genau dort liegt das Risiko. Repository-Referenz, Branch-Name, Vergleichsziel oder anderer Scan-Input koennen wie normaler Entwicklerkontext aussehen, aber in Command Execution, File Writes oder Host Mutation kippen, wenn der MCP Server sie ohne ausreichende Delimiter-Kontrolle an darunterliegende Tools weitergibt.
Fuer Security Teams geht die Lehre ueber dieses eine Paket hinaus. MCP Server sind Software-Supply-Chain-Assets. Sie brauchen Inventar, Version Tracking, Owner, Exposure Analyse und Patch-Evidenz. Sie brauchen auch Task-Grenzen: welcher Assistent darf den Server aufrufen, welche Repositories sind trusted, welche Pfade sind writable, welche Environment Variables sind erreichbar und ob der Server mehr Privilegien hat als die Aufgabe braucht.
Maetras Prompt-Injection-Kontrollen fuer KI-Agenten behandeln dasselbe Boundary-Problem aus Agentensicht. Tool Input ist nicht nur Text. Sobald ein Modell einen Tool Call verursachen kann, kann untrusted context zu einem Action Envelope werden.
Was Teams jetzt pruefen sollten
Zuerst sollten sie jede Instanz von AWS security-agent-mcp-server finden, einschliesslich Entwicklerrechnern, CI-Helfern, internen Agentenstacks und experimentellen MCP-Registries. Suchen Sie nach Paketversionen, Lockfiles, Docker Images und lokalen Wrappern. Erfassen Sie Owner und Agent oder Assistent, der jede Instanz aufrufen kann.
Zweitens sollten betroffene Installationen auf Version 0.2.0 oder hoeher aktualisiert werden. Bewahren Sie Evidenz zu Vorher-Version, Paketquelle, Change Approval, Install Output und Nachher-Version auf. Wenn ein Fork oder Derivat Diff-Scan-Code kopiert hat, vergleichen Sie ihn mit dem Fixed Release, statt anzunehmen, der Fork sei sicher.
Drittens sollten sie Blast Radius reduzieren. Betreiben Sie MCP Server als Least-Privileged User, isolieren Sie sie von sensiblen Host-Pfaden, scannen Sie untrusted Repositories erst nach dem Patch und loggen Sie, welcher Assistent welche Operation mit welcher Repository-Referenz aufgerufen hat. Diese Evidenz hilft bei Assurance und Incident Review.
Was unklar bleibt
Das AWS Bulletin behauptet keine Ausnutzung in freier Wildbahn. Es sagt nicht, dass Kundensysteme kompromittiert wurden, und beweist keine Remote-Kompromittierung aus einem Default Deployment. Das Risiko haengt davon ab, ob untrusted oder vom Angreifer beeinflusste Referenzwerte den Diff Scan erreichen koennen und was der lokale Server schreiben darf.
Die praktische Schlussfolgerung ist spezifisch: Betroffene Versionen muessen gepatcht werden, und agentenorientierte lokale MCP Tools sollten als privilegierte Execution Surfaces behandelt werden, auch wenn ihr Zweck defensive Scans sind.
Maetra-Analyse
Diese CVE zeigt sauber, dass Agentensicherheit nicht nur Modellverhalten ist. Das Modell kann sich korrekt verhalten, waehrend die Tool-Grenze falsch ist. Wenn ein gestalteter Input von Repository-Kontext in Kommandooptionen uebergeht, kann ein Security Agent den Workspace beschaedigen, den er pruefen sollte.
Das veraendert Governance-Anforderungen fuer Developer Tooling. Teams brauchen ein Inventar von MCP Servern, nicht nur ein Modellinventar. Sie brauchen Policy darueber, welche Agenten lokale Tools aufrufen duerfen. Sie brauchen Runtime Checks fuer Tool-Argumente. Sie brauchen Evidenz, dass Patches gelandet sind und isolierte Ausfuehrung isoliert bleibt.
Die Kontrollfrage ist einfach zu formulieren und schwer zu faken: Kann die Organisation zeigen, dass ein agentengestuetzter Scan im Workspace blieb, den er pruefen durfte? CVE-2026-97662 erinnert daran, diese Antwort explizit zu machen, bevor das naechste lokale Agent Tool ausgerollt wird.
Sources
Primary source: AWS Security Bulletin 2026-121-AWS.
Corroboration: Rapid7-Eintrag zu CVE-2026-97662.