GHSA-vh7m-p724-62c2 is a high-severity (CVSS 7.7) CWE-190 vulnerability in elliptic. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for elliptic — 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
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
ellipticnpmDescription
The Elliptic package before version 6.5.3 for Node.js allows ECDSA signature malleability via variations in encoding, leading '\0' bytes, or integer overflows. This could conceivably have a security-relevant impact if an application relied on a single canonical signature.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | elliptic | all versions | 6.5.3npm install elliptic@6.5.3 |
Affected Products
ellipticindutnyResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for elliptic, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update elliptic to 6.5.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vh7m-p724-62c2 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.
In both OpenShift Container Platform (OCP) and OpenShift ServiceMesh (OSSM), the grafana and prometheus containers don't use the vulnerable elliptic library for authentication (OpenShift OAuth is used) or traffic communications (OpenShift route is used). Therefore the impact for OCP and OSSM is Low. Red Hat Quay…
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat OpenShift Container Platform 4.6 | openshift4/ose-grafana:v4.6.0-202010061132.p0 | RHSA-2020:4298 |
| Red Hat Single Sign-On 7 | nodejs | RHSA-2020:5533 |
Frequently Asked Questions
Is GHSA-vh7m-p724-62c2 in your dependencies?
Find it across npm, including transitive dependencies.