PDF Prompt Injection

Was ist PDF Prompt Injection?

PDF Prompt Injection ist indirekte Prompt Injection über eine PDF-Datei, die ein KI-System liest, extrahiert, rendert, zusammenfasst, klassifiziert, indexiert oder anderweitig modellsichtbar macht. Angreifende können die gesamte Datei erstellen, einen Anhang liefern, ein Formularfeld ausfüllen, eine Annotation ergänzen oder ein Dokument beeinflussen, das später als PDF exportiert wird. Ein direkter Zugang zum Assistenten ist nicht nötig: Die Verarbeitung löst später eine reguläre Nutzerin, ein Connector oder ein Batch-Job aus.

Das Besondere an PDF ist keine spezielle Art von Anweisung. Es ist die Tatsache, dass eine einzige PDF-Datei mehrere unterschiedliche Repräsentationen ihres Inhalts erzeugen kann, die nicht übereinstimmen müssen. Ein Mensch sieht gerenderte Seiten in einem bestimmten Viewer. Eine Textextraktion liefert einen Zeichenstrom, dessen Reihenfolge und Vollständigkeit von der Implementierung abhängen. Ein Pfad aus Rendering und OCR erzeugt ein drittes Ergebnis. Annotationen, Formularwerte, Anhänge und Metadaten werden je nach Konfiguration einbezogen oder gar nicht berücksichtigt.

Modellbeeinflussung und Sicherheitsauswirkung bleiben getrennt. Eine veränderte Zusammenfassung oder Klassifikation zeigt Beeinflussung. Eine Sicherheitsfolge setzt zusätzlich einen Pfad zu sensiblen Daten oder Fähigkeiten und eine fehlende, zu weite oder fehlerhafte Anwendungskontrolle voraus.

Abgrenzung zur Dokument-Prompt-Injection

Der Artikel zur Dokument-Prompt-Injection behandelt das allgemeine Containerproblem: Office- und offene Formate, Markup und Klartext, kollaboratives Bearbeiten, Konvertierungspfade und die Bestandteile, die ein Parser durchläuft oder eben nicht. All das gilt auch für PDF. Diese Seite ergänzt nur das, was für ein Format mit fester Seitenaufteilung und Objektgraph spezifisch ist, das üblicherweise über Extraktion oder Rendering statt über ein strukturiertes Bearbeitungsmodell gelesen wird.

Wo beide Seiten dasselbe sagen würden, verlinkt diese Seite statt zu wiederholen. Die gemeinsame Schlussfolgerung bleibt: Die Repräsentation bestimmt die Exposition, und Exposition ist keine Autorität.

Keine Malware, kein Format-Exploit

PDF hat eine lange Sicherheitsgeschichte, die nichts mit Prompt Injection zu tun hat: eingebettetes JavaScript, Launch- und URI-Aktionen, bösartige eingebettete Dateien sowie Speicherfehler in Parsern und Renderern. Das sind Code-Ausführungs- und klassische Exploit-Probleme. Dagegen helfen Sandboxing, das Abschalten aktiver Funktionen, Patching und Malware-Scanning.

Prompt Injection ist eine andere Fehlerklasse. Es wird kein Code ausgeführt. Gewöhnliche Sprache, die eine Verarbeitungskette in modellsichtbaren Text verwandelt, beeinflusst eine Interpretation oder einen Plan. Eine Datei kann nach jedem Malware- und Konformitätsmaßstab harmlos sein und trotzdem Inhalte tragen, die den Vorschlag eines Assistenten verändern.

Verarbeitungskette von PDF-Dateien

Produkte kombinieren diese Stufen unterschiedlich. Manche extrahieren die Textebene und hören dort auf. Manche rastern Seiten und setzen OCR oder ein Vision-Modell ein. Manche tun beides und führen die Ergebnisse zusammen. Manche behandeln gescannte Dateien anders als digital erzeugte. Sicherheitsarbeit bedeutet, den tatsächlich laufenden Pfad je unterstütztem Fall zu dokumentieren und an jedem Übergang die Vertrauensentscheidung festzuhalten.

Vertrauenswürdige Infrastruktur liefert zuverlässig nicht vertrauenswürdigen Inhalt. Ein erfolgreicher Upload, eine korrekte Typprüfung und ein fehlerfrei arbeitender Parser belegen Eigenschaften der Pipeline, nicht Autorität für den ausgegebenen Text.

Das Problem der mehrfachen Repräsentationen

Eine einzige PDF-Datei kann viele verschiedene Inhaltsansichten erzeugen. Welche davon in einem Produkt tatsächlich existieren, hängt vollständig von dessen Verarbeitungskonfiguration ab.

