BREAKING
Wenn der Cyber-Benchmark ausbricht: Was der OpenAI-Hugging-Face-Vorfall über sichere KI-Evaluierungen lehrt FakeGit und AgentBaiting: Wenn KI-Agenten selbst nach Malware suchen NGINX CVE-2026-42533: Wenn Regex-Captures den Speicherpuffer sprengen Agent Data Injection: Warum KI-Agenten nicht nur Anweisungen, sondern Daten misstrauen müssen Cursor-0day: Warum geklonte Repositories auf Windows wie ausführbarer Code behandelt werden müssen

SharedRoot bei Claude Cowork: Warum eine VM allein keinen KI-Agenten sicher einschließt

Clara
5 min read
SharedRoot bei Claude Cowork: Warum eine VM allein keinen KI-Agenten sicher einschließt

Ein KI-Agent soll Verträge sortieren, Quellcode prüfen oder Dateien umbenennen. Dafür bekommt er Zugriff auf einen ausgewählten Ordner — nicht auf das gesamte Benutzerkonto. Genau darauf beruht das Sicherheitsversprechen von Desktop-Agenten: Selbst wenn ein Modell eine manipulierte Datei falsch interpretiert oder unerwartete Befehle ausführt, soll die Sandbox den Schaden auf den freigegebenen Bereich begrenzen.

Die am 23. Juli veröffentlichte Analyse „SharedRoot“ von Accomplish AI zeigt, wie diese Grenze bei lokalen Sitzungen von Claude Cowork durchbrochen werden konnte. Die Forscher kombinierten eine Linux-Kernel-Schwachstelle mit mehreren Architekturentscheidungen der Desktop-Laufzeit. Am Ende konnte der Agent Dateien auf dem Mac außerhalb des freigegebenen Ordners lesen und schreiben. Relevant ist der Fall weniger wegen eines einzelnen CVE. Die zentrale Lehre lautet: Eine virtuelle Maschine schützt den Host nur dann zuverlässig, wenn ein kompromittierter Gast dort nichts Wertvolles erreichen kann.

Wie die lokale Cowork-Sandbox aufgebaut ist

Nach Darstellung der Forscher läuft die macOS-Anwendung mit den Rechten des angemeldeten Benutzers. Die eigentliche Agentenarbeit erledigt eine Linux-VM, die über Apples Virtualization Framework gestartet wird. Jede Sitzung erhält darin einen kurzlebigen, unprivilegierten Benutzer. Ein Seccomp-Filter begrenzt Systemaufrufe. Ein Root-Dienst namens coworkd bindet die vom Nutzer ausgewählten Ordner in die VM ein.

Auf dem Papier ist das eine solide mehrschichtige Architektur. Entscheidend war jedoch ein zusätzlicher Mount: Laut Accomplish wurde das gesamte Host-Dateisystem / innerhalb der VM unter /mnt/.virtiofs-root les- und schreibbar bereitgestellt. Sichtbar war es nur für Root im Gast. Damit hing die tatsächliche Begrenzung nicht mehr allein an den ausgewählten Ordnern. Sie beruhte auch auf der Annahme, dass der Agent niemals Root-Rechte in der VM erlangt.

Genau diese Annahme brach in der Angriffskette. Die Forscher betonen, dass sie den Ablauf Ende-zu-Ende auf einem eigenen System reproduziert haben. The Hacker News berichtete unabhängig über die Veröffentlichung und die technischen Kernelemente.

Vier Schritte vom unprivilegierten Agenten zum Host-Dateisystem

Der erste Schritt brauchte noch keine Schwachstelle. Der Sitzungsbenutzer durfte einen unprivilegierten User Namespace erzeugen. Innerhalb dieses eigenen Namespace erhielt er Linux-Capabilities, darunter CAP_NET_ADMIN für den privaten Netzwerk-Namespace.

