Skip to content

Max number length config for BigInteger and BigDecimal#1068

Open
stleary wants to merge 6 commits into
masterfrom
max-number-length-config
Open

Max number length config for BigInteger and BigDecimal#1068
stleary wants to merge 6 commits into
masterfrom
max-number-length-config

Conversation

@stleary

@stleary stleary commented Jul 16, 2026

Copy link
Copy Markdown
Owner

Description
Additional work for CVE-2026-59171 (See #1065):

Refactoring
N/A

Testing done
New unit tests were added.

Sean Leary and others added 6 commits July 13, 2026 15:33
1063-option-3 parserConfig set max len
90563eb
@mechko @claude
#1063: bound BigDecimal->BigInteger expansion in objectToBigInteger
fce83c9 
Completes the CVE-2026-59171 fix started in ab92bb9 / #1065. The
1000-char length guard in stringToValue admits short exponent-notation
literals (e.g. 1e100000000, 11 chars) which are stored compactly as
BigDecimal and only expand when getBigInteger/optBigInteger calls
BigDecimal.toBigInteger(), materialising ~10^8 digits and stalling the
thread or throwing OOM.

Guard both toBigInteger() sites in objectToBigInteger by rejecting any
BigDecimal whose integer part would exceed
ParserConfiguration.DEFAULT_MAX_NUMBER_LENGTH decimal digits
(precision() - scale(), both O(1) reads). Returns defaultValue on
overflow, matching the method's existing behaviour for non-finite and
unparseable values.

Covers JSONObject.getBigInteger/optBigInteger and
JSONArray.getBigInteger/optBigInteger (all delegate to this helper).

Adds JSONObjectTest.getBigIntegerHugeExponentReturnsDefault with a 5s
timeout so a regression fails fast rather than hanging CI.

Co-Authored-By: Claude <noreply@anthropic.com>
@mechko @claude
#1063: add comment to expected-exception catch block (SonarCloud java…
e40d933 
…:S108)

Co-Authored-By: Claude <noreply@anthropic.com>
@mechko @claude
#1063: add JSONParserConfiguration overloads for getBigInteger/optBig…
703ac34 
…Integer

Per review on #1067:
- objectToBigInteger(val, dflt, JSONParserConfiguration) uses
  cfg.getMaxNumberLength() for the digit-count guard; -1 disables it.
  Existing 2-arg form delegates with a default config.
- New public overloads on JSONObject and JSONArray:
  getBigInteger(key, cfg) / optBigInteger(key, dflt, cfg).
  Existing methods delegate with a default config.
- objectToBigDecimal left unchanged (no expansion path; agreed on PR).
- Tests cover default (1000), raised (2000), lowered (5), disabled (-1),
  null config, and JSONArray overloads.

Co-Authored-By: Claude <noreply@anthropic.com>
@stleary
Merge pull request #1067 from mechko/1063-biginteger-exponent-dos
a28328c 
#1063: bound BigDecimal→BigInteger expansion in objectToBigInteger (completes CVE-2026-59171 fix)
max-number-length-config sonarqube fixes
9953b76
@sonarqubecloud

sonarqubecloud Bot commented Jul 16, 2026

Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@stleary

stleary commented Jul 16, 2026

Copy link
Copy Markdown
Owner Author

What problem does this code solve?
Completes the fix for CVE-2026-59171 Unbounded numeric string parsing

Does the code still compile with Java6?
Yes

Risks
Low. The behavior for very large BigInteger and BigDecimal has changed, but it is unlikely that anyone will encounter the change with valid JSON. If they do, the capability to disable this fix is included.

Changes to the API?
The lib will not attempt to parse strings containing very large numbers. When this happens, a string will be emitted instead of a BigInteger or BigDecimal.

Will this require a new release?
Yes

Should the documentation be updated?
Yes

Does it break the unit tests?
No, unit tests were added

Was any code refactored in this commit?
Minimal refactoring due to SonarQube results

Review status
APPROVED - by myself

Thanks to @waydeshi, @Damien-Warren-206, and @mechko for contributions that resulted in this fix

Starting 3 day comment window

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Approved - 3-day window

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

ParserConfiguration should support max number length

2 participants

@stleary @mechko