Re: CVE-2026-11460 - security flaw in serialization

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

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/BR5RUK3CJWHLJUQTFGHYKHX5SJK2KFAU/