Loading story…
Security researchers detailed a persistence technique that abuses Python’s PYTHONPYCACHEPREFIX environment variable to redirect .pyc bytecode into an attacker-controlled writable cache path and have that bytecode executed by applications that ship with bundled Python runtimes. The technique was demonstrated against PgAdmin4, where a malicious __init__.pyc for the pgadmin package executed within the trusted PgAdmin4 process context, giving attackers a way to maintain code execution without modifying the original application files.
The research found the method worked on PgAdmin4 v9.11.1 with Python 3.13.9 and could be made more durable by using Python’s PycInvalidationMode.UNCHECKED_HASH, allowing malicious cache files to remain valid even if the corresponding .py source changes. Although PgAdmin4 v9.11.2 and later disabled new bytecode writes through PYTHONDONTWRITEBYTECODE, the application still reads existing .pyc files, meaning pre-generated malicious bytecode can still be loaded; the researchers warned the issue is not unique to PgAdmin4 and may affect other software that launches bundled Python from user-controlled contexts.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
SRA Labs published research showing how attackers can abuse PYTHONPYCACHEPREFIX to place attacker-controlled .pyc files in a writable cache path and gain code execution through trusted applications that bundle Python. The write-up demonstrates the technique against PgAdmin4, including persistence via malicious __init__.pyc files and continued execution even when bytecode writing is disabled.
The research states that PgAdmin4 v9.11.2, released in February 2026, stopped writing bytecode files to the expected cache location. The change is attributed to a commit introducing use of the PYTHONDONTWRITEBYTECODE environment variable.
Python documentation describes the PYTHONPYCACHEPREFIX environment variable, which directs Python to write .pyc files to a parallel cache tree at a specified path instead of source-tree __pycache__ directories. This behavior underpins the later persistence technique discussed in the research.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Python maintainers and incident responders have highlighted a security risk in `.pth` path configuration files, which can execute arbitrary code during interpreter startup when a line begins with `import` followed by whitespace. A CPython issue raised concern over hidden `.pth` files, while DFIR reporting detailed how the behavior can be abused as a stealthy persistence mechanism that triggers whenever Python starts or imports modules, often from trusted locations such as `site-packages` or user package directories. The technique has been tied to real-world intrusion activity: DFIR analysis cited Volexity’s reporting on exploitation of Palo Alto Networks GlobalProtect `CVE-2024-3400`, where attackers allegedly deployed a backdoor as `/usr/lib/python3.6/site-packages/system.pth` and protected it from deletion. Researchers warned that malicious `.pth` files may evade many default forensic and security workflows because they resemble benign package metadata, though file-creation telemetry and EDR process-chain monitoring can help detect suspicious Python-launched activity.
Aug 1, 2026
CPython disclosed two medium-severity vulnerabilities affecting distinct parts of the runtime and tooling. **CVE-2026-1502** allows CR/LF bytes to pass through HTTP client proxy tunnel header or host handling, creating a header-injection risk in proxy tunnel scenarios. The issue was published through Python security channels and the `oss-sec` mailing list, with remediation details tracked in the CVE record and an associated CPython pull request. A second flaw, **CVE-2026-5713**, affects CPython remote debugging and introspection features and can trigger out-of-bounds read and write behavior when a privileged Python process connects to a malicious or compromised Python target. The bug impacts newer capabilities including `profiling.sampling` in Python 3.15+ and asyncio inspection commands such as ``` python -m asyncio ps python -m asyncio pstree ``` in Python 3.14+, and exploitation is expected to be unstable because the connecting process is likely to crash under ASLR.
Jun 29, 2026
dCERT issued advisories for two Python-related vulnerabilities affecting **Red Hat Enterprise Linux** and **CPython**. One advisory warns that a flaw in `python-wheel` on Red Hat Enterprise Linux can allow **privilege escalation** and **arbitrary code execution**, creating a path for attackers to gain elevated access and run malicious code on affected systems. A second dCERT advisory reports a **CPython** vulnerability that can **bypass security measures**, indicating that protections relying on expected interpreter behavior may be undermined on vulnerable deployments. Together, the advisories highlight risk across both the Python runtime and packaging ecosystem, with potential impact ranging from weakened defensive controls to full code execution on enterprise Linux environments.
Jun 29, 2026