Microsoft warnt vor einer neuen Art von Remote-Code-Execution-Angriffen auf autonome Software-Agenten. Unter dem Namen „AutoJack“ haben Forscher laut Microsoft gezeigt, wie sich ein webfähiger Agent über eine präparierte Webseite kapern lässt, um auf lokale Dienste zuzugreifen und Code auf dem Host-System auszuführen. Die konkret belegte Schwachstelle betraf nach Angaben des Unternehmens ausschließlich Entwicklungs-Builds von AutoGen Studio mit Unterstützung für das Model Context Protocol, kurz MCP. Noch bevor diese Versionen öffentlich über PyPI verteilt wurden, sei die Lücke geschlossen worden.
Damit geht die Warnung deutlich weiter als ein einzelner Patch. In solchen Architekturen taugt „localhost“ nach Microsofts Darstellung nicht mehr automatisch als verlässliche Vertrauensgrenze.
AutoJack: So läuft der Angriff ab
Im demonstrierten Szenario nahmen die Forscher laut Microsoft einen Browsing-Agenten in AutoGen Studio ins Visier, der fremde Webinhalte lokal rendert. Genau dort liegt die Angriffsfläche. Eine präparierte Webseite kann mit einem lokalen WebSocket-Dienst auf Basis des Model Context Protocols kommunizieren und dabei die privilegierten lokalen Rechte des Agenten für sich arbeiten lassen.
Im Kern ist das ein klassischer Fall von „confused deputy“. Der Agent hat an sich legitime Berechtigungen, wird von einem Angreifer aber dazu gebracht, sie für fremde Zwecke einzusetzen. Die Schwachstelle steckt also nicht bloß im Modell. Kritisch ist das Zusammenspiel aus Browser, Tools, lokalen Diensten und Prozessaufrufen.
Drei Schwachstellen in einer Kette
Für eine vollständige Kompromittierung mussten laut Microsoft drei Fehler zusammenkommen. Erstens ließen sich Localhost-Origin-Prüfungen umgehen, weil der lokale Browsing-Agent die Identität von „localhost“ übernahm. Zweitens waren MCP-WebSocket-Pfade von der regulären Authentifizierung ausgenommen, ohne dass dort eine eigene Zugriffskontrolle erzwungen wurde.
Der dritte Punkt saß tiefer im Ablauf: Benutzerdefinierte „server_params“ wurden dekodiert und danach direkt an Mechanismen zum Starten von Prozessen übergeben, ohne Allowlist für ausführbare Programme.
Am Ende entstand laut Microsoft ein direkter Weg vom Aufruf einer Webseite bis zur Ausführung von Befehlen auf dem Rechner. Für Angreifer ist das attraktiv, weil unter anderem kein klassischer Exploit gegen den Browser selbst nötig ist. Der Agent bringt den Zugriff auf lokale Ressourcen gewissermaßen schon mit.
Warum localhost als Sicherheitsgrenze an Bedeutung verliert
Die eigentliche Warnung reicht weit über AutoGen Studio hinaus. Wer Agenten entwickelt, bekommt mit „localhost“ spätestens dann ein Problem, wenn ein Agent sich frei durchs Web bewegt und zugleich mit privilegierten lokalen Diensten spricht. Was früher als intern und damit vertrauenswürdig galt, lässt sich auf diesem Weg indirekt von außen erreichen.
Dazu passt laut Microsoft eine wachsende Zahl ähnlicher Befunde: Fallen für autonome Agenten, „Agentjacking“ bei Coding-Assistenten, Prompt-Injection-zu-RCE-Probleme in Microsofts Semantic Kernel und ein Datenabfluss in Microsoft 365 Copilot. Es geht also nicht um einen einzelnen Bug, sondern um eine Architektur, die an mehreren Stellen anfällig ist.
Welche Schutzmaßnahmen jetzt wichtiger werden
Sicherheitsteams drängen deshalb auf einen Zero-Trust-Ansatz für Agentenumgebungen. Gemeint sind strengere Sandboxing-Konzepte, klare Allowlists für ausführbare Aktionen, eine saubere Trennung lokaler Dienste, durchgängige Authentifizierung auch auf MCP-Pfaden sowie Monitoring für auffälliges Agentenverhalten.
Vor allem sollten Aktionen, die von Agenten ausgelöst werden, und der von ihnen erzeugte Code standardmäßig als nicht vertrauenswürdig gelten. Microsofts Demo wirkt deshalb weniger wie eine isolierte Produktpanne, sondern eher wie ein Architekturproblem, das sich über einzelne Produkte hinweg zieht und auf das Entwickler zügig reagieren müssen.
