CVE-2026-106554: 
Java vulnerability analysis and mitigation

CVE-2026-106554 is an algorithmic complexity vulnerability (CWE-407) in FasterXML's jackson-dataformat-cbor CBOR parsing module that causes quadratic-time CPU and garbage collection exhaustion via unbounded stacked CBOR tags, resulting in a denial-of-service condition. It was reported by apvxlab (AppViewX security research) and v0xyc0n (jpac.at), with the GitHub Security Advisory (GHSA-cjg7-h3pr-p927) published on October 22, 2026, and the CVE formally published on November 4, 2026. Affected versions include com.fasterxml.jackson.dataformat:jackson-dataformat-cbor 2.15.0–2.18.11, 2.19.0–2.21.7, and 2.22.0–2.22.3, as well as tools.jackson.dataformat:jackson-dataformat-cbor 3.0.0–3.1.7 and 3.2.0–3.2.3. The vulnerability is rated Moderate severity by FasterXML (GitHub Advisory, Feedly).

The root cause is an inefficient algorithmic complexity flaw (CWE-407) in CBORParser.java within the jackson-dataformats-binary CBOR module. The CBOR specification allows a data item to be preceded by any number of semantic tag bytes; the parser accumulates these in a TagList whose backing array grows by a fixed increment of +8 elements rather than doubling, and re-scans/copies the array on each growth. This makes accumulating N stacked tags O(N²) in both CPU time and GC pressure, with no configurable cap on the number of tags. A PoC was executed against version 2.18.2 on JDK 17 by sending a CBOR stream with a long run of tag bytes (e.g., 0xC0+) before a trivial value, causing parse time to grow super-linearly and pin a request thread indefinitely (GitHub Advisory).

Successful exploitation causes an algorithmic-complexity denial of service: a single crafted CBOR input with a large number of stacked tags pins a request-handling thread due to quadratic CPU and GC consumption, and concurrent such requests can exhaust the thread pool entirely, rendering the service unavailable. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Any application that accepts and parses untrusted CBOR data using the affected library versions is at risk (GitHub Advisory, Feedly).

A PoC has been proven and executed (JDK 17) by the original reporters, demonstrating that a modest crafted CBOR input is sufficient to trigger the quadratic behavior. No evidence of in-the-wild exploitation or threat actor attribution has been reported as of the publication date. The vulnerability is not listed in the CISA KEV catalog, and no EPSS score data is currently available. Exploitation requires only the ability to send a crafted CBOR payload to an endpoint that parses it with the affected library — no authentication is inherently required if the endpoint is publicly accessible (GitHub Advisory).

1. Reconnaissance: Identify services that accept CBOR-encoded input and use com.fasterxml.jackson.dataformat:jackson-dataformat-cbor (2.x) or tools.jackson.dataformat:jackson-dataformat-cbor (3.x) in an affected version range. Look for REST APIs or message consumers with Content-Type: application/cbor or similar.
2. Craft malicious CBOR payload: Construct a CBOR byte stream consisting of a very long sequence of tag bytes (e.g., repeated 0xC0 major type 6 tag bytes) followed by a trivial value (e.g., a null or integer). The number of tags should be large enough (e.g., tens of thousands) to trigger observable quadratic slowdown.
3. Send payload: Submit the crafted CBOR stream to the target endpoint via HTTP POST or the relevant transport mechanism. No authentication bypass is needed if the endpoint is publicly accessible.
4. Trigger DoS: The CBOR parser's TagList will grow by fixed increments of +8, re-scanning and copying on each growth, causing O(N²) CPU and GC consumption that pins the request thread. Sending multiple concurrent such requests exhausts the thread pool, denying service to legitimate users (GitHub Advisory).

• Network: Unusual HTTP requests with Content-Type: application/cbor (or equivalent) containing very large payloads composed predominantly of repeated tag bytes; high request volume to CBOR-parsing endpoints from a single or small set of source IPs.
• Logs: Application logs showing abnormally long parse times or timeouts for CBOR deserialization; thread pool exhaustion warnings or errors in Java application server logs (e.g., RejectedExecutionException).
• Process: JVM threads stuck in CBORParser tag-handling code visible via thread dumps (jstack); sustained high CPU usage by the JVM process with GC activity dominating CPU time (visible in GC logs or JVM monitoring tools like JConsole/VisualVM).

Upgrade to a patched version of the affected artifact:

• com.fasterxml.jackson.dataformat:jackson-dataformat-cbor: upgrade to 2.18.12, 2.21.8, or 2.22.4 depending on your current branch.
• tools.jackson.dataformat:jackson-dataformat-cbor: upgrade to 3.1.8 or 3.2.4.

The fix changes TagList growth to use doubling and/or caps the number of stacked tags (analogous to StreamReadConstraints-style limits). If immediate upgrade is not possible, consider rejecting or rate-limiting CBOR input at the network or application layer, or validating input size before parsing (GitHub Advisory).

The advisory was published by FasterXML maintainer cowtowncoder on GitHub. The vulnerability was reported by apvxlab (AppViewX security research) and v0xyc0n (jpac.at). HeroDevs covered the vulnerability in their vulnerability directory and published a related blog post on Jackson EOL dates and latest releases. No significant broader media coverage or notable social media discussion beyond standard CVE aggregator postings has been identified (GitHub Advisory, HeroDevs).