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. That's a pretty serious restriction for Boost.Serialization. The kind that should go in big bold red text on the main page of the Boost.Serialization documentation. It's not a bug per se, but it means that Boost.Serialization can only be used for a small subset of serialization scenarios, and the user could easily miss this restriction if they don't read the entire documentation of the library. -- Rainer Deyke - rainerd@eldwood.com