Proof Portal

Sign in
Projects

jsonparser

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

nextTokenConfig drops the tab from its whitespace set — parsing fails on tab-formatted JSON

OpenOpenLow

Low-severity issue, currently open.

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.

SYS-REQ-001SYS-REQ-026

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.

Tab-indented or tab-separated JSON (common from pretty-printers and hand-edited config) fails to parse, so values after a tab are not found. Intentional demo defect on the proof-demo showcase branch; never shipped.

Reachability

Reachable via any Get*/ArrayEach/ObjectEach call on tab-formatted JSON; only inputs that place a tab where whitespace is expected are affected (space/newline/CR still parse).

Technical description

nextTokenConfig (parser.go) advances past insignificant whitespace before reading a token. On the proof-demo showcase branch the whitespace test lost its `|| c == '\t'` term (parser.go:247), so a tab is no longer treated as insignificant whitespace and token scanning stops on it, failing to locate the following value. RFC 8259 lists the tab among the four insignificant whitespace bytes, so this is a CWE-20 Improper Input Validation — spec-valid input is rejected. Intentional demo defect on the proof-demo showcase branch; never shipped.

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.
why this rating
Risk-rated
risk area
Correctness
Security classification
Security-relevant
CVSS
CVSS 3.7· Lowv3.1CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
CVE surface
None

Where it is

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

  • nextTokenConfig

How it's proven

The reproducer — an actual test that drives the real code and shows the issue happening. Run it yourself, or peek the test and the source it covers.

Known issue reproducedprovesSYS-REQ-001
Run it yourself
go test -run TestDemoKI13 -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.GetInt on {"a":\t123} (tab before the value) — or run: go test -run TestDemoKI13 -count=1 .
  3. Observe a parse failure/not-found instead of reading the value 123.
go test -run TestDemoKI13 -count=1 .
go test ./... -count=1

How it can be triggered

The input or condition that sets this issue off.

JSON that uses a tab as insignificant whitespace before a value, e.g. {"a":\t123}

What protects you, and the fix

What limits your exposure today, and the planned remediation.

What protects you now

Normalize/minify JSON (strip tabs) before parsing, or ensure producers emit spaces rather than tabs, until the whitespace set is restored.

The fix

Re-add the tab term to the whitespace test in nextTokenConfig (parser.go:247, restore `|| c == '\t'`) so tab-formatted JSON parses per RFC 8259 section 2. Closes 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.

Open in graph
Tracing blast radius…

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

Requirements (2)
SYS-REQ-001SYS-REQ-026
Code files (3)
  • fuzz.go
  • parser.go
  • path_compiler.go
Tests (13)
  • bytes_unsafe_test.go
  • dead_code_audit_test.go
  • fuzz_native_test.go
  • mcdc_code_supplement_test.go
  • mcdc_spec_witnesses_test.go
  • mcdc_supplement_test.go
  • obligation_evidence_test.go
  • parser_error_test.go
  • and 5 more

Per-requirement evidence

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

SYS-REQ-001
Implementing code (11)
  • fuzz.go
    FuzzTokenStart
  • parser.go
    Get
  • parser.go
    ValueType.String
  • parser.go
    findKeyStart
  • parser.go
    findTokenStart
  • parser.go
    getType
  • parser.go
    internalGet
  • parser.go
    lastToken
  • parser.go
    nextToken
  • parser.go
    searchKeys
  • parser.go
    tokenStart
Tests & evidence (14)
  • README.md
  • bytes_unsafe_test.go
  • dead_code_audit_test.go
  • fuzz_native_test.go
  • mcdc_code_supplement_test.go
  • mcdc_spec_witnesses_test.go
  • mcdc_supplement_test.go
  • obligation_evidence_test.go
  • parser_error_test.go
  • parser_test.go
  • path_compiler.go
  • path_compiler_test.go
  • property_test.go
  • reference_oracle_test.go
Proof obligations (1)
determinism

Output identical regardless of collection ordering or runtime conditions.

  • ✓nominal (required) — obligation_evidence_test.go:104
SYS-REQ-026
Implementing code (1)
  • parser.go
    Get
Tests & evidence (4)
  • README.md
  • deep_spec_test.go
  • mcdc_spec_witnesses_test.go
  • parser_test.go

Evidence trail

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

  • proof/evidence/KI-13-reproducer.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