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.

▲ bsamuels 3 days ago | parent [-]

dont unzip an untrusted payload

▲

cogman10 3 days ago | parent [-]

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.

▲

boston_clone 3 days ago | parent [-]

hello,

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

▲

cogman10 2 days ago | parent [-]

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.

▲

boston_clone 2 days ago | parent [-]

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

▲

cogman10 2 days ago | parent [-]

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.

	▲	boston_clone a day ago \| parent [-]
		and the zip bombs you mentioned! i keep a dummy SD card with one hehe. but yeah the first class of vulns is why we have advice like don’t run untrusted input, which is not dissimilar to “don’t unzip untrusted payloads”.