Was, wenn Ihr KI-Agent morgens eine harmlose Zusammenfassungs-Anfrage bearbeitet und am Ende ein Angreifer dadurch Code auf dem Entwickler-Laptop ausführt? Genau dieses Szenario ist Microsoft-Forschern in den vergangenen Tagen gelungen: Sie zeigten, dass eine einzelne vom Agenten geöffnete Webseite ausreicht, um die volle Kontrolle über den Host zu übernehmen. Der Angriff trägt den Namen AutoJack und richtet sich gegen AutoGen Studio, die offene Prototyping-Oberfläche für Microsofts Multi-Agent-Framework AutoGen. Die Schwachstelle vereint drei klassische Fehler im Model Context Protocol (MCP)-WebSocket: ein Vertrauen in localhost, fehlende Authentifizierung und eine unkontrollierte Befehlsausführung. Zusammen bilden sie eine Kette, die beweist, warum KI-Agenten keine Sandbox mehr sein dürfen, sondern als privilegierte Dienste behandelt werden müssen.

Konkret wurde die Angriffskette am 19. Juni 2026 von The Hacker News öffentlich gemacht, das auf einer Analyse der Microsoft Security Response Center-Forscher basiert. Die Forscher nutzten einen „Web Content Summarizer“-Agenten, der auf Anweisung hin eine externe URL öffnet. Sobald die Seite im Agenten-Rendering geladen war, lieferte ihr JavaScript einen Befehl an den lokalen MCP-WebSocket. Das Ergebnis: calc.exe startete auf dem Desktop des Entwicklers. Kein Login, kein weiterer Klick, keine Warnmeldung. Microsoft hat den Fehler im main-Branch von AutoGen mit Commit b047730 behoben, aber noch keine neue stabile PyPI-Version veröffentlicht. Betroffen sind die Pre-Releases 0.4.3.dev1 und 0.4.3.dev2; die aktuelle stabile Version 0.4.2.2 enthält den verwundbaren MCP-Handler gar nicht.

Was ist AutoJack und warum ist es mehr als ein Nischen-Bug?

Die Ausgangslage: Ein lokaler Agent mit globaler Reichweite

AutoGen ist eines der am weitesten verbreiteten Open-Source-Frameworks für Multi-Agent-Systeme. Entwickler können damit Agenten definieren, die untereinander Nachrichten austauschen, Werkzeuge aufrufen und im Idealfall komplexe Aufgaben eigenständig lösen. AutoGen Studio ist die grafische Prototyping-Oberfläche, mit der Teams schnell Workflows testen. Für die Verbindung zu lokalen Tools setzt Microsoft dabei auf das Model Context Protocol (MCP), das inzwischen von Anthropic, OpenAI, Google und vielen anderen unterstützt wird. MCP soll Agenten einen standardisierten Weg bieten, externe Datenquellen und Werkzeuge anzuzapfen.

Das Problem beginnt damit, dass viele Entwickler Agenten lokal auf ihrem Laptop betreiben. Der Agent öffnet Webseiten, liest Dokumente, startet Befehle und greift auf Datenbanken zu. Solange alles auf demselben Gerät läuft, wird localhost oft als vertrauenswürdige Zone behandelt. Genau diese Annahme nutzt AutoJack aus. Sobald der Agent eine präparierte Webseite lädt, ist diese Webseite nicht mehr „irgendwo im Internet“ – sie läuft im Kontext des lokalen Betriebssystems. Die Grenze zwischen „untrusted content“ und „trusted localhost“ verschwimmt. Unternehmen, die über KI-Agenten in der Geschäftswelt diskutieren, müssen dieses Architekturproblem ernst nehmen.

Die betroffenen Versionen im Detail

Laut der von Microsoft veröffentlichten Analyse und den Prüfungen von The Hacker News liegt die Schwachstelle in zwei Entwickler-Versionen auf PyPI: autogenstudio 0.4.3.dev1 und 0.4.3.dev2. Diese Pre-Releases enthalten einen MCP-WebSocket-Handler, der ungeschützt Befehle entgegennimmt. Wer mit pip install autogenstudio arbeitet, erhält aktuell 0.4.2.2. Diese stabile Version hat den betroffenen Code nicht, ist also nicht verwundbar. Wer jedoch aktiv Neuerungen testet und bewusst oder versehentlich eine Pre-Release installiert hat, ist im Risiko.

