Cowtowncoder

ProtobufParser. readStringKey() reads the length prefix of a protobuf map entry's string key into an attacker-controlled int and then checks ( inputPtr + len) <= inputEnd using signed arithmetic. For values near Integer.MAX VALUE the addition overflows to a negative value and the check passes even when the input contains no key data. The parser then calls finishShortText(len), which expands the text buffer to the declared length via TextBuffer.expandCurrentSegment and Arrays.copyOf, throwing OutOfMemoryError: Requested array size exceeds VM limit. An 8-byte malformed message containing a map entry with a declared key length of 0x7FFFFFFF is sufficient. Configured StreamReadConstraints, including maxStringLength, maxNameLength, maxDocumentLength and maxNestingDepth, do not prevent the failure. Applications running with -XX:+ExitOnOutOfMemoryError terminate the JVM. This is the same integer-overflow pattern addressed for other call sites in the remediation associated with CVE-2026-104016 and CVE-2026-104017; the map-key call site was corrected on the 3.x branches only, leaving the corresponding 2.x branches unguarded. Release lines 2.18, 2.19 and 2.20 do not contain readStringKey() and are not affected by this vector. No privileges or user interaction beyond the ability to submit data for parsing are required. The 3.0 release line and 3.1.0-3.1.5 / 3.2.0-3.2.1 do not contain readStringKey() and are therefore not affected; the method first appears in 3.1.6 and 3.2.2, mirroring its introduction at 2.21.6 on the 2.x side.

The asynchronous Smile parser `NonBlockingByteArrayParser` allocates a byte array based on a raw-binary length prefix from untrusted input without an upper bound or overflow check. Specifically, when encountering the raw-binary marker 0xFD, the ` decodeVInt()` function calculates the length without the overflow guard used in the blocking `SmileParser. readUnsignedVInt` function. Subsequently, ` startRawBinary` allocates the specified length immediately. This can allow a small input to trigger a massive memory allocation, leading to an `OutOfMemoryError` on reactive or asynchronous Smile endpoints. Additionally, a crafted VInt (Variable Integer) that overflows an integer can result in a negative length, causing a `NegativeArraySizeException`. Both scenarios can crash the request or processing thread.

An integer overflow occurs in the `ProtobufParser` when parsing length-prefixed protobuf string and bytes fields. The parser uses 32-bit signed integer arithmetic to check if `( inputPtr + len) <= inputEnd`. If an attacker provides a varint that decodes to a length near `Integer.MAX VALUE`, the addition overflows to a negative value, allowing the bounds check to pass. Subsequently, the ` finishShortText(len)` function calls `TextBuffer.expandCurrentSegment(len)`, which triggers `Arrays.copyOf` and results in an `OutOfMemoryError` because the requested array size exceeds the JVM limit. This issue persists regardless of `-Xmx` tuning or configurations for `StreamReadConstraints.maxStringLength` and `maxDocumentLength`. No privileges or user interaction are required beyond the ability to submit data for parsing.

Parsers built over character input, such as Reader, String, or char[] sources served by ReaderBasedJsonParser, fail to properly apply the `maxNameLength` constraint during the accumulation of JSON Object property names. Instead of the intended 50,000-character limit, the system uses the `maxStringLength` check, which allows up to 100,000,000 characters. This occurs because the ` parseName2()` function accumulates the name into the TextBuffer and only validates `maxStringLength` when a segment fills, delaying the `validateNameLength(int)` check until the entire name has been buffered. A remote attacker can exploit this by providing a sufficiently long property name, forcing memory allocations of approximately 200 MB per request, which can lead to heap exhaustion and process crashes. This issue is exploitable under default configurations as `maxDocumentLength` is disabled by default. Byte-input parsers are not affected.

An issue exists where the software validates the outer class of a class-name type ID but fails to properly validate classes within its generic arguments. This occurs because the `DatabindContext. resolveAndValidateGeneric()` function checks the outer class against the declared base type but passes arguments to ` validateTypeParameter()`, which validates them against the outer base type instead of their specific declared generic binding. Consequently, unrelated classes can be accepted inside a generic subtype or within plain array type IDs once the base type is approved. This can be exploited through annotation-based class-name polymorphism or configured default typing. For instance, if a property is declared as `Map<String,String>`, an attacker could provide a `HashMap<FileSystemXmlApplicationContext,String>`. If Spring is present on the classpath, this can lead to arbitrary command execution via `ProcessBuilder.start()` by loading attacker-controlled XML.

The non-blocking (asynchronous) JSON parser in jackson-core fails to enforce the `maxNumberLength` constraint defined in `StreamReadConstraints`. This occurs because the async parsing path in `NonBlockingUtf8JsonParserBase` and related classes does not invoke number length validation methods. Specifically, methods like ` finishNumberIntegralPart()` accumulate digits into the `TextBuffer` without checks, and ` valueComplete()` fails to call `resetInt()` or `resetFloat()`, where `validateIntegerLength()` and `validateFPLength()` are executed. An attacker can submit a JSON document containing a number token of arbitrary length, leading to excessive memory allocation in the `TextBuffer` and potential `OutOfMemoryError`. Additionally, if the application calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM may experience CPU exhaustion due to O(n^2) BigInteger parsing, resulting in a denial of service.

A number length constraint bypass exists in the non-blocking parser. An attacker can stream JSON in small chunks without sending a terminator byte, keeping the parser in the `MINOR NUMBER INTEGER DIGITS` state indefinitely. This causes the accumulator to grow based on `maxStringLength` (default 20 MiB) instead of `maxNumberLength` (default 1000), potentially consuming up to 40 MiB of heap per connection. This can lead to JVM heap exhaustion when combined with attacker-controlled concurrency. The issue affects the integer-digit paths in the `NonBlockingUtf8JsonParserBase` class, specifically within the ` startPositiveNumber()`, ` startNegativeNumber()`, and ` finishNumberIntegralPart()` functions. Reactive frameworks that feed bytes to the async parser as they arrive, such as Spring WebFlux/Reactor, Quarkus, Helidon, and Vert.x, are particularly susceptible. Synchronous parsers and async parsers operating on complete input are not affected.

The issue is related to resource exhaustion due to a lack of a check in primitive value deserializers to avoid deep wrapper array nesting when the UNWRAP SINGLE VALUE ARRAYS feature is enabled. This can allow an unauthenticated attacker to expose assets in the environment susceptible to exploitation, with no impact to confidentiality, no impact to integrity, and high impact to availability, requiring no user interaction.

The issue is related to the allocation of unlimited memory in the com.fasterxml.jackson.dataformat:jackson-dataformat-cbor package of the jackson-dataformats-binary library. This can be exploited by a remote attacker to cause a denial of service. The unchecked allocation of a byte buffer can cause a java.lang.OutOfMemoryError exception.

The issue allows remote attackers to conduct server-side request forgery (SSRF) attacks via vectors related to a DTD. This can be exploited in the XmlMapper component of the Jackson XML dataformat.