Copilot-AI-Wurm, der sich über Word-Dokumente selbst verbreitet

• In externen Word-Dokumenten versteckte Cross-Domain Prompt Injection (XPIA) kann die Schreib- und Bearbeitungsergebnisse von Copilot manipulieren und sich in neue Dokumente kopieren, sodass sie sich ohne das ursprüngliche Angriffsdokument entlang gewöhnlicher Arbeitsabläufe verbreiten kann.
• Selbst in weißer, kleiner Schrift verborgene Anweisungen liest Copilot, nachdem die Formatierung entfernt wurde; im Experiment wurden Finanzzahlen verändert und der vollständige Angriffs-Prompt am Ende des Ergebnisdokuments versteckt, um ein neues Angriffsmittel zu schaffen.
• Der Angreifer benötigt keinen Zugriff auf den Microsoft-365-Mandanten des Opfers; es genügt, das Dokument über SharePoint, Teams oder Outlook zu teilen und den Nutzer dazu zu bringen, es anzuhängen, oder dafür zu sorgen, dass Work IQ es als relevantes Material aus OneDrive auswählt.
• Microsoft hat zwar Sperren für bestimmte Payloads und Modell-Upgrades bereitgestellt, doch mit abgewandelten Prompts ließ sich die vollständige Angriffskette auch unter GPT-5.6 reproduzieren, und selbst nach 144 Tagen koordinierter Offenlegung wurde nicht der gesamte Schwachstellentyp blockiert.
• Infizierte Dokumente zirkulieren wie normale interne oder Partnerunterlagen, was Ursprungsermittlung und Erkennung erschwert; daher sollten externe Dokumente und Copilot-Ergebnisse geprüft sowie Originalquelle und Modell-Bearbeitungshistorie als Metadaten aufbewahrt werden.

---

Funktionsweise eines dokumentbasierten AI-Wurms

• Wenn von einem Angreifer kontrollierte Anweisungen aus einem Dokument in die von Copilot erzeugten oder bearbeiteten Ergebnisse kopiert werden, wird das Ergebnisdokument zu einem neuen Träger, der denselben Angriff transportiert.
  • Wird dieses Dokument als Material für andere Copilot-Aufgaben verwendet, werden die Anweisungen erneut ausgeführt und in weitere Dokumente kopiert.
  • Die Verbreitung kann auch ohne das ursprüngliche bösartige Dokument oder weiteres Eingreifen des Angreifers fortgesetzt werden.
• Das frühere Morris II demonstrierte selbstreplizierende Prompts im Ökosystem generativer AI-E-Mail-Assistenten.
• Der vorliegende Fall ist eine öffentliche Demonstration eines sich selbst verbreitenden dokumentbasierten AI-Wurms in normalen Dokument-Workflows eines gängigen kommerziellen Produktivitätsprodukts.

Angriff über normale Dokumentarbeit

• Ein Mitarbeiter lädt von einer kompromittierten vertrauenswürdigen Website ein Marktforschungsdokument mit versteckten Anweisungen herunter und verwendet es als Material für die Erstellung eines Finanzberichts mit Copilot.
  • Copilot verändert interne Finanzzahlen und kopiert die Angriffsanweisungen in einen neuen Bericht.
  • Der Mitarbeiter speichert den normal wirkenden Bericht und teilt ihn intern.
  • Verwendet ein Kollege diesen Bericht als Material für den nächsten Bericht, werden Zahlenmanipulation und Anweisungskopie erneut ausgeführt.
• Je häufiger der Bericht wiederverwendet wird, desto mehr Dokumente werden zu Angriffsträgern; die infizierte Website und das erste bösartige Dokument werden dann nicht mehr benötigt.

Bedrohungsmodell und Vertrauensgrenzen

• Der Angreifer muss nur ein bösartiges Dokument teilen, ohne Zugriffsrechte auf den Microsoft-365-Mandanten des Opfers.
  • Zu den Übertragungswegen gehören SharePoint, Teams, Outlook und andere Mittel zum Teilen von Dokumenten.
