Jackson Dataformats Binary CVE-2026-68495

Exploitation requires that attacker-controlled bytes reach CBOR parsing - specifically CBORFactory, or an ObjectMapper configured with the jackson CBOR dataformat module - so the application must accept and deserialize CBOR input from untrusted sources. No authentication or user interaction is needed (PR:N/UI:N). The flaw is reachable under default settings because StreamReadConstraints.maxDocumentLength is disabled by default and maxNameLength is never checked for CBOR, so no configuration hardening currently bounds the property-name length. Limiting factors that reduce real-world exposure: the app must actually expose a CBOR-parsing path to untrusted data (JSON-only or non-Jackson endpoints are unaffected), the installed jackson version must be 2.16.0 or later (pre-2.16.0 never had the constraint to enforce), and practical impact is bounded by the attacker's upload capacity and the victim's available heap. The companion Smile-parser defect is tracked separately as CVE-2026-68496.

All signals point to a genuine but bounded availability-only risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: a remote, unauthenticated attacker needs only to get CBOR bytes to a parsing endpoint, with no user interaction and low complexity, and the impact is purely availability (memory exhaustion/DoS) - no confidentiality or integrity effect, matching CWE-770 (unbounded resource allocation). Exploitation status is 'no public exploit identified at time of analysis': the input provides no EPSS score, no KEV listing, and no POC flag, so there is no evidence of active or automated exploitation. This is therefore a real patch-worthy issue for exposed CBOR-parsing services rather than an emergency: the realistic worst case is a crash/outage, not code execution or data theft. Note two caveats to verify: EPSS and KEV data are absent (not zero - simply not supplied), so widespread-exploitation probability cannot be quantified from this data; and exploitability depends on an application actually exposing jackson CBOR parsing to untrusted input, which the CVE metadata cannot confirm for any given deployment.

An attacker submits a crafted CBOR document to an application endpoint that deserializes it via CBORFactory or a CBOR-configured ObjectMapper. The document contains a single JSON object property name of enormous (effectively unbounded) length, which the parser buffers entirely in memory before returning it; because maxNameLength is never enforced for CBOR and maxDocumentLength is disabled by default, the JVM heap is exhausted, crashing or hanging the service. No public exploit code is identified at time of analysis, though the defect is trivially reproducible from the detailed advisory.