Proof Portal
jsonparser
ProbeLabs23 findings · 123 requirementsParseInt("-") returns (0, nil) — silent false-success on sign-only input
This defect has been fixed and verified.
Description
The issue as recorded. A plain-language impact summary hasn't been written for this finding yet.
ParseInt (parser.go:1498) delegates to parseInt (bytes.go:9). When the input is exactly a sign byte with no following digits ("-" or "+"-style input where + is rejected because it isn't valid JSON but - is a valid JSON number prefix), the parser:
1. strips the leading - (bytes.go:15-18), leaving an empty byte slice;
2. iterates over the empty slice (zero iterations), so n stays 0;
3. falls through to the if neg branch (bytes.go:43) and returns
(-0, true, false) = (0, nil).
The caller (GetInt / any code using ParseInt to validate a JSON number token) is told the input parsed successfully with value 0. This is silent false-success on caller-controlled input: a JSON value of just - is malformed (no digits follow the sign) but is reported as a well-formed integer equal to zero.
Hazard class: this is the same family as the JSON fuzzer's existing ParseInt finding — the input partition "sign byte only, no digits" is not covered by the parser's malformed-input branch. The catalog obligation malformed_input requires a typed error on this partition; the code returns (0, nil) instead.
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- risk area
- Error Handling
Root cause
What actually went wrong underneath — how it is classified, and the coverage gap that let it slip through.
Disposition: Covered by a known issue
Proof it's fixed
The tests, tightened requirements and new obligations that prove this defect is gone — and can't quietly return.
Covered by a known issue.
- Malformed Input on SYS-REQ-015
Blast radius
If you touch this issue, what else may need re-checking — the requirements it affects and the code and tests that hang off them. Historical view: authored trace links only — automatically derived links aren't reconstructible for past runs.
Nothing to trace into
This finding links no requirements, so there is no dependency graph to follow. Everything we know about it is in the evidence above.
Change history
Every recorded revision of this finding's source file — when it was added, edited, or re-classified, with the diff for each change.
Discussions
Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.