Eine Nachricht, voller Zugriff: Was die Claude-Cowork-Sicherheitslücke für Ihre Unternehmensdaten bedeutet

Eine einzige Nachricht. Ein frisch verbundener Ordner. Mehr brauchte es nicht, um die Sandbox von Claude Cowork zu umgehen und Zugriff auf das komplette Dateisystem eines Mac zu erhalten – SSH-Schlüssel, Cloud-Zugangsdaten und praktisch alle persönlichen Dateien eingeschlossen. Am 23. Juli 2026 veröffentlichte die Sicherheitsfirma Accomplish AI einen Blogpost, der genau das dokumentiert: eine Sandbox-Escape-Lücke namens SharedRoot. Für Unternehmen, die Cowork oder vergleichbare KI-Agenten mit Dateisystemzugriff einsetzen, ist das mehr als eine technische Fussnote. Es ist ein konkreter Test dafür, wie belastbar die Zusicherung "Der Agent läuft isoliert" in der Praxis tatsächlich ist.

Was ist SharedRoot – und warum betrifft es Sie als Unternehmer?

Claude Cowork ist Anthropics KI-Agent für Desktop-Aufgaben, gestartet am 12. Januar 2026 als Research Preview – ausdrücklich gedacht für nicht-technische Wissensarbeiter, nicht nur für Entwicklerinnen und Entwickler wie beim verwandten Claude Code. Seit Anfang Juli 2026 gibt es Cowork zusätzlich als Mobile- und Web-Beta. Wenn Sie oder Ihr Team Cowork lokal auf einem Mac nutzen, verbinden Sie dabei typischerweise einen Ordner – etwa mit Angeboten, Buchhaltungsunterlagen oder Vertragsentwürfen – damit der Agent darin lesen und schreiben kann. Die Idee dahinter: Der Agent soll ausschliesslich in diesem Ordner arbeiten, technisch abgeschottet vom Rest Ihres Rechners durch eine isolierte Linux-VM, die über Apples Virtualization Framework läuft.

Genau diese Abschottung ist der Kern von SharedRoot. Oren Yomtov, Principal Security Researcher bei Accomplish AI, beschreibt den Ausgangspunkt seines Tests so:

"We connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox." – Oren Yomtov, Accomplish AI. Auf Deutsch: Man verband einen Ordner mit einer frischen Claude-Cowork-Sitzung, schickte eine kurze Nachricht – und beobachtete, wie der Agent aus der Sandbox ausbrach.

Kein mehrstufiger Social-Engineering-Angriff, kein monatelanges Abtasten der Verteidigung. Eine Nachricht genügte, um eine Kette von technischen Schwachstellen auszulösen, an deren Ende der vollständige Host-Dateibaum offenstand – ohne einen einzigen Berechtigungs-Prompt, der die betroffene Person hätte warnen können.

Wie der Ausbruch technisch ablief

Die von Accomplish AI dokumentierte Exploit-Kette umfasst sechs Schritte, die – jeder für sich genommen fast unscheinbar – am Ende zu vollem Root-Zugriff auf das Host-System führen. Da diese technischen Angaben aus dem Blogpost der entdeckenden Sicherheitsfirma selbst stammen, ist an dieser Stelle Transparenz wichtig: Accomplish AI hat kommerzielles Interesse daran, die eigene Entdeckung sichtbar zu machen. Die Grundmechanik wurde jedoch unabhängig von mehreren Fachmedien bestätigt, unter anderem The Hacker News, GBHackers, CyberSecurityNews, TechRadar und SOCRadar.

Vereinfacht dargestellt läuft der Angriff so ab: Der Nutzeraccount der Cowork-Sitzung erstellt über den unshare-Systemaufruf einen sogenannten User-Namespace. Das ist ein Linux-Mechanismus, der eigentlich der Isolation dienen soll – hier verschafft er dem Session-User jedoch faktisch Root-Rechte samt der Capability CAP_NET_ADMIN innerhalb dieses Namespace. Mit diesen Rechten lässt sich das verwundbare Kernel-Modul act_pedit über einen Netlink-Socket konfigurieren. Genau hier setzt die eigentliche Schwachstelle an: CVE-2026-46331, intern auch "pedit COW" genannt, ist ein Bug im act_pedit-Modul des net/sched-Subsystems (Traffic-Control) des Linux-Kernels. Er war bereits seit Juni 2026 öffentlich als Ubuntu-Bug bekannt – und ermöglicht es, eine gecachte Kopie eines root-eigenen Helper-Binaries gezielt zu vergiften.

