IT-Sicherheit

ZUGFeRD — Das trojanische Pferd der E-Rechnung

21. April 2026

ZUGFeRD E-Rechnung XML-Sicherheit PDF/A-3 EN 16931 IT-Sicherheit

ZUGFeRD — Das trojanische Pferd der E-Rechnung

Hybrides PDF/A-3 + XML-Rechnungsformat nach EN 16931 — mit konkreten Angriffsvektoren, dokumentierten CVEs und Best Practices für die Implementierung.

Seit dem 01.01.2025 ist die E-Rechnungs-Empfangspflicht im deutschen B2B-Geschäftsverkehr in Kraft. Das am weitesten verbreitete Format heißt ZUGFeRD (aktuell Version 2.4, Dezember 2025) und basiert auf PDF/A-3 mit eingebettetem UN/CEFACT Cross Industry Invoice (CII) XML. Dieser Beitrag analysiert Architektur, Bedrohungsmodell und defensive Implementierung.

§ 01 — Architektur: Was ZUGFeRD eigentlich ist

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) ist seit Version 2.1 technisch identisch mit dem französischen Factur-X. Es ist ein hybrides Format: ein PDF/A-3-Dokument (ISO 19005-3) mit eingebettetem XML nach UN/CEFACT Cross Industry Invoice (CII), das der EU-Norm EN 16931 entspricht.

Die XML-Datei wird als Associated File (/AF-Entry im PDF-Katalog) angehängt — erlaubt durch den PDF/A-3-Standard, der im Gegensatz zu PDF/A-1 und PDF/A-2 beliebige Attachments zulässt. Der Dateiname ist fest vorgegeben: factur-x.xml (ZUGFeRD 2.1+) bzw. zugferd-invoice.xml (2.0).

┌─────────────────────────────────────────────────┐
│  PDF/A-3 Container                              │
│  ┌───────────────────────────────────────────┐  │
│  │  Sichtbeleg (menschenlesbar)              │  │
│  │  · Rendering durch PDF-Reader             │  │
│  │  · Kann JavaScript enthalten  ← Risiko    │  │
│  └───────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────┐  │
│  │  XMP Metadata (XML)                       │  │
│  │  · DocumentType, Version, ConformanceLvl  │  │
│  └───────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────┐  │
│  │  /AF Associated File Tree                 │  │
│  │  └─ factur-x.xml (UN/CEFACT CII)          │  │
│  │     · Strukturierte Rechnungsdaten        │  │
│  │     · Führend bei Abweichung zum PDF      │  │
│  │  └─ [weitere Anhänge möglich]             │  │
│  │     ← Attack Surface                      │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

Die sechs Profile

Profil	EN 16931	UStG-konform (DE)	Anwendung
MINIMUM	nein	nein	nur Referenzdaten, Buchungshilfe
BASIC WL	nein	nein	ohne Positionsdaten
BASIC	teilweise	ja	Standardrechnungen
EN 16931	voll	ja	Empfohlen für B2B
EXTENDED	voll+	ja	komplexe B2B-Fälle
XRECHNUNG	voll (CIUS)	ja	öffentliche Verwaltung

⚠ Falle: MINIMUM und BASIC WL sind in Deutschland keine umsatzsteuerlich gültigen Rechnungen — wer sie empfängt und naiv verbucht, verliert den Vorsteuerabzug.

§ 02 — Bedrohungsmodell: Angriffsvektoren im Detail

ZUGFeRD hat eine außergewöhnlich breite Angriffsfläche für ein Format, das ausdrücklich als “rechtsverbindlich” deklariert wird. Die folgenden Vektoren sind nicht theoretisch — sie sind teils öffentlich dokumentiert, teils bereits in freier Wildbahn ausgenutzt.

KRITISCH — PDF vs. XML Divergenz (Dual-Truth-Problem)

Die Spezifikation erlaubt, dass der menschenlesbare PDF-Teil andere Zahlen, Bankverbindungen oder Leistungsbeschreibungen enthält als die maschinenlesbare XML. Seit BMF-Schreiben ist der XML-Teil führend — aber zahlende Menschen schauen ins PDF.

