Fastly Compute@Edge JS Runtime has fixed random number seed during compilationGHSA-cmr8-5w4c-44v8
HIGHFix: fastly/js-compute-runtime@65524ffGHSA-cmr8-5w4c-44v8 is a high-severity (CVSS 7.5) CWE-335 vulnerability in @fastly/js-compute. A fix is available for @fastly/js-compute — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-cmr8-5w4c-44v8.
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.
@fastly/js-computenpmDescription
Impact
Math.random and crypto.getRandomValues methods failed to use sufficiently random values. The initial value to seed the CSPRNG (cryptographically secure pseudorandom number generator) was baked-in to the final WebAssembly module meaning the sequence of numbers generated was predictable for that specific WebAssembly module. An attacker with access to that same WebAssembly module that calls the affected methods could use the fixed seed to predict random numbers generated by these functions. This information could be used to bypass cryptographic security controls, for example to disclose sensitive data encrypted by functions that use these generators.
Patches
The problem has been fixed in version 0.5.3.
Corrected Math.random and crypto.getRandomValues methods to always use sufficiently random values. The previous versions would use a CSPRNG (cryptographically secure pseudorandom number generator) which we would seed with a random value. However, due to our use of Wizer, the initial value to seed the CSPRNG was baked-in to the final WebAssembly module meaning the sequence of numbers generated was predictable for that specific WebAssembly module. The new implementations of both Math.random and crypto.getRandomValues do not use a CSPRNG and instead pull random values from WASI (WebAssembly System Interface) libc’s random_get function, which is always a sufficiently random value.
Workarounds
There are no workarounds, you must upgrade to version 0.5.3 or later.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @fastly/js-compute | ≥ 0.4.0&&< 0.5.3 | 0.5.3npm install @fastly/js-compute@0.5.3 |
Affected Products
js-computefastlyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @fastly/js-compute, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @fastly/js-compute to 0.5.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cmr8-5w4c-44v8 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.
Frequently Asked Questions
Is GHSA-cmr8-5w4c-44v8 in your dependencies?
Find it across npm, including transitive dependencies.