CVE-2026-32285

What it actually does

CVE-2026-32285 is a denial-of-service flaw in the jsonparser project's Delete function. When malformed JSON causes offset calculations to become invalid, the function can produce a negative slice index and trigger a Go runtime panic. In applications that process attacker-controlled JSON and do not recover from panics, a single crafted request or message can terminate the affected process, causing service unavailability. The CVSS vector indicates network exploitability, low attack complexity, no authentication requirement, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Applications, APIs, workers, or data-processing services that use the affected jsonparser Delete function on untrusted JSON may be crashed remotely, interrupting service availability and potentially causing failed transactions, queue backlogs, degraded customer experience, or repeated restarts. Current public exploitation signals are low: EPSS is 0.0075 and flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity; however, the vulnerability is simple to trigger where reachable because it requires no privileges or user interaction.

How an attack unfolds

An attacker first identifies an application endpoint, API, webhook, ingestion pipeline, or message consumer that accepts JSON and passes that data to the jsonparser Delete function. The attacker then sends malformed JSON structured to confuse offset validation during deletion logic. When the library calculates slice boundaries, the malformed offsets can result in a negative slice index. In Go, this causes a runtime panic such as a slice-bounds error. If the application lacks panic recovery around request or message handling, the panic can crash the process. The attacker can repeat the request to keep the service unstable or unavailable, especially if process supervisors automatically restart it without blocking the offending input source.

How to fix it

Upgrade the affected jsonparser dependency to a vendor-confirmed fixed release as soon as one is available. No fixed versions were provided in the input, so engineering teams should monitor the upstream jsonparser project advisory, package registry, and release notes for the corrected version and pin to that version once published. Until a fix is available or fully deployed, avoid passing untrusted or malformed JSON directly to Delete; validate JSON syntax before invoking Delete; add defensive bounds checking around deletion logic where wrapping code is possible; implement panic recovery in HTTP handlers, queue consumers, and background workers; reject oversized or malformed JSON at the API gateway or application boundary; apply rate limits to JSON-ingestion endpoints; and ensure process supervisors restart crashed services while alerting on crash loops. Where practical, replace vulnerable usage with a parser or deletion routine that safely handles malformed input.

How to confirm the fix worked

Confirm exposure by producing a software bill of materials or dependency inventory and locating applications that import or vendor the affected jsonparser project and call Delete on externally supplied JSON. Verify remediation by confirming the deployed artifact uses a fixed upstream version once available, or that the vulnerable dependency is removed or replaced. In staging, test representative malformed JSON inputs against endpoints or workers that previously reached Delete and confirm they return controlled errors rather than panicking or terminating. Review runtime logs after validation tests for absence of Go panic messages, slice-bounds errors, stack traces referencing jsonparser Delete, process restarts, container restarts, or crash-loop events. Also confirm that request-size limits, JSON validation, rate limiting, and panic-recovery middleware are active on affected paths.

Typical attack path

1. Identify an exposed service or processing path that accepts JSON from unauthenticated or low-trust sources.
2. Determine that the application performs JSON field deletion using the affected jsonparser Delete functionality.
3. Send specially malformed JSON that leads to invalid offset calculation during Delete processing.
4. Trigger a Go runtime panic caused by a negative slice index or slice-bounds violation.
5. Cause the affected process, worker, or request handler to terminate if panic recovery is not in place.
6. Repeat malformed requests or messages to sustain denial of service and exhaust operational recovery mechanisms.

How to detect it

To determine whether this was already exploited, review application logs, container logs, process supervisor logs, API gateway logs, load balancer logs, and message-consumer logs for crashes or panics occurring immediately after malformed JSON requests or messages. Look for Go runtime panic entries, slice-bounds or negative-index errors, and stack traces that reference jsonparser Delete. Correlate panic timestamps with inbound HTTP requests containing invalid JSON, unusual content lengths, repeated 400/500 responses, or repeated requests from the same source IP, user agent, API key, or message producer. In containerized environments, check orchestrator events for restart spikes, CrashLoopBackOff conditions, liveness probe failures, and short-lived container instances. In queue-based architectures, inspect dead-letter queues or poison-message handling for malformed JSON payloads that repeatedly crash consumers. There are no known public exploit-specific network signatures from the provided data, so detection should focus on runtime crash artifacts and malformed JSON activity preceding service restarts.

• panic: runtime error: slice bounds out of range
• panic: runtime error: slice bounds out of range [:-
• slice bounds out of range [:-
• negative slice index
• jsonparser.Delete
• github.com/buger/jsonparser.Delete
• runtime.goexit
• CrashLoopBackOff
• Back-off restarting failed container
• liveness probe failed
• readiness probe failed

What your security team should do

• Inventory all services, APIs, workers, and third-party components that use the jsonparser project, especially code paths invoking Delete on untrusted JSON.
• Prioritize internet-facing JSON ingestion endpoints and unauthenticated APIs for mitigation because the flaw is network-exploitable with no required privileges.
• Ask engineering teams to add or verify panic recovery around request handlers and message consumers so malformed input cannot terminate the whole process.
• Deploy JSON syntax validation, request-size limits, and rate limiting at application and gateway layers for affected services.
• Monitor upstream jsonparser releases and apply the first vendor-confirmed fixed version promptly; pin dependencies rather than allowing ambiguous floating versions.
• Create alerts for Go panic logs, slice-bounds errors, stack traces involving jsonparser.Delete, abnormal process restarts, and container crash loops following malformed JSON requests.
• Because EPSS is currently low and the issue is not in KEV, treat this as important availability hardening rather than an active widespread exploitation emergency unless local telemetry shows crash attempts.