CVE-2026-68496: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-68496 is a denial-of-service vulnerability in the Smile parser of FasterXML jackson-dataformats-binary caused by failure to enforce the maxNameLength constraint when decoding JSON object property names. The SmileParser._handleLongFieldName() method grows its internal name buffer via an unconstrained _growArrayTo() call without ever invoking StreamReadConstraints.validateNameLength(), allowing an attacker to submit a Smile document with an arbitrarily large property name that is fully buffered in heap memory. Affected versions include com.fasterxml.jackson.dataformat:jackson-dataformat-smile 2.16.0–2.18.9, 2.19.0–2.21.5, and 2.22.0–2.22.1, as well as tools.jackson.dataformat:jackson-dataformat-smile 3.0.0–3.1.5 and 3.2.0–3.2.1. The vulnerability was reported by @tinyb0y, fixed on July 24, 2026, and publicly disclosed on September 30, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Vendor Advisory).

The root cause is CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). When the Smile parser encounters a long field name, it routes through SmileParser._handleLongFieldName(), which calls _growArrayTo() to expand an internal char[] buffer incrementally as it reads name bytes — but never calls StreamReadConstraints.validateNameLength() at any point during this process. This contrasts with jackson-core's JSON parsers, which enforce maxNameLength incrementally during name decoding. Because StreamReadConstraints.maxDocumentLength is also disabled by default (-1), no secondary bound exists under default configuration. The constraint maxNameLength and its associated validateNameLength() method were introduced in jackson-core 2.16.0, so only versions 2.16.0 and later are affected — earlier releases simply lack the constraint mechanism entirely. A related defect in the CBOR parser (_decodeLongerName()) is tracked as CVE-2026-68495 and covered in the same vendor advisory (Vendor Advisory, Issue #726).

Successful exploitation results in complete availability loss of the targeted JVM process through heap memory exhaustion, causing an OutOfMemoryError or application hang. There is no confidentiality or integrity impact — the vulnerability is purely a denial-of-service condition. Any application parsing untrusted Smile input via SmileFactory.createParser() or through a jackson-databind ObjectMapper configured with the Smile module is at risk, including high-throughput inter-service messaging systems that commonly use the Smile binary format (Vendor Advisory).

A public proof-of-concept (BinaryLenVerify.java) is available in the vendor's security advisory, demonstrating successful parsing of a 3,000,000-character property name despite a configured maxNameLength of 10 — confirming the constraint is entirely unenforced. The attack is network-accessible, requires no authentication or user interaction, and is classified as automatable by NVD SSVC. The EPSS score is approximately 0.67% (51st percentile). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog (Vendor Advisory, GitHub Advisory).

1. Identify target: Locate an application that accepts Smile-formatted binary input — either directly via SmileFactory.createParser() or through a jackson-databind ObjectMapper configured with the Smile module. Common targets include REST APIs accepting application/x-jackson-smile content type or inter-service messaging endpoints.
2. Craft malicious Smile document: Using SmileFactory.createGenerator(), construct a Smile document containing a single JSON object with one property whose name is of unbounded length (e.g., 3,000,000 characters). The generator encodes the name with a varint-length prefix in standard Smile binary format — no obfuscation is needed.

   SmileFactory f = new SmileFactory();
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   JsonGenerator g = f.createGenerator(out);
   g.writeStartObject();
   StringBuilder name = new StringBuilder();
   for (int i = 0; i < 3_000_000; i++) name.append((char)('a' + (i % 26)));
   g.writeName(name.toString());
   g.writeString("v");
   g.writeEndObject();
   g.close();
   byte[] payload = out.toByteArray(); // ~3 MB binary payload

3. Deliver payload: Submit the raw binary payload to the target parsing endpoint via HTTP POST (with appropriate Content-Type: application/x-jackson-smile header), a message queue, or any channel that reaches the Smile parsing code. No authentication or special framing is required.
4. Trigger memory exhaustion: The target application calls p.nextToken() on the malicious document. When the PROPERTY_NAME token is reached, SmileParser._handleLongFieldName() buffers the entire 3,000,000-character name in memory without invoking validateNameLength(), consuming approximately 6 MB of heap per document (2 bytes per Java char).
5. Achieve denial of service: By sending multiple such requests concurrently or repeatedly, the attacker exhausts the JVM heap, causing OutOfMemoryError and rendering the service unavailable (Vendor Advisory).

• Network: Unusual HTTP POST requests with Content-Type: application/x-jackson-smile (or equivalent binary content type) containing payloads of several megabytes directed at parsing endpoints; repeated large binary submissions from the same source IP.
• Logs: Java application logs showing OutOfMemoryError or heap exhaustion errors correlated with incoming binary parse requests; JVM GC logs showing sustained full GC activity or GC overhead limit exceeded errors during request processing.
• Process: JVM process exhibiting rapidly increasing heap usage during request handling; application threads blocked or hung in SmileParser._handleLongFieldName() or _growArrayTo() as visible in thread dumps.
• Application: Service becoming unresponsive or crashing shortly after receiving large binary payloads; health check endpoints timing out following ingestion of Smile-formatted data.

Upgrade to patched versions of jackson-dataformats-binary: for the 2.x line, use 2.18.10, 2.21.6, or 2.22.2 depending on your current branch; for the 3.x line, use 3.1.6 or 3.2.2. As a temporary workaround, explicitly configure StreamReadConstraints with a bounded maxNameLength value at the application level — note this alone is insufficient until the patch is applied, since the constraint is not enforced by the vulnerable parser. Additionally, enforce upload size limits at the network or application gateway layer to bound the maximum payload size reaching the parser, and monitor JVM heap usage for parsing operations that handle untrusted Smile input (Issue #726, Vendor Advisory).

SUSE issued a security update announcement (SUSE-SU-2026:4394-1) addressing this vulnerability in their supported packages. Tenable published Nessus detection plugins (IDs 351412 and 362621) to identify vulnerable installations. The vulnerability was also covered by pro-linux.de in the context of broader jackson security issues. No significant independent researcher commentary or social media discussion beyond standard vulnerability aggregator coverage has been observed (SUSE Advisory, Tenable Plugin).