A technique that alters Python compiled bytecode so the interpreter executes attacker-controlled logic instead of or alongside the visible source. It exploits the gap between source review and runtime execution, especially when hash-based validation is disabled or bypassed.
Expanded Definition
Pyc cache poisoning is a Python supply chain and runtime integrity problem in which a compiled .pyc file is modified so the interpreter loads malicious bytecode while the source code appears unchanged. The risk is not in compilation itself, but in the trust placed in cached artifacts that may outlive the source review that originally approved them.
In practice, the attack matters when bytecode caches are writable, copied across environments, or accepted without strong validation. Python can treat cache files as a convenience layer for startup performance, yet that convenience becomes a liability if the environment does not verify whether the cached object still matches the source. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because integrity monitoring, change control, and secure configuration all reduce the chance that altered runtime artifacts go unnoticed.
The concept is often confused with source-code tampering, but pyc cache poisoning is different because the visible source may remain intact while execution is redirected through compiled output. The most common misapplication is assuming source review alone is sufficient, which occurs when teams ignore the integrity of cached bytecode and the permissions that govern who can write it.
Examples and Use Cases
Implementing bytecode integrity rigorously often introduces operational friction, requiring organisations to weigh faster startup times and deployment convenience against tighter file controls and validation overhead.
- A container image ships with prebuilt Python caches, but the build pipeline does not verify that the .pyc files correspond to the reviewed source at release time.
- A shared server allows a low-privilege process to write into a directory containing Python cache files, creating a path for execution changes at the next restart.
- An incident responder finds that a script’s source diff is clean, yet the executed behavior is hostile because the interpreter is loading a poisoned cached artifact.
- A CI/CD system caches Python artifacts between jobs, but weak isolation lets one pipeline step influence another by replacing compiled bytecode before deployment.
- Teams using hardened baseline guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls can pair file integrity checks with restricted write access to reduce this exposure.
Why It Matters for Security Teams
Pyc cache poisoning is important because it breaks a basic assumption of application security: that what is reviewed is what runs. For security teams, that means code review, dependency scanning, and source control protections may still miss the actual execution path if runtime artifacts are not governed with equal care.
The impact can be especially serious in build systems, containers, and ephemeral workloads where bytecode may be generated automatically and then reused in ways that are not obvious to application owners. Python hardening guidance and platform integrity practices help, but the larger lesson is that runtime trust must extend beyond the repository. This is consistent with the control intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where monitoring, configuration management, and least privilege intersect.
Organisations typically encounter the operational consequences only after an unexplained behavior change, at which point pyc cache poisoning becomes unavoidable to investigate and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Integrity of software and data is central when cached bytecode can alter execution. |
| NIST SP 800-53 Rev 5 | SI-7 | Integrity checks and software validation directly address poisoned compiled artifacts. |
Apply integrity verification to detect unauthorized changes in executable bytecode.