• Die zentrale Sicherheitsgrenze liegt zwischen angehängtem Material und dem aktuell bearbeiteten Dokument.
  • Copilot muss alle angehängten Dokumente lesen, um die zu verwendenden Informationen auszuwählen.
  • Informationen aus angehängten Dokumenten dürfen genutzt werden, ihre darin enthaltenen Anweisungen dürfen jedoch nicht als autoritative Nutzervorgaben behandelt werden.
• In der Praxis verändern in Dokumente eingefügte Anweisungen das Verhalten von Copilot.
  • Zahlen in Finanzberichten werden geändert, ohne den Nutzer darüber zu informieren.
  • Die vollständige XPIA wird in Folgedokumente eingefügt, damit sie auch bei späteren Aufgaben erneut ausgeführt wird.

Wie in Word die Vertrauensgrenze überschritten wird

• Das erste bösartige Dokument enthält einen Prompt im JSON-Format, der durch weiße Schrift auf weißem Hintergrund und kleine Schriftgröße vor dem Nutzer verborgen werden kann.
• Copilot for Word entfernt vor der Weitergabe des Texts an das zugrunde liegende LLM Formatierungen wie Farbe und Schriftgröße, sodass auch für den Nutzer unsichtbare Inhalte vom Modell vollständig gelesen werden.
• Die Tarnung lässt sich noch verbessern, wenn die Angriffsanweisungen in ein ansonsten normal wirkendes, aufgabenrelevantes Dokument eingebettet werden.
• Damit das bösartige Dokument in Copilots Kontext aufgenommen wird, ist eines der folgenden Szenarien nötig.
  1. Der Nutzer hängt das Dokument direkt in Copilot for Word an oder lädt es hoch.
  2. Der Nutzer verwendet den work-/Work-IQ-Modus von Edit with Copilot, und Copilot stuft das Dokument in OneDrive als relevantes Material ein und wählt es aus.
• Der Angreifer muss den Inhalt so gestalten, dass die Wahrscheinlichkeit steigt, dass das Dokument direkt ausgewählt oder in Suchergebnissen enthalten ist.
• Diese Schwachstelle betrifft sowohl den magic pen in Word als auch Edit with Copilot.

Phase 1: Dokumentmanipulation und erste Replikation

• Der erste Proof of Concept (PoC) verwendete ein Dokument, das nur einen bösartigen Prompt in weißer Schrift enthielt, und bestätigte, dass der Angriff ausgeführt werden kann, sobald das Material in den Kontext gelangt, selbst wenn es für die Aufgabe nicht relevant ist.
• Der PoC-Prompt bestand aus zwei Teilen.
  • Der erste Teil manipulierte das Zieldokument, indem er die Bedeutung einer Zusammenfassung subtil veränderte oder Zahlen in Finanzdokumenten änderte.
    • Entscheidend war, Copilot glauben zu lassen, dies sei eine legitime, aufgabenbezogene Anforderung.
    • Während der Experimente mussten sogar separate Anweisungen hinzugefügt werden, die geänderten Stellen hervorzuheben, da inhaltlich sinnvolle Änderungen visuell schwer zu erkennen waren.
    • In einem realen Angriff würde keine Kennzeichnung der Änderungen verlangt; das veröffentlichte Beispiel nutzt stattdessen sofort leicht prüfbare Änderungen an Finanzzahlen.
  • Der zweite Teil wies an, den Angriffs-Prompt in das Ergebnisdokument zu kopieren.
    • Dies wurde als Maßnahme zur Nachverfolgung der Herkunft von Folgedokumenten getarnt, und aus Gründen der Lesbarkeit wurde zugleich die eigene Tarnmethode angewiesen.
