CVE-2025-9288

What it actually does

sha.js versions through 2.4.11 contain an improper input validation flaw that can allow crafted or unexpected input data to be handled incorrectly by the hashing implementation. The primary technical risk is integrity failure: applications that rely on sha.js digests for verification, signing workflows, cache keys, deduplication, tamper checks, or authorization decisions may compute or accept hashes over manipulated input in ways the application developer did not intend. This is not currently characterized as remote code execution, privilege escalation, or direct data disclosure by itself; impact depends on how the affected package is used and whether attacker-controlled data reaches sha.js.

Why it matters to the business

Organizations using sha.js in security-sensitive workflows could make incorrect trust decisions, such as accepting altered content, validating the wrong data, or bypassing integrity checks. The current public exploitation signal is low: EPSS is 0.00676, it is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no mature public exploit is indicated. However, because sha.js is commonly included transitively in JavaScript dependency trees, exposure may be broader than direct package usage suggests, especially in applications that bundle browser-side cryptographic code.

How an attack unfolds

An attacker first identifies an application path where user-controlled input is passed into sha.js. This could be a browser-side bundle, API endpoint, file validation workflow, token or message verification routine, checksum comparison, or any feature that computes SHA digests using the vulnerable package. The attacker then supplies specially crafted input designed to trigger the package's input validation weakness. If the surrounding application relies on the resulting digest for a security or business decision, the attacker may be able to manipulate what data is effectively hashed or accepted. Successful exploitation is therefore application-specific: the vulnerability becomes meaningful when sha.js output is trusted for integrity, authenticity, routing, caching, or authorization without independent validation and canonicalization.

How to fix it

Upgrade sha.js to a version newer than 2.4.11 once a fixed upstream release is available and confirm that all direct and transitive dependency paths resolve to the fixed version. No exact fixed version was provided in the input, so teams should verify the current upstream advisory, npm metadata, and package manager audit results before selecting the target version. If an upgrade is not immediately available, mitigate by replacing sha.js with a maintained cryptographic implementation such as the platform-native Node.js crypto module or Web Crypto API where feasible, strictly validating and canonicalizing input before hashing, rejecting unsupported input types and encodings, and avoiding reliance on client-side hash results for security decisions. Use package-manager overrides or resolutions to force a safe replacement across transitive dependencies, then rebuild and redeploy all affected artifacts, including server packages, browser bundles, containers, and serverless deployments.

How to confirm the fix worked

Confirm exposure by searching package manifests, lockfiles, SBOMs, container images, and built JavaScript bundles for sha.js versions through 2.4.11. Use commands such as npm ls sha.js, npm audit, yarn why sha.js, pnpm why sha.js, and SCA tooling to identify direct and transitive dependency paths. After remediation, verify that no package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOM, or deployed artifact still resolves sha.js to 2.4.11 or earlier. Functional validation should include regression tests for all features that hash attacker-supplied input, with explicit tests for unsupported types, unusual encodings, empty values, large inputs, and malformed data. Where sha.js was replaced, compare expected digest behavior against a trusted implementation and ensure security decisions are made only over canonicalized input.

Typical attack path

1. Inventory or fingerprint a JavaScript application or bundled dependency tree to determine whether sha.js version 2.4.11 or earlier is present.
2. Locate functionality where attacker-controlled input is hashed, validated, signed, compared, cached, or otherwise processed through sha.js.
3. Submit malformed, ambiguous, or specially crafted input that exercises the improper input validation condition.
4. Observe whether the application computes an unexpected digest, accepts manipulated data, bypasses an integrity check, or behaves inconsistently.
5. Use the incorrect trust decision to alter content, bypass validation, poison downstream state, or gain unauthorized access to functionality dependent on the hash result.

How to detect it

There are no universal compromise indicators for this vulnerability because exploitation depends on how an application uses sha.js and may leave only application-specific traces. To assess possible prior exploitation, identify application features that pass external input into sha.js and review logs around those paths for malformed payloads, repeated validation failures, checksum mismatches, unexpected digest comparisons, file integrity failures, signature verification anomalies, cache inconsistencies, or unusual error spikes. Relevant sources include web access logs, API gateway logs, application logs, WAF logs, CDN logs, JavaScript error telemetry, package/SBOM history, CI/CD build logs, container image manifests, and endpoint telemetry for production build artifacts. If the library was used in authentication, authorization, signing, or integrity enforcement, compare historical accepted transactions or artifacts against a trusted hashing implementation using canonicalized input to look for mismatches. Treat dependency-presence findings as exposure indicators, not proof of compromise.

What your security team should do

• Prioritize inventory of JavaScript, Node.js, browser bundle, container, and serverless assets for sha.js versions through 2.4.11, including transitive dependencies.
• Assess whether sha.js is used in security-sensitive paths such as signature verification, checksum validation, token handling, file integrity checks, request authentication, cache keys, or authorization decisions.
• Upgrade or replace sha.js when a fixed version is available; if no fixed version is available, use dependency overrides or migrate to Node.js crypto or Web Crypto API.
• Add input canonicalization and strict type validation before any hashing operation that processes user-controlled data.
• Do not rely on client-side hashes or unauthenticated hashes for security enforcement; perform trusted validation server-side.
• Run SCA in CI/CD and fail builds that introduce sha.js versions 2.4.11 or earlier once an approved fixed version or replacement is defined.
• Review application logs and telemetry for unusual validation failures, checksum mismatches, malformed input errors, or repeated probing of endpoints that perform hashing.
• Because EPSS is low and there is no KEV or known ransomware use, handle as a dependency integrity risk rather than an emergency internet-wide exploitation event, unless the package is used in a critical trust boundary.