ForEach and Get disagree on duplicate object keys (parser smuggling vector)

I'm Thiago (@TryZeroDay). I found this in my first fuzzing campaign against gjson. I'm transparent about my workflow: I directed the methodology, ran the campaign, reproduced the bug, and minimised it manually — but I used an LLM (Claude) to write the fuzzing harnesses and to help me draft this report. I originally wrote it in Portuguese and translated it to English.

Summary

I found that gjson.Result.ForEach and gjson.Get resolve a duplicated object key to different values. ForEach yields every occurrence in source order; Get returns the first occurrence only. The two APIs are not internally consistent.

This opens a JSON parser smuggling vector when gjson is mixed with other JSON parsers — notably the Go standard library, which keeps the last duplicate instead.

Affected version

I tested against:

• github.com/tidwall/gjson v1.19.0 (commit 0fac2c9aa6eb5d5564bfaaaad513ce0d5d2314de)
• Go 1.23 / linux-amd64

Minimal reproducer

package main

import (
    "fmt"
    "github.com/tidwall/gjson"
)

func main() {
    const json = `{"a":1,"a":2}`

    gjson.Parse(json).ForEach(func(k, v gjson.Result) bool {
        fmt.Printf("ForEach  key=%q  value=%s\n", k.String(), v.Raw)
        return true
    })
    fmt.Printf("Get(\"a\")  value=%s\n", gjson.Get(json, "a").Raw)
}

Output

ForEach  key="a"  value=1
ForEach  key="a"  value=2
Get("a")  value=1

ForEach exposes both 1 and 2; Get resolves only to 1. The two APIs cannot both be correct simultaneously for any single key-resolution policy.

Why I think this matters

RFC 8259 §4 leaves the meaning of duplicate object members undefined and warns implementations that interoperability is at risk if they diverge. gjson itself diverges internally, and across the ecosystem:

This is the same shape as published vulnerabilities:

• CVE-2017-12635 — Apache CouchDB (admin role injection via duplicate roles key; CVSS 9.8 critical)
• CVE-2022-23541 — Auth0 jsonwebtoken (JWT verification bypass via parser disagreement; CVSS 7.6 high)
• CVE-2020-27619 — Python (multiple parser-disagreement issues)

Concrete attack scenario I built to demonstrate it

package main

import (
    "encoding/json"
    "fmt"
    "github.com/tidwall/gjson"
)

// authorize uses gjson on the hot path.
func authorize(payload string) string {
    return gjson.Get(payload, "role").String()
}

// auditLog uses encoding/json (already wired into the audit pipeline).
func auditLog(payload string) string {
    var m map[string]interface{}
    _ = json.Unmarshal([]byte(payload), &m)
    if r, ok := m["role"].(string); ok {
        return r
    }
    return ""
}

func main() {
    payload := `{"role":"admin","role":"user"}`
    fmt.Println("authorize() sees:", authorize(payload))  // admin
    fmt.Println("auditLog()  sees:", auditLog(payload))   // user
}

For payload {"role":"admin","role":"user"}:

The attacker is granted admin access while the audit log records a user-level action.

How I found it

I ran a libFuzzer + AddressSanitizer campaign with 13 harnesses spread across 3 Docker containers (~103k execs/s combined), built on top of the Google OSS-Fuzz tooling. One of the harnesses I wrote checks ForEach/Get consistency on randomly-generated valid JSON. It panicked on a 733-byte input after ~750k executions; I minimised the crashing input manually to the 13-byte case above.

By the time this bug surfaced the campaign had tested roughly 38 million JSON documents.

Suggested resolutions

Any of these would close the issue from my point of view:

1. Align Get with encoding/json — return the last occurrence of a duplicated key. This brings gjson into alignment with the wider ecosystem (stdlib encoding/json, browser JSON.parse, Python json.loads) and removes the cross-library smuggling vector.
2. Document the divergence prominently in the README, in a "Duplicate keys" section, with a clear warning about parser smuggling when gjson is mixed with other JSON parsers.
3. Add a strict mode — for example gjson.ParseStrict(json) that returns an error on duplicate keys, plus a gjson.ValidStrict predicate. This gives security-sensitive callers a way to reject ambiguous input.

A combination of (1) and (3) would be ideal in my opinion.

Thiago — @TryZeroDay.