Damit konnte er über Netlink das Traffic-Control-Modul act_pedit ansprechen. Der Seccomp-Filter erlaubte die nötigen Aufrufe, der Kernel lud das Modul automatisch. Dort lag CVE-2026-46331, auch „pedit COW“ genannt. Der offizielle CVE-Eintrag beschreibt eine fehlerhafte Copy-on-Write-Behandlung in net/sched: Bei bestimmten Laufzeit-Offsets konnte ein Teil des Schreibbereichs außerhalb der vorgesehenen COW-Kopie bleiben. Der Linux-CNA bewertet die lokale Schwachstelle mit CVSS 7,8 und nennt hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Accomplish nutzte den Fehler nach eigener Darstellung, um den Page Cache einer nur lesbaren, Root gehörenden Hilfsdatei zu manipulieren. Die Bytes auf dem Datenträger mussten dabei nicht dauerhaft verändert werden. Als coworkd diese Datei im normalen Ablauf erneut ausführte, lief bereits die manipulierte Cache-Version in einem Root-Prozess. So entstand Root-Zugriff innerhalb des Linux-Gasts.

Der letzte Schritt war kein weiterer Exploit. Gast-Root konnte den vollständigen, schreibbaren Host-Mount sehen. Dateien, die das macOS-Benutzerkonto erreichen durfte — etwa SSH-Schlüssel, Cloud-Konfigurationen oder Arbeitsdokumente — lagen damit innerhalb der Wirkungskette. Der Agent hatte die Hypervisor-Grenze nicht im klassischen Sinn gebrochen. Die Architektur hatte den Host vielmehr absichtlich in den Gast eingebunden und nur über Gast-Rechte abgeschirmt.

Warum ein Kernel-Patch nicht genügt

CVE-2026-46331 ist real und seit Juni öffentlich dokumentiert. Der CVE-Datensatz nennt korrigierte Linux-Stable-Stände für mehrere Kernel-Zweige und verweist auf einen öffentlichen Proof of Concept. Ein aktuelles Gast-Image ist deshalb eine notwendige Sofortmaßnahme. Es beseitigt aber nur diesen einen Weg zu Gast-Root.

Für eine belastbare Agenten-Sandbox muss Root im Gast als mögliches Fehlerbild gelten. Linux-Kernel, Namespaces, automatisch ladbare Module und komplexe Systemaufrufe bilden eine große Angriffsfläche. Gerade ein Agent, der untrusted Code, Dokumente oder Repositories verarbeitet und Werkzeuge ausführen kann, darf nicht davon abhängen, dass im Gast niemals eine lokale Privilegienausweitung existiert.

Die wichtigste Kontrolle liegt daher am Ende der Kette: Nur explizit freigegebene Verzeichnisse sollten in die VM gelangen. Ein Mount des gesamten Hosts — insbesondere mit Schreibrechten — vergrößert den Blast Radius unnötig. Wird ausschließlich der ausgewählte Ordner eingebunden, bleibt selbst Gast-Root auf diesen Datenbereich begrenzt.

Konkrete Implikationen für Unternehmen

