How Denial of Service via Malformed JSON happens in Go and how to fix it

How Denial of Service via Malformed JSON Happens in Go and How to Fix It

The Vulnerability at a Glance

Introduction

The go.mod file in this repository listed github.com/buger/jsonparser v1.1.1 as an indirect dependency — quietly pulled in as part of the broader dependency tree. While indirect dependencies often go unnoticed, they carry the same security obligations as direct ones. In this case, buger/jsonparser v1.1.1 contains a high-severity Denial of Service vulnerability (CVE-2026-32285) that can be triggered by feeding the parser deliberately malformed JSON input.

For developers building services that accept user-supplied data — API payloads, webhook bodies, configuration uploads — this is exactly the kind of silent exposure that can turn a routine request into an outage.

The Vulnerability Explained

What is buger/jsonparser?

github.com/buger/jsonparser is a popular, high-performance Go library for parsing JSON without the overhead of encoding/json. It operates directly on raw []byte slices, making it fast — but also meaning it must be especially careful about how it handles unexpected or malformed byte sequences.

The Root Cause: Uncontrolled Resource Consumption on Malformed Input

In buger/jsonparser v1.1.1, certain malformed JSON byte sequences can cause the parser to enter a state where it consumes disproportionate CPU or memory resources — or panics entirely — before returning an error. This falls squarely under CWE-400: Uncontrolled Resource Consumption.

The vulnerable dependency declaration in go.mod looked like this:

// go.mod (before fix)
github.com/buger/jsonparser v1.1.1 // indirect

And the corresponding hash in go.sum:

github.com/buger/jsonparser v1.1.1 h1:2PnMjfWD7wBILjqQbt530v576A/cAbQvEW9gGIpYMUs=
github.com/buger/jsonparser v1.1.1/go.mod h1:6RYKKt7H4d4+iWqouImQ9R2FZql3VbhNgx27UK13J/0=

How Could This Be Exploited?

Consider a service that accepts a JSON body from an HTTP client and passes it — directly or indirectly — through buger/jsonparser. An attacker could craft a request body containing a malformed JSON payload specifically designed to trigger the vulnerable code path. For example:

// Hypothetical usage in a dependent component
jsonparser.Get(userSuppliedBody, "field")

If userSuppliedBody contains a malformed structure that exercises the bug in v1.1.1 — such as deeply nested incomplete objects, invalid Unicode escape sequences, or truncated number tokens — the parser can stall or crash the goroutine handling that request.

In a high-traffic service, an attacker sending a stream of such requests could:

1. Exhaust goroutine pool resources, causing legitimate requests to queue and time out.
2. Trigger a panic in the parsing goroutine, which — if not recovered — crashes the entire service process.
3. Cause memory pressure if the parser allocates buffers proportional to malformed input size before failing.

Because buger/jsonparser is listed as an indirect dependency here, the exact call site depends on which direct dependency pulls it in. However, the vulnerability is present in the binary regardless of call depth.

Real-World Impact

Any endpoint in this application that processes untrusted JSON — even indirectly — could be a vector. A single unauthenticated HTTP request with a crafted body is all that's needed to trigger the condition. No authentication bypass, no privilege escalation — just availability destruction.

The Fix

The fix is a targeted, minimal dependency upgrade: github.com/buger/jsonparser from v1.1.1 to v1.1.2.

Before and After: go.mod

- github.com/buger/jsonparser v1.1.1 // indirect
+ github.com/buger/jsonparser v1.1.2 // indirect

Before and After: go.sum

  github.com/buger/jsonparser v1.1.1 h1:2PnMjfWD7wBILjqQbt530v576A/cAbQvEW9gGIpYMUs=
  github.com/buger/jsonparser v1.1.1/go.mod h1:6RYKKt7H4d4+iWqouImQ9R2FZql3VbhNgx27UK13J/0=
+ github.com/buger/jsonparser v1.1.2 h1:frqHqw7otoVbk5M8LlE/L7HTnIq2v9RX6EJ48i9AxJk=
+ github.com/buger/jsonparser v1.1.2/go.mod h1:6RYKKt7H4d4+iWqouImQ9R2FZql3VbhNgx27UK13J/0=

Why Both Files Need to Change

Go modules use two files to pin dependencies:

• go.mod: Declares the required version. Changing v1.1.1 to v1.1.2 here tells the Go toolchain to resolve the new version.
• go.sum: Contains cryptographic hashes (h1: entries) that verify the integrity of downloaded modules. The new version's hash must be added to authenticate the upgrade. Note that the old entries remain — Go keeps them for auditability — and the new v1.1.2 hashes are appended.

