Proof Portal

Projects

jsonparser

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

ParseBoolean uses prefix match instead of exact equality — "trueish"/"falsehood" accepted as booleans

OpenOpenHigh

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

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.

Malformed boolean tokens with trailing bytes are silently accepted as true/false, so authorization flags, feature toggles, or state derived from GetBoolean can be driven to the wrong value by crafted input. Intentional demo defect on the proof-demo showcase branch; never shipped.

Reachability

Reachable via ParseBoolean/GetBoolean on attacker-controlled JSON; any token beginning with "true"/"false" is accepted, so trailing-garbage payloads decode as valid booleans.

Technical description

ParseBoolean (parser.go) decides a boolean by comparing the token bytes to the "true"/"false" literals. On the proof-demo showcase branch both comparisons were changed from `bytes.Equal(b, trueLiteral)` / `bytes.Equal(b, falseLiteral)` to `bytes.HasPrefix(...)` (parser.go:2137-2139), so any value that merely begins with "true" or "false" — "trueish", "falsehood" — now parses successfully as the corresponding boolean instead of erroring. This is a CWE-20 Improper Input Validation (prefix match where exact equality is required), admitting malformed tokens as valid data. 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).

HighRated severity — the impact if this issue is exploited or hit.
why this rating
Risk-rated
risk area
Data Integrity
Security classification
Security-relevant
CVSS
CVSS 7.5· Highv3.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CVE surface
Unlikely

Where it is

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

  • ParseBoolean

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-012
Run it yourself
go test -run TestDemoKI11 -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.GetBoolean on a value of "trueish" — or run: go test -run TestDemoKI11 -count=1 .
  3. Observe the value decode as true with a nil error instead of MalformedValueError.
go test -run TestDemoKI11 -count=1 .
go test ./... -count=1

How it can be triggered

The input or condition that sets this issue off.

a Boolean token with trailing bytes after the literal, e.g. "trueish" or "falsehood"

What protects you, and the fix

What limits your exposure today, and the planned remediation.

What protects you now

Re-validate boolean fields against exact "true"/"false" tokens in caller code, or use a strict schema validator, until the exact comparison is restored.

The fix

Restore exact-equality comparison in ParseBoolean (parser.go:2137 and 2139, `bytes.HasPrefix` -> `bytes.Equal`) so only the literal "true"/"false" tokens parse and any trailing garbage returns MalformedValueError. 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.

Tracing blast radius…

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

Code files (2)
  • fuzz.go
  • parser.go
Tests (7)
  • fuzz_native_test.go
  • mcdc_spec_witnesses_test.go
  • mcdc_supplement_test.go
  • obligation_evidence_test.go
  • parser_test.go
  • reference_oracle_test.go
  • deep_spec_test.go

Per-requirement evidence

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

Implementing code (2)
  • fuzz.go
    FuzzParseBool
  • parser.go
    ParseBoolean
Tests & evidence (7)
  • README.md
  • fuzz_native_test.go
  • mcdc_spec_witnesses_test.go
  • mcdc_supplement_test.go
  • obligation_evidence_test.go
  • parser_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:189
Implementing code (1)
  • parser.go
    ParseBoolean
Tests & evidence (4)
  • README.md
  • mcdc_spec_witnesses_test.go
  • obligation_evidence_test.go
  • parser_test.go
Proof obligations (1)
malformed_input

Behavior when inputs are syntactically or structurally invalid.

  • negative (required)obligation_evidence_test.go:351
  • nominal (required)obligation_evidence_test.go:350
Implementing code (1)
  • parser.go
    ParseBoolean
Tests & evidence (4)
  • README.md
  • deep_spec_test.go
  • mcdc_spec_witnesses_test.go
  • obligation_evidence_test.go
Proof obligations (1)
partial_literal
  • nominal (required)obligation_evidence_test.go:464

Evidence trail

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

  • proof/evidence/KI-11-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