Python Cache Poisoning as a Linux Privilege Escalation Technique

How misconfigured bytecode caching turns a Python performance feature into a local privilege escalation path — and why it keeps showing up in environments that otherwise look well-hardened.

Introduction

There’s a particular kind of finding that’s uncomfortable to present — not because it’s catastrophic, but because it’s embarrassing. When you show a team that one of their privileged automation scripts has been running with a world-writable __pycache__ directory for the past two years, the reaction isn’t usually alarm. It’s a long pause, followed by something like: “wait, that actually works?”

It does. Python’s bytecode caching mechanism, which every Python developer uses implicitly every single day, has a property that makes it interesting from an attacker’s perspective: Python trusts cached bytecode with essentially zero verification. Pair that with a privileged script and a writable cache directory, and you have a reliable local privilege escalation path that doesn’t require touching the source file, doesn’t require a running service, and in some configurations doesn’t leave obvious forensic artifacts.

This post is not a how-to. It’s a breakdown of the mechanism, the conditions that create vulnerability, and what actually matters when you’re trying to find and fix this in a real environment. If you’re a security engineer preparing for a Linux hardening review, a DevOps lead who owns automation infrastructure, or a compliance stakeholder trying to map real attack surface to framework controls, this is worth understanding in depth.

What Python Bytecode Caching Actually Does

When Python imports a module — or runs a script that imports one — it compiles the source code down to bytecode. Bytecode is a lower-level, platform-independent instruction set for the Python virtual machine. The CPython interpreter executes it significantly faster than parsing raw source every time.

To avoid repeating that compilation step on every execution, Python caches the bytecode in .pyc files. In Python 3, these live in a __pycache__ directory co-located with the source, with filenames that embed the interpreter version:

Python checks a small header in the .pyc file to decide whether the cache is still valid. The default validation mode relies on a timestamp and the source file’s size. If both match what’s recorded in the header, Python skips recompilation and loads the bytecode directly.

You can inspect that header yourself with the struct module:

There is no cryptographic signature. No hash of the bytecode itself. The validation is purely based on filesystem metadata: timestamp and size.

Import Resolution Order and the Attack Surface

When a script executes import utils, Python searches a list of directories in order. That list — stored in sys.path — typically puts the script’s own directory first:

The cache directory Python checks for bytecode is co-located with the script. So the chain looks like this: a privileged process runs a Python script, that script imports a module, Python checks the local __pycache__ directory for a valid .pyc file, and if the header metadata matches the source, Python loads it — without further verification.

If an attacker can write to that __pycache__ directory, they can place a crafted .pyc file with arbitrary bytecode. When the privileged process next imports that module, the attacker’s code executes in that elevated context.

The source file itself is never touched. If you’re auditing file modification times on .py scripts, you won’t see anything. The attack surface is entirely in the cache layer.

The Specific Conditions That Create Vulnerability

This requires a specific combination of conditions — all must be present simultaneously. That’s actually why it’s worth understanding carefully: it tells you exactly what to look for.

Condition 1: A Privileged Python Script

The most common examples in practice are cron jobs running as root, systemd service units executing Python with elevated permissions, and scripts in /etc/sudoers that allow a lower-privileged user to run them. Let’s look at each:

Condition 2: A Writable __pycache__ Directory

This is the permission misconfiguration that enables the attack. Let’s look at what a vulnerable directory looks like versus a properly hardened one:

How does this happen? When a developer runs a script as root for the first time, Python creates __pycache__ using the process umask. If the system umask is 022, the directory is created 755 — fine. But if umask is 000 or someone later runs chmod 777 to fix a PermissionError during testing and forgets to revert it, the door is open.

Condition 3: Predictable Module Imports

The attacker needs to know which module to target. With read access to the script, this is trivial. Even without it, the .pyc filenames in __pycache__ reveal exactly which modules are imported — because the filename IS the module name:

Why This Gets Missed in Practice

Here’s the honest answer: it doesn’t look like a vulnerability until you understand it. A world-writable __pycache__ directory doesn’t trigger alerts. It’s not a CVE. It’s a permission misconfiguration that only becomes dangerous in a specific context, and identifying that context requires connecting filesystem permissions, process privilege, Python import behavior, and scheduler or service configuration simultaneously.

