ECHO-a10b-dd74-a1af
See a problem?- Import Source
- https://advisory.echohq.com/osv/ECHO-a10b-dd74-a1af.json
- JSON Data
- https://api.osv.dev/v1/vulns/ECHO-a10b-dd74-a1af
- Upstream
- Withdrawn
- 2026-08-09T08:33:45Z
- Published
- 2026-08-09T08:33:45Z
- Modified
- 2026-09-02T02:56:34Z
- Summary
- Two async-parser number-length DoS advisories in NonBlockingUtf8JsonParserBase (r7wm completes 72hv): - GHSA-72hv-8253-57qq (High 8.7): async parser never enforced StreamReadConstraints.maxNumberLength, so huge numbers exhausted memory/CPU; length assignments now route through validating helpers. - GHSA-r7wm-3cxj-wff9 (Moderate): follow-up — chunked digits still grew unbounded on the streaming path; now validated at suspension points too. Commits b0c428e6 (#1555) and 4cdd5297 (#1611) applied verbatim — production code and both upstream regression tests byte-identical; only the release-notes and CI-workflow hunks are dropped. Backport changes: the two commits are combined into one patch because r7wm's streaming-path fix builds on the _setIntLength() helper that 72hv introduces, and the builder dry-runs each patch against pristine source (a dependent second patch would be rejected). Verified byte-equal to both commits cherry-picked in order. Tests: AsyncLargeNumberReadTest (3) + AsyncNumberLengthConsistencyTest (5); 7 of the 8 fail on unpatched 2.20.2 and all pass with the patch (JDK 8).
- Details
- References
Affected packages
Echo:Maven / com.fasterxml.jackson.core:jackson-core
Package
- Name
- com.fasterxml.jackson.core:jackson-core
- Purl
- pkg:maven/com.fasterxml.jackson.core/jackson-core
Echo:Maven / jackson-core
Package
- Name
- jackson-core
- Purl
- pkg:maven/jackson-core