Was eine einzige Nachricht erreichte

Am 23. Juli legte die Sicherheitsfirma Accomplish eine Schwachstelle offen, die sie SharedRoot nannte. Ihr Chefforscher Oren Yomtov beschrieb den Test nüchtern: Man verband einen Ordner mit einer frischen Claude-Cowork-Sitzung, schickte eine kurze Nachricht und sah zu, wie der Agent die Sandbox verließ.

Claude Cowork betreibt seinen Agenten in einer virtuellen Linux-Maschine auf dem Mac, aufgebaut auf Apples eigenem Virtualisierungs-Framework. Jede Sitzung erhält einen unprivilegierten Benutzer und eine Filterung der Systemaufrufe, was dem Wort Sandbox erst Gewicht gibt. Das Problem war nicht die Box. Es war das, was die Box sehen konnte.

Das gesamte Host-Dateisystem war mit Lese- und Schreibzugriff in diese Maschine eingebunden. Von innen erreichte der Agent SSH-Schlüssel, Cloud-Zugangsdaten, API-Schlüssel, Quellcode-Repositorys und alles andere, worauf das angemeldete Konto zugreifen konnte. Nach Zählung der Firma hatten rund 500.000 Menschen Cowork lokal betrieben, bevor die Lücke geschlossen wurde.

Warum kein Patch kam

Anthropic erhielt den Bericht und schloss ihn als informativ. Im Sprachgebrauch der Bug-Bounty-Programme ist das eine Bestätigung ohne eigenen Patch, und das Unternehmen ordnete ihn in das Dreißig-Tage-Fenster ein, das sein Programm für solche Fälle vorsieht.

Die Antwort war architektonisch, nicht korrigierend. Die aktuelle Version von Cowork betreibt den Agenten standardmäßig in Anthropics Cloud, und die Forscher stimmen zu, dass dieser lokale Ausbruchspfad dort nicht zu gelten scheint. Der Standard verlagerte das Risiko vom Rechner des Kunden weg, für jeden, der ihn akzeptiert.

Damit bleibt eine klare Trennlinie. Betreiben Ihre Entwickler den Agenten im Cloud-Standard, ist dieser Ausbruch nicht ihr Problem. Wählen sie die lokale Ausführung, aus Datenschutz, für Offline-Arbeit oder aus Gewohnheit, tragen sie das gesamte Risiko, und kein Update wird es für sie beseitigen.

Die Grenze war eine Einbindung, keine Mauer

Das Lehrreiche ist, wie gewöhnlich die Schwäche war. Das Host-Dateisystem war so in die virtuelle Maschine eingebunden, dass es nur der Root-Benutzer im Gast sehen sollte. Der Ausbruch wurde schlicht zum Root im Gast, über eine bekannte Lücke im Linux-Kern mit der Kennung CVE-2026-46331, und die Einbindung erledigte den Rest.

Die Lehre für Verteidiger ist nicht der Fehler eines einzelnen Anbieters, sondern seine Form. Eine Sandbox, die den gesamten Host teilt, ist nur so stark wie die Annahme, dass niemand darin je Root wird. Bei einem Agenten, der ungeprüfte Inhalte liest und danach handelt, ist genau das die Annahme, die Sie nicht treffen sollten.

Was vor dem lokalen Betrieb zu sichern ist

Behandeln Sie jeden Rechner, der einen lokalen Agenten betreibt, so, als könne der Agent das Benutzerverzeichnis lesen, denn in diesem Fall konnte er es. Halten Sie SSH-Schlüssel und Cloud-Zugangsdaten von Entwickler-Laptops fern, auf denen Agenten mit ungeprüften Inhalten laufen, oder begrenzen Sie diese Agenten so, dass die Einbindung des Host-Dateisystems auf die verbundenen Ordner beschränkt und nur lesbar ist.

Wo die Plattform es zulässt, empfehlen die Forscher, unprivilegierte Benutzer-Namespaces zu deaktivieren, den Systemaufruf-Filter zu verschärfen und das bedarfsweise Laden ungenutzter Kernmodule zu unterbinden - die Schritte, die genau diese Kette blockiert hätten. Das sind Konfigurationsmaßnahmen, und die liegen bei Ihnen, nicht beim Anbieter.

Die Meldepflicht liegt ebenfalls bei Ihnen. Nach NIS2 in der Europäischen Union, und nach DORA für Finanzunternehmen, ist ein durchgesickerter Entwickler-Zugang, der die Produktion erreicht, Ihr Vorfall, den Sie fristgerecht melden - in Deutschland gegenüber dem BSI. Die Sandbox wurde als Sicherheit verkauft; die Verantwortung lag immer bei Ihnen.

Weiterlesen: Die offene Tür war die Paketquelle  |  Eine KI führte einen ganzen Ransomware-Angriff allein