Boost Serialization CVE-2026-11460: Overview of an Unpatched Type Confusion and RCE Vulnerability Affecting Two Decades of Releases

Introduction

A deserialization flaw in Boost Serialization lets an attacker run arbitrary code by crafting a malicious archive that abuses improper validation of internal metadata fields, and the maintainer has postponed the fix indefinitely. A public proof of concept showing root shell access has been available since October 2025, and every version of the library from 1.0 through 1.91 is affected. The risk keeps growing for the many C++ applications that depend on Boost Serialization across finance, embedded systems, telecommunications, and critical infrastructure.

Technical Information

Root Cause

CVE-2026-11460 comes from how Boost Serialization handles pointer deserialization within archive files. The library supports serialization of pointers, which can reference arbitrary objects within the same archive. Two serialized metadata fields, object_id and tracking_level, are not validated properly during deserialization. An attacker who controls the content of a serialized archive (XML, binary, or text format) can manipulate these fields to make two distinct classes share the same memory location, or to violate ownership semantics at runtime.

The researcher's disclosure states: "Type Confusion is realized when two objects of different classes share the same memory, and the classes' methods operate on that same memory." It also notes: "Ownership Confusion is realized when an ownership model is violated at runtime; for instance, pointers which are assumed to be unique are instead shared upon deserialization, which may lead to double free."

The vulnerability maps to several CWEs, which reflects how many ways it can go wrong:

Attack Flow

The disclosure documents three concrete attacks, each building on the last to escalate impact. All were tested on Boost Serialization v1.83 and v1.88 using an Ubuntu 24.04 container with GCC 13.3.0.

Attack 1: Type Confusion Leading to Address Leak

The attacker deserializes a non pointer object A followed by a pointer B*. By editing the serialized XML archive to assign both objects object_id="_0" and adding tracking_level="1" to the non pointer object, the attacker tricks the library into pointing b at the memory of a. When b->data is read as uint64_t, it reveals the internal buffer address of a.data (a std::string), leaking a stack address such as 0x7fffcc28da80. The malicious XML payload:

<a class_id="0" tracking_level="1" version="0" object_id="_0">
    <type>Apple</type>
    <data>foo</data>
</a>
<b class_id="1" object_id="_0">
</b>

This first stage matters because it undermines ASLR, which makes the later attacks more reliable.

Attack 2: VTable Hijacking Leading to Arbitrary Code Execution

Building on Attack 1, this variant targets a virtual class B with a VTable. The attacker creates a global table holding a pointer to a pwned() function, then leaks its address using the technique from Attack 1. The attacker writes this leaked address into the <data> field of object a and applies the same object ID confusion. On deserialization, b's v pointer is overwritten, and calling the virtual function b->foo() runs pwned() instead. The disclosure shows this with an interactive root shell (uid=0(root)). The malicious XML payload:

<a class_id="0" tracking_level="1" version="0" object_id="_0">
    <data>94862724882448</data>
</a>
<b class_id="1" object_id="_0" version="0">
</b>

Attack 3: Ownership Confusion Leading to Double Free

The attacker deserializes a std::vector<std::unique_ptr<A>> and edits the serialized XML so that two distinct unique_ptr entries carry the same object_id="_0" reference. This forces the library to assign the same raw pointer (for example, 0x55825bdf2680) to both unique_ptr instances. On destruction, the pointer is freed twice, which triggers heap protections (free(): double free detected in tcache 2) and a crash. The researcher notes that a vector is not strictly necessary: the double free primitive also works with plain arrays or raw pointers. The critical manipulated XML snippet:

<tx class_id="2" tracking_level="1" object_id="_0" version="0">
    <data>16</data>
</tx>
...
<item><tx object_id="_0"></tx></item>

Exploitation Characteristics

The escalation across these three attacks mirrors real world exploitation chains. Information disclosure (the address leak) enables code reuse attacks (VTable hijacking for RCE), while memory corruption primitives (double free) open up more exploitation paths. VulDB rates the attack as remotely exploitable with easy complexity, no privileges required, and no user interaction needed. The CVSS Meta Base Score is 7.3 (HIGH) with a Meta Temp Score of 6.6, and the vulnerability impacts confidentiality, integrity, and availability equally.

Affected Systems and Versions

Every Boost Serialization release from version 1.0 through 1.91 is affected, which covers over two decades of deployments. The vulnerability was confirmed and tested on versions 1.83 and 1.88 specifically. All archive formats the library supports (XML, text, binary) are potentially affected, because the underlying deserialization logic for pointer tracking and object ID resolution is shared across formats.

Any application that uses Boost Serialization to deserialize data from external or untrusted sources is at risk. This includes applications that handle persistent storage, network transmission of object state, or inter process communication using Boost Serialization archives.

Vendor Security History

Boost's security track record shows a pattern common to volunteer maintained open source projects. In May 2024, Shielder audited a subset of Boost C++ libraries with OSTIF and Amazon Web Services, producing five findings, which suggests that systematic security review had been thin before the audit. Historical CVEs include CVE-2023-34399 (an integer overflow in a Boost library) and CVE-2016-9840 (a zlib related vulnerability addressed in Boost.Beast). OpenCVE and OpenHub both track multiple historical vulnerabilities across Boost components.

The maintainer response to CVE-2026-11460 stands out. The researcher (TrebledJ) followed coordinated vulnerability disclosure to the letter: private notification in August 2025, a 90 day deadline, and temporary redaction of details while discussions were ongoing. The maintainer acknowledged the report but postponed it indefinitely, citing time concerns. The GitHub issue (#331) has no labels, no assignees, and no associated pull requests as of the disclosure date. A validated RCE in a foundational library going unpatched because the maintainer lacks bandwidth is a systemic risk in the open source ecosystem, and it reaches well beyond this single CVE.

References

• NVD: CVE-2026-11460
• VulDB: CVE-2026-11460
• VulDB: Vulnerability Entry 369080
• GitHub Issue #331: Insecure Deserialization and Memory Based Confusion
• Coordinated Vulnerability Disclosure Document (TrebledJ)
• EUVD-2026-9118 (European Union Vulnerability Database)
• Boost C++ Libraries Official Site
• Shielder: Boost Security Audit (May 2024)
• Boost CVEs on OpenCVE
• Boost Security Profile on OpenHub
• CISA Known Exploited Vulnerabilities Catalog
• 2026 VulnCheck Exploit Intelligence Report