• Als der Angriff in weißer Schrift am Ende eines Marktforschungsdokuments der fiktiven Firma Tfosorcim Ltd. eingefügt wurde, halbierte Copilot alle Zahlen im Q1-Finanzbericht.
• Anschließend kopierte es den vollständigen bösartigen Prompt in weißer 8-Punkt-Schrift an das Ende des Ergebnisdokuments, ohne den Nutzer darüber zu informieren, dass Zahlen verändert und ein Prompt eingefügt wurden.
• Selbst wenn der Nutzer das bösartige Dokument nicht direkt anhängte und nur die Erstellung des Tfosorcim-Q1-Berichts verlangte, suchte Copilot in OneDrive, fand das bösartige Marktforschungsdokument in einem anderen Ordner, und der Angriff war erfolgreich.
• In diesem PoC wurde das damals neueste Modell GPT-5.6 verwendet.

Phase 2: Selbstverbreitung in Folgedokumente

• Da der infizierte Q1-Bericht selbst zu einem neuen Angriffsträger wird, wird das erste bösartige Dokument in späteren Erstellungssitzungen nicht mehr benötigt.
• Wurde der Q1-Bericht angehängt, um einen Q2-Bericht zu erstellen, halbierte Copilot erneut alle Finanzzahlen und kopierte den vollständigen Prompt in weißer Schrift.
• Der neue Träger ist ein mit legitimen internen Ressourcen erzeugtes Dokument und erhält daher das Vertrauen, das internen Dokumenten entgegengebracht wird.
  • Teilt das Opfer das Dokument mit Kollegen und verwendet es selbst oder verwendet es ein Kollege als Material für Copilot-Schreib- oder Bearbeitungsaufgaben, verbreitet sich der Angriff in neue Dokumente.
• In allen gemeldeten PoCs veränderte Copilot die Dokumente und kopierte die versteckten Anweisungen; gelangte ein infiziertes Dokument in einen späteren Kontext, wurde der Angriff auch ohne Original erneut ausgeführt.

Auswirkungen auf Organisationen und kollaborative Umgebungen

• Nach dem ersten Eindringen wirken infizierte Dokumente wie normal intern erzeugte Unterlagen, und es werden keine genehmigten Copilot-Bearbeitungsspuren angezeigt, was die Angriffsverfolgung sehr erschwert.
• Breitet sich dies still über normale Dokumentarbeit aus, kann die Vertrauenswürdigkeit der Informationsgrundlage beschädigt werden, auf der organisatorische Entscheidungen beruhen.
• Eine Organisation, die die Infektion nicht bemerkt, kann Dokumente über gemeinsam genutzte SharePoint-Seiten oder Teams-Kollaboration an andere Organisationen weitergeben.
  • Das erste Angriffsdokument einer bestimmten Organisation kann bereits von einem kompromittierten vertrauenswürdigen Partner stammen.
  • Wegen des Vertrauens in Partnerdokumente steigt zudem die Wahrscheinlichkeit, dass Nutzer sie in den Copilot-Kontext aufnehmen.
• Wenn Copilot tiefer in Systeme integriert wird, die Dokumente, Tools und Kollaborationsabläufe automatisch erzeugen und manipulieren, wie Microsoft Cowork oder Microsoft Scout, kann derselbe Mechanismus eine breitere Oberfläche mit Maschinengeschwindigkeit beeinflussen.

Microsofts Gegenmaßnahmen und verbleibende Schwachstellen

• Microsoft blockierte den ursprünglich eingereichten PoC-Prompt und stellte während der koordinierten Offenlegung mehrere Korrekturen bereit.
  • Die konkret gemeldete Payload wurde blockiert, sodass für spätere Reproduktionen keine ursprüngliche Formulierung, sondern eine abgewandelte Payload nötig war.
  • Die in Teil 1 und 2 der Serie behandelten Angriffswege über Speicher und E-Mail-Textkörper wurden entschärft.
• Der Schwachstellentyp, bei dem Anweisungen aus dem Quelldokument die Copilot-Ausgabe verändern und sich in Folgedokumente kopieren, besteht jedoch weiter.
  • Auch wenn Aufgabe oder Formulierung geändert werden, ändern sich die grundlegende Schwachstelle und der Verbreitungsmechanismus nicht.
  • Selbst bei Anwendung aller bereitgestellten Gegenmaßnahmen ließ sich die vollständige Angriffskette mit einer modifizierten Payload reproduzieren.
