Proof Portal

Projects

jsonparser

ProbeLabs36 findings · 123 requirements
Back to findings
Problem reportDEFECT-260726-3F95

ParseInt("-") returns (0, nil) — silent false-success on sign-only input

FixedFixedLow

This defect has been fixed and verified.

Verified by 1 regression testResolved 1 known issue:KI-2

Introduced

When and where this issue first entered the codebase — the commit it traces back to.

Inception (latent from the first version)
Origin
Audit Finding

What this means for you

Plain-language impact — what this issue could mean for your users and your system, before any of the technical detail.

`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).

LowRated severity — the impact if this issue is exploited or hit.
risk area
Error Handling

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.

verified by
regression tests
strengthened requirements
New proof obligations

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.

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.

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.

Sign in to discuss this with the proof team.Sign in