Real-World: DATEV dokumentierte 2025 Fälle, in denen Angreifer ZUGFeRD-Rechnungen auf dem E-Mail-Transportweg abfingen und nur die PDF-Sichtkomponente mit gefälschter IBAN überschrieben. Empfänger zahlten ans Konto der Täter — die XML war korrekt, das PDF nicht.

KRITISCH — XXE in verbreiteten ZUGFeRD-Libraries

Der DocumentBuilder in mustangproject (meistgenutzte Java-Library, >369 GitHub-Stars) hatte bis Version 2.16.3 (März 2025) XXE-Verarbeitung standardmäßig aktiviert. Angreifer konnten per <!ENTITY>-Deklaration Server-Side-Request-Forgery, File-Disclosure und DoS auslösen — einfach durch Senden einer präparierten Rechnung.

Referenz: GitHub Issue #685 (15.01.2025). Pull Request #725 deaktiviert XML-Entities und ging am 04.02.2025 in den Master. Wer eine ältere Version pinnt, ist verwundbar.

HOCH — PDF/A-3 erlaubt beliebige Zusatzanhänge

PDF/A-3 (im Gegensatz zu -1 und -2) erlaubt Dateianhänge jedes MIME-Typs im /EmbeddedFiles-Namensbaum. Die ZUGFeRD-Spec beschränkt zwar auf eine XML — aber das PDF-Format selbst nicht.

Konsequenz: Angreifer können neben factur-x.xml weitere Executables, Scripts oder Phishing-PDFs einbetten. Adobe Reader rendert diese nicht automatisch — aber automatisierte Buchhaltungs-Pipelines extrahieren oft alle Anhänge und stellen sie in Shared Folders ab.

HOCH — E-Mail als Transport, keine Ende-zu-Ende-Integrität

Das BMF bestätigt ausdrücklich: “Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Keine Signaturpflicht, kein PAdES, kein qualifizierter Zeitstempel. Integrität und Authentizität sollen durch “ordnungsgemäße Buchführung” bewiesen werden — eine juristische Fiktion, kein technischer Schutz.

Realität: SMTP ist klartextorientiert. STARTTLS ist opportunistisch und wird regelmäßig durch Downgrade-Angriffe umgangen. Ohne DANE/MTA-STS ist jede Rechnung auf dem Weg von Sender-MTA zu Empfänger-MTA manipulierbar.

HOCH — XML-Parser-Diversität & Interpretationsspielraum

“Aussage ist Interpretationssache — das gilt leider auch für XML”, schreibt Janis König in heise/iX. Es existieren Dutzende ZUGFeRD-Implementierungen (Java/mustang, .NET, Python/factur-x, PHP, proprietär). Jede interpretiert Whitespace, Zahlendarstellung und optionale Felder leicht anders.

Attack: Parser-Differential-Angriffe. Eine XML, die in Parser A einen Betrag von 100,00 € ergibt, kann in Parser B 10.000,00 € liefern. Der Rechnungssteller validiert mit A, die Bank verarbeitet mit B.

HOCH — Phishing mit legitim aussehenden ZUGFeRD-Rechnungen

Nach Einführung der Empfangspflicht am 01.01.2025 ist jeder Unternehmer verpflichtet, E-Rechnungen per E-Mail zu akzeptieren. Sender-Verifikation existiert im Standard nicht. Eine ZUGFeRD-Rechnung von buchhaltung@amaz0n-partner.de sieht technisch valide aus.

Daten: QR-Code-Phishing-Angriffe sind zwischen 2023 und 2025 um 400 % gestiegen. Allein zwischen August und November 2025 verfünffachte sich das Volumen von ~47.000 auf über 249.000 erfasster Mails pro Monat (Keepnet Labs, 2025). 12 % aller Phishing-Mails enthielten 2025 einen QR-Code.

MITTEL — JavaScript im PDF-Teil

PDF/A-3 verbietet zwar Forms und JavaScript (Conformance Level A/B/U schließen Actions aus) — aber nur bei strikter Validierung. In der Praxis passieren nicht-konforme “PDF/A-3”-Dateien viele Mail-Gateways, weil sie oberflächlich korrekt aussehen. Acrobat-Schwachstellen (CVE-Historie: mehrere Hundert) bleiben relevant.

