🔗 Unexpected security footguns in Go's parsers

In Go applications, parsing untrusted data creates a dangerous attack surface that’s routinely exploited in the wild. During our security assessments, we’ve repeatedly exploited unexpected behaviors in Go’s JSON, XML, and YAML parsers to bypass authentication, circumvent authorization controls, and exfiltrate sensitive data from production systems.

These aren’t theoretical issues—they’ve led to documented vulnerabilities like CVE-2020-16250 (a Hashicorp Vault authentication bypass found by Google’s Project Zero) and numerous high-impact findings in our client engagements.

This post contextualizes these unexpected parser behaviors through three attack scenarios that every security engineer and Go developer should understand:

1. (Un)Marshaling unexpected data: How Go parsers can expose data that developers intended to be private
2. Parser differentials: How discrepancies between parsers enable attackers to bypass security controls when multiple services parse the same input
3. Data format confusion: How parsers process cross-format payloads with surprising and exploitable results

We’ll demonstrate each attack scenario with real-world examples and conclude with concrete recommendations for configuring these parsers more securely, including strategies to compensate for security gaps in Go’s standard library.

Below is a summary of the surprising behaviors we’ll examine, with indicators showing their security status:

• 🟢 Green: Secure by default
• 🟠 Orange: Insecure by default but configurable
• 🔴 Red: Insecure by default with no secure configuration options

	JSON	JSON v2	XML	YAML
json:"-,…"	YES (bad design)	YES (bad design)	YES (bad design)	YES (bad design)
json:“omitempty”	YES (expected)	YES (expected)	YES (expected)	YES (expected)
Duplicate keys	YES (last)	NO	YES (last)	NO
Case insensitivity	YES	NO	NO	NO
Unknown keys	YES (mitigable)	YES (mitigable)	YES	YES (mitigable)
Garbage leading data	NO	NO	YES	NO
Garbage trailing data	YES (with Decoder)	NO	YES	NO