fix: bounds check in Delete to prevent index out of range panic

[Yanhu007]

Fixes #274

Problem

Delete accesses data[endOffset+tokEnd] without checking if the index is within bounds. tokenEnd() returns len(data) when no terminator is found, so endOffset+tokEnd can exceed the slice length, causing a panic:

panic: runtime error: index out of range [9] with length 9

Found by fuzzing.

Fix

Add a bounds check before accessing data[endOffset+tokEnd]:

if endOffset+tokEnd >= len(data) {
    return data
}

All existing tests pass.

[colek42]

Hi @buger and @Yanhu007 — we hit the same panic in the TestifySec Platform supply-chain stack and ended up vendoring a fork of v1.1.1 with a defer/recover wrapper around Delete() as a stopgap. The bounds check in this PR is the more correct fix — it addresses the root cause rather than masking it.

Two things that may help land this:

Adversarial test fixtures

We built a regression suite for GHSA-6g7g-w4f8-9c9x while building our fork. Drops cleanly into parser_test.go. Happy to open a follow-up PR contributing it once this lands. The cases that crash upstream v1.1.1 today:

• Truncated JSON immediately after a key (breaks endOffset calculation downstream)
• Malformed nested objects with mismatched braces
• Unicode escape sequences with truncated payloads
• Several oss-fuzz outputs reduced to minimal repros

The PoC from #274 (eyJ0ZXN0Ijox base64) is one such case.

Bounds check coverage

The check at the call site fixes the specific panic in the linked stack trace, but tokenEnd() returning len(data) can affect other accessors in Delete too. Worth running the fuzz target (fuzz.go:31) for a few minutes after this lands to confirm no other related panics surface — happy to share the corpus we collected.

Tag a release after merge and we can drop our fork — there are 31 dependabot alerts in our org that this resolves.

Thanks for the fix.