GHSA-jf24-p9p9-4rjh is a high-severity (CVSS 7.5) CWE-190 vulnerability in github.com/gorilla/websocket. A fix is available for github.com/gorilla/websocket — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-jf24-p9p9-4rjh by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/gorilla/websocketReal-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
An integer overflow vulnerability exists with the length of websocket frames received via a websocket connection. An attacker would use this flaw to cause a denial of service attack on an HTTP Server allowing websocket connections.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gorilla/websocket | all versions | 1.4.1go get github.com/gorilla/websocket@v1.4.1 |
Affected Products
debian linuxdebianwebsocketgorillatoolkitDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gorilla/websocket, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/gorilla/websocket to 1.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jf24-p9p9-4rjh is resolved across your whole dependency graph.
Workarounds
Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.
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.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat OpenShift Container Platform 3.11 | atomic-openshift-cluster-autoscaler-0:3.11.404-1.git.0.2c258fe.el7 | RHSA-2021:0833 |
| Red Hat OpenShift Container Platform 4.6 | openshift4/compliance-rhel8-operator:v4.6.0-97 | RHSA-2021:0190 |
| Red Hat OpenShift Container Platform 4.7 | openshift4/cnf-tests-rhel8:v4.7.0-34 | RHSA-2020:5364 |
| Red Hat OpenShift Container Platform 4.7 | openshift4/ose-console:v4.7.0-202102130115.p0 | RHSA-2020:5633 |
| Red Hat OpenShift Container Platform 4.7 | openshift4/file-integrity-rhel8-operator:v4.7.0-9 | RHSA-2021:0100 |
| Red Hat OpenShift Container Platform 4.7 | openshift4/ose-hyperkube:v4.7.0-202105160013.p0 | RHSA-2021:1561 |
| RHEL-8-CNV-2.5 | container-native-virtualization/vm-import-controller-rhel8:v2.5.3-4 | RHSA-2021:0187 |
| RHEL-8-CNV-4.8 | container-native-virtualization/vm-import-operator-rhel8:v4.8.0-18 | RHSA-2021:2920 |
Frequently Asked Questions
Is GHSA-jf24-p9p9-4rjh in your dependencies?
Find it across Go, including transitive dependencies.