Hinweis: Die meisten modernen Reader rendern PDF/A-3 konform und deaktivieren JS. Aber: nicht alle Buchhaltungssysteme verwenden moderne Reader. Ghostscript, pdfium, alte Acrobat-Versionen — alle mit eigener CVE-Liste.

MITTEL — Archivierung: XML oder PDF — oder beides?

§ 14b UStG verlangt 8 Jahre Aufbewahrung. Bei ZUGFeRD ist “zumindest deren strukturierter Teil” unversehrt zu archivieren. Was mit dem PDF passiert, wenn es abweicht, bleibt grau. GoBD-konforme Archivierung in Cloud-SaaS-Lösungen mit “10-Jahres-Versprechen” hält einer Prüfung im Ernstfall oft nicht stand.

Empfehlung: beide Teile separat hashen und WORM-archivieren.

“Bei ZUGFeRD ist wohl eher vorgesehen, dass ein Mensch das PDF manuell mit den maschinell lesbaren Daten in einem glorifizierten XML-Viewer vergleicht. Oder vielleicht mit KI?”

— Janis König, heise online, 2024

§ 03 — Kryptografie: Was fehlt

Der vielleicht größte Kritikpunkt: ZUGFeRD spezifiziert keine verpflichtende kryptographische Signatur. PDF/A-3 unterstützt PAdES (PDF Advanced Electronic Signatures) nach ETSI EN 319 142 — die ZUGFeRD-Spec macht davon aber keine Pflicht.

Die eIDAS-Verordnung kennt drei Stufen elektronischer Signaturen:

Stufe	Rechtliche Wirkung	Technik	ZUGFeRD
SES (einfach)	formlos, vor Gericht angreifbar	Mailsignatur, eingescannt	faktisch erlaubt
AES (fortgeschritten)	starker Beweiswert	PAdES B-B / B-LT	optional
QES (qualifiziert)	gleichgestellt mit Handschrift	QSCD + QTSP	optional

In der Schweiz wurde die OElDI-Pflicht zur digitalen Signatur 2018 aufgehoben — “ordnungsgemäße Buchführung” gilt als Nachweis. Deutschland folgt dieser Linie. Der Beweiswert hängt also am Prozess, nicht am Dokument. Wer verklagt wird, muss Buchhaltungsprozesse forensisch rekonstruieren — in einer Welt, in der E-Mails routinemäßig verschwinden.

Warum das ein Problem ist

Ohne PAdES-B-LTA-Signatur mit qualifiziertem Zeitstempel:

keine kryptografische Integritätsprüfung — “jede Änderung wird erkannt” ist Wunschdenken
keine Nicht-Abstreitbarkeit — Aussteller kann später Rechnung leugnen
kein Schutz vor Bit-Rot oder Manipulation im Archiv
keine Langzeitvalidität — in 8 Jahren sind heutige Zertifikate abgelaufen, ohne LTA auch die Archivkette

Die EU DSS (Digital Signature Services) stellt kostenlos Open-Source-Tooling bereit, um PAdES-Signaturen zu erzeugen und zu verifizieren. Es gibt also keinen technischen Grund, das nicht zu tun — außer, dass ZUGFeRD es nicht fordert.

§ 04 — Implementierung: Technische Umsetzung & typische Fehler

Minimale ZUGFeRD 2.x CII XML (EN 16931-Profil)

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>RE-2026-000042</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>  <!-- 380=Rechnung -->
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260421</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <!-- Parteien, Positionen, Summen, Steuer folgen -->
</rsm:CrossIndustryInvoice>

So wird das XML gefahrlos geparst (Java)

Die Standard-XML-Parser in fast allen Sprachen haben XXE, DTD-Loading und External-Entity-Resolution per Default aktiviert. Das muss explizit deaktiviert werden:

// Java — DocumentBuilder härten (gegen CVE-Kategorie XXE)
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

So wird das XML gefahrlos geparst (Python)

# Python — lxml defusen
from lxml import etree
parser = etree.XMLParser(
    resolve_entities=False,
    no_network=True,
    huge_tree=False,
    load_dtd=False,
)

