CVE-2026-68495: FasterXML Jackson CBOR Parser DOS Vulnerability

CVE-2026-68495 Overview

CVE-2026-68495 is a resource exhaustion vulnerability [CWE-400] in the Concise Binary Object Representation (CBOR) parser of FasterXML jackson-dataformats-binary. The parser never invokes StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the configured maxNameLength limit has no effect. An attacker who can submit CBOR data to a parsing endpoint can embed a single property name of unbounded length, forcing the parser to buffer the entire name in memory. The defect is tracked under vendor advisory GHSA-3v8f-v6vx-fmrm alongside the related Smile parser issue CVE-2026-68496.

Critical Impact
Remote, unauthenticated attackers can trigger memory exhaustion and denial of service against any service that parses attacker-controlled CBOR documents through CBORFactory or an ObjectMapper configured with the CBOR module.

Affected Products

FasterXML jackson-dataformats-binary CBOR module (releases 2.16.0 and later, where maxNameLength was introduced but is not enforced for CBOR)
Any Java application using CBORFactory directly to parse untrusted CBOR
Any application using an ObjectMapper configured with the Jackson CBOR module on untrusted input

Discovery Timeline

2026-10-01 - CVE-2026-68495 published to the National Vulnerability Database
2026-10-02 - Last updated in NVD database

Technical Details for CVE-2026-68495

Vulnerability Analysis

The defect sits in how the CBOR parser handles property name decoding. CBORParser._decodeLongerName() decodes a definite-length property name without applying any length check. CBORParser._decodeChunkedName() delegates to the value-oriented _finishChunkedText() routine, which validates maxStringLength instead of maxNameLength. Neither path calls StreamReadConstraints.validateNameLength(), so the configured name limit is never consulted during CBOR decoding.

Jackson's JSON parsers in jackson-core enforce maxNameLength incrementally during name decoding. The gap is specific to the binary formats. Because StreamReadConstraints.maxDocumentLength is also disabled by default, no secondary bound applies under default settings. The only effective limits become the attacker's upload capacity and available Java heap.

Root Cause

The root cause is a missing invocation of StreamReadConstraints.validateNameLength() in the CBOR name-decoding paths. The maxNameLength constraint and its validator were introduced in jackson-core 2.16.0, but the CBOR parser never wired them into property-name decoding. Releases before 2.16.0 do not contain the constraint at all, so the gap is specific to how later versions integrated the control.

Attack Vector

Exploitation requires only the ability to deliver bytes to a parsing endpoint. The attacker crafts a CBOR document containing one object property whose name field uses a very large definite length or an unbounded chunked encoding. When the parser reads the key, it allocates a buffer sized to the declared or streamed length and reads the full value into memory before returning. Repeated or sufficiently large requests exhaust the heap, producing OutOfMemoryError and denial of service across the affected JVM process.

No authentication or user interaction is required. Any HTTP, message queue, or RPC endpoint that deserializes untrusted CBOR into Jackson is reachable. See the GitHub Security Advisory GHSA-3v8f-v6vx-fmrm for technical details.

Detection Methods for CVE-2026-68495

Indicators of Compromise

Repeated java.lang.OutOfMemoryError: Java heap space events in application logs correlated with CBOR-accepting endpoints
Abnormally large request bodies with Content-Type: application/cbor or custom CBOR media types
Thread dumps showing threads blocked in CBORParser._decodeLongerName() or _finishChunkedText()
Sudden spikes in old-generation heap usage immediately after inbound CBOR traffic

Detection Strategies

Inspect dependency manifests (Maven, Gradle, SBOMs) for com.fasterxml.jackson.dataformat:jackson-dataformat-cbor at vulnerable versions
Instrument CBOR parsing paths with request-size histograms and alert on outlier payload sizes
Add JVM garbage collection and heap monitoring to flag rapid allocation bursts during deserialization
Review application code for direct CBORFactory usage or ObjectMapper instances registered with CBORFactory

Monitoring Recommendations

Forward JVM metrics and garbage collection logs to a centralized analytics platform for anomaly detection
Alert on HTTP 5xx surges coinciding with CBOR endpoint traffic
Enable Web Application Firewall (WAF) logging for binary content types and track payload size distributions

How to Mitigate CVE-2026-68495

Immediate Actions Required

Upgrade jackson-dataformats-binary to a fixed release listed in advisory GHSA-3v8f-v6vx-fmrm
Enforce request body size limits at the reverse proxy, API gateway, or servlet container for endpoints that accept CBOR
Audit services for untrusted CBOR deserialization paths and restrict exposure where feasible
Set an explicit StreamReadConstraints.maxDocumentLength on CBORFactory instances to bound total input size

Patch Information

Fixes are tracked under jackson-dataformats-binary issue #725 and distributed through advisory GHSA-3v8f-v6vx-fmrm. Review the jackson-dataformats-binary 2.x release notes for the specific patched version and upgrade to that release or later. The related Smile parser defect is tracked as CVE-2026-68496 and should be remediated together.

Workarounds

Configure a strict maxDocumentLength on StreamReadConstraints for CBORFactory to bound total input processed per document
Reject inbound CBOR requests above a conservative byte threshold at the network edge before they reach the JVM
Disable CBOR deserialization on endpoints that do not require it until the dependency is upgraded
Isolate services that must parse untrusted CBOR with per-process heap limits and automatic restart policies

bash

# Configuration example: bound CBOR document size via StreamReadConstraints
# Apply when constructing CBORFactory in application code
#
#   StreamReadConstraints constraints = StreamReadConstraints.builder()
#       .maxDocumentLength(1_048_576)   // 1 MiB cap on total document bytes
#       .maxStringLength(50_000)        // conservative string cap
#       .build();
#   CBORFactory factory = CBORFactory.builder()
#       .streamReadConstraints(constraints)
#       .build();
#
# Also enforce an upstream body size limit, for example in nginx:
client_max_body_size 1m;