CVE-2026-18401

CVE-2026-18401 exposes a fundamental inconsistency in jackson-core's security architecture: the async parser has been operating outside the StreamReadConstraints boundary that protects the synchronous parser, creating a DoS vector that reactive applications have been exposed to for years without their operators' knowledge. StreamReadConstraints was introduced in jackson-core 2.15.0 as a hardening layer against resource exhaustion attacks, with maxNumberLength specifically capping the allowable digit count in numeric parsing. The synchronous parser was retrofitted with this validation. The async parser was not. This is not a subtle logic error — it is evidence that the security hardening was applied to one code path and not the other, likely because the async parser was treated as architecturally distinct and exempt from the same threat model. The practical impact is amplified by where reactive frameworks deploy. Applications using Spring WebFlux and similar non-blocking stacks typically sit at API gateways and service boundaries — precisely the components that receive untrusted input at scale. An attacker sending a single crafted JSON payload with an excessively long number to such an endpoint can trigger either memory exhaustion (through unbounded TextBuffer accumulation) or CPU exhaustion (through O(n²) BigInteger parsing), selecting the vector that best matches the target's resource profile. For defenders, the immediate actions are: confirm which jackson-core version your application uses (2.15.0 and later are affected); identify whether your framework uses the async parser path (Spring WebFlux does by default); and check whether StreamReadConstraints is being applied to your ObjectMapper configuration. Note that configuring constraints on the sync parser does not automatically protect the async path — they are separate code paths with separate validation logic. One unresolved analytical gap: the GHSA record cites 2.0.0 as the affected lower bound while this CVE specifies 2.15.0. This discrepancy suggests either a documentation error or that pre-2.15 versions face a different but related risk from the same architectural pattern. Until reconciled, treat pre-2.15 versions as requiring separate threat modeling rather than automatically assuming they are unaffected.

Reviewed through automated stages and approved by a human before publication.