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.