CVE-2026-106554
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
jackson-dataformat-cbor is the CBOR (Concise Binary Object Representation, RFC 8949) data format module of the FasterXML Jackson suite. It lives in the jackson-dataformats-binary repository and provides a streaming parser and generator that let Jackson read and write CBOR through the same APIs it uses for JSON.
A denial of service vulnerability (CVE-2026-106554) has been identified in the CBORParser of jackson-dataformat-cbor, which allows attackers to consume excessive CPU time and memory by sending a CBOR document in which a long run of tags precedes a single value.
Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.
This issue affects multiple versions of Jackson.
Details
Module Info
- Product: Jackson
- Affected packages:
com.fasterxml.jackson.dataformat:jackson-dataformat-cbor - Affected versions: >=2.15.0 <2.18.12, >=2.19.0 <2.21.8, >=2.22.0 <2.22.4
- GitHub repository: https://github.com/FasterXML/jackson-dataformats-binary
- Published packages: https://central.sonatype.com/artifact/com.fasterxml.jackson.dataformat/jackson-dataformat-cbor
- Package manager: Maven
- Fixed in:
- OSS Jackson 2.18.12, 2.21.8, 2.22.4
- NES for Jackson v2.15.11
Vulnerability Info
This Medium-severity vulnerability is found in the com.fasterxml.jackson.dataformat:jackson-dataformat-cbor package in multiple versions of Jackson. CBOR allows any number of tags (major type 6) to be stacked in front of a data item. When CBORParser reads the next token, it loops over every tag that precedes the value and records each one in a TagList:
_tagValues.clear();
while (type == 6) {
_tagValues.add(_decodeTag(lowBits));
// (EOF handling omitted) read the next initial byte
ch = _inputBuffer[_inputPtr++] & 0xFF;
type = (ch >> 5);
lowBits = ch & 0x1F;
}TagList.add() grows its backing int[] by a fixed 8 slots each time it fills up, copying the whole array on every resize:
public void add(int tag) {
if (_tagCount == _tags.length) {
// Linear growth since we expect a small number of tags.
int[] newTags = new int[_tagCount + 8];
System.arraycopy(_tags, 0, newTags, 0, _tagCount);
_tags = newTags;
}
_tags[_tagCount++] = tag;
}Because the array grows linearly rather than geometrically, accumulating n tags performs about n/8 resizes whose copies add up to roughly n²/16 element copies, plus a matching volume of short-lived allocations. Each tag costs as little as one byte of input, so a payload of a few megabytes made of repeated tag bytes forces the parser into quadratic work before it ever reaches the value. Any application that parses untrusted CBOR with Jackson, whether through CBORParser directly or through an ObjectMapper built on CBORFactory, can have request threads tied up and memory churned by such input.
Mitigation
Only recent versions of Jackson are community-supported. Release lines the project has closed are End-of-Life and will not receive community updates addressing this issue. Branch status is published on the project's own Jackson Releases page.
Users of the affected components should apply one of the following mitigations:
- Upgrade jackson-dataformat-cbor to a currently supported release containing the fix, such as 2.18.12 or later.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
