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

On 23 Jun 2026 09:03, Rainer Deyke via Boost wrote:
> On 6/22/26 23:59, 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.
> 
> Using checksums for authentication, or indeed any authentication system
> whatsoever, is quite problematic for serialization.  Data sanitation is
> not an authentication problem, and no authentication may be possible.
> 
> Imagine this scenario:
>   - User A creates a file and uploads it onto the internet, without any
> knowledge of who is going to consume the file.
>   - User B downloads the file and loads it in program C, trusting the
> security of program C to remain secure in the presence of untrusted data.
>   - There are no shared secrets between A and B.  There are no public
> keys.  These users do not know or trust each other at all.
> 
> Somehow this scenario works for image files.  It works for HTML files.
> It even more or less works for Javascript files, and Javascript is a
> Turing-complete programming language.  But it does not work at all for
> Boost.Serialization archives, and it cannot be made to work for
> Boost.Serialization archives.

I believe, it works in the same definition of "works" as for the other
file types you mention. That is, the user B can download and use the
archive, but he has no way of knowing whether the file he downloaded is
the same as the one uploaded by user A. This includes possible tampering
or unintentional corruption in transit. The user B also doesn't know
whether the file he downloaded is safe to use. E.g. is the JavaScript
safe to run? Does the image file have some embedded data that exploits a
vulnerability in the image parsing library? etc.

A parsing library, including Boost.Serialization, must be prepared for
malformed content, though. If the downloaded archive is broken (i.e.
invalid in terms of the archive format), Boost.Serialization must give
the user an error when attempting to read it instead of crashing or
corrupting memory. Requirements beyond that, I think, are out of scope
for a deserialization library as they typically can't be fulfilled at
the deserialization level.

_______________________________________________
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/F2TKYQZLSPKFLE5MPPEXIKLSO7B53C6G/