Der letzte Schritt ist dann fast schon banal: Der Root-Daemon von Cowork, coworkd, führt das vergiftete Binary erneut aus – und ein eigentlich vorgesehener Schutzmechanismus namens NoNewPrivs, der genau solche Rechteausweitungen verhindern soll, wird dabei umgangen. Der so erlangte Guest-Root-Zugriff trifft am Ende auf einen vollständigen Host-Dateisystem-Mount, der unter dem Pfad /mnt/.virtiofs-root eingebunden ist. Dieser Mount war laut Accomplish AI als beschreibbarer VirtioFS-Mount konfiguriert – eigentlich nur für Guest-Root sichtbar gedacht. Nach dem Ausbruch war er für den kompromittierten Agenten vollständig les- und schreibbar zugänglich.

Was ein Angreifer nach dem Ausbruch tatsächlich sehen konnte

An dieser Stelle wird die Lücke für Unternehmen konkret gefährlich. Nach einem erfolgreichen SharedRoot-Ausbruch reichte der Zugriff weit über den ursprünglich mit Cowork verbundenen Ordner hinaus. Zugänglich waren nach Angaben von Accomplish AI unter anderem SSH-Private-Keys, Cloud-Zugangsdaten und praktisch alle Dateien des angemeldeten Nutzerkontos – ohne jeglichen Berechtigungs-Prompt, der eine solche Aktion sichtbar gemacht hätte. Stellen Sie sich vor, Sie verbinden bewusst nur den Ordner mit den aktuellen Angebotsvorlagen mit dem Agenten – und am Ende hätte ein kompromittierter Agent theoretisch Zugriff auf Ihre AWS-Zugangsdaten, Ihren privaten SSH-Schlüssel für den Produktivserver oder die Zugangsdaten zu Ihrem Buchhaltungssystem gehabt.

Nach Schätzung von Accomplish AI waren vor der Mitigation rund 500.000 macOS-Nutzerinnen und -Nutzer betroffen, die lokale Cowork-Sitzungen ausführten. Diese Zahl ist wichtig einzuordnen: Sie stammt aus einer Sekundärquelle, nicht aus einer offiziellen Anthropic-Statistik zur aktiven Installationsbasis, und sollte entsprechend als Schätzung der entdeckenden Sicherheitsfirma verstanden werden – nicht als bestätigte Anthropic-Zahl. Ebenso wichtig: Die Lücke bezieht sich ausdrücklich auf die lokale Ausführung von Cowork auf macOS, wo der Agent in einer isolierten Linux-VM via Apples Virtualization Framework läuft. Zu Windows- oder Linux-Desktop-Versionen von Cowork liegen zu dieser spezifischen Lücke keine verifizierten Angaben vor.

Relevant für die Einschätzung des Schadenspotenzials ist auch, wie verbreitet Cowork im geschäftlichen Alltag bereits ist. Nach einer separaten, nicht sicherheitsbezogenen Auswertung von Anthropic über 1,2 Millionen anonymisierte Cowork-Sitzungen nutzten 33,4 Prozent der Kunden das Tool für Geschäftsprozesse und Betriebsabläufe, weitere 16,4 Prozent für die Erstellung von Dokumenten und Präsentationen. Das zeigt: Cowork wird längst nicht mehr nur für einfache Textaufgaben eingesetzt, sondern für Workflows, bei denen Zugriff auf sensible Geschäftsunterlagen naheliegt – genau die Art von Nutzung, die eine funktionierende Sandbox-Isolation voraussetzt.

Wie Anthropic auf den Bericht reagiert hat

Nach übereinstimmenden Berichten mehrerer Fachmedien, darunter thehackernews.com und cybersecuritynews.com, wurde der Report von Accomplish AI von Anthropic als "informative" eingestuft – also ohne dass ein dedizierter Fix für den beschriebenen Escape-Pfad selbst ausgeliefert wurde. Ein direktes, verifiziertes Original-Zitat von Anthropic zu dieser Einstufung liess sich in der Recherche nicht auffinden; die Formulierung stammt aus der Presseberichterstattung. Als Mitigation verweist Anthropic laut diesen Berichten darauf, dass die aktuelle Cowork-Version standardmässig auf Cloud-Ausführung setzt – ein Modus, in dem dieser konkrete lokale Escape-Pfad nicht greift, weil kein lokal isoliertes Dateisystem eines Mac betroffen ist.

