CVE-2026-106448 in StableLib
Summary
by MITRE • 10/06/2026
StableLib is a stable library of useful TypeScript and JavaScript code. Prior to 2.0.4, the @stablelib/cbor CBOR map decoding path creates ordinary JavaScript objects and assigns attacker-controlled keys with bracket assignment. A map key named __proto__ invokes the inherited prototype setter instead of creating an ordinary own property, allowing the decoded object's prototype to contain attacker-controlled authorization or feature-flag values. Downstream code that trusts normal property lookup or merges the decoded object can therefore make security-sensitive decisions using inherited attacker data. This issue is fixed in version 2.0.4.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified within StableLib versions prior to 2.0.4 represents a classic prototype pollution attack vector embedded within its CBOR decoding implementation. The core technical flaw lies in how the library handles map keys during the deserialization process. Specifically, when decoding a CBOR map, the library creates standard JavaScript objects and assigns properties using bracket notation based on the input data. In JavaScript, object property assignment via brackets does not inherently distinguish between own properties and inherited prototype properties unless specific checks are performed. Consequently, if an attacker crafts a malicious payload containing a key named _proto_, the assignment operation triggers the setter for the Object.prototype._proto_ rather than creating a new enumerable own property on the decoded instance. This behavior allows the attacker to directly modify the internal [[Prototype]] of the object being constructed or any subsequent objects that inherit from it, effectively polluting the global prototype chain if not properly isolated.
The operational impact of this vulnerability is significant because it undermines the integrity of security-sensitive decisions made by downstream applications relying on StableLib for data parsing. Many JavaScript frameworks and libraries assume that properties accessed via standard dot notation are own properties or safely inherited values from trusted sources. When an attacker successfully injects keys such as _proto_, isAdmin, or featureFlag into the prototype chain, any code performing a simple property lookup may inadvertently retrieve these maliciously injected values instead of expected defaults or legitimate data. For instance, if an application checks for user privileges by looking up an isAdministrator flag on a decoded object, it might return true due to the polluted prototype rather than actual authentication state. Similarly, feature flags used to enable or disable security controls could be manipulated, leading to unauthorized access or bypass of critical safeguards. This type of attack is particularly dangerous because it can occur silently without throwing errors, making detection difficult for developers who do not explicitly validate input keys against a whitelist of allowed property names.
From an industry standards perspective, this vulnerability aligns with CWE-1321: Prototype Pollution and is often associated with the MITRE ATT&CK technique T1508: Exploitation for Defense Evasion or more broadly under injection-based attacks where untrusted data influences control flow. The root cause stems from a failure to enforce strict input validation on object keys during deserialization, which violates secure coding principles regarding the handling of dynamic property names in JavaScript environments. To mitigate this risk, developers must ensure that any library used for parsing external or semi-trusted data implements robust checks against prototype pollution vectors. This includes verifying that map keys do not match dangerous properties such as _proto_, constructor, and prototype before assignment. Alternatively, using Object.create(null) to create objects without a prototype chain can prevent inheritance-based attacks entirely, although this requires careful handling of existing codebases that rely on standard object methods. Upgrading to StableLib version 2.0.4 or later is the primary remediation step as it addresses these internal logic flaws by implementing safer property assignment mechanisms that do not inadvertently trigger prototype setters. Organizations should also conduct a thorough review of their dependency tree for other libraries performing similar deserialization tasks and apply equivalent hardening measures, such as using JSON.parse with custom reviver functions or dedicated safe-object creation utilities to ensure data integrity during parsing operations.