Proof Portal

Sign in
Project overview

jsonparser

ProbeLabs24 findings · 123 requirements
Back to findings
Known issueKI-12

arrayEachConfig empty-input guard returns the wrong documented error type (MalformedJsonError vs MalformedObjectError)

OpenOpenInfo

Informational-severity issue, currently open.

How well is this finding proven?

  1. 1.Reported / candidate

    Complete

  2. 2.Reproducer written

    Complete

    View reproducer
  3. 3.Reproduces (recorded run)

    Complete

    View evidence
  4. 4.Independently re-run

    Not yet established

  5. 5.Meets quality standard

    Not assessed

  6. 6.Validated for submission

    Not assessed

Recorded runs show whether the issue reproduces. Independent re-runs are shown separately. A later review does not fill in a missing earlier step.

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.

Code that switches on the specific error type returned by ArrayEach for empty input sees an inconsistent error value versus the documented contract and the arrayEachErr sibling — a cosmetic/robustness nit with no runtime risk. Intentional demo defect on the proof-demo showcase branch; never shipped.

Reachability

Reachable only by calling ArrayEach with a zero-length input; purely a contract/error-type consistency nit with no security or availability impact.

Technical description

arrayEachConfig (parser.go) guards a zero-length input by returning an error before scanning. On the proof-demo showcase branch that empty-input return was changed from MalformedObjectError to MalformedJsonError (parser.go:1709), so ArrayEach on empty input surfaces an error type that disagrees with the documented contract and with the sibling arrayEachErr path. This is a CWE-20 Improper Input Validation nit — the failure is still reported, but with the wrong (inconsistent) error value. Purely informational: no security, availability, or data-integrity impact. Intentional demo defect on the proof-demo showcase branch; never shipped.

Affected requirements

The requirement(s) this issue violates — click through to the spec.

SYS-REQ-029

Severity, explained

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

InfoRated severity — the impact if this issue is exploited or hit.
why this rating
Risk-rated
risk area
Correctness
Security classification
Not a security surface
CVE surface
None

Where it is

The code the issue lives in — peek the affected function inline to see it in context.

  • arrayEachConfig

Reproducer and evidence

The recorded reproducer and its evidence-run outcome. Inspect the test and source, or run the command to check the behavior yourself.

Reproduces (recorded run)Run status: Passprofileknown_issue_reproducerrequirementSYS-REQ-029
Run it yourself
go test -run TestDemoKI12 -count=1 .
Covers (3)
Last run Aug 3, 2026, 11:00 AM

Reproduction steps

Technical steps for your engineers to confirm the issue by hand.

  1. Check out the proof-demo showcase branch and build the package.
  2. Call jsonparser.ArrayEach with an empty byte slice — or run: go test -run TestDemoKI12 -count=1 .
  3. Observe MalformedJsonError where the contract documents MalformedObjectError.
go test -run TestDemoKI12 -count=1 .
go test ./... -count=1

How it can be triggered

The input or condition that sets this issue off.

an empty byte slice passed to ArrayEach (contract/robustness nit, no security impact)

What protects you, and the fix

What limits your exposure today, and the planned remediation.

What protects you now

Treat any non-nil error from ArrayEach on empty input as "no elements"; do not branch on the exact error type until the return is normalized.

The fix

Restore MalformedObjectError as the empty-input return of arrayEachConfig (parser.go:1709, `MalformedJsonError` -> `MalformedObjectError`) so the error type matches the documented contract and the arrayEachErr path. Consistency fix for CWE-20 Improper Input Validation.

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.

Tracing blast radius…

Touch this finding and you re-check 1 requirements · 2 code files · 3 tests.

Requirements (1)
SYS-REQ-029
Code files (2)
  • aliases.go
  • parser.go
Tests (3)
  • mcdc_spec_witnesses_test.go
  • obligation_evidence_test.go
  • parser_test.go

Per-requirement evidence

For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.

SYS-REQ-029
Implementing code (2)
  • aliases.go
    EachArray
  • parser.go
    ArrayEach
Tests & evidence (4)
  • README.md
  • mcdc_spec_witnesses_test.go
  • obligation_evidence_test.go
  • parser_test.go
Proof obligations (2)
malformed_input

Behavior when inputs are syntactically or structurally invalid.

  • ✓negative (required) — obligation_evidence_test.go:305, parser_test.go:2524
  • ✓nominal (required) — obligation_evidence_test.go:304
non_array_root_no_callback
  • ✓negative — parser_test.go:2525

Evidence trail

The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.

  • proof/evidence/KI-12-reproducer.yaml

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