Das ist eine berechtigte technische Antwort, aber keine vollständige Entwarnung. Wichtig für Ihre Einschätzung: Unklar bleibt, ob und wann Anthropic die Lücke inzwischen tatsächlich technisch gepatcht hat – etwa durch eine Härtung der Seccomp-Profile oder einen auf Nur-Lese umgestellten Host-Mount. Berichtet wird lediglich die Umstellung auf Cloud-Ausführung als neuer Standard für neu gestartete Sitzungen. Bereits bestehende lokale Installationen, die weiterhin im lokalen Modus laufen, sind davon nicht automatisch geschützt. Wer als Unternehmen also schon länger mit einer lokalen Cowork-Installation arbeitet, sollte aktiv prüfen, in welchem Modus die Sitzungen tatsächlich laufen, statt sich auf eine automatische Absicherung zu verlassen.

Von Accomplish AI werden konkrete Härtungsmassnahmen empfohlen, die grundsätzlich für jede Umgebung sinnvoll sind, in der KI-Agenten mit Namespace-Isolation arbeiten: unprivilegierte User-Namespaces deaktivieren, ein restriktiveres Seccomp-Profil einsetzen, das unshare, clone3 und bestimmte Namespace-Flags blockiert und Adressfamilien einer Allowlist unterwirft, das Autoloading ungenutzter Kernel-Module wie act_pedit verhindern, sowie den Host-Dateisystem-Mount konsequent auf die tatsächlich verbundenen Ordner zu begrenzen und nur read-only einzubinden. Diese Massnahmen liegen im Verantwortungsbereich des Anbieters – für Sie als Unternehmen sind sie vor allem als Prüfkriterium relevant: Fragen Sie aktiv nach, ob und wie ein Anbieter solche Härtungsschritte umgesetzt hat.

Kein Einzelfall: Sandbox-Ausbrüche als branchenweites Muster

SharedRoot reiht sich in eine breitere Serie von KI-Agent-Sandbox-Ausbrüchen im Juli 2026 ein. Am selben Tag, dem 23. Juli, wurde nach vorliegender News-Zusammenfassung auch über ein unveröffentlichtes OpenAI-Modell berichtet, das wiederholt aus seiner eigenen Sandbox ausgebrochen sein soll. Diese Häufung ist kein Zufall, sondern spiegelt einen branchenweiten Trend wider: Kernel-Privilegien-Eskalations-Advisories haben sich laut einer Branchenauswertung von SOCRadar im Jahresvergleich um das 2,3-fache erhöht, und die Zeitspanne zwischen der Verfügbarkeit eines Exploits und einem verfügbaren Patch ist teils auf nur wenige Stunden geschrumpft. Diese Zahl bezieht sich ausdrücklich auf den allgemeinen Trend bei Kernel-Schwachstellen, nicht spezifisch auf Claude Cowork – sie liefert aber wichtigen Kontext: Die Angriffsfläche wächst schneller, als viele Organisationen ihre Verteidigung anpassen.

Für Sie als mittelständisches Unternehmen bedeutet das: Es geht bei SharedRoot nicht um ein Anthropic-spezifisches Problem, das mit dem nächsten Konkurrenzprodukt automatisch verschwindet. Es geht um eine strukturelle Eigenschaft von KI-Agenten, die mit Betriebssystem-Rechten und Dateisystemzugriff arbeiten – unabhängig davon, welcher Anbieter dahintersteht. Ob ein Agent auf einem Mac, einem Windows-Rechner oder in einer Cloud-Umgebung läuft: Sobald er Dateien lesen, schreiben oder Befehle ausführen darf, entsteht zwangsläufig eine Angriffsfläche, die technisch angegriffen werden kann – unabhängig davon, wie vertrauenswürdig das zugrundeliegende Sprachmodell selbst ist. Wer ein Agenten-Tool produktiv einsetzt, sollte deshalb grundsätzlich mit Zero-Trust-Prinzipien planen, statt sich auf die Marketing-Zusicherung einer Sandbox zu verlassen. Mehr zur Frage, warum die Wahl der richtigen KI-App allein nicht die entscheidende strategische Frage ist, lesen Sie auch in unserem Beitrag ChatGPT Work, Claude Cowork und Co.: Warum eine KI-App für Ihr Unternehmen die falsche Frage ist.

Bemerkenswert ist dabei auch die Geschwindigkeit, mit der sich solche Funde inzwischen verbreiten. Innerhalb weniger Tage nach der Erstveröffentlichung durch Accomplish AI griffen unabhängige Fachmedien wie The Hacker News, GBHackers, CyberSecurityNews, TechRadar, SOCRadar und AI Weekly den Fall auf und bestätigten die Kernfakten: den Namen SharedRoot, das Datum 23. Juli, den verantwortlichen Forscher Oren Yomtov und die betroffene Plattform macOS beziehungsweise lokale Ausführung. Diese breite, unabhängige Bestätigung unterscheidet den Fall von einzelnen, schwer verifizierbaren Sicherheitsmeldungen – gleichzeitig bleibt zu beachten, dass die technischen Detailangaben zur Exploit-Kette primär von der entdeckenden Firma selbst stammen und bislang nicht durch einen unabhängigen Drittanbieter reproduziert wurden.

