NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

CVE-2024-37298 — schema

HIGHFix: gorilla/schema@cd59f2f

CVE-2024-37298 is a high-severity (CVSS 7.5) CWE-770 vulnerability in github.com/gorilla/schema. A fix is available for github.com/gorilla/schema — see the affected versions and patch details below.

Potential memory exhaustion attack due to sparse slice deserialization

Also known asGHSA-3669-72x9-r9p3GO-2024-2958
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2024-37298.

EPSS Exploitation Probability

via FIRST.org ↗
1.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs66th percentile — riskier than 66% of all scored CVEsHighest risk
0.00%0.54%1.07%1.61%0.3%1.1%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/gorilla/schema

Real-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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/gorilla/schemaall versions1.4.1go get github.com/gorilla/schema@v1.4.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gorilla/schema, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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 CVE-2024-37298 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This vulnerability in the gorilla/schema package is a high-severity issue due to its potential to cause a Denial of Service (DoS) attack through memory exhaustion. The schema.Decoder.Decode() function, when processing a struct with fields of type []struct{...}, is susceptible to malicious input that exploits sparse…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Source: Red Hat security advisory for CVE-2024-37298 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Advanced Cluster Security 4.4advanced-cluster-security/rhacs-central-db-rhel8:4.4.5-2RHSA-2024:6054
Red Hat Enterprise Linux 8container-tools:rhel8-8100020240808093819.afee755dRHSA-2024:5258
Red Hat Enterprise Linux 8.8 Extended Update Supportcontainer-tools:rhel8-8080020240724065004.0f77c1b7RHSA-2024:5194
Red Hat Enterprise Linux 9podman-4:4.9.4-10.el9_4RHSA-2024:6194
Red Hat Enterprise Linux 9.0 Update Services for SAP Solutionspodman-2:4.2.0-5.el9_0RHSA-2024:4825
Red Hat Enterprise Linux 9.2 Extended Update Supportpodman-2:4.4.1-20.el9_2RHSA-2024:5634
Red Hat OpenShift Container Platform 4.12podman-3:4.2.0-11.rhaos4.12.el9RHSA-2024:5202
Red Hat OpenShift Container Platform 4.13podman-3:4.4.1-10.3.rhaos4.13.el9RHSA-2024:4848

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is CVE-2024-37298 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2024-37298: schema — Fixed in 1.4.1