Your RSA-2048 keys break in 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
Jul 1, 2024
Updated
Aug 12, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 26, 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 CVEs64th percentile — riskier than 64% of all scored CVEsHighest risk

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.

How urgent is this, really

CVE-2024-37298 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 379,145 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

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

    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.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2024-37298 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2024-37298. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

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?

O3 Security finds CVE-2024-37298 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2024-37298: schema (High 7.5) | O3 Security