Nichts davon ist an sich bösartig. Es ist eine Sichtbarkeits- und Provenienzbedingung: Der Inhalt, der ein Modell beeinflusst hat, muss nicht der Inhalt sein, den eine prüfende Person gesehen hat - und umgekehrt.

Was tatsächlich modellsichtbar wird

Ein Screenshot belegt nicht, was das Modell erhalten hat, und eine Rohausgabe belegt nicht, was ein Mensch gesehen hat. Untersuchungen und Tests brauchen beides sowie die Transformation dazwischen. Teams sollten die exakte modellsichtbare Repräsentation je PDF-Klasse erfassen - digital erzeugt, gescannt, formularbasiert, annotiert, gemischt - statt ein einheitliches Verhalten anzunehmen.

Unterschiede zwischen Parsern, Renderern und Extraktoren

Zwei konforme Werkzeuge können für dieselbe Seite unterschiedlichen Text liefern. Die Leserichtung wird rekonstruiert und nicht deklariert, daher können mehrspaltige Layouts, Tabellen, Fußnoten, Kopfzeilen und frei platzierte Elemente unterschiedlich angeordnet werden. Zeichenzuordnung, Ligaturen, Abstandsheuristiken und Schriftkodierung prägen die ausgegebene Zeichenkette. Die Rendering-Treue unterscheidet sich, und OCR bringt eigene Fehler- und Reihenfolgemuster mit.

Diese Varianz ist aus drei Gründen sicherheitsrelevant. Ein Testergebnis gilt nur für die geprüfte Bibliothek und Version. Eine Passage, die in einer Pipeline unsichtbar bleibt, kann in einer anderen prominent erscheinen. Und eine Vorfallsrekonstruktion muss festhalten, welche Komponente in welcher Version die Repräsentation erzeugt hat, die das Modell erreichte - sonst lässt sich der Befund nicht reproduzieren.

Versionsfixierung, eine dokumentierte Extraktionskonfiguration und erneute Tests nach Bibliotheksaktualisierungen gehören deshalb zum Kontrollumfang und sind keine Nebensache.

Voraussetzungen und Zustellwege

Ein PDF wird für ein KI-System erst relevant, wenn es einen Verarbeitungsweg erreicht. Die realistischen Zustellwege sind gewöhnliche Geschäftskanäle.

Jeder Weg hat eine andere Voraussetzung: ein Konto, eine E-Mail-Adresse, eine Kundenbeziehung, Schreibrechte in einem Raum oder lediglich eine öffentliche URL. Zu erfassen, wer welche Datei in welche Pipeline bringen kann, ist der erste Schritt sowohl der Bedrohungsmodellierung als auch einer beauftragten Prüfung.

Offensive Perspektive auf die PDF-Verarbeitung

In einer beauftragten Prüfung lautet die Ausgangsfrage nicht, wie sich eine raffinierte Datei schreiben lässt. Sie lautet, welche PDF-Fläche das Team berechtigt kontrolliert, unter welcher Identität, und welche realistische Aufgabe diese Datei überhaupt in Verarbeitung bringt. Kontrolle ohne Erreichbarkeit ergibt keinen Befund.

Die weiteren Randbedingungen sind technischer, nicht sprachlicher Natur. Die Datei muss Größen-, Typ- und Richtlinienprüfungen passieren. Sie muss in den Extraktionspfad gelangen, den das Produkt wirklich nutzt - Textebene, Rendering mit OCR oder einen Konvertierungsdienst. Die betreffende Objektklasse - Seiteninhalt, Annotation, Formularfeld, Anhang, Metadaten - muss von der Implementierung zurückgegeben werden. Was Normalisierung, Kürzung und Chunking überlebt, entscheidet schließlich darüber, was das Modell sieht und in welcher Reihenfolge neben dem echten Aufgabenmaterial.

Diese Seite richtet sich gleichermaßen an Verteidigung und beauftragte Prüfung: Sie erklärt die Struktur der Hürden und wie jede Stufe gemessen wird. Verschleierungstechniken, wiederverwendbare Anweisungstexte, Rezepte zur Objektplatzierung und Verfahren zur Erhöhung von Extraktions- oder Beeinflussungswahrscheinlichkeit bleiben bewusst außen vor. Diese Umsetzungsdetails verbleiben in der zitierten Forschung.

Erfolgskette der PDF-Prompt-Injection

Jede Schranke ist für eine vollständige Ende-zu-Ende-Auswirkung notwendig, und jede lässt sich getrennt prüfen. Die Berichterstattung sollte sie auseinanderhalten: eine angenommene Datei ist ein Annahmebefund, eine extrahierte kontrollierte Passage ein Extraktionsbefund, eine veränderte Zusammenfassung ein Beeinflussungsbefund - und erst eine fehlgeschlagene Autorisierungsentscheidung mit realer Nebenwirkung ein Autorisierungsbefund.