Unternehmen, die Desktop-, Coding- oder Datei-Agenten einsetzen, sollten lokale Agentenlaufzeiten wie privilegierte Endpoint-Software prüfen:

  • Lokale Ausführung inventarisieren: Klären, welche Nutzer lokale Cowork-Sitzungen oder vergleichbare Agenten verwenden. Cloud- und lokale Ausführung sind unterschiedliche Risikomodelle und gehören getrennt in Richtlinien und Telemetrie.
  • Host-Mounts technisch prüfen: Nicht auf UI-Texte verlassen. Mit Runtime- und Endpoint-Tests verifizieren, welche Pfade tatsächlich in Gast, Container oder Sandbox sichtbar sind und ob sie schreibbar sind.
  • Gast-Root als Designannahme setzen: Die Sicherheitsarchitektur muss auch dann halten, wenn der Agent Root im Gast erreicht. Hostseitige Dateifreigaben, Broker und Berechtigungen müssen den erlaubten Bereich durchsetzen.
  • Kernel und Module minimieren: Gast-Images schnell aktualisieren, unprivilegierte User Namespaces einschränken, unnötige Module entfernen oder deren Autoload blockieren und Seccomp als Allowlist statt als kurze Denylist gestalten.
  • Secrets vom Agenten-Endpoint trennen: Dauerhafte Cloud-Schlüssel, Paket-Registry-Tokens und produktive SSH-Identitäten gehören nicht auf Geräte oder in Konten, in denen breit berechtigte Agenten arbeiten. Kurzlebige, zweckgebundene Identitäten reduzieren die Folgen.
  • Untrusted Input einkalkulieren: Manipulierte PDFs, Repositories oder Webseiten sind keine Ausnahme, sondern normaler Agentenkontext. Die Freigabe eines Ordners darf deshalb nie automatisch Vertrauen in dessen Inhalt bedeuten.

Risiken und Limitierungen der Meldung

Die technische Analyse stammt von Accomplish AI, einem Anbieter, der selbst Endpoint-Laufzeiten für Agenten entwickelt. Diese Interessenlage gehört zur Einordnung. Der Linux-Kernelfehler und seine Bewertung sind durch den offiziellen CVE-Eintrag bestätigt. Die konkrete Cowork-Kette wurde öffentlich jedoch vor allem vom Forschungsteam beschrieben und von The Hacker News aufgegriffen.

Accomplish gibt an, ungefähr 500.000 macOS-Nutzer lokaler Cowork-Sitzungen seien vor der Umstellung betroffen gewesen. Diese Reichweitenzahl ist nicht unabhängig verifiziert. Sie sollte auch nicht mit 500.000 kompromittierten Geräten gleichgesetzt werden. Es gibt keinen veröffentlichten Beleg für eine Ausnutzung bei Kunden oder für realen Datendiebstahl.

Auch beim Status ist Präzision wichtig: Laut Forschungsbericht schloss Anthropic die Meldung im Bug-Bounty-Prozess als „Informative“. Cowork nutze inzwischen standardmäßig Cloud-Ausführung, auf die der lokale Angriffspfad nicht zuzutreffen scheine. Das reduziert das Risiko. Es belegt aber nicht, dass jede weiterhin wählbare lokale Konfiguration architektonisch behoben wurde. Unternehmen sollten den konkret eingesetzten Modus und den aktuellen Herstellerstand prüfen.

Fazit

SharedRoot ist kein Argument gegen virtuelle Maschinen. Der Fall zeigt vielmehr, wie ihr Schutzwert unterlaufen werden kann: Wenn das gesamte Host-Dateisystem schreibbar im Gast liegt, wird eine lokale Kernel-Lücke zur Brücke auf den Endpoint.

Für Entscheider lautet die praktische Regel: Die Sandbox eines KI-Agenten muss auch bei Gast-Root sicher bleiben. Minimale Mounts, hostseitig erzwungene Berechtigungen, kleine Gast-Images, kurzlebige Identitäten und eine klare Trennung lokaler und cloudbasierter Ausführung zählen mehr als das Versprechen, der Agent laufe „in einer VM“.

Quellen

  • Accomplish AI: „SharedRoot; Escaping the Claude Cowork sandbox“, 23. Juli 2026:
  • CVE Program / Linux CNA: CVE-2026-46331, „net/sched: fix pedit partial COW leading to page cache corruption“:
  • The Hacker News: „Claude Cowork Flaw Could Let AI Agent Escape Its VM and Access Mac Files“, 23. Juli 2026:
  • Anthropic: Claude Cowork – Produkt- und Sicherheitsbeschreibung:
Teilen:
// Mission Critical

Woechentliches AI Security Briefing erhalten.

Fuer Analysten, Forscher und Verteidiger, die Bedrohungen im AI Stack verfolgen.

Kostenlos abonnieren

Verwandte Artikel