Proof Portal

Projects

jsonparser

ProbeLabs23 findings · 123 requirements
Showing the current git stateNo audit has been synced for this project yet — verification results (proof status, coverage, solver signals) appear once an audit is published.proof-demod79405e
Back to findings
Problem reportDEFECT-260726-3PSJ

Delete left dangling trailing comma on array/object element followed by whitespace+comma

FixedFixedHigh

This defect has been fixed and verified.

Closure: Hazard class closed
Verified by 1 regression test

Description

The issue as recorded. A plain-language impact summary hasn't been written for this finding yet.

Delete (parser.go:864) produced malformed JSON output (rejected by encoding/json.Unmarshal) whenever the deleted element was followed by one or more JSON whitespace bytes (space, tab, LF, CR) and then a comma or the container close bracket. The dangling-byte sequences were: * Delete("[0,0 ]", "[1]") -> [0, ] (trailing comma before ]) * Delete("[0,0 ,0]", "[1]") -> [0, ,0] (dangling comma between spaces) * Delete("[0,0\n,0]", "[1]") -> [0,\n,0] (newline variant) * Delete("[0,0 ,0]", "[1]") -> [0, ,0] (multi-space variant) Root cause was two-fold: 1. The array-branch cleanup (parser.go:932-938, data[idx] == ']' case) only advanced keyOffset to tokStart; it did not handle the whitespace-before-] shape, so the cleanup block ran with the wrong endOffset and left the comma. 2. The array-branch whitespace-then-comma case was missing entirely. The object-branch (parser.go:907-916) had data[idx] == ' ' && data[nextIdx] == ',', but (a) it only matched a SINGLE 0x20 space, missing \t, \n, \r, and multi-byte whitespace runs, and (b) the symmetric case was absent from the array branch. 3. The final cleanup (parser.go:948) only checked remainedValue[i] == '}' (object close), so deleting the LAST array element left the comma dangling before ]. Hazard class: silent malformed-JSON output on caller-controlled input shape (whitespace placement is arbitrary in JSON). Found by FuzzPathMutation during the final hazard sweep.

Severity, explained

Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).

HighRated severity — the impact if this issue is exploited or hit.
risk area
Data Integrity

Root cause

What actually went wrong underneath — how it is classified, and the coverage gap that let it slip through.

defect class: Missing Validation
Why this escaped

Disposition: Covered by a requirement

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 requirement.

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

Provenance
Origin: Test Failure · hazard-swe

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.

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