Security Issues with Electronic Invoices

This page provides supplementary material for a presentation given at the German OWASP
Day 2025
(Presentation Slides).

Intro

With the eInvoicing Directive (2014/55/EU), the European
Union introduced “standardized” electronic invoices in XML format. Increasingly,
institutions and businesses in EU member states will be required to support these
electronic invoices.

While machine-readable invoices are, in general, a good idea, there are various issues
with the EU’s approach, including needless complexity, a lack of true standardization
(multiple syntaxes and various sub-formats), and a tendency to use technologies with
inherent security problems.

Due to a combination of unfortunate design decisions, implementing software for
electronic invoices is likely to be affected by security flaws if no countermeasures are
implemented.

XML Insecurity and XXE

The XML format is known to have inherent security flaws, the most dangerous ones being
XXE vulnerabilities (XML eXternal Entity injection).

XXE vulnerabilities often allow the exfiltration of files. While some XML implementations have
implemented secure defaults or were never vulnerable to begin with (e.g., Python, libxml2, .NET, Expat), others remain insecure
by default.

Two notable examples of implementations with insecure defaults are the Java standard
library and the Saxon library. Both are commonly used within the electronic invoicing
ecosystem.

The problem with XSLT 2.0

XSLT is a document transformation language. Only XSLT version 1.0 is widely supported.
For XSLT 2.0 and above, only one freely available implementation exists: Saxon.

To check compliance with the EN16931 standards, the EU provides validation artifacts
based on Schematron. Those validation artifacts
require XSLT 2.0.

Thus, anyone using these validation artifacts will likely use Saxon to implement invoice
parsing. Saxon, as mentioned, is vulnerable to XXE by default.

Despite its poor implementation status and the fact that its primary implementation
has insecure defaults, XSLT 2.0 (and its successor 3.0) is a W3C recommendation. I
raised these concerns with the W3C.

Security test suite

A security test suite for electronic invoices is provided here.

Getting the EN16931 standards

The EU requirements for electronic invoices are standardized by the European Committee
for Standardization (CEN) in a set of standards named EN16931. The first two parts are
available free of charge. Subsequent parts cost money.

Accessing these standards is surprisingly difficult. A link on the EU web page to CEN is
currently broken. CEN does not provide direct downloads of these documents and refers to
national standardization organizations. Those often require account registrations even
to access the free-of-charge parts of the standard.

The Estonian standardization organization (EVS) provides downloads of parts one and two
without registration:

For the parts of EN16931 that are not available free of charge, prices at EVS are
cheaper than those at most other national standardization organizations.

XXE vulnerabilties

List of security vulnerabilities discovered in electronic invoicing software during this
research:

* ZUV is no longer developed, and it is recommended to use Mustang instead. Mustang was
also vulnerable to XXE in versions before 2.16.3 (CVE-2025-66372).

More

Questions?

Get in touch!

Text and logo are licensed as CC0.
The logo is a mix of
three
icons from svgrepo.com, all CC0.
The web page uses Pico CSS (MIT license) and
Hugo.

Created by Hanno Böck

(created: November 25, 2025, last update: December 12, 2025)

Imprint