Notifications
Clear all
Topic starter
18/08/2026 2:49 pm
TL;DR: A 4-byte change to a Python .pyc header can make malicious bytecode run while source review, static scanning, and even VirusTotal still see an innocent .py file, according to ActiveFence. The result is a supply-chain trust gap that also affects AI agent skill bundles and any workflow that treats cached runtime artifacts as non-executable.
NHIMG editorial — based on content published by ActiveFence: Poisoned Python Bytes & Malicious Caches
Questions worth separating out
Q: What breaks when Python caches are trusted more than source code?
A: The security model breaks because review, diffing, and source-based scanners no longer describe what actually runs.
Q: Why do cached Python artifacts matter in AI and automation environments?
A: AI agents and automation pipelines often consume reusable bundles, dependencies, and helper modules without deep human review at runtime.
Q: How do security teams know if Python bytecode is outside its intended boundary?
A: Look for prebuilt .pyc files in repositories, wheels, container layers, and skill bundles, then verify whether the interpreter is allowed to accept hash-based caches without rechecking them.
Practitioner guidance
- Treat .pyc files as executable artifacts Block committed __pycache__ directories and scan build outputs for compiled bytecode before release.
- Force hash validation at runtime Run Python with --check-hash-based-pycs=always in security-sensitive environments so the interpreter validates hash-based caches even when a header claims otherwise.
- Deploy skills from source only Reject AI agent skill bundles, wheels, and tarballs that contain prebuilt caches, then compile them during deployment under controlled build conditions.
What's in the full article
ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:
- The exact .pyc header fields and flag bits that switch Python into unchecked-hash mode.
- A proof-of-concept builder that rewrites bytecode caches and demonstrates silent execution.
- Hex-level inspection output showing how the poisoned cache appears in practice.
- Practical safe-handling steps for wheels, tarballs, CI outputs, and AI skill bundles.
👉 Read ActiveFence's analysis of poisoned Python bytecode and cache poisoning →
Poisoned .pyc caches: what security teams need to check now?
Explore further
18/08/2026 3:31 pm
Unchecked runtime artifacts create a source-of-truth failure: this attack works because teams assume reviewed source equals executed code. In Python, that assumption breaks as soon as a trusted cache is allowed to outrank the source file. The broader lesson applies to software supply chains and AI agent bundles alike: integrity controls must cover runtime artifacts, not just repository content. Practitioners should treat this as an executable trust problem, not a code review problem.
A question worth separating out:
Q: Should organisations allow AI skills to ship with compiled caches?
A: No, not when the skill can influence code execution or tool use. Compile at deploy time from source, strip caches from distribution packages, and validate the runtime artefact before the agent inherits any privileges. Otherwise, a small hidden payload can survive ordinary review and become an execution path.
👉 Read our full editorial: Poisoned Python bytecode exposes a hidden supply-chain trust gap
