jackson-dataformats-binary CVE-2026-68496

Exploitation requires that the target application parse input using the Smile binary dataformat - specifically that attacker-supplied bytes reach SmileFactory parsing directly or via an ObjectMapper configured with the Smile module; applications using only standard JSON parsing are unaffected because jackson-core's JSON parsers enforce maxNameLength incrementally. The affected library must be a 2.16.0-or-later release (earlier releases lack the maxNameLength constraint entirely and are a separate consideration). No authentication is required (PR:N) and the default configuration is vulnerable because StreamReadConstraints.maxNameLength is not enforced for Smile and maxDocumentLength is disabled by default, so the only practical limits are the attacker's upload capacity and available heap. The main limiting factor is simply whether Smile parsing is exposed to untrusted input.

This is a credible but bounded-impact vulnerability. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H) is internally consistent with the description: a remote attacker needs only to submit a Smile document to a parsing endpoint, with no privileges or user interaction, and the sole impact is availability (memory exhaustion / DoS) - there is no confidentiality or integrity impact, which correctly caps the severity at 7.5 (High) rather than Critical. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit code is referenced, so there is no public exploit identified at time of analysis - meaning there is no evidence of active exploitation. The practical risk is tempered by a key precondition the raw CVSS does not capture: the application must actually parse the Smile binary format (via SmileFactory or an ObjectMapper with the Smile module), which is far less common than default JSON parsing. The signals therefore align rather than conflict: a genuinely network-reachable, unauthenticated, low-complexity DoS, but one whose real-world blast radius depends on Smile being in use. Note the input CPE for jackson-dataformats-binary uses a wildcard version with no fixed-version boundary, so affected/fixed ranges should be verified against GHSA-3v8f-v6vx-fmrm; the description clarifies the constraint (maxNameLength) only exists from jackson-core 2.16.0 onward.

An attacker identifies a service that accepts and deserializes Smile-format input (for example an API endpoint using an ObjectMapper configured with the Smile module). The attacker uploads a single crafted Smile document containing one object property name of enormous length; because SmileParser._handleLongFieldName() grows its buffer via an unconstrained _growArrayTo() and never calls validateNameLength(), the parser buffers the entire name in heap before returning, exhausting memory and causing a denial of service. No public exploit is identified, but the technique is trivial given the described defect.