On 6/22/26 2:59 PM, Seth via Boost wrote:
On Mon, Jun 22, 2026, at 11:12 PM, Chris Frey via Boost wrote:
I haven't seen mention of this on this list yet, so just passing it along.
Vulnerability page: https://vuldb.com/cve/CVE-2026-11460
More details: https://gist.github.com/TrebledJ/b7c872f869b5ed7cbd936f71f16c7d75
Isn't this by design and as documented?
Boost Serialization does not have checksums/tampering protection. Basically, reading untrusted archives is a no-no because malformed archives lead to undefined behavior. I believe this is documented under some version compatibility paragraphs, and likely under the `archive_flags`?
That's a limitation of the scope of the library, but not necessarily in application, because the protection/authentication can be built into a higher layer of the serialization that is based on Boost Serialization archives.
Just thinking out loud here, Seth
- Chris
this has been brought up before. The serialization library does not provide any mechanism to verify that an archive has not been tampered with. I have considered from time to time and I've concluded that it's not a trivial thing to address. The first idea which occurs is to append some sort of checksum to an archive when it is closed. This would be unsatisfactory for a number of reasons: a) It would be pretty easy to tamper with the archive, and just replace the checksum with and updated one. This would defeat the system. b) The API permits the usage of an archive in "streaming" mode where the consumer reads the archive in parallel with the supplier. One would not be able to know that the archive has been tampered with "on the fly" until the archive is closed. Besides, if the archive stream is tampered with on the fly, the check sum could be updated when the stream is closed. c) The only way I see to reliably detecte that archive has been tampered with would be to generate the checksum "out of line" and transmit it over a separate channel/message. This would need to be stored in a separate place than the archive itself to avoid it (the checksum) being tampered with. This would be possible of course. But it doesn't require any changes to the serialization library itself. The scheme would look something like: i) create the archive as one does now ii) create the check sum iii) send the archive iv) send the check sum on a separate channel So no library changes needed. If one had nothing else to do, one could create an archive class which generates the checksum. The one create the two archives - the data and the checksum and then send them separately. Again no library changes needed to do this. Finally, if you've still got time on your hands, you caould make a parallel archive adaptor. This would compose two archives with a "composition archive which woould call the save/load functions of the constituent archives. This would likely be more generally useful, for example if one wanted to stream and store a local copy of an archive simultaneously. Again no changed to the Serialization library itself. These components - checksum archive, composition archive would be described/documented as. examples in updated/extended documentation of the serialization library build with Boost Book. Soooooo ... That's my answer Robert Ramey