Most security tools and manual reviews focus on the script itself. Is the script writable? Is its parent directory writable? The cache directory — one level deeper, named with an underscore convention that signals “internal plumbing” — escapes scrutiny.

There’s also a cognitive gap in how developers think about .pyc files. These are widely understood as ephemeral build artifacts — something you .gitignore and forget. The idea that they represent a persistent, exploitable attack surface doesn’t fit the mental model.

The Role of Metadata in .pyc Headers

For a crafted .pyc to be loaded by a privileged process, the attacker must forge the header metadata correctly — specifically, the source file’s mtime and size. If either value doesn’t match the real source, Python discards the cache and recompiles from source, overwriting the malicious file.

This is not cryptographically difficult — it’s metadata transcription. But it does require read access to the source file. If read access to the source is restricted, the attacker must guess the mtime and size, which is generally impractical for mtime (Unix epoch precision to the second).

The critical defensive implication: file integrity monitoring that only watches .py source files will not detect this attack. The malicious .pyc will have a creation time consistent with normal cache generation. You need to monitor .pyc files too, and ideally validate header consistency against source stats.

Real-World Contexts Where This Shows Up

The risk profile varies considerably by environment. These are the contexts where this finding surfaces most frequently.

Internal Automation and Shared DevOps Tooling

A team builds Python utilities for deployment or log rotation. These accumulate over months, running as root in a shared /opt directory. Nobody has revisited the permissions since initial deployment. The __pycache__ directories were generated automatically at first run and haven’t been thought about since.

Cron Infrastructure

Scheduled jobs often run as root and are rarely revisited after initial setup. Scripts executed by cron don’t go through the same code review cycle as application code. Permissions drift over time.

Containerized Workloads Running as Root

Containers that run as root internally and use bind mounts extend this attack surface from container to host. If the bind-mounted path is writable by an unprivileged process on the host, the host’s filesystem becomes the attack surface.

Legacy Python 2 Applications

Python 2’s .pyc files sit directly in the source directory alongside the .py files, making the permission surface more obvious but the problem equally real. EOL since January 2020, but still running in countless production environments.

Strategic Remediation

Fixing this is not complicated. The hard part is finding it. Here’s how to approach remediation across the layers that matter.

1. Filesystem Permissions — The Immediate Fix

Privileged script directories and their __pycache__ subdirectories should not be writable by any user other than the owning account. Treat them like system files.

2. PYTHONDONTWRITEBYTECODE — Eliminate the Cache

For privileged scripts that don’t need caching performance, the simplest fix is telling Python not to write cache files at all.

3. Hash-Based Validation (Python 3.8+)

For environments where you want to keep caching but harden the validation, compile .pyc files in checked-hash mode. Python will recompute the source hash at import time and reject any cache that doesn’t match.

4. File Integrity Monitoring

AIDE and Tripwire can be configured to watch __pycache__ directories alongside source files. Any unexpected modification to a .pyc file in a monitored directory should trigger an alert.

5. Auditing Sudo and Cron for Python Scripts

The audit should enumerate all privileged Python execution contexts and check each one’s directory permissions systematically.

Prioritization and What Actually Matters

Not every writable __pycache__ directory represents the same risk. Prioritize by the privilege level of the process consuming the cache and the number of users who can reach the writable path.

One more thing for engineering leaders: automated scanning helps here, but generic vulnerability scanners won’t surface this. You need tooling that understands Python’s import mechanics and correlates execution context with filesystem permissions. The audit script above is a starting point. A full review by someone who knows what they’re looking for will surface things automation misses.

Closing Thoughts

The finding that’s hardest to operationalize isn’t the one with the highest CVSS score. It’s the one that requires connecting three separate data points that no single tool is watching. Python cache poisoning as a local privilege escalation path is exactly that — technically straightforward once you see it, consistently overlooked because it lives at the intersection of performance optimization, filesystem permissions, and execution context.

The remediation isn’t exotic. Tighten directory permissions. Disable unnecessary caching on privileged scripts. Add __pycache__ to your integrity monitoring scope. Audit your cron and sudoers configurations with this threat model in mind.

But finding it in the first place requires knowing where to look.