Im Zentrum des Fehlers stand nach Angaben von Sand Security die Live-Vorschaufunktion von Writer, mit der sich Anwendungen über das Writer Framework vorab anzeigen lassen. Genau diese Funktion habe die Mandantentrennung unterlaufen und damit das Modell geteilter Verantwortung geschwächt, weil Schutzmechanismen zur Isolation zwischen verschiedenen Kundeninstanzen nicht mehr griffen.
Sand Security beschreibt den Angriff als Ein-Klick-Schwachstelle. Demnach konnte ein Angreifer einen präparierten Agenten im eigenen Writer-Konto anlegen und dessen Vorschau per Link weitergeben. Klickte ein Opfer auf diesen Link, während es mit seiner eigenen Sitzung bei Writer angemeldet war, ließ sich dessen Konto kapern. Laut den Forschern war dafür kein vorheriger Zugriff auf die Zielumgebung nötig.
Die technische Ursache lag dem Bericht zufolge darin, dass der bösartige Agent Code innerhalb der von Writer verwalteten Sandbox ausführen konnte. Dadurch sei es möglich gewesen, den Speicher des Sandbox-Prozesses auszulesen, das Sitzungstoken des Opfers wiederherzustellen und an einen vom Angreifer kontrollierten Server zu übermitteln. Sand Security formuliert es so: Ein Angreifer könne die von Writer verwaltete KI-Sandbox missbrauchen, um Sitzungen vollständig getrennter Unternehmen einzusammeln und darin wie ein echter Nutzer zu handeln.
Die möglichen Folgen gingen laut Sand Security über den Zugriff auf einzelne Inhalte hinaus. Mit einer übernommenen Writer-Sitzung konnten Angreifer auf private Chats, Dokumente und weitere sensible Daten zugreifen, darunter Informationen zu Agenten, Konfigurationen, privaten Modellen, Konnektoren und Zugangsdaten für große Sprachmodelle. War das Opfer entsprechend berechtigt, konnte die Lücke auch zur Übernahme administrativer Kontrolle missbraucht werden.
Writer hat den Fehler nach verantwortungsvoller Offenlegung behoben. Nach Angaben im Bericht unterbindet die Plattform nun vollständig, dass die Sitzungs-Cookies von Nutzern an Sandbox-Vorschauen weitergereicht werden. Zudem wurden diese Vorschauen auf eine isolierte Herkunft verschoben.
Sand Security betont, dass durchaus Schutzmechanismen vorhanden gewesen seien. Demnach sollte eine Filterung auf Eingabeseite verhindern, dass Nutzer Umgebungsvariablen auslesen oder offensichtlich schädlichen Code einreichen. Das Problem habe jedoch darin gelegen, worauf diese Prüfungen schauten: auf die Anweisung, nicht auf das Laufzeitverhalten.
Die Umgehung dieser Schutzplanken sei laut den Forschern vergleichsweise einfach gewesen. Statt den Schadcode direkt in die Eingabe zu schreiben, habe das Team den Agenten lediglich angewiesen, ein entferntes Skript herunterzuladen und auszuführen. Für die Schutzprüfung habe das wie eine harmlose Aufforderung zum Herunterladen und Ausführen ausgesehen, während die eigentliche Ausnutzungslogik überhaupt nicht in der Eingabe erschien.