CVE-2026-68494

This is a second bypass of the same constraint system that CVE-2026-18401 was supposed to fix, and the root cause is a structural asymmetry in how the original patch was applied. The developer correctly added validation to the fraction-handling path (_finishFloatFraction() calls _setFractLength() before returning NOT_AVAILABLE), but the integer-handling path is missing the equivalent call to validateIntegerLength() on that same return. This isn't a subtle drift—it's a direct code-level gap between two parsing branches that should behave identically. The versions affected are 2.15.0 through 2.21.3. Versions 2.22.x and 3.2.x are clean, but that's a temporal artifact: they postdate the original fix, not a deliberate architectural correction. The maintainers sidestepped the question rather than answering it. The critical operational risk is the false sense of security around maxNumberLength. Setting this to 1000 creates a 20,000x amplification gap—the actual memory bound for streaming integer parsing is maxStringLength at 20 MiB, not maxNumberLength. An operator who patched CVE-2026-18401 and configured maxNumberLength as a memory guard is getting exactly the protection that was supposed to be fixed. There's no log, no metric, no alert that reveals this gap. For non-blocking endpoints specifically, the vulnerability window predates CVE-2026-68494's disclosure. If you applied the 2.18.6 or 2.21.1 patch believing the resource exhaustion vector was closed, your deployment has been operating under false assurance. The severity of the original CVE assumed a complete fix; it wasn't. Check your deployed jackson-core version. If you're on 2.15.x through 2.21.x with non-blocking parsing enabled, assume the constraint bypass is active regardless of maxNumberLength settings until the backported patch is verified. The long-term fix requires formal enumeration of every NOT_AVAILABLE return path in the non-blocking parser—every yield point where control returns to the caller mid-value—cross-referenced against every constraint that should have fired. That's not how patches are typically validated, which is why this pattern recurs.

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