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

El 23/06/2026 a las 10:07, Andrey Semashev via Boost escribió:
> 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.

100% agree. The only security-related requirement we should put on 
Boost.Serialization, and we should put it, is that no UB be generated on 
archive loading time.

Joaquín M López Muñoz

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