Eine Nachricht genügt: Der Cowork-Sicherheitsvorfall und Ihre KI-Agenten

Ein Satz reichte. Nicht ein raffinierter Angriff mit monatelanger Vorbereitung, kein Zero-Day, das erst mühsam verkettet werden musste – sondern eine einzige, präparierte Nachricht an einen KI-Agenten mit Zugriff auf einen Projektordner. Genau das haben Sicherheitsforscher von Accomplish AI am 23. Juli 2026 öffentlich gemacht, als sie die Schwachstelle „SharedRoot" in Anthropics Claude Cowork beschrieben. Für Sie als Unternehmerin oder Unternehmer ist das mehr als eine weitere Sicherheitsmeldung aus der Tech-Szene. Es ist ein sehr konkretes Fallbeispiel dafür, was passiert, wenn ein General-Purpose-KI-Agent mit weitreichenden Rechten in Ihrem Unternehmen läuft – und warum die Frage „Ist das eigentlich sicher?" nicht an den Anbieter delegiert werden sollte.

Was bei Claude Cowork passiert ist

Claude Cowork ist ein Anthropic-Produkt, das im Januar 2026 als Research Preview startete: ein „KI-Kollege", dem Nutzerinnen und Nutzer Zugriff auf einen Projektordner geben und der im Hintergrund oder als geplante Aufgabe arbeitet – Dateien liest, bearbeitet, neue Dateien erstellt. Im Juli 2026 wurde das Produkt auf Mobile und Web ausgeweitet, inklusive Cloud-Hintergrundausführung. Die Grundidee ist attraktiv: ein Agent, der eigenständig an Ordnern arbeitet, während Sie sich um anderes kümmern.

Genau in dieser Eigenständigkeit lag das Problem. Der Principal Security Researcher Oren Yomtov von Accomplish AI zeigte, dass eine einzige Nachricht in einer neuen Session mit verbundenem Ordner ausreichte, um aus der Linux-VM-Sandbox von Cowork auszubrechen. Das Ergebnis: Lese- und Schreibzugriff auf das gesamte Host-Dateisystem des Mac-Nutzers – einschließlich SSH-Keys und Cloud-Zugangsdaten. Nach Angaben von Accomplish AI waren vor dem Patch rund 500.000 macOS-Nutzerinnen und -Nutzer mit lokalen Cowork-Sessions potenziell betroffen. Diese Zahl stammt von Accomplish AI selbst und wurde unter anderem von The Hacker News übernommen; eine offizielle Bestätigung durch Anthropic dazu liegt nach aktuellem Kenntnisstand nicht vor.

Wichtig für die Einordnung: Es handelt sich um eine Proof-of-Concept-Demonstration durch Sicherheitsforscher. Es gibt keine öffentlich bestätigte Ausnutzung „in the wild", also keinen bekannten dokumentierten Datenabfluss bei einem konkreten Kunden. Das macht den Vorfall nicht harmloser – es zeigt lediglich, dass wir hier über eine nachgewiesene, aber (soweit bekannt) noch nicht aktiv missbrauchte Lücke sprechen.

Man muss kein Kernel-Entwickler sein, um den Kern des Problems zu verstehen. Der Host-Dateisystem-Mount (/mnt/.virtiofs-root) wurde vollständig lese- und schreibbar in die virtuelle Maschine freigegeben und war für den sogenannten „guest-root"-Nutzer sichtbar. Von dort aus eskalierte der Session-User über den Linux-Befehl unshare in einen eigenen User-Namespace, lud über die Capability CAP_NET_ADMIN das Kernel-Modul act_pedit nach und nutzte eine als CVE-2026-46331 bekannte Schwachstelle („pedit COW") aus – ein Page-Cache-Poisoning-Bug, der ursprünglich im Juni 2026 als öffentlicher Ubuntu-Bug gemeldet worden war. Damit ließ sich eine vom coworkd-Daemon verwendete Binärdatei gezielt „vergiften" und beim erneuten Ausführen Guest-Root-Rechte erlangen.

Bemerkenswert ist dabei die Geschwindigkeit der ganzen Kette: Vom ersten Kontakt mit dem Agenten bis zum vollständigen Ausbruch aus der Sandbox brauchte es laut Beschreibung von Accomplish AI keine mehrstufige Social-Engineering-Kampagne und keine wochenlange Vorbereitung, sondern eine einzige, technisch präparierte Nachricht in einer neu gestarteten Session mit verbundenem Ordner. Genau diese Niedrigschwelligkeit macht den Fall für die breite Öffentlichkeit relevant, nicht nur für Sicherheitsteams: Wer auch immer einen Ordner mit einem Cowork-Agenten verbindet, öffnet potenziell eine Tür, deren Reichweite die meisten Nutzerinnen und Nutzer schlicht nicht einschätzen können.

