Security Issues with Electronic Invoices

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

Video Recording at media.ccc.de

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:

• EVS-EN 16931-1:2017+A1:2019/AC:2020 (source)
• CEN/TS 16931-2:2017 (English) (source)

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.

Questions?

Get in touch!