Im Januar 2026 veröffentlichte „ OPSWAT “ eine Analyse zu CVE-2025-66516, einer kritischen Sicherheitslücke in Apache Tika, , die durch eine bösartige PDF-Datei ausgelöst wurde, die einen Backend-Parser erreichte. Die Lösung war elegant: Die Datei wird bereinigt, bevor sie den Parser erreicht, sodass dieser die Nutzlast nie zu Gesicht bekommt. Das funktionierte, weil es nur einen Parser, einen Dateityp und eine bekannte Bibliothek gab.
Was ist nun, wenn es sich bei der XML-Datei nicht um ein PDF handelt, sondern um eine Konfigurationsdatei, die in eine SSO-Plattform (Single Sign-On) importiert wird, eine Workflow-Definition, die an eine Finanzautomatisierungs-Engine gesendet wird, oder eine Nutzlast mit Gesundheitsdaten, die von einem Krankenhaus-Integrationssystem verarbeitet wird? Diese Dateien werden täglich zwischen Organisationen, Auftragnehmern, Aufsichtsbehörden und Partnern ausgetauscht und gelangen über verwaltete Dateiübertragungsdienste und Partnerportale als vertrauenswürdige Geschäftsdaten an ihren Bestimmungsort. Die meisten Lösungen zur Datenbereinigung überprüfen sie dabei nie.
XML ist die Sprache der Industrie, und genau darin liegt das Problem
PDF- und SVG-XXE-Angriffe (XML External Entity) folgen einem ähnlichen Muster: Ein Benutzer lädt eine Datei hoch; eine Backend-Bibliothek analysiert diese; der Parser führt die Payload aus. Der Einstiegspunkt ist erkennbar.
XML-Daten aus der Industrie sind anders. Es handelt sich dabei um B2B-Übertragungen, Konfigurationsimporte und System-zu-System-Daten von bekannten Partnern, Aufsichtsbehörden, Auftragnehmern und Anbietern. Genau diese scheinbare Legitimität ist der Grund, warum sie die bei Web-Uploads angewandten Sicherheitsprüfungen umgehen.
XML ist in den Betriebsabläufen zahlreicher Branchen fest verankert:
- Finanzdienstleistungen: SWIFT-Nachrichten, FIX-Anweisungen (Financial Information eXchange) und Zahlungen nach ISO 20022 basieren alle auf XML.
- Gesundheitswesen: HL7 (Health Level Seven) und FHIR (Fast Healthcare Interoperability Resources), die Standardprotokolle für den Austausch von Gesundheitsdaten, basieren auf XML. Eine böswillige Komponente in einer FHIR-Nutzlast gelangt durch jedes System, das zwar die Struktur, nicht aber den DOCTYPE überprüft.
- Unternehmens-IT: Identitäts- und SSO-Plattformen lesen bei der Integration, Migration und Einbindung XML-Konfigurationsdateien ein. Ein einziger Import kann alle Anwendungen erreichen, die von der Plattform authentifiziert werden.
- OT: SCADA- und Energiemanagementsysteme tauschen Daten in XML-Formaten aus, die durch die Normen IEC 61968 und 61970 definiert sind, häufig über IT/OT-Grenzen hinweg, wo nur minimale Kontrollmaßnahmen bestehen.
In jedem Fall handelt es sich bei der Nutzlast nicht um ein Skript oder ein Makro, sondern sie befindet sich in der Inhaltsschicht des XML: eine DOCTYPE-Deklaration, die auf eine externe Entität verweist, welche wiederum auf einen lokalen Dateipfad oder einen internen Endpunkt verweist. Wenn der Parser die Datei verarbeitet, ruft er diesen Inhalt ab.
Zwar ist die Datei bei der Schema-Prüfung strukturell gültig, doch erfordert ihr Inhalt eine gründlichere Bereinigung, z. B. hinsichtlich der Angaben im DOCTYPE oder der Verweise der Entitäten.
Das ist kein Altlastenproblem
XXE wurde 2003 beschrieben und 2017 in die OWASP Top 10 aufgenommen, was dazu führt, dass Teams diese Schwachstelle manchmal als behoben betrachten. Die Daten aus den Jahren 2025 und 2026 sprechen jedoch eine andere Sprache, und für die Dateisicherheit sind vor allem jene Fälle relevant, in denen die Nutzlast als Datei eintrifft.
- lxml (CVE-2026-41066): Die Standardkonfiguration des Parsers in einer weit verbreiteten Python-XML-Bibliothek ermöglichte es, dass nicht vertrauenswürdiges XML lokale Dateien auslesen konnte. lxml ist dieselbe Bibliothek, die svglib zum Parsen von SVG-Dateien (Scalable Vector Graphics) verwendet – die in seinem Blogbeitrag „SVG XXE 2024“ demonstrierte, über Dateien übertragene Pfad OPSWAT . Durch die Bereinigung der Datei wird die Entität entfernt, bevor der Parser sie sieht.
- Atlassian Crowd (CVE-2026-21569, CVSS 7,9 – Hoch): eine SSO- und Identitätsplattform. Eine speziell gestaltete XML-Nutzlast verschafft einem Angreifer lokalen oder Fernzugriff auf Dateien, und die CVSS-Einstufung „Scope:Changed“ bedeutet, dass ein erfolgreicher Angriff alle Anwendungen betrifft, die von Crowd authentifiziert werden. Die XML-Datei wird als Konfigurations- oder Integrationsimport von einem Partner oder einem Administrator-Arbeitsplatz übermittelt.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 „High“): IBM BAW verarbeitet XML in Workflows wie der Kreditvergabe und der Schadenbearbeitung. Die Schwachstelle ermöglicht die Offenlegung von Dateien und SSRF (Server-Side Request Forgery), wodurch ein Angreifer auf interne Endpunkte zugreifen kann; zudem kann dieselbe DOCTYPE-Struktur eine Entitätserweiterung für DoS (Denial of Service) auslösen. Die XML-Daten werden über Partnerportale von Schadensregulierern, Aufsichtsbehörden und Integratoren übermittelt.
Alles deutet auf ein gemeinsames Muster hin: eine vertrauenswürdige XML-Datei aus dem Geschäftsbereich, die eine DOCTYPE-Nutzlast enthält und über einen etablierten Workflow gelangt, bevor sie einen anfälligen Parser erreicht.
Ein Hinweis zum Anwendungsbereich: In diesem Blogbeitrag geht es um XXE, das in Form einer Datei auftritt. XML und XML-basierte Formate wie SVG, PDF mit XFA sowie Office-Dateien, die einen Bereinigungsworkflow durchlaufen, werden fehlerfrei rekonstruiert. Die über Dateien übertragenen Fälle sind die häufigsten: Uploads, Konfigurationsimporte, Datenaustausch mit Partnern und E-Mail-Anhänge. Bei XXE, das über einen rohen „ API “-Anfrage-Body oder einen im Code enthaltenen Parsing-Aufruf erfolgt, wird keine Datei übertragen, sodass ein Gateway zur Dateibereinigung in diesem Pfad nicht zum Einsatz kommt.
Wie die Deep CDR™-Technologie eigenständige XML-Dateien verarbeitet
Die Deep CDR™-Technologie unterstützt XML 1.0 und 1.1 sowie damit verbundene XML-basierte Formate wie ZEI, JNLP, TDS, RDF, BML, MPD und TTML unter derselben Engine.
Bei XML-Dateien werden Verweise, die außerhalb des Dokuments liegen, standardmäßig abgelehnt, und der DOCTYPE sowie dessen Verweise auf externe Entitäten werden in der rekonstruierten Datei nicht beibehalten. Keines dieser Verhaltensweisen stellt eine Richtlinie dar, die ermittelt und angepasst werden muss. Solange externes XML den Bereinigungs-Workflow in „ MetaDefender Core™“ durchläuft, gilt dieser Schutz.
Zusätzlich zu dieser standardmäßigen Entfernung des DOCTYPE-Tags stehen den Betreibern weitere Steuerelemente zur Verfügung, die sie an ihre jeweilige Umgebung anpassen können.
- Makro entfernen: Entfernt VBA-Makros, die in XML-basierten Office-Formaten kodiert sind
- CDATA entfernen: vier abgestufte Richtlinienoptionen, von „Keine Aktion“ bis „Alle entfernen“, die den Teams die Kontrolle darüber geben, wie rigoros CDATA-Abschnitte je nach Sensibilität des Workflows behandelt werden
- „Injection entfernen“: Behebt XML-Injection und in Elementwerten eingebettetes JavaScript auf der Inhaltsebene
- Verarbeitung von Base64-kodierten Daten: Verarbeitet kodierte Nutzdaten, die in XML-Werten eingebettet sind, einschließlich Daten-URL-Schema-Muster
Ein damit verbundener Schutzmechanismus deckt die andere Seite derselben Richtung ab. Strukturen, die so geschrieben sind, dass sie sich so lange ausdehnen, bis der Speicher erschöpft ist, werden erkannt und entfernt, sodass eine kleine Datei im Laufe des Prozesses nicht zu einer riesigen Datei werden kann – daher rührt auch der Name „XML-Bombe“ (oder „Billion Laughs“), mit dem solche Fälle bezeichnet werden.
Jede Bereinigungsmaßnahme wird in einem forensischen JSON-Bericht erfasst. Der Bericht enthält den Objektnamen, den entfernten Inhalt (begrenzt auf 5.000 Zeichen pro Eintrag) und den SHA-256-Hash des entfernten Objekts. Sicherheitsteams verfügen so über einen lückenlosen Prüfpfad für die Compliance-Prüfung und die Rekonstruktion von Vorfällen, ohne die Originaldatei erneut untersuchen zu müssen.
Eine ausführliche Erläuterung zu XML-Injection, CDATA-Injection, XML-Bomben und damit verbundenen XML-Angriffsmechanismen finden Sie in unserem technischen Tiefgang zu Angriffsvektoren auf XML-Dokumente.
Schützen Sie Ihre XML-Datei-Workflows
Wenn ein vertrauenswürdiger Parser auf eine bösartige XML-Datei trifft, hat die Datei die Oberhand. Apache Tika, Atlassian Crowd, IBM BAW und der SVG-Parsing-Pfad belegen dies in Dokumentenpipelines, Identitätsplattformen und Workflow-Engines.
Diese Dateien werden nicht als Bedrohungen eingestuft. Sie stammen von bekannten Partnern über etablierte Arbeitsabläufe und enthalten legitime Inhalte – genau das macht sie so wirksam. Die Abhilfe bleibt von einer CVE zur nächsten unverändert: Abfangen auf der Übertragungsebene, Bereinigung, bevor die Datei den Parser erreicht, und Sicherstellung, dass der Schutz auch externe XML-Datendateien abdeckt, nicht nur E-Mail-Anhänge und Web-Uploads.
