Pyc Cache Poisoning

What Pyc Cache Poisoning Does

Pyc cache poisoning is dangerous because Python will execute compiled bytecode if it trusts the cached artifact more than the source text. That creates a gap between what reviewers see and what the interpreter actually runs, especially in environments where bytecode integrity checks are weak, disabled, or inconsistently enforced.

The technique matters most when bytecode files are treated as a normal runtime optimisation rather than as executable code that can change program behaviour. Once an attacker can replace or influence the cached .pyc artifact, the visible source may no longer be the authoritative execution path.

Where the Trust Boundary Breaks

The core failure is a trust mismatch between source review, packaging, and runtime execution. Teams often inspect .py files, dependency manifests, or review diffs while overlooking the compiled cache that the interpreter may actually load.

That mismatch becomes more serious in build pipelines, containers, shared filesystems, or writable deployment paths where compiled artifacts can persist across runs. It also becomes easier to miss when cache files are generated automatically and rarely examined as security-sensitive inputs.

How Attackers Exploit Poisoned Bytecode

Attacker value comes from invisibility and persistence. Poisoned bytecode can introduce malicious logic without changing the source file that defenders expect to audit, and the altered code may survive application restarts if the cache is reused.

The technique is especially attractive when an attacker can tamper with artifact storage, influence build outputs, or place a crafted cache file where the interpreter will trust it. The result is often a hidden execution path that is harder to spot than a source-only backdoor.

What Defenders Should Verify

Exposure checks should start with inventory: identify where Python bytecode is generated, stored, mounted, or packaged, and whether those paths are writable by less-trusted processes. Review whether production systems load from immutable builds, whether cache directories are segregated, and whether deployment controls prevent artifact replacement.

When investigating a suspected compromise, compare runtime artifacts against the expected source and package provenance, then inspect the file timestamps, permissions, and build chain that produced them. If your environment also relies on cached or generated artifacts in adjacent layers, the same defensive mindset used in Web Cache Poisoning and Cache Deception Guide and GitHub and GitHub Actions Security Guide helps frame the problem as trust in generated output, not just source code.

Risk and Threat Considerations

Poisoned bytecode creates integrity risk first and then turns into execution risk. If an attacker can alter the cache, they can redirect application behaviour without necessarily touching the reviewed source tree, which makes the compromise harder to detect and easier to persist.

Failure mechanism: The interpreter loads attacker-modified compiled code because the cache is trusted, replayed, or insufficiently validated against the source and build provenance.

Impact: Hidden code execution can enable backdoors, credential theft, data manipulation, or persistence inside application runtimes and deployment images.

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?