Accomplish AI ordnet den Fund zudem in einen größeren Trend ein: Kernel-Privilege-Escalation-Advisories seien nach eigenen Angaben des Unternehmens im Jahresvergleich um rund 230 Prozent gestiegen. Diese Zahl stammt direkt vom Sicherheitsforscher selbst und wurde nicht unabhängig verifiziert – sie sollte entsprechend vorsichtig als Kontextangabe und nicht als belastbare Branchenstatistik gelesen werden. Sie passt aber zu einer plausiblen Entwicklung: Je mehr KI-Agenten mit Systemzugriff in produktiven Umgebungen laufen, desto attraktiver werden genau solche Kernel- und Sandbox-Schwachstellen als Angriffsfläche.

Der eigentliche Skandal an SharedRoot ist nicht die einzelne Kernel-Schwachstelle. Es ist die Kombination aus einem komplett offenen Host-Mount und einem Agenten, der eine einzige Nachricht als ausreichende Grundlage nimmt, um im Hintergrund tief in Ihr System einzugreifen.

Für Sie als Entscheiderin oder Entscheider ist der technische Pfad im Detail zweitrangig. Entscheidend ist das Muster: Eine als „isoliert" beworbene Sandbox-Umgebung war durch die Kombination aus einem großzügigen Host-Mount und einer kritischen, aber unabhängigen Kernel-Lücke vollständig umgehbar. Sandbox ist eben kein Sicherheitsversprechen an sich – sie ist nur so stark wie ihre schwächste Konfigurationsentscheidung.

Anthropics Reaktion – und warum sie Sie nicht beruhigen sollte

Nach Berichten wurde der Bericht von Anthropic als „informative" eingestuft, ein dedizierter Fix blieb aus. Die Begründung: Die aktuelle Cowork-Version nutzt standardmäßig die Cloud-Ausführung, bei der der beschriebene lokale VM-Escape-Pfad nicht greift. Lokale Ausführung bleibt den Quellen zufolge weiterhin verwundbar.

Das ist aus Anbietersicht nachvollziehbar – der Standardpfad für neue Nutzerinnen und Nutzer mag heute tatsächlich anders aussehen. Für Sie als Unternehmen bedeutet es aber etwas anderes: Sie können sich nicht darauf verlassen, dass jede gemeldete Lücke in einem von Ihnen genutzten KI-Tool aktiv geschlossen wird, nur weil sie öffentlich bekannt wurde. Wenn ein Anbieter eine Schwachstelle als „informativ" einstuft, weil der Standardpfad sie umgeht, heißt das nicht, dass niemand in Ihrem Unternehmen den betroffenen, verwundbaren Modus noch nutzt. Die Verantwortung, das zu prüfen – lokale versus Cloud-Ausführung, welche Ordner und Zugangsdaten ein Agent überhaupt sehen kann –, bleibt bei Ihrer Geschäftsführung und IT, nicht beim Werbetext des Anbieters.

Accomplish AI hat vier konkrete Mitigationen genannt, die technisch orientierte Leserinnen und Leser interessieren dürften: unprivilegierte User-Namespaces deaktivieren, restriktivere Seccomp-Filter setzen, die unshare, clone3 und Namespace-Flags blockieren sowie AF_NETLINK einschränken, das automatische Nachladen ungenutzter Kernel-Module unterbinden, und Host-Mounts auf tatsächlich verbundene Ordner begrenzen beziehungsweise read-only mounten. Wenn Sie mehr über den regulatorischen Rahmen rund um KI-Sicherheit wissen möchten, lesen Sie auch unseren Beitrag zu dem gemeinsamen Sicherheitsstandard von Anthropic, Google, Amazon und Microsoft.

Die Governance-Lücke: Zahlen, die zu denken geben

