lib0 CVE-2026-102521

Requires an application that uses lib0's decoder (directly, or transitively via Yjs) to decode attacker-supplied binary/serialized input, where the decoder's backing Uint8Array is a view onto a larger ArrayBuffer - notably Node's shared/pooled Buffer produced by base64 decoding (fromBase64Node) or any subarray/sliced view. The over-read paths are the decoder view constructions in readFromDataView / readUint8Array / peekVarString that built new Uint8Array(arr.buffer, ...) / new DataView(arr.buffer, ...) without bounding to arr's own length. Limiting factors: the leaked bytes are whatever is adjacent in the pooled/backing buffer (opportunistic, not attacker-selected), the decoded output must be observable/returned to the attacker to exfiltrate the leak, and the target must run a version before 0.2.119; there is no code-execution or integrity/availability impact.

This is a genuine priority, not high-CVSS noise, though the impact class is disclosure rather than code execution. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N = 8.6) describes a network-reachable, low-complexity, unauthenticated flaw with a scope change and high confidentiality impact, and that is consistent with the mechanism: lib0's decoder processes untrusted serialized input and can be made to read past its view into adjacent process heap memory. Signals are mixed on likelihood: there is no CISA KEV listing and no EPSS score supplied, and the references are only a vendor GitHub Security Advisory (GHSA-g75x-89c3-rvmr) and the fix commit - no weaponized proof-of-concept is provided (the diff includes a regression test that demonstrates the bounds failure, but that is not a public exploit). The confidentiality rating is also opportunistic: an attacker leaks whatever bytes happen to be adjacent (potentially credentials or logs, per the advisory) rather than arbitrarily chosen memory, so real-world value per attempt varies. Net: elevated priority because lib0 is a very widely pulled dependency (chiefly via Yjs) and the trigger is default decoder behavior, tempered by the absence of active-exploitation or POC evidence and the read-only, opportunistic nature of the leak.

An attacker sends crafted serialized/encoded data to an application that deserializes untrusted input with lib0's decoder (for example a Yjs-based real-time collaboration backend accepting sync/update messages, or any service base64-decoding attacker data via lib0). Because the decoder builds a view onto the underlying (possibly Node-pooled) ArrayBuffer without bounding it to its own view, a length that exceeds the intended view causes the decoder to return adjacent process memory in the decoded output. No public exploit code is identified at time of analysis, though the fix commit ships a regression test that reproduces the out-of-bounds read.