GHSA-3669-72x9-r9p3
HIGHPotential memory exhaustion attack due to sparse slice deserialization
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/gorilla/schemaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Details
Running schema.Decoder.Decode() on a struct that has a field of type []struct{...} opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. For instance, in the Proof of Concept written below, someone can specify to set a field of the billionth element and it will allocate all other elements before it in the slice.
In the local environment environment for my project, I was able to call an endpoint like /innocent_endpoint?arr.10000000.X=1 and freeze my system from the memory allocation while parsing r.Form. I think this line is responsible for allocating the slice, although I haven't tested to make sure, so it's just an educated guess.
Proof of Concept
The following proof of concept works on both v1.2.0 and v1.2.1. I have not tested earlier versions.
package main
import (
"fmt"
"github.com/gorilla/schema"
)
func main() {
dec := schema.NewDecoder()
var result struct {
Arr []struct{ Val int }
}
if err := dec.Decode(&result, map[string][]string{"arr.1000000000.Val": {"1"}}); err != nil {
panic(err)
}
fmt.Printf("%#+v\n", result)
}
Impact
Any use of schema.Decoder.Decode() on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. There seems to be no possible solution that a developer using this library can do to disable this behaviour without fixing it in this project, so all uses of Decode that fall under this umbrella are affected. A fix that doesn't require a major change may also be harder to find, since it could break compatibility with some other intended use-cases.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gorilla/schema | all versions | 1.4.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gorilla/schema. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/gorilla/schema to 1.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3669-72x9-r9p3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3669-72x9-r9p3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3669-72x9-r9p3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3669-72x9-r9p3 in your dependencies?
O3 detects GHSA-3669-72x9-r9p3 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.