Jackson Dataformat Smile CVE-2026-104895

Exploitation requires that the target application construct and feed the asynchronous, non-blocking Smile parser - SmileFactory.builder().build().createNonBlockingByteArrayParser(...) (class tools.jackson.dataformat.smile.async.NonBlockingByteArrayParser) - with attacker-supplied Smile bytes, the deployment pattern used by reactive/async stacks such as Spring WebFlux, Vert.x and Micronaut. No authentication, privileges, or user interaction are needed beyond the ability to submit data for parsing (PR:N/UI:N). The key LIMITING factor is the parser path: the blocking SmileParser._readUnsignedVInt already contains the (value >>> 25) != 0 overflow guard and is NOT vulnerable, so applications using only synchronous Smile parsing, or not accepting Smile input at all, are unaffected. Exploitation also depends on the JVM heap being small enough that an ~2 GB eager allocation (or the negative-length overflow variant) exhausts memory or throws before the body is read.

All quantitative signals point to a genuine but bounded availability problem rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) describes a remotely reachable, low-complexity, unauthenticated flaw whose impact is confined to availability - confidentiality and integrity are explicitly N (CWE-789, memory allocation without limits). The vuln.today decision label is 'this_week', consistent with a serious DoS that is not under active attack. No EPSS score and no KEV status were provided in the input; per the precision rules this is 'no public exploit identified at time of analysis' in the KEV/POC sense, though the GHSA advisory contains a detailed, code-verified reproduction recipe (header + 0xFD marker + crafted 5-byte VInt), so a working proof-of-concept is clearly achievable even if no packaged exploit code is cited. The real limiter is reach, not difficulty: only applications that build the async NonBlockingByteArrayParser (createNonBlockingByteArrayParser) and feed it untrusted Smile data are exposed; the blocking SmileParser already carries the (value >>> 25) overflow guard and is not affected. This is a real priority for teams running reactive Smile endpoints (WebFlux, Vert.x, Micronaut), but for the large majority of Jackson deployments that use JSON or the blocking Smile parser it is not reachable. Missing data: EPSS and KEV are absent (not errors, just unsupplied), so widespread-exploitation probability cannot be quantified from the input.

An attacker sends a roughly ten-byte Smile payload (a 4-byte Smile header, the 0xFD raw-binary marker, and a 5-byte VInt encoding ~2,000,000,000) to a reactive service that parses untrusted Smile input with the async NonBlockingByteArrayParser. On nextToken(), _startRawBinary eagerly executes new byte[len], forcing an ~2 GB allocation that throws OutOfMemoryError; a VInt crafted to overflow int instead yields a negative length and a NegativeArraySizeException that escapes the JacksonException contract. The GHSA advisory supplies a code-verified reproduction, so a working PoC is readily constructed, though no packaged exploit code is cited in the input.