Der SharedRoot-Vorfall ist kein Einzelfall in einem Vakuum. Er trifft auf eine Unternehmenslandschaft, die auf breiter Front noch nicht darauf vorbereitet ist, KI-Agenten mit weitreichenden Rechten sicher zu betreiben. Laut der Darktrace-Studie „State of AI Cybersecurity 2026", ausgewertet unter anderem von Kiteworks, sind 92 Prozent der Sicherheitsfachleute wegen der Auswirkungen von KI-Agenten auf die Unternehmenssicherheit besorgt. 63 Prozent können keine Zweckbindung für KI-Agenten durchsetzen – die Agenten tun also potenziell mehr, als sie eigentlich sollen. 60 Prozent geben an, einen fehlverhaltenden Agenten im Ernstfall nicht stoppen zu können. Und nur 37 Prozent der Organisationen verfügen überhaupt über eine formale KI-Richtlinie.

Für den deutschen Mittelstand ist die Lage nach einer Auswertung des Fachmagazins CoKom nicht grundlegend besser: Aktuell hat nur gut die Hälfte der Unternehmen in Deutschland überhaupt KI-Richtlinien. Das ist besonders für Mittelständler ohne dedizierte IT-Governance-Abteilung ein Risiko – denn genau dort werden KI-Tools oft pragmatisch eingeführt, mit vollem Systemzugriff, weil „es schnell gehen musste" und niemand explizit die Frage gestellt hat, welche Rechte der Agent eigentlich braucht.

Diese Zahlen sind kein abstrakter Kontext. Sie erklären, warum ein Vorfall wie SharedRoot überhaupt in dieser Größenordnung passieren konnte: Wenn kaum jemand Zweckbindung durchsetzt und kaum jemand einen Agenten im Zweifel stoppen kann, ist die Wahrscheinlichkeit hoch, dass ein KI-Tool mit deutlich mehr Zugriff läuft, als für die eigentliche Aufgabe nötig wäre.

Der Fall wurde inzwischen nicht nur von Accomplish AI selbst, sondern auch von mehreren unabhängigen Fachmedien aufgegriffen und in ihren Kernpunkten – Name SharedRoot, die zugrunde liegende CVE-2026-46331, die betroffene Nutzerzahl sowie Anthropics Einordnung als „informativ" – bestätigt, darunter The Hacker News, GBHackers, Cybersecurity News, SOCRadar, SC Media und AI Weekly. Das ist insofern relevant, als es sich hier nicht um eine isolierte Einzelmeinung handelt, sondern um einen Vorfall, der branchenweit als ernstzunehmend eingestuft wird – auch wenn Anthropic selbst keinen dedizierten Patch für den lokalen Modus veröffentlicht hat. Für Sie als Leserin oder Leser bedeutet diese Bestätigung durch mehrere Quellen: Die Faktenlage ist robust genug, um daraus konkrete Konsequenzen für die eigene IT-Sicherheitspraxis abzuleiten, statt auf Entwarnung durch den Anbieter zu warten.

Das eigentliche Muster: Breiter Zugriff ist das Risiko, nicht nur der einzelne Bug

Es wäre zu kurz gedacht, SharedRoot nur als „ein gepatchter Kernel-Bug" abzuhaken. Die eigentliche Lehre liegt woanders: Ein General-Purpose-Agent, dem Sie pauschal Zugriff auf einen gesamten Projektordner oder gar ein Dateisystem geben, ist strukturell riskanter als ein eng zugeschnittener, zweckgebundener Agent mit minimalen Rechten. Das Least-Privilege-Prinzip – einem System nur genau die Rechte zu geben, die es für seine konkrete Aufgabe braucht – ist in der klassischen IT-Sicherheit seit Jahrzehnten Standard. Bei der Einführung von KI-Agenten wird es in der Praxis jedoch häufig übersprungen, weil „einfach draufloslegen" schneller wirkt als „vorher genau definieren, was der Agent darf".

Genau hier liegt auch der Unterschied zwischen einer generischen KI-App, die Sie sich herunterladen und mit weitreichenden Rechten ausstatten, und einem für Ihr Unternehmen maßgeschneiderten Agenten, der von vornherein nur mit den Systemen und Daten arbeitet, die für seine Aufgabe nötig sind. Wenn Sie sich schon einmal gefragt haben, warum wir bei Amazing Agents grundsätzlich für zweckgebundene, eng definierte Agenten statt für die pauschale Einführung einer generischen KI-App plädieren, ist der SharedRoot-Vorfall ein sehr konkretes Argument dafür. Mehr zu dieser Frage finden Sie auch in unserem Beitrag „ChatGPT Work, Claude Cowork und Co.: Warum eine KI-App für Ihr Unternehmen die falsche Frage ist".