• Das Problem ist eine strukturelle Schwäche heutiger LLM-basierter Systeme; es wurde keine Methode bestätigt, die diesen Typ in vergleichbaren Produkten vollständig verhindert.
• Es handelt sich eher um ein Problem für weitere Forschung als für einen einzelnen Patch, doch Microsofts Korrekturen haben die Exposition praktisch verringert.

Offenlegungsstatus und Reaktion der Nutzer

• Mit MSRC und dem Microsoft-Produktteam wurde die Veröffentlichung koordiniert; übermittelt wurden Reproduktionsschritte, Videos, Umgebungsannahmen und der genaue PoC-Prompt.
• Der ursprüngliche 90-Tage-Zeitraum der koordinierten Offenlegung wurde zweimal verlängert, sodass insgesamt 144 Tage für die Reaktion blieben, doch auch zum Veröffentlichungszeitpunkt ließ sich der Angriff reproduzieren.
• Zwei Gegenmaßnahmen, darunter Modell-Upgrades, verhinderten den gesamten Schwachstellentyp nicht; deshalb erfolgte die Offenlegung auf Ebene des Angriffstyps und Verbreitungsmechanismus statt mit konkreter Payload.
• Zum Zeitpunkt der Veröffentlichung gab es auf Kundenseite keine vollständige Abhilfe; folgende Maßnahmen können die Exposition verringern.
  1. Externe Quelldokumente, die mit Copilot verwendet werden, als nicht vertrauenswürdiges Material behandeln.
  2. Angehängte Dokumente prüfen, bevor mit der Copilot-Erstellung oder -Bearbeitung begonnen wird.
  3. Von Copilot erzeugte oder bearbeitete Dokumente sorgfältig prüfen, bevor sie wiederverwendet, geteilt oder verteilt werden.

Zeitplan der koordinierten Offenlegung

• 6. März 2026: Erster Bericht mit Reproduktionsschritten, Video, Umgebungsannahmen und PoC-Prompt an MSRC übermittelt.
• 9. März: MSRC bestätigte den Eingang und eröffnete den Fall.
• 31. März: Microsoft bestätigte das Verhalten, und das Produktteam begann mit Gegenmaßnahmen.
• 3. April: Erste Gegenmaßnahme über die neue Edit with Copilot-Erfahrung bereitgestellt.
• 9. April: Die Sperrung des bisherigen Angriffs-Prompts wurde bestätigt, doch der Angriff ließ sich mit einer neuen XPIA-Aufgabe zur Manipulation von Finanzzahlen reproduzieren und wurde als separater Fall gemeldet.
• 10. April: MSRC nahm den neuen Fall auf, und das Produktteam begann mit Gegenmaßnahmen.
• 8. Juni: Auf Microsofts Bitte wurde die Veröffentlichung auf den 15. Juli verschoben.
• 14. Juli: Zweite Gegenmaßnahme mit Upgrade des Basismodells auf GPT-5.5 bereitgestellt.
• 15. Juli: Reproduktion des Angriffs einschließlich Wurmverbreitung auf dem damals neuesten Modell GPT-5.6 erfolgreich.
  • Um Zeit für weitere Gegenmaßnahmen zu schaffen, wurde die Veröffentlichung erneut auf den 28. Juli verschoben, dem Microsoft zustimmte.
• 28. Juli: Koordinierte Veröffentlichung, obwohl sich der Angriff weiterhin reproduzieren ließ.

Informationsintegrität und Herkunftsnachverfolgung

• Mit der Einbindung von LLMs in Geschäftsabläufe wird Informationsintegrität zu einem zentralen Sicherheitsproblem.
• Von Angreifern kontrollierte Inhalte können nicht nur einzelne Ausgaben manipulieren oder Datenabfluss auslösen, sondern sich auch entlang normaler Nutzeraufgaben replizieren und selbst verbreiten.
• In generierten Inhalten enthaltene bösartige Anweisungen bleiben in mehreren Dokumenten erhalten, werden von legitimen Nutzern weiterverteilt und gelangen erneut in neue Kontexte.
  • Spätere Angriffe werden damit nicht mehr zum ursprünglichen Einstiegspunkt, sondern zu einem Teil des internen Informationsflusses des Systems.