Kontrollen können die Kette an mehreren Stellen unterbrechen: Einschränkung der Einreichenden, Beschränkung der akzeptierten Objektklassen, Isolierung des Parsings, Provenienzkennzeichnung, Kontextminimierung, Erkennung von Aufgabenabweichung, minimale Rechte und deterministische Richtlinien vor jeder folgenreichen Aktion. Diese mehrschichtige Sicht kommt ohne perfekte semantische Erkennung aus und behandelt beobachtete Beeinflussung dennoch als untersuchungswürdiges Signal.

Konkurrierende Randbedingungen

Die Kette beschreibt zugleich, wogegen ein Angriff konkurriert - und warum reale Ausnutzung deutlich unsicherer ist, als eine Laborvorführung vermuten lässt.

Genau deshalb ist eine stufenweise Messung aussagekräftiger als eine einzelne Erfolgszahl: Sie zeigt, welche Schranke die Abwehrlast tatsächlich trägt.

Offensive Review-Fragen

Eine beauftragte PDF-Prüfung sollte jede Schranke einzeln belegen - mit synthetischen Dateien, synthetischen Schutzdaten, begrenzten Rechten und umkehrbaren Nebenwirkungen. Die folgenden Fragen strukturieren die Prüfung, ohne einen Ausnutzungsablauf vorzugeben.

Durchgespieltes Szenario: automatisierter Rechnungseingang

Beeinflussung fand statt, weil PDF-basierte Sprache den Vorschlag veränderte. Die Auswirkung blieb eingedämmt, weil das synthetische geschützte Konto nie in den Kontext gelangte und keine externe Aktion ausgeführt wurde. Der Extraktor versagte nicht; die Architektur behandelte seine Ausgabe als nicht vertrauenswürdiges Aufgabenmaterial. In solchen Übungen sollten alle Daten synthetisch und alle Nebenwirkungen umkehrbar sein.

PDFs in RAG und abgeleitete Artefakte

PDF ist eines der häufigsten Formate in unternehmensweiten Retrieval-Beständen. Sobald eine Datei geparst, gechunkt und indexiert ist, wird eine einmalige Exposition dauerhaft und kann Nutzende erreichen, die mit dem ursprünglichen Upload nichts zu tun haben. Provenienz und Zugriffsrichtlinie müssen Chunking, Embedding, Indexierung, Abruf und Kontextaufbau überleben; verlorene Dokumentberechtigungen an Kind-Chunks sind ein Autorisierungsfehler, noch bevor Beeinflussung überhaupt betrachtet wird.

Das Löschen der Quelldatei entfernt ihre Ableitungen nicht automatisch. Zusammenfassungen, Caches, Indexeinträge, Embeddings und Memory-Einträge können die Datei überdauern und müssen ausdrücklich erfasst und invalidiert werden. Der Artikel zur RAG-Prompt-Injection behandelt Abruferreichbarkeit, Security Trimming, Mandantentrennung und Indexgenerationen ausführlich; diese Seite liefert die seiten- und objektgenaue Herkunft, die die Retrieval-Schicht bewahren statt einebnen muss.

Erkennung und Telemetrie

Diese Signale belegen Abfolge und Kontext, selten aber modellinterne Kausalität. Harte Evidenz liefern Dateihistorie, Autorisierungsentscheidungen und Aufzeichnungen ausgeführter Aktionen. Extrahierter Text und Modellkontext können vertrauliche Inhalte enthalten; daher gelten Zweckbindung, Zugriffskontrolle, Aufbewahrungsgrenzen und Schwärzung, ohne die Rekonstruierbarkeit eines Vorfalls zu verlieren.

Abwehr und sichere Architektur

1. 01
   Repräsentationsbewusst verarbeiten

   Dokumentieren, welche Repräsentationen - Textebene, Rendering, OCR, Annotationen, Formularwerte, Anhänge, Metadaten - jede Pipeline erzeugt.

2. 02
   Akzeptierte Flächen minimieren

   Nur die Objektklassen annehmen, die die Aufgabe braucht, statt alles zu extrahieren, was eine Bibliothek liefern kann.

3. 03
   Parsing isolieren

   Parser, Renderer und OCR sandboxen, um klassische Dateirisiken einzudämmen, und Komponenten gepatcht und versionsfixiert halten.

4. 04
   Provenienz feststellen

   Einreichende, Kanal, Eigentum, Dateihash, Seite und Objektidentität erfassen, ohne Angaben aus der Datei zu glauben.

5. 05
   Herkunft durchreichen

   Quelle, Seite, Objektklasse und Zugriffslabel in jede modellsichtbare Passage, jeden Chunk, jede Zusammenfassung und jeden Cache-Eintrag tragen.

