JSON Interoperability Vulnerabilities — Bishop Fox Research

The Core Finding

In November 2022, researchers at Bishop Fox published a detailed study documenting how JSON parser inconsistencies can be weaponised to bypass security controls. The paper is significant because it moves beyond the theoretical — it demonstrates concrete attack scenarios against systems that are common in modern web architectures.

The fundamental premise: many security-sensitive systems (API gateways, load balancers, authentication services, WAFs) receive a JSON payload and pass it through multiple parsers — often written in different languages or using different libraries. If those parsers disagree on how to interpret the same bytes, an attacker can craft a payload that satisfies the security check in one parser while being interpreted differently by the downstream application parser.

How Parser Differences Become Vulnerabilities

RFC 8259 leaves a number of behaviours undefined or implementation-specific. The most exploitable of these are:

• Duplicate keys: RFC 8259 says object key uniqueness "SHOULD" be enforced — a non-normative recommendation. Different parsers return the first occurrence, the last occurrence, all occurrences, or throw an error. An attacker sending {"admin":false,"admin":true} may trigger different boolean outcomes in different parsers.
• Number precision: JSON numbers are not bounded; parsers that use 64-bit floats silently truncate integers larger than 2⁵³. A token ID of 99999999999999999 and 100000000000000000 may become the same float in a JS parser but remain distinct in a Java BigDecimal parser.
• Unicode and encoding edge cases: Lone surrogates, non-minimal UTF-8 encodings, and null bytes embedded in strings are handled inconsistently. A WAF looking for a specific string may miss it if encoded differently than the application parser expects.

Three Attack Patterns

Bishop Fox categorised the exploitable patterns into three classes:

1. Key collision attacks: Duplicate keys used to smuggle a different value past an authorisation check that reads the first key while the application reads the last.
2. Number coercion attacks: Crafted numeric values that compare equal in the security layer's floating-point arithmetic but are distinct in the application layer's integer representation (or vice versa).
3. Comment and whitespace injection: Some parsers accept comments (// ... or /* ... */) or unexpected control characters. Injecting these can shift the structural interpretation of the document.

Mitigations

The researchers recommend several defensive practices:

• Use the same JSON parser (or at least the same library) throughout your stack wherever possible. Heterogeneous parser chains are the root cause.
• Reject JSON with duplicate keys at the point of ingestion, before the document reaches any security logic.
• Apply schema validation on the raw input before deserialising to a typed structure. A strict schema rejects structurally unexpected inputs early.
• For numeric identifiers that exceed safe integer range, transmit them as strings rather than numbers to avoid float-precision loss.

The research directly informed the IETF JSONBIS working group's charter, which was formalised earlier the same year to address these gaps in the JSON specification. Developers who regularly parse JSON from external sources can use online JSON fixers to inspect and repair payloads before they reach application code, reducing exposure to ambiguous inputs.