CVE-2026-68496: FasterXML Smile Parser DOS Vulnerability

CVE-2026-68496 Overview

CVE-2026-68496 is a denial-of-service vulnerability in the Smile parser of FasterXML jackson-dataformats-binary. The parser never calls StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the configured maxNameLength limit is not enforced for the Smile binary format. An attacker who can submit a Smile document to a parsing endpoint can embed a single property name of unbounded length. The parser buffers the entire name in memory through an unconstrained _growArrayTo() call, leading to memory exhaustion. The issue is tracked alongside the related CBOR parser defect (CVE-2026-68495) in advisory GHSA-3v8f-v6vx-fmrm.

Critical Impact
Remote, unauthenticated attackers can trigger heap exhaustion and process-level denial of service against any service that parses attacker-supplied Smile data.

Affected Products

FasterXML jackson-dataformats-binary — Smile format module
Applications using SmileFactory directly for parsing untrusted input
Applications using ObjectMapper configured with the Smile module

Discovery Timeline

2026-10-01 - CVE-2026-68496 published to NVD
2026-10-02 - Last updated in NVD database

Technical Details for CVE-2026-68496

Vulnerability Analysis

The defect lives in SmileParser._handleLongFieldName(), which decodes long JSON object property names from Smile-encoded input. The method grows its internal name buffer through _growArrayTo() without consulting StreamReadConstraints.validateNameLength(). As a result, the maxNameLength constraint introduced in jackson-core 2.16.0 is silently ignored for the Smile format. The vulnerability is classified as uncontrolled resource consumption [CWE-400].

By contrast, the JSON parsers in jackson-core enforce maxNameLength incrementally during name decoding. The gap is specific to the binary formats, with the same class of defect present in the CBOR parser tracked as CVE-2026-68495.

Root Cause

The root cause is a missing input validation step. SmileParser._handleLongFieldName() performs no length check before expanding its name buffer. Because StreamReadConstraints.maxDocumentLength is also disabled by default, no other constraint bounds the field name. Under default settings, the only limits are the attacker's upload capacity and the available Java heap.

Attack Vector

Exploitation requires only that attacker-controlled bytes reach SmileFactory parsing, directly or via an ObjectMapper configured with the Smile module. No authentication, user interaction, or elevated privileges are required. An attacker crafts a Smile document containing a single object property whose name header advertises an extremely large length. The parser allocates and grows an internal buffer to hold the entire name before returning control. Repeated or large-enough requests exhaust process heap and crash the JVM, producing a persistent denial of service.

See the GitHub Security Advisory GHSA-3v8f-v6vx-fmrm and GitHub Issue #726 for upstream technical details.

Detection Methods for CVE-2026-68496

Indicators of Compromise

Java processes terminating with OutOfMemoryError after receiving requests to endpoints that accept Smile (application/x-jackson-smile) payloads.
Sudden heap growth and garbage collection pressure correlated with inbound requests carrying the Smile magic header 0x3A 0x29 0x0A.
Large request bodies to endpoints known to deserialize binary Jackson formats, especially where request size does not match expected business payloads.

Detection Strategies

Inventory applications that import jackson-dataformats-binary and identify any that register SmileFactory or the Smile module with an ObjectMapper.
Enable JVM heap monitoring and alert on abnormal allocation spikes tied to parsing threads.
Inspect HTTP and message-queue payloads for the Smile signature when the endpoint is not explicitly expected to accept binary Jackson input.

Monitoring Recommendations

Collect application logs and JVM crash dumps centrally to correlate OutOfMemoryError events with inbound request metadata.
Add request-size limits at the reverse proxy or API gateway and alert on payloads exceeding business-defined thresholds.
Track dependency versions of jackson-dataformats-binary in CI/CD pipelines and flag releases that remain on vulnerable versions.

How to Mitigate CVE-2026-68496

Immediate Actions Required

Upgrade jackson-dataformats-binary to the fixed release identified in GHSA-3v8f-v6vx-fmrm and the 2.x release notes.
Reject or hard-limit the size of any request body that reaches an endpoint parsing Smile data.
Disable Smile parsing entirely on endpoints that do not require it.

Patch Information

The maintainers fixed the defect in the Smile module of jackson-dataformats-binary as tracked in GitHub Issue #726. Consult the 2.x release notes for the exact fixed version and apply the upgrade to all services that transitively depend on the library. Releases prior to jackson-core 2.16.0 do not contain the maxNameLength constraint at all and should be upgraded regardless.

Workarounds

Configure a strict StreamReadConstraints.maxDocumentLength on the SmileFactory so that oversized documents fail before the long-name buffer grows.
Enforce request-size limits at the ingress tier (load balancer, API gateway, or servlet filter) to cap attacker-controlled payload size.
Isolate services that must accept Smile input in resource-limited containers so that a crash does not affect co-located workloads.

bash

# Configuration example: enforce document-length bound on SmileFactory
# (Java pseudocode shown as a config reference)
#
# StreamReadConstraints constraints = StreamReadConstraints.builder()
#     .maxDocumentLength(1_048_576)   // 1 MiB cap on parsed document size
#     .maxNameLength(32_768)          // reinforce once upstream fix is deployed
#     .build();
# SmileFactory factory = SmileFactory.builder()
#     .streamReadConstraints(constraints)
#     .build();
# ObjectMapper mapper = new ObjectMapper(factory);