Proof Portal

Projects

jsonparser

ProbeLabs36 findings · 123 requirements
Back to findings
Known issueKI-4

Set on top-level array-index beyond length returns KeyPathNotFoundError instead of appending

FixedFixedMedium

This defect has been fixed and verified.

Introduced

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

Inception (latent from the first version)

Affected requirements

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

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.

Set fails for a common use case (appending to a top-level JSON array); callers must wrap the array in an object.

Technical description

SYS-REQ-110 unconditionally requires append-at-end for [N] where N >= len(array), but Set's top-level branch explicitly rejects matching array+array-index paths with KeyPathNotFoundError. Nested arrays are fixed (DEFECT-260727-WWWY); only top-level arrays are affected.

Severity, explained

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

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

  • Set

Reproduction steps

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

go test -v -run TestSetTopLevelArrayAppend_KI4 -count=1 ./...

How it can be triggered

The input or condition that sets this issue off.

Caller-controlled path [N] where N >= len(top-level array)

What protects you, and the fix

What limits your exposure today, and the planned remediation.

What protects you now

Wrap the top-level array in an object (e.g. {"items":[...]}), or append manually by re-slicing.

The fix

Extend parser.go:Set endOffset==-1 branch to handle (pathIsIndex && dataIsArray) top-level arrays, OR narrow SYS-REQ-110 to document the top-level exception.

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.

Tracing blast radius…

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

Requirements (1)
Code files (2)
  • append.go
  • parser.go
Tests (7)
  • append_test.go
  • fuzz_native_test.go
  • mcdc_supplement_test.go
  • parser_test.go
  • reference_oracle_test.go
  • set_spec_test.go
  • sys_req_110_111_witness_test.go

Per-requirement evidence

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

Implementing code (4)
  • append.go
    Append
  • parser.go
    Set
  • parser.go
    createInsertComponent
  • parser.go
    setConfig
Tests & evidence (9)
  • README.md
  • append_test.go
  • docs/proof-gap-root-cause.md
  • fuzz_native_test.go
  • mcdc_supplement_test.go
  • parser_test.go
  • reference_oracle_test.go
  • set_spec_test.go
  • sys_req_110_111_witness_test.go
Proof obligations (3)
boundary

Behavior at limits, thresholds, and edge-of-range values.

  • nominal (required)sys_req_110_111_witness_test.go:33
  • negativeparser_test.go:2484
element_type_partition
  • nominal (required)parser_test.go:2485
nested_mutation
  • nominal (required)sys_req_110_111_witness_test.go:81

Evidence trail

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

  • proof/evidence/ki4-set-toplevel-array-beyond-length.yaml

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