Page cache poisoning is an attack that corrupts cached file pages in memory so a process reads malicious or stale content instead of the intended file data. It targets the operating system page cache, where shared cached pages can influence file reads, execution paths, or integrity checks if trust is misplaced.
How Page Cache Poisoning Works
page cache poisoning corrupts the operating system’s cached view of file data, so later reads can return content that no longer matches the on-disk file. The danger is not just stale data, but trust in a shared in-memory cache that may influence multiple processes.
This matters because page cache is meant to improve performance while preserving file semantics. When an attacker can alter what sits in cache, the system may serve malicious bytes, bypass expected integrity assumptions, or make a process operate on content that was never actually written to the underlying file.
Why It Becomes a Security Problem
At a technical level, page cache poisoning attacks the boundary between the file system and memory. If a process assumes cached pages are authoritative without revalidating the source of truth, then poisoned cache entries can affect execution paths, configuration reads, package handling, or integrity checks.
The issue is most serious where cached file pages are reused across privilege boundaries, workloads, or security-sensitive reads. In those cases, a single contaminated cache entry can influence more than one consumer, which turns a local integrity flaw into a broader trust failure.
Common Conditions That Make It Possible
Page cache poisoning usually depends on some combination of weak cache invalidation, shared trust in cached content, race conditions, or an attacker who can influence file state while another process is reading it. It is especially concerning when software assumes that “cached” means “safe” rather than “current and verified”.
In practice, the exposure grows when applications read files whose contents can change quickly, when integrity checks are done against stale views, or when the environment includes layered storage, overlays, or other abstractions that make file provenance harder to reason about. Web Cache Poisoning and Cache Deception Guide is useful for understanding the broader cache-trust pattern, even though the filesystem cache is the target here.
Detection and Hardening Focus
Defending against this class of issue starts with understanding where the system trusts cached data more than the underlying file state. Logging, integrity monitoring, and careful invalidation behavior help reveal when a process is consuming data that does not match expected file metadata or provenance.
Where file reads are security-sensitive, the safer pattern is to reduce ambiguity about freshness and origin, and to avoid designs that let mutable content and high-trust decisions share the same cache assumptions. Web Application Attacks Guide and Confidential Computing Guide are both relevant reading when you want to see how trust boundaries and protected execution environments change the impact of poisoned or tampered content.
Risk and Threat Considerations
Page cache poisoning is dangerous because it can turn a performance feature into an integrity bypass. If an attacker can influence what gets cached, the system may consume malicious or stale content even when the on-disk file looks correct.
Failure mechanism: a process reuses cached file pages instead of re-reading validated source data, so the attacker wins by corrupting the in-memory trust path rather than the file itself.
Impact: affected processes can load bad configuration, execute tainted content, fail integrity checks, or propagate incorrect state into other trusted operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1557 — Adversary-in-the-Middle | Cache poisoning is a technique for altering trusted data in transit or at rest |
| Recommendation — Map poisoned-read patterns to T1557 and hunt for integrity bypass paths in your detection content. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-transit is protected | Addresses integrity of data paths when cache trust can be abused |
| DE.CM-09 — Configurations, system software and code are monitored for unauthorized changes | Cache poisoning is often detected through monitoring for unexpected file-state changes | |
| Recommendation — Protect file read paths so cached content cannot subvert expected data integrity. Monitor file-state and cache-related anomalies for unauthorized or unexpected changes. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Directly supports validating that consumed content matches expected integrity |
| Recommendation — Apply integrity-validation controls before trusting cached file content in security-sensitive workflows. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logs are needed to trace suspicious file-read and integrity anomalies |
| Recommendation — Retain and review logs that expose unexpected file-access and content-drift behavior. | ||
Practitioner Guidance
What to watch for: treat unexpected file-content drift, integrity-check mismatches, and suspicious reuse of mutable files as signals that cache trust is too broad. If a workflow depends on exact file content, make freshness and provenance explicit rather than assuming the cache is authoritative.
Practitioner takeaway: the key control question is not whether caching is enabled, but whether any security decision still depends on cached bytes that could outlive the file state they are supposed to represent.
Related resources from NHI Mgmt Group
- Why can file-integrity checks miss page-cache corruption exploits?
- What breaks when a Linux kernel logic flaw can write to the page cache?
- What breaks when a Linux local exploit can alter the page cache instead of the file on disk?
- How should security teams test whether a cache key is safe from poisoning in practice?