Microsoft stellte klar, dass der MCP-Handler „niemals in einem PyPI-Release enthalten war“. Diese Aussage bezieht sich auf die stabilen Versionen, denn die dev-Releases sind ebenfalls über PyPI erhältlich und werden von pip installiert, sobald der Nutzer --pre setzt oder die Version festpinnt. Der korrigierte Code liegt seit März 2026 auf GitHub, wurde aber bislang nicht in ein neues Paket überführt. Für Entwickler bedeutet das: Entweder sie wechseln auf den main-Branch oder sie isolieren ihre Installation rigoros. Mehr zum MCP-Ökosystem und Agentic AI lesen Sie in unserem Hintergrundartikel.

So funktioniert die AutoJack-Angriffskette

Drei Schwächen, die zusammen RCE ermöglichen

AutoJack ist ein ausgeklügelter, aber konzeptionell einfacher Exploit. Er verknüpft drei Schwächen im MCP-WebSocket von AutoGen Studio, die jede für sich schon problematisch sind, zusammen aber fatal werden. Die erste Schwäche ist der localhost-Check. Der WebSocket akzeptierte Verbindungen nur von 127.0.0.1, um böswillige Webseiten im Internet fernzuhalten. Das klingt vernünftig, solange man davon ausgeht, dass localhost gleich „sicher“ bedeutet. Ein KI-Agent, der auf demselben Rechner läuft und eine Webseite rendert, erscheint jedoch ebenfalls als localhost. Die präparierte Seite erbt damit die erlaubte Identität.

Die zweite Schwäche ist die fehlende Authentifizierung. Die Authentifizierungsmiddleware übersprang MCP-Pfade mit der Annahme, der Handler würde Tokens selbst prüfen. Das tat er nie. Das bedeutet: Sobald die Verbindung zum WebSocket stand, konnte jeder Befehl abgesetzt werden, ohne ein gültiges Token oder eine Session vorzuweisen. Die dritte Schwäche ist die Befehlsausführung aus der Anfrage. Der Endpunkt nahm den auszuführenden Befehl direkt aus einem Request-Parameter entgegen und startete ihn, ohne eine Whitelist, ohne Sandbox, ohne Rückfrage. Ein Angreifer musste also nur noch den richtigen JSON-String an den Socket senden.

Der Proof-of-Concept: calc.exe aus einem Link

Im öffentlich beschriebenen Proof of Concept erstellten die Microsoft-Forscher einen Agenten, der Webinhalte zusammenfassen soll. Der Agent erhielt eine URL, die auf eine vom Angreifer kontrollierte Seite zeigte. Sobald der Agent die Seite öffnete, lieferte das JavaScript der Seite einen Befehl an den MCP-WebSocket. Innerhalb von Sekunden startete der Rechner des Entwicklers calc.exe. Der Befehl lief mit den Rechten des AutoGen-Studio-Prozesses, also typischerweise mit den Rechten des angemeldeten Entwicklers.

Der Clou dabei ist die geringe Reibung: Kein Phishing-Mail, kein Exploit für das Betriebssystem, keine Malware-Installation. Die gesamte Kette basiert auf legitimem Verhalten – einem Agenten, der das Web surft, und einem lokalen Dienst, der Befehle annimmt. Microsoft betont, dass es sich um Forschung handelt und keine aktive Kampagne bekannt ist. Doch genau solche Forschungsergebnisse werden schnell zu Angriffs-Templates. Wer sich für ähnliche Agent-Schwachstellen interessiert, findet in unserem Beitrag zu CVE-2026-48710 „BadHost“ einen direkten Vergleich.

Warum localhost keine Sicherheitsgrenze mehr ist

Agenten teilen die Identität des Hosts