# ODER: defusedxml nehmen (empfohlen)
from defusedxml.lxml import fromstring
tree = fromstring(xml_bytes)  # wirft bei XXE / Billion Laughs

Die wichtigsten Open-Source-Bausteine

mustangproject (Java, Apache-2) — Generierung, Validierung, CLI. Ab Version 2.16.3 / März 2025 XXE-hardened.
factur-x (Python) — leichtgewichtig, Erzeugung und Parsen von Factur-X-PDFs
KoSIT Validator — offizieller Schematron-Validator für EN 16931 und XRechnung
EU DSS — Signatur / PAdES-Erzeugung und Prüfung
QUBA Viewer — visuelle Darstellung reiner XML-Rechnungen

§ 05 — Best Practices: So sollte ZUGFeRD implementiert werden

Wenn das Format schon gesetzlich vorgeschrieben ist und sich nicht umgehen lässt, dann wenigstens defensiv. Die folgenden zehn Punkte sind keine Diskussionsgrundlage, sondern das Minimum für eine halbwegs verantwortbare Pipeline.

01 — XML ist führend. Immer.

Buchhaltung nur auf Basis des XML-Datensatzes. Das PDF ist Sichtbeleg — nicht Zahlungsgrundlage. Automatisiertes Matching XML ↔ Bestellung ↔ Wareneingang, dann Dunkelbuchung. Kein Mensch liest PDFs zur Zahlungsfreigabe.

02 — PDF-XML-Divergenz-Check

Vor jeder Verbuchung: Parse XML, rendere PDF-Text (pdftotext oder vergleichbar), vergleiche IBAN, Betrag, USt-ID, Rechnungsnummer. Abweichung = Quarantäne + manueller Review. Das ist keine Nettigkeit, das ist Anti-Fraud-Baseline.

03 — Hardened XML-Parser — kein XXE, keine Billion Laughs

In jedem Projekt defusedxml (Python), gehärtete DocumentBuilderFactory (Java) oder XmlReaderSettings.DtdProcessing = Prohibit (.NET). Niemals den Default-Parser nehmen. Größenlimit für XML (z. B. 10 MB) und DTD-Tiefe setzen.

04 — Schematron-Validierung gegen EN 16931

Jede eingehende Rechnung mit KoSIT-Validator oder mustang-Validator prüfen. Invalide XML = ablehnen, nicht “best effort parsen”. Validierung auch beim Versand, vor dem Einbetten.

05 — PAdES-B-LTA-Signatur mit QES

Rechnungen ausgehend signieren — qualifizierte elektronische Signatur mit Langzeit-Archivstempel. Kosten ~10 €/Monat bei QTSP. Empfangsseitig: Signaturprüfung automatisiert, unsignierte Rechnungen werden gesondert gekennzeichnet (nicht automatisch abgelehnt, aber sichtbar gemacht).

06 — Dediziertes E-Rechnungs-Postfach + Transportsicherung

Eigene Mail-Adresse (rechnung@firma.de), getrennt vom allgemeinen Postfach. DMARC mit p=reject, SPF hard-fail, DKIM, MTA-STS, DANE/TLSA. Content-Filter, der nur PDF/A-3 mit factur-x.xml durchlässt. Alles andere in Quarantäne.

07 — PDF-Attachment-Whitelist

PDF/A-3 erlaubt beliebige Anhänge. Akzeptieren: ausschließlich factur-x.xml oder zugferd-invoice.xml. Alles andere = Attachment entfernen, Rechnung zur manuellen Prüfung, Incident-Log. Nie automatisiert Zusatzanhänge ins Dateisystem schreiben.

08 — Peppol statt Mail für B2B-Automation

Peppol BIS 3.0 hat Access Points, S/MIME-Transport, Authentifizierung, Routing über Leitweg-ID. E-Mail ist für E-Rechnungen ein Zugeständnis an KMU ohne IT — wer ernsthafte Volumina verarbeitet, sollte Peppol-Access-Point oder Provider (z. B. B2Brouter, SEEBURGER) nutzen.

09 — WORM-Archivierung mit Hash-Chain

