A critical vulnerability in the widely used npm package sha.js lets attackers supply
unexpected input types that rewind or corrupt the internal hash state, produce identical digests for distinct inputs, and trigger denial-of-service conditions — a flaw tracked as CVE‑2025‑9288 and patched in sha.js 2.4.12. The bug is a missing input-type validation in the library’s update/digest path: crafted non-Buffer, non-string objects (for example, objects with a manipulated length property) can cause the hash implementation to behave unpredictably — including
hash rewind, value miscalculation, and resource exhaustion — with real downstream consequences for integrity-critical code and availability of services that depend on sha.js. Official advisories and package maintainers classify the issue as critical and have published a patch; operators should treat existing installations as urgent to remediate.
Background / Overview
sha.js is a pure‑JavaScript implementation of common SHA-family algorithms maintained as part of the browserify/npm ecosystem. It is embedded directly or indirectly in many Node.js modules, bundlers, and JavaScript-based crypto stacks where a compact, dependency‑free hash implementation is useful. Because many higher-level libraries and protocols rely on hashing for
integrity,
nonce generation, and as a building block in signature or key-derivation schemes, flaws in hash implementations or their use can have outsized consequences beyond a single npm package.
The maintainers published an advisory after public disclosure that describes the root cause as
missing input type checks in the sha.js update/digest code path and identifies affected versions as <= 2.4.11, with the fix released in 2.4.12. The advisory also includes a lightweight proof-of-concept illustrating how a crafted message (an array or parsed JSON structure containing an object with negative length) can rewind the hash state or otherwise produce the same digest for distinct logical inputs. Independent vulnerability trackers and Linux distributor advisories cross‑reference the advisory and list the issue with
high to
critical severity ratings; the NVD entry and multiple distributions mark the CVE as having severe integrity and availability impacts.
Technical anatomy — what exactly is wrong
The missing type checks and how hash rewind happens
At a high level, sha.js exposes an API where callers create a hash instance (for example SHA‑256), call update with successive chunks of data, and finish with digest. The implementation assumes inputs are either Buffer objects or strings, and it performs internal arithmetic and buffer indexing using the consumer-supplied length and numeric indices.
The vulnerability stems from
not verifying the input object's type and its length fields before using them in internal buffer math. An attacker who can cause the hash implementation to receive an object (for example, by sending a JSON‑encoded structure that is parsed and forwarded to the hash library without validation) can supply an object whose length is negative or absurdly large, or which contains properties that influence how the algorithm advances its internal state.
Two practical failure modes are described in the advisory:
- Hash rewind via negative length: If an object like { length: -x } is passed in a way the library accepts, the arithmetic that advances or rewinds the internal digest counters can underflow or apply a negative offset, effectively undoing previously incorporated data. This can convert a tagged hash into an untagged hash, or make two different message sequences produce the same digest when consumers treat them as distinct. The advisory’s PoC demonstrates this by feeding a forged JSON message that, once parsed back into tokens and passed into sha.js, yields the same digest as the original valid message.
- Value miscalculation and collision-like effects: By shaping object properties that control indexing (for example presenting numeric slots that mimic Buffer fields but with altered numeric content), an attacker can cause the library to compute a digest that matches another input’s digest while the semantic values differ (for instance, differing numeric representations that canonicalization routines treat inconsistently). The advisory outlines examples where a crafted object produces the same hash as the original data but is interpreted differently by downstream libraries (e.g., bn.js), opening integrity bypass or signature-forgery routes in particular contexts.
- Denial-of-Service through resource exhaustion: The code also fails to restrict pathological inputs such as giant numeric length strings ("1e99") or massively nested structures; those input forms can cause the hash code to loop, allocate enormous internal buffers, or hang the event loop — producing DoS against services that call sha.js on untrusted inputs. The GHSA advisory explicitly lists DoS on
{length:'1e99'} as an observed impact.
Why a type-check matters more than it sounds
Hash algorithms are deterministic, but their implementations rely on consistent, bounded input views (byte arrays or strings). Languages and runtime environments that allow structural typing or flexible object shapes — JavaScript being the canonical example — present a class of risks where
data is indistinguishable from an object that imitates the data. Without conservative type guards and explicit conversions (for example: coerce to Buffer, verify Buffer.isBuffer(input) or typeof input === 'string'), an attacker-controlled value can slip past checks and be interpreted incorrectly by low-level code that performs pointer-like arithmetic.
The sha.js fix enforces stricter input handling and guards the internal code paths that process length and byte indexes. The upstream pull request that implements the hardening — which also adds support for multi-byte typed arrays in a safe way — is part of the public remediation. Operators should treat the maintainer patch as authoritative and upgrade to the patched release.
Impact — who and what is at risk
The vulnerability’s impact vector varies by deployment, but three classes of risk are the most important.
- Integrity failures in crypto-dependent flows: Any code that relies on sha.js to compute nonces, signable digests, or steps in cryptographic protocols (HMAC keys, deterministic nonces, input to ECDSA nonce derivation, etc. can be affected. If an attacker manipulates a hash input so that two different messages yield the same digest, this breaks the assumptions that underpin many cryptographic constructions and can lead to private key extraction in fragile protocols (for example where nonce reuse reveals secret keys). The advisory explicitly warns about cases where subsequent system processing can convert a digest collision into key compromise. This is not speculative: the advisory describes how matching hashes with different numeric representations can produce catastrophic downstream effects in cryptographic code.
- Denial-of-Service of hashing services and downstream components: Replaying crafted inputs that cause rewind, infinite loops, or massive allocations will lock the Node.js event loop or crash processes, producing a total loss of availability for the impacted component until the attack stops or the process restarts. The advisory lists DoS as a principal impact and producers such as containerized logging agents, API gateways, or any service that consumes untrusted payloads are plausible targets. Distributors and vulnerability catalogs also rate Availability as a high-impact dimension.
- Supply-chain and transitive dependency exposure: sha.js is a low-level library; many higher-level packages embed or depend on it indirectly via bundlers and auxiliary crypto libraries. A vulnerable sha.js in a shared package-lock or container image can silently affect many services in an organization. Linux distributors and package trackers have published fixes and advisories for their consumers, underscoring the widespread dependency risk.
Severity metrics reported at disclosure placed CVE‑2025‑9288 at a critical level (GHSA / CVSS-like scores around 9.1 in some trackers), primarily reflecting the combination of network-accessible exploit vectors (attacker can deliver crafted data remotely in many web-facing flows), low privileges required, and the combination of high integrity and availability consequences. Public CVE/NVD entries reiterate the fundamental facts while distributors provide patch status per release. Caveat: the feasibility of serious cryptographic compromise (for example, extracting ECDSA private keys) depends on how sha.js is used and whether downstream code makes additional invariants assumptions. Some claims in community discussion point to worst‑case scenarios that require further context to be deterministic; these should be investigated case-by-case. Where a product derives critical material directly from sha.js outputs, assume the worst until proven otherwise.
Real-world exploitation scenarios
Below are representative attack scenarios to help triage risk.
- Web API that accepts JSON data and computes a digest for request validation. An attacker crafts a JSON payload where a parsed array element is an object that mimics a Buffer but sets length to a negative number. The server passes the parsed payload to sha.js without coercion; the hash state rewinds and the computed digest matches a valid token — granting unauthorized actions or bypassing integrity checks.
- Client-side bundling flows in CI/CD pipelines. A build tool parses inputs or metadata and uses sha.js to fingerprint artifacts. A malicious package or artifact with a crafted field can cause the bundler to compute identical fingerprints for different artifacts, confusing provenance checks and poisoning build outputs. This threatens supply‑chain integrity.
- Logging, telemetry, or monitoring agents that compute short fingerprints of incoming events may be crashed by huge or malformed inputs causing event-loop hangs and service downtime. In containerized environments where an agent runs as a DaemonSet, a local container with write access to input directories (or a compromised tenant) could repeatedly send crafted inputs to produce a denial-of-service across nodes.
Each of these scenarios is realistic because the vulnerability requires only the ability to deliver crafted data to a sha.js consumer; many web servers, APIs, and tooling pipelines accept or process attacker-controlled content. The advisory’s PoC shows the exploit is low‑complexity if type validation is missing.
Mitigation and remediation — practical checklist
- Upgrade affected packages immediately:
- Update sha.js to 2.4.12 or later. This is the authoritative fix; patched releases are published in the npm registry. Upgrading avoids the missing-type-check behavior described in the advisory.
- Rebuild and redeploy:
- For server-side apps and container images, rebuild artifacts and container images after applying the updated dependency and redeploy through normal CI/CD channels to ensure binaries and bundles include the fixed library.
- Audit dependency graph:
- Run
npm ls sha.js or use SCA tooling (npm audit, OWASP dependency-check, commercial scanners) to find transitive instances of sha.js in your codebase and third-party packages.
- Pin and lock:
- Use lockfiles (package-lock.json, yarn.lock) and enforce deterministic dependency resolution in CI. If a transitive dependency pulls in sha.js prior to 2.4.12, consider temporary overrides (npm overrides or yarn resolutions) while waiting for maintainers to update.
- Add input-type hardening where sha.js is called:
- Coerce inputs explicitly: convert to Buffer via Buffer.from, verify
Buffer.isBuffer(input) or typeof input === 'string' before calling update, and validate lengths and bounds.
- Centralize hashing calls behind a wrapper that enforces strict type and length checks and rejects unexpected inputs.
- Apply runtime limits:
- Enforce maximum input sizes and parsing depth on incoming data (JSON depth, string length), and reject requests exceeding limits before they reach hashing code.
- Monitor and hunt:
- Search logs for process crashes, unhandled exceptions around hashing paths, and repeated 5xx errors from endpoints that compute digests. Review CI build logs for failed builds or unusual hash outputs.
- Compensating crypto actions:
- If there is any suspicion that cryptographic nonces, deterministically-derived keys, or signatures may have been influenced by the vulnerable hash outputs, rotate affected keys and secrets, and reissue certificates where practical. The advisory suggests that nonce reuse or matching digests in specific contexts could lead to private-key leakage in the worst cases; treat such scenarios as highest priority for key rotation and forensic response.
Detection, incident response and forensics
- Host and process monitoring:
- Alert on repeated Node.js process restarts, sudden memory spikes in hashing processes, or worker threads that are stuck in CPU‑intensive loops.
- Application-layer telemetry:
- Log the types of values handed to hashing wrappers (sanitize logs to avoid exfil of sensitive content). If logs show objects rather than Buffer/string types being passed into hash functions, escalate and patch those call sites.
- Integrity validation:
- If your system uses sha.js in signature verification or key generation, add independent verification using platform-provided cryptography (for example, Node.js built-in crypto module or a vetted C/C++ library) to cross-check digests during incident triage.
- Forensics and evidence preservation:
- Preserve sample inputs that triggered abnormal behavior, export heap/process memory dumps where possible, and capture timeline of events. If private-key compromise is suspected, isolate and rotate keys immediately and engage cryptographic incident response procedures.
- Threat hunting:
- Check package manifests and deployment inventories for the presence of vulnerable sha.js versions, especially in shared container images and base images used across environments.
Supply-chain considerations and long-term risk reduction
This vulnerability is a textbook supply‑chain hazard: a small, low-level library flaw can cascade into high-impact integrity and availability failures wherever that library is embedded. Organizations should adopt these longer-term mitigations:
- Strengthen dependency governance: Require signed and reproducible builds, verify upstream patches, and adopt strict dependency review for critical path packages (crypto-related dependencies should receive special scrutiny).
- Layered cryptography: Prefer platform-native cryptography primitives (e.g., native Node.js crypto bindings) for security-sensitive operations when feasible, and isolate pure-JS implementations behind well-reviewed adapters.
- Continuous monitoring and fast-patch pipelines: Ensure patch artifacts can be rapidly built, tested, and rolled out; treat packages affecting cryptographic primitives as high-priority in patch windows.
- Defense in depth: Even if a library is patched, apply runtime guards, input validation, and least-privilege execution models to minimize the blast radius if a library exhibits undefined behavior.
Assessment: strengths of the response — and residual risks
The public response to CVE‑2025‑9288 is comparatively strong: the package maintainers released a patch promptly and documented the issue and PoC, and multiple distributions and vulnerability databases have published advisories and packaged fixes. That means operators have an authoritative code-level fix to apply and that major downstream distributors are tracking the issue. However, residual risks remain:
- Transitive exposure may delay remediation. Many projects consume libraries indirectly; until all consumers rebuild and redeploy, vulnerable code may linger in images and packages.
- The worst-case cryptographic scenarios (private key recovery through nonce reuse triggered by hash collisions) are environment-dependent. While the advisory highlights plausible paths, confirming real-world exploitation leading to key theft requires targeted forensic evidence. Treat such claims as plausible and high‑impact, and assume conservative key-rotation where cryptographic outputs are security-critical.
- Some embedded or long-lived artifacts (signed container images, vendor‑supplied binaries, or archived bundle artifacts) may contain vulnerable sha.js versions and persist in the field; auditing and rebuild campaigns are necessary to find and eradicate these survivors.
Where disclaimers are necessary: some online posts may extrapolate catastrophic outcomes from the advisory without demonstrating an end‑to‑end exploitation that yields private keys or system takeover. Those extrapolations should be investigated and validated against your own telemetry and threat intelligence before assuming the worst-case scenario has occurred in your estate. Always cross-check with patch timelines and vendor statements.
Practical checklist — immediate actions (0–72 hours)
- Inventory:
- Find every project, container image, and build artifact that includes sha.js (direct or transitive).
- Patch:
- Update sha.js to 2.4.12 and rebuild images, bundles, and server artifacts.
- Harden:
- Add type and length validation around every hashing call (wrap update/digest calls with explicit Buffer conversion).
- Monitor:
- Turn on alerts for hashing-related errors, process crashes, and large memory allocations.
- Rotate keys where risk is unacceptable:
- If cryptographic key material or deterministically-derived nonces may have been influenced by vulnerable hashing outputs, rotate immediately.
- Communicate:
- Notify vendor and upstream maintainers if you find unpatched downstream packages that still ship vulnerable versions so they can coordinate remediation.
CVE‑2025‑9288 is a clear reminder that in dynamic, duck‑typed languages like JavaScript,
type safety is a security property. When untrusted data reaches low‑level primitives without defensive guards, the resulting undefined behavior can break integrity assumptions and take systems offline. The fix is available and straightforward: upgrade to the patched sha.js release, add conservative input validation, and hunt for lingering copies in your dependency graph. Treat hashing and other cryptographic primitives as high‑assurance code paths — and make small, systematic changes now to prevent a repeat of this class of supply‑chain and runtime hazards.
Source: MSRC
Security Update Guide - Microsoft Security Response Center