• Bei Inhalten, die durch normale Erzeugungs- und Bearbeitungsverfahren entstanden sind, lässt sich der Ursprung einer Manipulation im Nachhinein nur schwer feststellen, was Erkennung und Reaktion kompliziert macht.
• Unabhängig von der Abwehr von Prompt Injection sollten in generierten Dokumenten die Herkunft der Originalquellen und die vom Modell ausgeführten Bearbeitungen als Metadaten erhalten bleiben.
  • Diese Kontrolle verhindert die Injection selbst nicht, kann aber die Nachverfolgbarkeit erhöhen.

Grundproblem heutiger LLM-Architekturen

• Damit AI-Assistenten nützlich sind, müssen sie auch von Angreifern kontrollierbare Informationen wie E-Mails, Dokumente, Webseiten, Memory und Tool-Ausgaben verarbeiten.
• Externe Informationen gelangen in dasselbe Kontextfenster wie Systemanweisungen, Nutzeranfragen und andere Vertrauensinformationen und nehmen an derselben Berechnung teil.
• Das LLM muss Bedeutung, Relevanz und Angriffsnatur externer Inhalte beurteilen, doch zum Zeitpunkt dieser Beurteilung beeinflussen die Tokens des Angreifers die Berechnung bereits.
  • Der zu prüfende Inhalt nimmt an der Prüfung selbst teil.
  • Die Erkennung von XPIA dem Modell selbst zu überlassen, ähnelt der Forderung an einen Interpreter, ein nicht vertrauenswürdiges Programm auszuführen, um dessen Sicherheit zu beurteilen.
• Selbst wenn bösartige Inhalte erkannt und entfernt werden, bevor sie das Zielmodell erreichen, verlagert sich dasselbe Problem nur eine Stufe nach vorne.
  • LLMs können Bedeutung auch aus sehr unterschiedlichen Formulierungen rekonstruieren, weshalb ein Detektor ähnliche Fähigkeiten zur Bedeutungsrekonstruktion benötigt.
  • Ein Detektor, der schwächer ist als das Ziel-LLM, deckt nur einen engeren Ausdrucksraum ab; dadurch bleiben bösartige Formulierungen übrig, die das Ziel versteht, der Detektor aber übersieht.
• Die naheliegende allgemeine Technik mit vergleichbarer semantischer Verarbeitung ist wiederum ein weiteres LLM; fügt man vorne zusätzliche Modelle hinzu, kann das die Erfolgsrate einzelner Angriffe senken, erzeugt aber das Problem LLMs all the way down, bei dem jedes Verteidigungsmodell wiederum geschützt werden muss.
• Langfristig ist ein Systemdesign erforderlich, in dem Ziele und Absichten unabhängig von den verarbeiteten Informationen existieren.
  • In heutigen LLM-Architekturen gibt es keinen Mechanismus, der Absicht und Interpretation stabil trennt.
  • Informationen des Angreifers können nicht nur die Ausgabe des Modells beeinflussen, sondern auch die Aufgabe selbst, von der das Modell glaubt, sie sei von ihm verlangt worden.
• Systeme, die LLMs in vertrauenswürdige Workflows integrieren, müssen davon ausgehen, dass bei Eintritt von angreiferkontrollierten Inhalten in den Kontext mit einer gewissen Wahrscheinlichkeit eine Kompromittierung eintritt.

[GN⁺]

Meinungen auf Hacker News