XML und PDF separat ablegen, beide mit SHA-256 hashen, Hashes in append-only Log (idealerweise mit TSA-Zeitstempeln). Cloud-SaaS-”10-Jahres-Versprechen” sind keine Archive — lokale Backups in eigener Kontrolle, immutabler Storage (S3 Object Lock, WORM-NAS).

10 — IBAN-Whitelisting & Zahlungsanomalie-Detection

Lieferanten-IBANs pflegen. Neue IBAN in eingehender Rechnung = Blocker, manuelle Verifikation per Telefon (nicht per E-Mail, nicht per Kontakt aus der Rechnung!). Anomaly-Detection auf Beträgen — 10-fache Abweichung vom Durchschnitt = Hold.

§ 06 — Fazit & Bewertung

ZUGFeRD ist ein politisches Kompromissformat. Es versucht, drei inkompatible Ziele gleichzeitig zu erfüllen: Menschenlesbarkeit (PDF), Maschinenlesbarkeit (XML) und Low-Tech-Tauglichkeit (E-Mail-Versand, keine PKI). Das Ergebnis trägt die Kompromisse sichtbar.

Die positiven Seiten: EN 16931-Konformität, europaweite Kompatibilität mit Factur-X, Open-Source-Tooling, klare Spezifikation, aktive Weiterentwicklung (Version 2.4 erschien am 4. Dezember 2025). Für reine B2B-Prozesse zwischen technisch kompetenten Partnern funktioniert es.

Die gravierenden Schwächen: Die Dual-Truth-Architektur ist ein Geburtsfehler, den nachträgliche Patches nicht heilen. Die Abwesenheit verpflichtender kryptografischer Signaturen ist 2026 unentschuldbar. Die Zulassung von E-Mail als Standardtransport für rechtsverbindliche Finanzdokumente ist aus sicherheitstechnischer Sicht fahrlässig. Die bekannten XXE-Vulnerabilities in weit verbreiteten Libraries zeigen, dass das Ökosystem systematisch unterschätzt wird.

Schulnote: 4− (ausreichend, mit deutlichen Abstrichen)

Funktioniert im Alltag, erfüllt die gesetzliche Pflicht, bietet in gut implementierten Pipelines akzeptable Automatisierung. Versagt aber bei fast jeder Sicherheitsannahme, die man 2026 an ein rechtsverbindliches Finanzformat stellen sollte. Die Spezifikation delegiert Sicherheit an die Implementierer — die sie überwiegend nicht liefern werden.

Kurzform

Für KMU ohne IT: Kommt ihr dran vorbei? Nein. Tut, was möglich ist, nehmt einen Provider, macht IBAN-Whitelisting, zahlt nie ohne telefonische Rückfrage bei IBAN-Wechsel.
Für IT-kompetente Unternehmen: defensive Pipeline nach obiger Best-Practice-Liste, Peppol bevorzugen, XML-only-Verarbeitung, QES signieren, was ihr ausstellt.
Für Gesetzgeber: Die E-Rechnung ist überfällig, das Format mittelmäßig. Eine nachträgliche PAdES-Signatur-Pflicht ab einer Umsatzschwelle wäre technisch trivial und würde einen Großteil der offenen Flanken schließen.

“Aber sollte Technologie nicht eigentlich so gebaut sein, dass man solche Fehler gar nicht erst begehen kann?”

— Janis König, heise online

“ZUGFeRD ist das Format, das Deutschland verdient — nicht das, was es brauchte.”

Du betreibst oder baust eine ZUGFeRD-Pipeline?

Ich auditiere bestehende E-Rechnungs-Implementierungen (Parser-Härtung, Divergenz-Checks, Transportsicherung, Archivierung) und unterstütze bei defensiven Neuaufbauten — inklusive Code-Review, Konfiguration und Schematron-Validierung. Mehr dazu unter Leistungen › IT-Sicherheit, oder direkt per E-Mail.

Martin Pfeffer — Software-Entwickler aus Berlin, IHK-zertifiziert in IT-Sicherheit, seit über 10 Jahren Softwareprojekte für kleine und mittelständische Unternehmen. Schreibt auf celox.io über Entwicklung, IT-Sicherheit und KI-Automatisierung. LinkedIn · GitHub · Stack Overflow