Description

The Smile parser in FasterXML jackson-dataformats-binary never invokes StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the maxNameLength limit is not enforced for this format. SmileParser._handleLongFieldName() grows its internal name buffer through an unconstrained _growArrayTo() call and performs no length validation. An attacker who can have a Smile document parsed may therefore embed a single property name of unbounded length; the parser buffers the whole name in memory before returning it, whatever maxNameLength is configured to. Because StreamReadConstraints.maxDocumentLength is also disabled by default, nothing else bounds the name under default settings, so the only limits are the attacker's upload capacity and available heap, leading to memory exhaustion and denial of service. No privileges beyond the ability to submit data to a parsing endpoint are required, and exploitation needs only that the bytes reach SmileFactory parsing, directly or through an ObjectMapper configured with the Smile module. jackson-core's own JSON parsers enforce maxNameLength incrementally during name decoding; this gap is specific to the binary formats. maxNameLength and validateNameLength were introduced in jackson-core 2.16.0, so releases before 2.16.0 do not contain the constraint that is left unenforced. This issue is tracked together with the CBOR parser defect in the same vendor advisory, GHSA-3v8f-v6vx-fmrm, which covers both binary formats. The Smile parser defect (jackson-dataformats-binary issue #726) is CVE-2026-68496; the CBOR parser defect (issue #725) is assigned CVE-2026-68495.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-01T18:17:27.360Z",
  "pubdate": "2026-10-01T18:17:27.360Z",
  "executiveSummary": "The Smile parser within FasterXML jackson-dataformats-binary is susceptible to a denial-of-service (DoS) vulnerability due to improper input validation.\nThe vulnerability occurs because the parser fails to enforce 'maxNameLength' constraints during the decoding of JSON object property names, leading to unconstrained memory allocation.\nAffected products include FasterXML jackson-dataformats-binary versions 2.16.0 and later, as these versions introduced the constraints that the Smile format fails to implement.\nAn unauthenticated attacker can exploit this flaw by submitting a specially crafted Smile document containing a property name of arbitrary length.\nThe parser attempts to buffer the entire name into the heap without validation, which allows an attacker to exhaust system memory and cause a crash.\nNo specific privileges are required; the only prerequisite is the ability to send data to a parsing endpoint that utilizes the SmileFactory or an ObjectMapper configured with the Smile module.\nThe risk is categorized as high, as it facilitates a resource-exhaustion DoS attack targeting the application's memory pool.",
  "technicalDetails": "The root cause of CVE-2026-68496 lies in the failure of the SmileParser to invoke StreamReadConstraints.validateNameLength() during the parsing of binary JSON object keys. While Jackson-core introduced these constraints in version 2.16.0 to mitigate resource exhaustion, the Smile format implementation bypasses these security checks.\nWhen the SmileParser encounters a property name, it delegates the handling of long field names to the SmileParser._handleLongFieldName() method. This method utilizes an unconstrained call to _growArrayTo(), which dynamically expands an internal buffer to accommodate the size of the incoming key. Because there is no check against the 'maxNameLength' configuration property, the buffer continues to grow linearly with the length of the malicious field name provided in the input stream.\nThe attack flow begins when a remote, unauthenticated attacker transmits a Smile-encoded payload to an endpoint serviced by a vulnerable Jackson component. The payload includes a property name with an extremely large byte length. As the Smile parser processes the binary input, it identifies the long property name and allocates heap memory to store the full string representation of this key before returning it to the calling application.\nSince the default configuration for 'maxDocumentLength' is also unbounded, the parser does not stop the execution until the system heap is exhausted, leading to an OutOfMemoryError (OOM) and subsequent service unavailability.\nThe vulnerability is specific to the binary formats within the jackson-dataformats-binary suite, as standard JSON parsers in jackson-core correctly enforce these constraints incrementally. This creates a disparity in security postures between plain text JSON and binary formats (Smile and CBOR) processed by the same library. Exploitation is possible through any ObjectMapper that is initialized with the Smile module, making applications that support binary input formats specifically vulnerable to this memory-based DoS attack vector."
}