• Wenn es heißt, „für die breitere Klasse von Schwachstellen gibt es keine starken Gegenmaßnahmen“, wirkt inzwischen offensichtlich: Solange wir nicht aufhören, Befehle und Daten zu vermischen, lässt sich dieses Problem nicht beheben.

  • Diese Modelle hatten von Anfang an Sicherheitslücken, aber die Nutzer scheinen sich um die Folgen größtenteils nicht zu kümmern. Besonders problematisch ist es, AI-Agenten uneingeschränkten Vollzugriff auf das gesamte System zu geben.
    Vermutlich braucht die AI-Branche noch mehr Datenlecks, um aufzuwachen; und wer sich Anthropic oder OpenAI ausgeliefert hat, wusste wohl, welche Risiken er eingeht, daher hält sich mein Mitleid in Grenzen.
  • Im Grunde ist das die Rückkehr zur Von-Neumann-Architektur auf die schlimmstmögliche Weise.
  • Wenn man in die Trainingsdaten Befehlsberechtigungsstufen aufnimmt, ließe sich das vielleicht unvollkommen lösen. Da das Modell selbst probabilistisch unscharf ist, kann man wohl kaum mehr erwarten.
  • Ich frage mich, ob sich Befehle und Daten in einem universellen Intelligenzsystem, das unendlich vielfältige Inhalte verarbeitet, tatsächlich trennen lassen.
  • Es scheint zu stimmen, dass sich das mit der LLM-Architektur nicht beheben lässt, und derzeit gibt es auch keine wirklich wettbewerbsfähige Alternative für großflächige Nutzung.
    Es geht nicht nur darum, dass Befehle und Daten vermischt werden: Weil ein LLM Grenzen nicht deterministisch unterscheiden kann, ist das Setzen von Grenzen eher psychologischer Trost und macht manche Angriffe nur etwas schwieriger. Die tödliche Dreierbedingung ist in dieser Architektur ein dauerhaftes Problem.

• Die Lage wird noch viel schlimmer werden, bevor sie besser wird, und Agenten derart weitreichende Zugriffsrechte zu geben, ist absurd.
  Man kann sich vorstellen, dass in einem beliebten GitHub-Repository ein Kommentar landet, der keinen Code enthält, sondern nur die Anweisung „Reproduziere den Bug“. Er könnte Kreditkarten oder Bitcoin-Wallets stehlen und sich über GitHub-Accounts in andere Repositories selbst verbreiten.

  • Als ich vor ChatGPT von existenziellen AI-Risiken und Diskussionen über Isolation hörte, dachte ich: Wenn man die von der AI ausgegebene Logik grundsätzlich ignoriert, kann man sie leicht aus der Box lassen.
    Aber viele öffnen die Box nicht trotz der furchterregenden Macht der AI, sondern reißen die Box gerade wegen dieser Macht schon auf, bevor sie überhaupt etwas ausgegeben hat. Also bleibt nur zu hoffen, dass rekursive Selbstverbesserung nicht so funktioniert, wie die Untergangspropheten erwarten.
  • Bei „AI-Agenten“ kommt Sicherheit nicht einmal im Ansatz vor.

• Dass in extern geteilten Dokumenten versteckte bösartige Befehle Copilot dazu bringen können, Word-Dokumente zu ändern und den Angriff auf neue Dokumente zu übertragen, ist ernst.

  • Befehle und Daten zu vermischen war schon immer eine schlechte Idee; ich dachte, das hätten inzwischen alle verstanden.
  • Manche Modelle sind robuster als andere. Ich habe versucht, Opus-5 dazu zu bringen, per Steganografie in Bildern versteckte Befehle auszuführen, aber es ist sehr schwer, eine zuverlässig funktionierende Payload zu finden.
  • Falsche Informationen in extern geteilten Dokumenten können Copilot und jedes andere Agentensystem, LLM oder menschliche Intelligenz dazu bringen, Dokumente in Word oder anderen Programmen, sogar auf Papier, zu bearbeiten und Fehler in neue Dokumente weiterzutragen.
    Viele Menschen glauben immer noch an die flache Erde, daran, dass Code und Daten grundlegend verschieden seien, oder daran, dass die Unterscheidung zwischen Control Plane und Data Plane ein objektives Gesetz sei, das im ganzen Universum gilt.