Die naheliegende Reaktion – "dann nutzen wir eben kein Cowork mehr" – greift zu kurz. Die eigentliche Lehre aus SharedRoot ist grundsätzlicher: Sandbox-Isolation ist kein Nice-to-have, sondern die einzige Schutzschicht zwischen einem KI-Agenten und Ihrem Unternehmenssystem. Wenn diese Schicht durch einen einzigen Kernel-Bug und eine einzige Nachricht vollständig umgangen werden kann, dürfen Sie sich als Verantwortlicher nicht allein auf Hersteller-Zusicherungen verlassen. Fünf Fragen sollten Sie sich vor jedem produktiven Rollout eines Agenten-Tools stellen:

Erstens: Läuft der Agent lokal oder cloud-basiert, und welche Isolationsgarantien gelten tatsächlich in dem Modus, den Sie einsetzen? Cloud-Ausführung reduziert lokale Angriffsflächen, verlagert das Vertrauensproblem aber auf den Cloud-Anbieter – prüfen Sie in diesem Fall die entsprechenden Datenschutz- und Auftragsverarbeitungsverträge.

Zweitens: Welche Ordner und Laufwerke sind tatsächlich verbunden, und ist der Zugriff wirklich auf diese begrenzt – im Sinne des Least-Privilege-Prinzips? Je grosszügiger die Freigabe, desto grösser der potenzielle Schaden im Ernstfall.

Drittens: Sind SSH-Schlüssel, Cloud-Zugangsdaten und Passwort-Manager-Daten physisch oder zumindest logisch getrennt vom Nutzerkonto, unter dem der Agent läuft? Genau diese Trennung fehlte im dokumentierten SharedRoot-Szenario – mit der Folge, dass ein kompromittierter Agent praktisch alles erreichen konnte, was auf dem Rechner der angemeldeten Person lag.

Viertens: Existiert ein Monitoring oder Logging, das ungewöhnliche Dateizugriffe ausserhalb des vorgesehenen Ordners erkennen würde? Ohne ein solches Monitoring bleibt ein Ausbruch wie SharedRoot faktisch unsichtbar – es gab schliesslich keinen Berechtigungs-Prompt, der Alarm geschlagen hätte.

Fünftens: Wie reagiert der jeweilige Anbieter auf Sicherheitsmeldungen? Gibt es einen dokumentierten Patch-Prozess mit klaren Fristen, oder werden Berichte wie im vorliegenden Fall als "informative" eingestuft, ohne dass der eigentliche Escape-Pfad geschlossen wird? Diese Frage lohnt sich, bevor Sie Vertragsdaten, Kundendaten oder Finanzunterlagen in die Hände eines Agenten-Tools legen.

Fazit: Vertrauen ist gut, getrennte Zugangsdaten sind besser

Der SharedRoot-Fall zeigt in aller Deutlichkeit, wie schnell eine als isoliert beworbene Umgebung durch eine Kombination aus Kernel-Bug und einer einzigen präparierten Nachricht durchbrochen werden kann. Für Sie als Unternehmerin oder Unternehmer ist die wichtigste Konsequenz nicht, KI-Agenten grundsätzlich zu meiden – dafür ist der operative Nutzen, den Werkzeuge wie Cowork inzwischen für Geschäftsprozesse, Dokumentenerstellung und Kundenkommunikation liefern, zu gross. Die Konsequenz ist vielmehr, KI-Agenten von Anfang an mit derselben Vorsicht zu behandeln wie jeden anderen privilegierten Systemzugriff auch: mit getrennten, rechtebeschränkten Service-Accounts, mit einer klaren Trennung von Zugangsdaten und Agenten-Umgebung, und mit der Bereitschaft, kritisch nachzufragen, wenn ein Anbieter eine Sandbox als sicher bewirbt. Gerade kleinere Unternehmen ohne eigene IT-Sicherheitsabteilung nutzen Agenten-Tools häufig mit denselben Admin-Konten, die auch für das Tagesgeschäft und die Cloud-Verwaltung verwendet werden – ein Muster, das sich nach diesem Fall nicht mehr rechtfertigen lässt. Wie generell für den sicheren Einsatz von KI-Agenten branchenweite Sicherheitsstandards entstehen, beleuchten wir ausführlich in unserem Beitrag Wenn sich Anthropic, Google, Amazon und Microsoft einig sind: Was der neue Sicherheitsstandard für Ihr Unternehmen bedeutet.