CVE-2025-9288: Critical Input Validation Flaw in sha.js

CVE-2025-9288 is a Critical (CVSS 9.1) improper input validation flaw in the npm package sha.js, through version 2.4.11. The maintainers' advisory says version 2.4.12 is the patched release. Upgrade, then check your lockfile for older copies pulled in by other packages, since this library usually arrives as a dependency.

What's affected

The record says the issue affects sha.js through 2.4.11. The GitHub advisory for the project states the affected range as 2.4.11 and earlier, and describes the fix this way: version 2.4.12 is the patched release.

Scores deserve a note. The record gives CVSS 3.1 score 9.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. The GitHub advisory rates it Critical with a CVSS 4.0 base score of 9.1 and a different vector. The numbers agree, the scoring versions do not, so quote the version alongside the number when you report it.

The advisory says related polyfill packages that depend on this code are affected too, naming create-hash and crypto-browserify. Anything that bundles Node crypto polyfills for the browser is a candidate, which includes many front end builds that you may not think of as using hashing libraries at all.

How to check if you're exposed

1. In a project, run npm ls sha.js to print every installed copy and the packages that pull it in. Add --all if your npm version hides deeper levels.
2. Run npm explain sha.js to see the dependency path for each copy.
3. For Yarn or pnpm, use yarn why sha.js or pnpm why sha.js.
4. Search lockfiles directly across repositories with grep -rn "sha.js" --include=package-lock.json --include=yarn.lock --include=pnpm-lock.yaml .
5. Then decide which findings are reachable. Hashing is often called only from a few code paths, and reachability analysis helps separate copies your code calls from copies that just sit in node_modules.

The free in-browser dependency scan reads your manifest and lockfile in the browser and flags affected versions, and the Gold directory shows other known issues in the same package.

What to do now

1. Upgrade sha.js to the fixed release named in the advisory, and confirm the version your lockfile resolves after install. Version 2.4.12 is the patched release.
2. If a parent package pins an old copy, update the parent first, or use your package manager's override mechanism (npm overrides, Yarn resolutions) to force the patched version while you wait for the parent to move.
3. Rebuild and redeploy front end bundles. A fixed lockfile does not change an already built bundle.
4. Look for code of your own that passes unusual values to hash functions, such as objects instead of strings or buffers. Validating types at your boundary is cheap and removes a class of surprises.
5. Where hashes protect something important, such as signatures, integrity checks or key derivation, review whether any value could have been miscomputed while you ran the old version.

Why it matters

The weakness class is CWE-20 (improper input validation). The advisory describes missing input type checks: values that are not a well formed Buffer or string can pass through, which can produce wrong hash values, hang execution or rewind hash state, among other undefined behavior. A hash function that returns the wrong answer for crafted input undermines anything that trusts it, and the advisory links this to downstream effects such as matching hashes for different values.

It is not in CISA's Known Exploited Vulnerabilities catalog according to the record, and the advisory does not report attacks. The reason to move quickly is reach. Small utility packages sit under thousands of builds, and the exposure shows up in transitive dependencies that nobody chose directly.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NVD record data for CVE-2025-9288
• GitHub advisory GHSA-95m3-7q98-8xr5

Last reviewed: 18 October 2026.