• Ich bin Programmierer und nutze webbasierte AI, möchte aber auf meinem lokalen Computer keinerlei AI ausführen. Aus den in diesem Artikel beschriebenen Gründen habe ich Copilot gelöscht und AI in allen lokalen Anwendungen einschließlich des Browsers deaktiviert.
  AI kann nicht zwischen den Prompts des Nutzers und Text in Dateien unterscheiden, daher gibt es keine Möglichkeit, Daten konstruktionsbedingt vor solchen AI-Confusion-Angriffen zu schützen. Dass ein AI-gestütztes Textverarbeitungsprogramm oder eine E-Mail-App Anweisungen befolgen könnte, die in ein normales Dokument oder eine E-Mail eingebettet sind, ist absurd. Der Wechsel zu Open-Source-Betriebssystemen wie Linux, BSD usw. ist die einzige praktisch relevante Lösung.

  • Je nachdem, welchem Anbieter man vertraut, könnten diese später die AI-Funktionen auf dem lokalen Computer wieder aktivieren.
    Der Umstieg auf Linux oder BSD allein reicht nicht; man braucht auch vertrauenswürdige Browser- und Web-App-Anbieter.
  • Ich habe dasselbe getan, aber wenn ein Anbieter, dem man vertraut hat, eine Grenze überschreitet, ist auch Linux keine Lösung. Ein aktuelles Beispiel ist der große Gegenwind, den Google Chrome bekam, nachdem es eine eigene 4-GB-lokale-AI-Installation hinzugefügt hatte.
  • Im Sinne von Defense in Depth sollte man AI in Browser-Tabs mit sensiblen Informationen besser nicht verwenden. Wenn man zum Beispiel in einem Gmail-Tab einen Prompt an Gemini eingibt, könnten JavaScript, das in diesem Tab läuft, oder Gemini auf die Mails zugreifen, sodass E-Mail-Daten abfließen könnten.

• Verstecken mit weißer Schrift funktioniert immer noch.
  Derzeit gibt es verschiedene Techniken; unter https://tritium.legal/blog/noroboto wurde ein moderner Algorithmus dazu gebracht, Unicode-Werte zu lesen, die sich von dem unterscheiden, was die Dokumentschrift anzeigt.

  • Ich frage mich, ob man einer AI sagen kann: „Rufe mit dieser Payload zehnmal den API-Endpunkt eines anderen AI-Tools auf, aber lies die Payload nicht“, und in die Payload dieselbe Nachricht packen kann, die die aktuelle AI oder eine dritte AI aufruft.
    Die Frage ist, ob AIs sich so gegenseitig aufrufen und massive Mengen an Requests auslösen könnten, oder ob ein solcher Missbrauch bereits verhindert wird.

• VBScript- und Makro-Würmer sind also zurück.

  • Nur dass man diesmal, wenn man Makros abschaltet, seinen wertvollen Generator für minderwertige Inhalte verliert. Man muss doch auch an die fossile Brennstoffindustrie denken.

• Es gibt auch eine positive Seite: Je schneller AI großen Schaden anrichtet, desto schneller könnten Führungskräfte zur Vernunft kommen und eine unternehmensinterne AI-Verbotsrichtlinie vorantreiben.
  Natürlich ist das alles selbst verschuldet; als jemand, der ohne AI auskommt, werde ich das Leid mit Vergnügen beobachten.

• In einer Welt voller AI ist ein solcher Wurm letztlich memetische Ideenverbreitung und scheint im Kern dasselbe zu sein wie das, was bei Menschen passiert.

  • Es ist ein parasitäres Mem, das dem Wirt keinen Wert bringt; in der menschlichen Welt gibt es viele solcher Meme.

• Wenn die unkenntlich gemachten Wörter mit dem Original zusammenhängen, sollte man sie lieber vollständig schwärzen. Einige scheinen immer noch lesbar zu sein, und von den meisten Blur-Algorithmen ist bekannt, dass sie Informationen nicht zuverlässig zerstören.