ZeroPath at Black Hat USA 2026

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

A brief summary of CVE-2026-11460, a high severity deserialization flaw in Boost Serialization (versions 1.0 through 1.91) that enables type confusion, VTable hijacking, and double free attacks with no patch available.

CVE Analysis

10 min read

ZeroPath CVE Analysis
ZeroPath CVE Analysis

2026-06-07

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

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A deserialization flaw in Boost Serialization allows an attacker to achieve arbitrary code execution by crafting a malicious archive that exploits improper validation of internal metadata fields, and the maintainer has postponed fixing it indefinitely. With a public proof of concept demonstrating root shell access available since October 2025 and every version of the library from 1.0 through 1.91 affected, this vulnerability represents a significant and growing risk for the enormous number of C++ applications that depend on Boost Serialization across finance, embedded systems, telecommunications, and critical infrastructure.

Technical Information

Root Cause

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

As 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." Similarly, "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 multiple CWEs reflecting its multi faceted nature:

CWE IDCWE NameRole in Vulnerability
CWE-20Improper Input ValidationRoot cause: archive metadata fields not validated
CWE-1287Improper Validation of Specified Type of InputSpecific: object_id and tracking_level type not checked
CWE-502Deserialization of Untrusted DataEnabling condition: untrusted archive content deserialized
CWE-843Access of Resource Using Incompatible Type (Type Confusion)Attack outcome: objects of different classes share memory
CWE-415Double FreeAttack outcome: ownership confusion causes double free

Attack Flow

The disclosure documents three concrete attacks, each building on the previous to escalate impact. All attacks 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 library is tricked into pointing b at the memory of a. When b->data is interpreted 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 is critical because it undermines ASLR protections, making subsequent 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. A global table containing a pointer to a pwned() function is created, and its address is leaked using the technique from Attack 1. The attacker then writes this leaked address into the <data> field of object a and applies the same object ID confusion. Upon deserialization, b's v pointer is overwritten, and calling the virtual function b->foo() executes pwned() instead. The disclosure demonstrates 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 modifies the serialized XML so that two distinct unique_ptr entries contain the same object_id="_0" reference. This forces the library to assign the same raw pointer (e.g., 0x55825bdf2680) to both unique_ptr instances. Upon destruction, the pointer is freed twice, triggering 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 can be achieved 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 pattern across these three attacks mirrors typical real world exploitation chains: information disclosure (address leak) enables code reuse attacks (VTable hijacking for RCE), while memory corruption primitives (double free) provide additional exploitation pathways. 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. This represents over two decades of library deployments. The vulnerability was confirmed and tested on versions 1.83 and 1.88 specifically. All archive formats supported by the library (XML, text, binary) are potentially affected, as 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 performing persistent storage, network transmission of object state, or inter process communication using Boost Serialization archives.

Vendor Security History

Boost's security track record reveals a pattern common to volunteer maintained open source projects. In May 2024, Shielder performed a security audit on a subset of Boost C++ libraries in partnership with OSTIF and Amazon Web Services, resulting in five findings, which indicated that systematic security review had been insufficient prior to 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 is particularly notable. The researcher (TrebledJ) followed exemplary coordinated vulnerability disclosure protocol: 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 indefinitely citing time concerns. The GitHub issue (#331) has no labels, no assignees, and no associated pull requests as of the disclosure date. This outcome, where a validated RCE vulnerability in a foundational library goes unpatched due to maintainer bandwidth constraints, highlights a systemic risk in the open source ecosystem that extends well beyond this single CVE.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Jira
  • Linear
  • Slack
  • Security Compass
Security magnifying glass visualization