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

CVE-2026-68495 is a denial-of-service vulnerability in FasterXML's jackson-dataformats-binary library caused by missing maxNameLength enforcement in the CBOR parser. The CBOR parser never invokes StreamReadConstraints.validateNameLength() when decoding JSON object property names, allowing an attacker to submit a document with an unbounded property name that exhausts heap memory. It affects com.fasterxml.jackson.dataformat:jackson-dataformat-cbor versions 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-cbor versions 3.0.0–3.1.5 and 3.2.0–3.2.1. The vulnerability was reported by tinyb0y, fixed in July 2026, and publicly disclosed via GitHub Security Advisory on September 30, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, GitHub Issue).

The root cause is uncontrolled resource consumption (CWE-400) and allocation without limits (CWE-770) in two CBOR parser methods. CBORParser._decodeLongerName() decodes definite-length property names with no call to validateNameLength(), and CBORParser._decodeChunkedName() delegates to _finishChunkedText(), which validates maxStringLength instead of maxNameLength. As a result, the parser buffers the entire property name in heap memory before returning it, regardless of any configured maxNameLength constraint. Because StreamReadConstraints.maxDocumentLength is disabled by default (value -1), no secondary bound exists under default settings. By contrast, jackson-core's JSON parsers enforce maxNameLength incrementally during name decoding — this gap is specific to the binary format parsers. Exploitation requires only that attacker-controlled CBOR bytes reach CBORFactory parsing, directly or via an ObjectMapper configured with the CBOR module (GitHub Advisory).

Successful exploitation causes memory exhaustion (heap OutOfMemoryError) or severe garbage-collection thrashing in the JVM hosting the parsing service, resulting in a denial of service. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Any application that parses untrusted CBOR input (e.g., IoT/constrained-device protocols, RPC endpoints, or high-throughput inter-service messaging) is at risk, and no StreamReadConstraints configuration can prevent the attack on affected versions (GitHub Advisory).

A proof-of-concept (BinaryLenVerify.java) is publicly available in the GitHub Security Advisory, demonstrating that a 3,000,000-character property name bypasses maxNameLength=10 and parses successfully in both CBOR and Smile formats. The exploit requires no authentication, no user interaction, and no special privileges — only the ability to submit data to a CBOR-parsing endpoint. The EPSS score is 0.00666 (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the advisory date. The NVD SSVC assessment classifies exploitation status as "poc" and automatable as "yes" (GitHub Advisory, Feedly).

1. Identify target: Locate an application that accepts CBOR-encoded input (e.g., an HTTP endpoint, message queue consumer, or RPC service) using CBORFactory or ObjectMapper with the CBOR module from an affected version of jackson-dataformat-cbor.
2. Craft malicious CBOR document: Using any CBOR library or the PoC generator, serialize a JSON object containing a single property name of extreme length (e.g., 3,000,000 characters) into CBOR binary format. The resulting document is a legitimate CBOR encoding — no obfuscation is needed.
3. Submit the document: Deliver the crafted CBOR byte sequence to the target parsing endpoint via HTTP upload, message queue publish, or any other available ingress channel.
4. Trigger unbounded allocation: The CBOR parser invokes _decodeLongerName() or _decodeChunkedName(), neither of which calls validateNameLength(). The parser allocates and buffers the entire multi-megabyte name in heap memory.
5. Exhaust heap: Repeat submissions with progressively larger names or concurrent requests until available JVM heap is exhausted, triggering OutOfMemoryError and crashing or severely degrading the target service (GitHub Advisory).

• Network: Unusually large CBOR-encoded HTTP request bodies (multi-megabyte payloads) submitted to parsing endpoints; repeated large uploads from the same source IP in a short time window.
• Logs: JVM OutOfMemoryError or heap exhaustion errors in application logs coinciding with CBOR parsing activity; java.lang.OutOfMemoryError: Java heap space stack traces originating from CBORParser._decodeLongerName() or CBORParser._decodeChunkedName().
• Process: Sudden spike in JVM heap usage followed by garbage-collection thrashing or process crash; application health checks failing immediately after large CBOR document ingestion.
• File System: Heap dump files (.hprof) generated by the JVM on OutOfMemoryError if -XX:+HeapDumpOnOutOfMemoryError is configured, potentially containing the oversized property name string in memory.

Upgrade to a patched version of jackson-dataformat-cbor: 2.18.10, 2.21.6, or 2.22.2 for the com.fasterxml.jackson.dataformat artifact, and 3.1.6 or 3.2.2 for the tools.jackson.dataformat artifact. The fix adds incremental validateNameLength() calls within CBOR name-decoding routines. As a defense-in-depth measure, explicitly configure StreamReadConstraints with a maxDocumentLength limit (disabled by default) to provide a secondary bound on document size. If immediate upgrade is not possible, consider placing an upstream request-size limit (e.g., via a reverse proxy or API gateway) to restrict the maximum body size of CBOR payloads accepted by the application (GitHub Advisory, GitHub Issue, Release Notes).

The vulnerability was reported by security researcher tinyb0y and fixed by FasterXML maintainer cowtowncoder (Tatu Saloranta) in July 2026, with the fix included in the 2.18.10 milestone. The Apache Spark project promptly upgraded to Jackson 2.22.2 in response (SPARK-59393). SUSE issued a security update (SUSE-SU-2026:4394-1) addressing this and related Jackson CVEs. Tenable published Nessus detection plugins (IDs 351412 and 362621) for the vulnerability (GitHub Issue, SUSE Advisory, Tenable).