Das heißt nicht, dass Tools wie Claude Cowork per se ungeeignet sind. Anthropic hat auf den Bericht reagiert, die Cloud-Ausführung als Standardpfad etabliert und damit den konkret demonstrierten lokalen Angriffspfad entschärft. Es heißt aber, dass die Verantwortung für die Konfiguration – welcher Modus läuft, welche Rechte ein Agent hat, welche Daten er sehen kann – nicht beim Anbieter allein liegen darf, sondern aktiv von Ihnen als Unternehmen gesteuert werden muss.

Was Sie jetzt konkret tun sollten

Aus dem SharedRoot-Vorfall und den begleitenden Governance-Zahlen lässt sich eine direkt umsetzbare Checkliste ableiten:

• Zugriffsrechte definieren, bevor der Agent läuft. Klären Sie für jeden KI-Agenten in Ihrem Unternehmen konkret: Welche Ordner, welche Systeme, welche Zugangsdaten darf er sehen – und welche ausdrücklich nicht?
• Kernsysteme isolieren. SSH-Keys, Cloud-Zugangsdaten und Zugänge zu kritischer Infrastruktur gehören nicht in denselben Ordner oder dieselbe Umgebung wie ein KI-Agent mit breitem Aufgabenspektrum.
• Cloud- statt Lokalausführung bevorzugen, wo verfügbar. Der SharedRoot-Angriffspfad setzte konkret an einer lokalen VM-Sandbox an. Prüfen Sie bei jedem eingesetzten KI-Tool, welcher Ausführungsmodus tatsächlich aktiv ist – Standardeinstellungen sind nicht immer die sichersten.
• Eigene, zweckgebundene Agenten statt General-Purpose-Tools für Aufgaben mit sensiblen Daten oder Systemzugriffen einsetzen. Ein Agent, der ausschließlich eine definierte Aufgabe erledigt, hat schlicht weniger Angriffsfläche als ein Alleskönner mit vollem Dateisystemzugriff.
• Eine formale KI-Richtlinie erstellen, falls noch nicht geschehen – angesichts von nur 37 Prozent der Organisationen mit einer solchen Richtlinie und gut der Hälfte der deutschen Unternehmen ohne KI-Richtlinien ist dies für viele Mittelständler der naheliegendste erste Schritt.
• Regelmäßig prüfen, ob Sie einen Agenten im Zweifel stoppen können. Wenn 60 Prozent der Sicherheitsfachleute das laut Darktrace/Kiteworks-Auswertung nicht können, lohnt sich die Frage, ob genau dieser Notfallmechanismus in Ihrem Unternehmen tatsächlich existiert und getestet wurde.

Diese Punkte sind keine Raketenwissenschaft. Sie erfordern aber, dass jemand in Ihrem Unternehmen sie tatsächlich durchgeht – und das passiert erfahrungsgemäß eher, wenn ein konkreter Vorfall wie SharedRoot als Anlass dient, als wenn man auf den „richtigen Zeitpunkt" wartet. Wenn Sie sich außerdem fragen, wie sich das Ganze zur kommenden EU-Regulierung verhält, lohnt sich ein Blick in unseren Beitrag zum EU AI Act für den Mittelstand – Sicherheitsanforderungen und regulatorische Pflichten laufen hier zunehmend parallel.

Fazit: Sandbox ist kein Sicherheitsversprechen, Vertrauen ist kein Freifahrtschein

Der SharedRoot-Vorfall bei Claude Cowork zeigt in aller Deutlichkeit, wie schnell aus einer komfortablen Automatisierung ein ernsthaftes Sicherheitsrisiko werden kann, wenn ein KI-Agent zu weitreichende Rechte bekommt. Eine einzige Nachricht genügte für einen vollständigen Ausbruch aus einer als isoliert beworbenen Umgebung, bis hin zu Lese- und Schreibzugriff auf SSH-Keys und Cloud-Zugangsdaten. Weder die Reputation des Anbieters noch das Etikett „Sandbox" waren dabei eine tatsächliche Garantie.

Für Ihr Unternehmen bedeutet das: Prüfen Sie nicht nur, welche KI-Tools Sie einsetzen, sondern vor allem, mit welchen Rechten sie das tun. Ein sorgfältig konzipierter, zweckgebundener Agent mit minimalem Zugriff ist nicht nur aus Effizienzgründen oft die bessere Wahl – er ist es auch aus Sicherheitsgründen. Genau das ist der Ansatz, den wir bei Amazing Agents verfolgen: Agenten, die exakt das tun, wofür sie gebaut wurden, mit genau den Rechten, die dafür nötig sind. Nicht mehr.