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.
Editorial analysis by NHI Mgmt Group, based on content published by ActiveFence: “Poisoned Python Bytes & Malicious Caches”.
By the numbers:
- The poisoned cache was undetectable by every antivirus on VirusTotal, and all 70 antivirus engines missed it.
Key questions
Q: How should security teams handle poisoned .pyc caches in release pipelines?
A: Treat cached bytecode as executable output, not as disposable build residue.
Q: Why do poisoned Python caches create a supply-chain risk?
A: Because the runtime trusts the compiled artefact, not just the source file humans review.
Q: What signs indicate that Python bytecode should not be trusted?
A: A .pyc file that ships with the application, appears in a package or skill bundle, or uses unchecked-hash mode should be treated as suspicious.
Practitioner guidance
- Block shipped .pyc and __pycache__ artefacts Refuse packages, wheels, tarballs, containers, and AI skill bundles that carry cached Python bytecode unless the cache is explicitly validated and required for execution.
- Force hash validation at runtime Run Python with --check-hash-based-pycs=always in security-sensitive environments so hash-based caches cannot silently bypass source checks.
- Disable cache writes where integrity matters Use PYTHONDONTWRITEBYTECODE=1 and -B in build, test, and sensitive execution paths to stop new caches being created in the first place.
Bottom line: The problem is not Python syntax, it is the mismatch between reviewed source and executable cache, which lets hidden code run without obvious signs.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:31 pm
Cache provenance, not source provenance, is the control boundary: this article shows that a build artefact can become the real execution unit while source review continues to provide false reassurance. That is a governance failure in software supply chains because the trust decision is being made at the wrong layer. Practitioners should treat any environment that ships cached bytecode as a provenance problem, not merely a language runtime detail.
A few things that frame the scale:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: Should organisations allow runtime caches in AI agent skill bundles?
A: Only if they can validate and govern those caches as executable content. Agent skills are often trusted too quickly, so the safer default is to reject bundled bytecode, rebuild from source at deployment, and apply the same integrity rules to skills that you would apply to any other software supply artefact.
👉 Read our full editorial: Poisoned Python bytecode exposes a hidden supply-chain trust gap