Require cache poisoning is a Node.js attack where an attacker causes a malicious module to be stored in the CommonJS require cache. Later imports reuse the cached object, so the attacker can influence code execution, change exported functions, or persist altered behaviour within the process.
How Require Cache Poisoning Works
Require cache poisoning is a Node.js process-level attack against CommonJS module loading. The attacker gets a malicious module or altered export object into the require cache, so later imports reuse the poisoned object instead of loading the intended module again.
Because the cache is trusted inside the process, the technique can change execution flow without needing to keep re-exploiting the original injection point. That makes it especially dangerous when the poisoned module controls authentication checks, request handling, configuration, or other security-sensitive behaviour.
Why the Cache Becomes a Security Boundary
Node.js caches loaded modules to improve performance and preserve singleton-like behaviour. In normal use, that is helpful; in an attack, it becomes a persistence point inside the runtime. If an attacker can influence what is loaded first, replace exports, or tamper with the cache entry, the process may continue using attacker-influenced logic for the rest of its lifetime.
This is why require cache poisoning is more than a one-off code injection issue. The real concern is trust in process state. Once the cache is polluted, downstream code may assume it is calling vetted application logic when it is actually invoking altered behaviour.
Where Exposure Usually Comes From
Exposure often starts with insecure module resolution, writable paths, untrusted input that affects module names or paths, or compromised build and deployment artefacts. In package-heavy JavaScript environments, the risk also grows when applications rely on transitive dependencies, dynamic imports, or startup code that executes before integrity checks are in place.
Web Cache Poisoning and Cache Deception Guide is useful background because it explains how poisoning bugs exploit trust in cached state, even though the mechanism here is the Node.js module cache rather than an HTTP cache. For adjacent JavaScript supply-chain risk, see GitHub and GitHub Actions Security Guide and Ultralytics PyPI compromise 2024, which illustrate how compromised delivery paths can seed malicious code into runtime environments.
Detection, Containment, and Recovery
Detection focuses on the moment the runtime deviates from expected module behaviour. Unexplained changes in exported functions, unexpected side effects at import time, or modules resolving from unusual locations are all warning signs. In incident response, defenders should treat a poisoned cache as a runtime integrity problem, not just a bad dependency event.
Containment usually means restarting the affected process after the code path is fixed, because cache state lives in memory. After patching the source issue, teams should review whether the compromise changed application logic, loaded additional payloads, or exposed credentials, sessions, or other sensitive material during the altered execution window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Require cache poisoning exploits unsafe module-loading design and mutable runtime state. |
| Recommendation — Review module-loading paths and runtime trust boundaries for unsafe dynamic behaviour. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The issue is an application security flaw in code loading and trust assumptions. |
| Recommendation — Harden application code paths that load or reuse executable modules. | ||
| MITRE ATT&CK | T1055 — Process Injection | The attack alters process execution behaviour inside a running runtime. |
| Recommendation — Hunt for runtime tampering that changes process behaviour after startup. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The term concerns protecting the integrity of loaded code and process state. |
| Recommendation — Apply integrity controls to detect unauthorized changes in executable code paths. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe module resolution and trust in runtime configuration can enable poisoning. |
| Recommendation — Eliminate configuration paths that let untrusted input influence code loading. | ||
Practitioner Guidance
Why practitioners should care: Require cache poisoning matters because the attack can persist for the life of the Node.js process and silently alter trusted application logic. If the poisoned module influences access decisions, configuration, or request handling, the compromise can become much more impactful than the original injection point.
What to watch for: Pay close attention to dynamic module paths, unusual startup behaviour, and any code that writes to or depends on mutable process state. Review build and deployment pipelines as well, since a poisoned artefact can be just as damaging as a runtime-only manipulation.
Related resources from NHI Mgmt Group
- How should security teams test whether a cache key is safe from poisoning in practice?
- What do teams get wrong about detecting cache poisoning and related cache key flaws?
- What happens when a cache poisoning flaw is chained with a reflected client-side gadget?
- What should security teams do first when auditing for web cache poisoning risk?