What v1.1.2 Changes

Version 1.1.2 of buger/jsonparser tightens the parser's handling of malformed input by adding proper bounds and error checks on the problematic byte-sequence paths. Crucially, the fix is backward compatible: valid JSON input is parsed identically to v1.1.1, so no application behavior changes for well-formed data.

Prevention & Best Practices

1. Treat Indirect Dependencies as First-Class Security Concerns

The // indirect comment in go.mod can create a false sense of distance. As shown here, an indirect dependency's vulnerability is just as exploitable as a direct one. Include all dependencies — direct and indirect — in your vulnerability scanning.

2. Use Software Composition Analysis (SCA) in CI

Tools like Trivy, govulncheck, and Dependabot can automatically flag vulnerable versions of Go modules:

# Scan your Go project with govulncheck
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

# Or with Trivy
trivy fs --scanners vuln .

In this case, Trivy flagged the CVE-2026-32285 pattern against the go.mod file.

3. Validate and Limit JSON Input Before Parsing

Even with a patched parser, defense-in-depth means you should:

// Limit request body size before any parsing
http.MaxBytesReader(w, r.Body, 1<<20) // 1 MB max

// Read body with limit
body, err := io.ReadAll(r.Body)
if err != nil {
    http.Error(w, "request too large", http.StatusRequestEntityTooLarge)
    return
}

This prevents a class of resource-exhaustion attacks independent of parser behavior.

4. Fuzz-Test Your JSON Parsing Code

Go's built-in fuzzing support can help uncover parser edge cases before they become CVEs:

func FuzzParseConfig(f *testing.F) {
    f.Add([]byte(`{"key":"value"}`))
    f.Fuzz(func(t *testing.T, data []byte) {
        // Should never panic
        jsonparser.Get(data, "key")
    })
}

5. Follow OWASP Guidance on Input Validation

The OWASP Input Validation Cheat Sheet recommends validating all input for type, length, format, and range before processing — a principle that applies directly to JSON parsing pipelines.

Key Takeaways

• // indirect doesn't mean safe: github.com/buger/jsonparser was an indirect dependency, but its vulnerability was fully exploitable. Every entry in go.mod is a security responsibility.
• CVE-2026-32285 is triggered by malformed input, not by valid JSON: This means normal application testing won't expose it — only adversarial or fuzz inputs will.
• Both go.mod and go.sum must be updated together: Updating only go.mod without the corresponding go.sum hash will cause build failures; both changes are required for a complete, verifiable fix.
• The v1.1.1 → v1.1.2 upgrade is a drop-in fix: The API surface of buger/jsonparser is unchanged; no calling code needs modification.
• SCA tooling (Trivy) caught what code review would miss: This vulnerability lives entirely in a version string — a single character difference between v1.1.1 and v1.1.2. Automated scanning is the only reliable way to catch this class of issue at scale.

How Orbis AppSec Detected This

• Source: User-influenced input entering any code path that invokes github.com/buger/jsonparser functions (e.g., jsonparser.Get(), jsonparser.ArrayEach()) with untrusted byte slices.
• Sink: The malformed-input parsing routines inside github.com/buger/jsonparser v1.1.1, reachable through the indirect dependency declared in go.mod.
• Missing control: No version constraint preventing the use of the vulnerable v1.1.1 release; no input sanitization or size enforcement upstream of the parser call.
• CWE: CWE-400 — Uncontrolled Resource Consumption
• Fix: The dependency declaration in go.mod was updated from github.com/buger/jsonparser v1.1.1 to v1.1.2, with the corresponding cryptographic hash added to go.sum.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-32285 is a reminder that high-severity vulnerabilities don't always look dramatic in a diff. A single version number change — v1.1.1 to v1.1.2 in go.mod — is the difference between a service that can be taken offline by a crafted HTTP request and one that handles malformed input safely. The fix is minimal, backward-compatible, and verifiable through Go's module hash system.

For Go developers, the lesson is clear: your dependency tree is your attack surface. Keep it scanned, keep it current, and treat every // indirect entry with the same scrutiny as your direct dependencies.

References

• CWE-400: Uncontrolled Resource Consumption
• OWASP Input Validation Cheat Sheet
• OWASP Denial of Service Cheat Sheet
• Go Modules Reference — go.sum files
• govulncheck — Go Vulnerability Scanner
• Semgrep rules for Go dependency vulnerabilities
• fix: upgrade github.com/buger/jsonparser to 1.1.2 (CVE-2026-32285)