Security issues with electronic invoices

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the document?

The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.

Other answers are good. One more that you could do is put the JSON document inside a container (A zip archive for example). Then your document can effectively be

    invoice.inv (zip archive)
    └- payload.json
    └- signature.asc

This has the benefit of adding more opportunities for many json documents within the archive.

It's effectively what the Java jar is.

dont unzip an untrusted payload

Unless you are worried about something like a gzip bomb, I don't see why this is an issue. A lot of formats are effectively just zips. The xlsx, odf, etc for example. It's a pretty common format style.

It helps to have a well defined expected structure in the archive.

hello,

https://nvd.nist.gov/vuln/detail/CVE-2025-11001

Right, so long as step 1 in reading your file isn't "extract everything" you're pretty safe.

This specific exploit is one that only exists when you are extracting a zip on windows.

this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.

A curious search reveals that vulnerabilities that do exist are of 2 flavors.

1. Standard C memory vulnerabilities

2. Unsafe file traversal while unzipping

The entire second class is avoided in a fixed file format. The first class of vulnerabilities plague everything. A quick look at libxml2 CVEs shows that.