6. 06
   Berechtigungsbewusst ingestieren

   Repository- und Mandantenautorisierung anwenden, bevor Inhalte in Index oder Modellkontext gelangen.

7. 07
   Kontext minimieren

   Nur aufgabenrelevante PDF-Inhalte und nur die notwendigen Anwendungsdaten übergeben.

8. 08
   Vorschlag und Ausführung trennen

   Modellausgaben als nicht vertrauenswürdige Vorschläge behandeln und jede sensible Aktion deterministisch autorisieren.

9. 09
   Fähigkeiten und Abfluss begrenzen

   Minimale Rechte, aufgabenbezogene und kurzlebige Zugangsdaten, Zielrichtlinien und beobachtbare Ausführung einsetzen.

10. 10
    Freigabe an die Aktion binden

    Wo menschliche Freigabe genutzt wird, an die exakte unveränderliche Aktion binden und bei Änderung des Vorschlags verfallen lassen.

Der Abwehrbereich ordnet diese Kontrollen in das übergreifende Modell aus Provenienz, Informationsfluss, minimalen Rechten, Aktionskontrolle, Monitoring und Wiederherstellung ein.

Kontrolliertes Testen

Synthetische PDFs, synthetische Identitäten, Testbestände und Testmandanten verwenden. Variieren Sie PDF-Klasse - digital erzeugt, gescannt, formularbasiert, annotiert, gemischt -, Extraktionspfad, Bibliotheksversion, zurückgegebene Objektklassen, Rechtestand und verfügbare Fähigkeiten. Jede Stufe wird getrennt gemessen.

Das Lab zu Prompt Injection über Dokumente / PDF übt die zugrunde liegenden Vertrauensentscheidungen an fiktiven Dokumenten: Speicherort, Extraktion und Dokumentangaben gegenüber Provenienz und Anwendungsdatensätzen.

Diese Werte dürfen nicht zu einer Kennzahl verrechnet werden. Hohe Sichtbarkeit bei geringer Beeinflussung beschreibt ein anderes Kontrollergebnis als hohe Beeinflussung ohne jede Richtlinienumgehung; erst die Trennung zeigt, ob Extraktionsrichtlinie, Erkennung, Autorisierung oder Eindämmung verbessert werden muss.

Incident Response

Häufige Fehlannahmen

Standards und Forschungskontext

OWASP LLM01:2026 hält fest, dass indirekte Prompt Injection über externe Quellen wie Dateien erfolgen kann, dass solche Inhalte für Menschen nicht sichtbar sein müssen, solange sie vom Modell verarbeitet werden, und dass multimodale Systeme zusätzliche modalitätsübergreifende Risiken mitbringen. NIST AI 100-2e2025 beschreibt indirekte Prompt Injection als Kontrolle über eine Ressource, die ein generatives KI-System verarbeitet, und trennt diesen Mechanismus von der nachgelagerten Auswirkung.

Microsoft zählt Dokumente zu den nicht vertrauenswürdigen externen Inhalten und empfiehlt mehrschichtige probabilistische und deterministische Kontrollen. Die Leitlinie Input, Context, and Retrieval Hygiene hält fest, dass jeder Prompt, jedes Dokument, jeder abgerufene Chunk, jedes Tool-Ergebnis und jeder Memory-Schreibvorgang als nicht vertrauenswürdige Eingabe zu behandeln ist und dass sicheres Retrieval Quellenprovenienz, berechtigungsbewusste Indexierung und Prüfung bei jedem Lese- und Schreibvorgang erfordert. Das gilt unmittelbar für extrahierte PDF-Seiten und die daraus abgeleiteten Zusammenfassungen, Caches und Indexeinträge.

Als Forschungskontext dient CrackedPDFs, ein kontrollierter Benchmark für verborgene Prompt Injection in PDFs. Die Ergebnisse gelten für diesen Versuchsaufbau und sind keine allgemeingültigen Aussagen über beliebige Produkte. Zitiert wird hier eine defensive Lehre: Verflachung und Extraktion können den Nachweis zerstören, dass ein Inhalt für Menschen nie sichtbar war - genau deshalb brauchen Untersuchungen die gerenderte Ansicht, die extrahierte Repräsentation und deren Differenz. Forschung zu KI-gestützter Begutachtung dokumentiert ebenfalls, dass über PDFs eingebrachte verborgene Prompts LLM-Gutachter beeinflussen können. Verschleierungsmethoden und Optimierungsverfahren werden hier nicht wiedergegeben. Die PDF-Spezifikation dient ausschließlich der faktischen Struktur; sie ist kein KI-Sicherheitsstandard und vergibt kein Vertrauen.

Häufige Fragen