Die klassische Web-Sicherheit lehrt: „Same-Origin-Policy“ und „localhost ist isoliert“. Diese Annahmen gelten, solange ein normaler Browser eine Webseite öffnet. KI-Agenten ändern das Modell grundlegend. Sie sind Programme, die im Hintergrund laufen, Webseiten rendern, APIs aufrufen und gleichzeitig lokale Dienste bedienen. Wenn ein Agent eine Webseite öffnet, passiert das oft im gleichen Betriebssystemprozess oder in einem Prozess, der dieselbe IP-Identität trägt. Für einen lokalen WebSocket ist die Herkunft damit 127.0.0.1 – egal, ob ein Mensch im Browser sitzt oder ein Agent automatisch navigiert.

Microsoft schreibt in seiner Analyse, dass der Fehler ein Muster aufzeigt, das über AutoGen hinausgeht: „Wir erwarten die gleiche Form in anderen Agent-Frameworks.“ Überall dort, wo ein lokaler Dienst mit vielen Rechten läuft und ein KI-Agent im gleichen Kontext Webseiten öffnet, entsteht die gleiche Angriffsfläche. Das Problem ist nicht AutoGen, sondern die Kombination aus privilegiertem lokalem Dienst, localhost als Trust-Annahme und autonomem Browsen. Wer heute Agentic-Systeme evaluiert, sollte dieses Design-Muster auf der Stelle als Risiko kennzeichnen.

Ein wiederkehrendes Muster: ChatGPhish und Semantic Kernel

AutoJack ist nicht das erste Mal, dass ein KI-Agent durch das Öffnen externer Inhalte kompromittiert wird. Im Mai 2026 berichtete The Hacker News über ChatGPhish, bei dem ChatGPT-Zusammenfassungen zu einem Phishing-Vektor wurden. Ebenfalls im Mai veröffentlichte Microsoft eine Untersuchung zu Semantic Kernel, die zwei CVEs einbrachte: CVE-2026-26030 und CVE-2026-25592. Auch dort gelang es, durch Prompts eigentlich harmlose Agenten dazu zu bringen, schädliche Aktionen auszuführen.

Die Gemeinsamkeit ist nicht der Hersteller, sondern die Architektur: Ein Agent, der gleichzeitig das offene Web und vertrauenswürdige lokale Dienste erreicht, wird zur Brücke für Angreifer. Wo früher ein Angriff einen Exploit für den Browser oder das Betriebssystem brauchte, reicht heute oft ein gezielter Link oder eine Prompt-Injection. Die Angriffsoberfläche verschiebt sich damit von der Infrastruktur zur Anwendungslogik des Agenten. Unternehmen, die Supply-Chain-Sicherheit bereits ernst nehmen, sollten diese Erkenntnis auf ihre KI-Pipeline übertragen.

Betroffene Versionen, Patches und Workarounds

PyPI-Status und die GitHub-Fix

Stand 20. Juni 2026 ist die aktuelle stabile Version von autogenstudio 0.4.2.2. Wer diese installiert hat, ist nicht betroffen, weil der MCP-Handler in dieser Version noch nicht vorhanden ist. Wer jedoch 0.4.3.dev1 oder 0.4.3.dev2 nutzt, hat den verwundbaren Code. Diese Versionen sind bislang nicht von PyPI entfernt worden. Eine gepatchte PyPI-Version gibt es noch nicht. Die Korrektur liegt im GitHub-Repository von Microsoft vor.

Der Fix ist in Commit b047730 nachvollziehbar. Der MCP-Handler liest den Befehl nicht mehr direkt aus der URL, sondern speichert Parameter serverseitig hinter einer einmaligen Session-ID. Unbekannte IDs werden abgelehnt. Zusätzlich durchlaufen MCP-Routen nun die reguläre Authentifizierung. Das ist eine sinnvolle, aber nicht übermäßig komplexe Änderung. Sie zeigt, wie wenig es oft braucht, um solche Ketten zu unterbrechen – solange man das Problem rechtzeitig erkennt. Entwickler sollten deshalb direkt auf den main-Branch wechseln oder die Installation vollständig isolieren, bis ein neues Release erscheint.

Was Admins und Entwickler sofort tun können

