3 ms·
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
by cogman10 11mo ago
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 11mo agodont unzip an untrusted payload
- cogman10 11mo agoUnless 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 11mo agohello, https://nvd.nist.gov/vuln/detail/CVE-2025-11001 https://nvd.nist.gov/vuln/detail/CVE-2025-11001
- cogman10 11mo agoRight, 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 11mo agothis is just one instance of a vulnerability associated with unzipping; a curious search would yield more.
- cogman10 11mo agoA 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 11mo agoand 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”.