Prompt Injection via Markdown: AI-Agenten im Visier

Sicherheitsforscher haben eine neue Angriffstechnik dokumentiert, bei der Prompt Injection über manipulierte Markdown-Dateien KI-Code-Assistenten dazu bringt, Malware zu installieren oder Authentifizierungsdaten preiszugeben. Das Bedrohungsszenario ist alltäglich: Ein Entwickler lädt eine Datei herunter, öffnet sie in einem Editor mit integrierten KI-Agenten – und der Agent führt schädliche Anweisungen aus, die sich im Dateisystem verstecken.

Was passiert

Laut Dark Reading haben Angreifer eine neue Prompt-Injection-Technik entwickelt, die ausnutzt, wie Code-Assistenten lokale Dateien interpretieren. Die Angreifer platzieren manipulierte Markdown- oder Textdateien so, dass sie vom KI-Agenten als Systemanweisungen oder Ausführungsaufträge gelesen werden – statt als bloße Dokumentation. Das Prinzip ist elegant: Die KI vertraut Dateien im Kontext des Benutzers und unterscheidet nicht mehr zwischen Dokumentation und Befehl.

Dark Reading berichtet, dass die Attacke die Grenze zwischen Textdokumenten und ausführbaren Aktionen verwischt. Besonders kritisch ist das Szenario, das The Hacker News dokumentiert: Eine bösartige Anweisungsdatei, die sich im Downloads-Ordner eines Entwicklers befindet, kann den KI-Agenten dazu verleiten, ein bekanntermaßen schädliches npm-Paket zu installieren. Das funktioniert, weil moderne KI-Agenten versuchen, den Entwicklungskontext zu verstehen – und eine Markdown-Datei im Download-Verzeichnis als potenziell legitime Anweisung interpretieren.

Konkrete Angriffsszenarien: Ein Angreifer hostet eine Website, die automatisch eine Datei mit namen wie „README.md" oder „.env.example" in den Downloads-Ordner speichert – ohne ausdrückliche Nutzergenehmigung. Wenn der Entwickler später diese Datei öffnet (etwa um den Inhalt zu überprüfen) und dabei ein KI-Tool wie GitHub Copilot oder ähnliche Assistenten aktiv sind, kann die versteckte Prompt-Injection-Anweisung in der Datei den Agent dazu bringen:

• Ein npm-Paket mit bekannter Malware zu installieren
• Login-Token oder API-Keys aus der Shell-History oder .bash_history zu exfiltrieren
• Unbemerkt Befehle auszuführen, die den Code kompromittieren

Help Net Security ergänzt die Bedrohungslage: Dateien, die ohne Genehmigung in den Downloads-Ordner gelangen, werden von vielen Nutzern nicht sofort überprüft. Der psychologische Faktor ist entscheidend – wer sicher ist, dass er eine legitime Dokumentation öffnet, wird weniger kritisch und gibt dem KI-Assistenten stillschweigend mehr Handlungsspielraum.

Warum für DACH relevant

Die DSGVO und regulatorische Anforderungen wie der EU AI Act adressieren zwar Datenschutz und KI-Governance, doch Prompt Injection über lokale Dateien ist eine Grauzone: Sie ist technisch ein klassischer Angriffsvektor (Dateimanipulation), aber mit KI-Agenten als Verursacher. Das hat unmittelbare Konsequenzen für Unternehmen im DACH-Raum.

Mittelständische Agenturen und Softwareunternehmen vertrauen auf KI-Code-Assistenten wie GitHub Copilot oder proprietäre Lösungen. Falls ein Entwickler unbewusst von einem Prompt-Injection-Angriff betroffen wird, hat das Unternehmen ein Supply-Chain-Problem: Der kompromittierte Code könnte in Production gehen, und die Nachverfolgung ist schwierig, weil der Fehler nicht im Code selbst liegt, sondern in der Bedienung des KI-Tools.

Für Unternehmen mit TISAX- oder IT-Sicherheitsanforderungen ist das ein Compliance-Risiko. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat noch keine spezifischen Richtlinien zu Prompt Injection veröffentlicht, aber die Verantwortung für Entwicklungs-Tools liegt beim Unternehmen. Das heißt: Wer seinen Entwicklern KI-Agenten zur Verfügung stellt, muss auch die Sicherheit dieser Agenten gewährleisten – und das ist mit klassischen Patch-Management-Prozessen nicht gelöst.

Ein weiterer Aspekt: Im DACH-Raum sind viele Agenturen und Dienstleister auf Open-Source angewiesen. Die npm-Registry und andere Paket-Ökosysteme sind potenzielle Einfallstore für Attacken, die über Prompt Injection aktiviert werden. Eine einzige infizierte npm-Installation könnte hunderte von Projekten betreffen.

Was du jetzt tun solltest

Der konkrete Schutzmaßstab liegt nicht nur bei den KI-Anbietern, sondern auch bei den Entwicklern selbst. Unternehmen sollten ihre Entwickler-Richtlinien um einen neuen Punkt ergänzen: Sandbox-Isolation von KI-Agenten für kritische Operationen. Das bedeutet konkret: Agenten, die npm-Pakete installieren oder Shell-Befehle ausführen, sollten nur in kontrollierten Umgebungen mit expliziter Bestätigung funktionieren – nicht automatisch im lokalen Dateisystem des Entwicklers.

Parallel dazu empfiehlt sich ein Audit der verwendeten KI-Tools: Welche Agenten haben Zugriff auf den Downloads-Ordner? Welche können Bash-Befehle ausführen? Können sie lokal gespeicherte Dateien als Anweisungen interpretieren? Diese Fragen sollten in den nächsten Security-Reviews gestellt werden, besonders bei Teams mit hohem Open-Source-Anteil.

Für Pentester ist diese Attackfläche relevant – sie zeigt, dass KI-Pentesting nicht nur um direkte Modell-Jailbreaks dreht, sondern auch um die Ausnutzung von Vertrauen im Dateisystem. Wer die Sicherheit von KI-Agenten prüfen will, sollte auch solche indirekten Injection-Vektoren einplanen. Ein verwandtes Szenario ist die RCE-Welle und Supply-Chain-Chaos, wo Angreifer ähnlich gezielt Dateisystem-Vertrauen ausnutzen – nur dass dort auch klassische Code-Injection im Spiel ist.

Die Lehre: KI-Agenten sind Werkzeuge, aber keine heiligen Kuhe. Sie müssen wie jedes andere Sicherheit-kritische System behandelt werden – mit Zugriffskontrollen, Überwachung und skeptischer Konfiguration.

Quellen

• Dark Reading: In-the-Wild Attack Abuses AI Agents' Trust in Markdown
• The Hacker News: Malicious File in Downloads Folder Tries to Trick AI Coding Agent Into Installing Malware
• Help Net Security: AI coding agents fall for malicious instructions planted in the Downloads folder