Bis ein gepatchtes Release verfügbar ist, bleiben vier pragmatische Maßnahmen. Erstens: Trennung der Komponenten. AutoGen Studio sollte nicht auf derselben Maschine laufen wie ein Agent, der unvertrauenswürdige Webinhalte öffnet. Die Kette funktioniert nur, weil beide dieselbe localhost-Identität teilen. Zweitens: Containment. Wenn beide Dienste zusammen betrieben werden müssen, sollten sie in separaten virtuellen Maschinen oder Containern laufen. Drittens: Prinzip der geringsten Rechte. AutoGen Studio sollte unter einem dedizierten, eingeschränkten Benutzerkonto ausgeführt werden, nicht unter dem eigenen Entwicklerprofil. Viertens: Netzwerksegmentierung. Lokale WebSockets sollten durch Firewall-Regeln oder Bindungen auf spezifische Interfaces eingeschränkt werden, statt blind auf 0.0.0.0 oder 127.0.0.1 zu lauschen.

Was Unternehmen jetzt tun müssen

Neu bewerten: Agenten sind keine harmlosen Helfer

Die AutoJack-Kette macht eines deutlich: Ein KI-Agent, der das Internet browsen und lokale Dienste bedienen darf, ist kein gewöhnliches Anwendungsprogramm. Er hat die gleiche Reichweite wie ein privilegierter Dienst. Unternehmen sollten Agenten deshalb in ihre Threat Model-Überlegungen aufnehmen. Das bedeutet, Zugriffsrechte, Netzwerksegmentierung, Logging und Patch-Management explizit für Agenten-Frameworks zu definieren. Wer heute Copilot-ähnliche Werkzeuge, Claude Code, Cursor oder AutoGen im Unternehmen erprobt, muss fragen: Welche lokalen Ports öffnen diese Tools? Wer darf sich verbinden? Welche Befehle können sie ausführen?

Langfristige Architekturprinzipien

Microsoft schlägt drei Leitlinien vor, die sich auf die gesamte Agent-Branche übertragen lassen. Erstens: Authentifiziert die Steuerungsebene. Ein lokaler Socket allein darf keine Berechtigung implizieren. Jede Steueranfrage braucht eine geprüfte Identität. Zweitens: Whitelisting für Befehle. Prozessstarts dürfen nicht aus beliebigen Request-Parametern erfolgen, sondern nur aus einer fest definierten, überprüften Liste. Drittens: Agenten brauchen ihre eigene Identität. Ein Agent darf nicht einfach die Session oder das Benutzerkonto des Entwicklers übernehmen. Er braucht ein separates Konto mit begrenzten Rechten, ähnlich wie ein Service-Account in klassischen Unternehmensanwendungen.

Diese Prinzipien helfen nicht nur gegen AutoJack, sondern gegen die nächste Generation ähnlicher Angriffe. Denn sobald Agenten in Produktion gehen, wird die Zahl der Frameworks, Tools und Protokolle weiter steigen. Wer jetzt die Architektur richtig aufstellt, vermeidet später teure Nachbesserungen. Unser Artikel über Cybersecurity 2026: Neue Bedrohungen und Schutzstrategien liefert dazu einen breiteren Rahmen.

Im Fokus: Zusammenfassung

AutoJack demonstriert, wie schnell die Sicherheitsarchitektur von KI-Agenten ins Wanken gerät, wenn localhost als Vertrauensanker missbraucht wird. Microsofts AutoGen Studio in den Pre-Releases 0.4.3.dev1 und 0.4.3.dev2 erlaubte es einer einzelnen Webseite, über den MCP-WebSocket beliebige Befehle auf dem Host auszuführen. Die stabile Version 0.4.2.2 ist nicht betroffen, ein gepatchtes PyPI-Release steht aber noch aus. Bis dahin sollten Entwickler auf den GitHub-main-Branch wechseln oder AutoGen Studio von Agenten mit Internetzugriff isolieren. Langfristig müssen Unternehmen Agenten als privilegierte Dienste behandeln: mit Authentifizierung, Befehls-Whitelisting und separaten Identitäten. Wer das Thema vertiefen möchte, findet weitere Kontexte in unseren Artikeln zu MCP und Agentic AI, MCP-Architektur sowie KI-Agenten im Unternehmen.