A .pth file is a Python startup file that can extend interpreter search paths and, when it contains import statements, execute code automatically. In supply-chain attacks, adversaries abuse this mechanism to run payloads at every Python startup, before the application imports anything. It turns package installation into a delayed execution trigger.
What a .pth file actually does
A .pth file is not just a path list, it is part of Python’s startup path processing. When placed in a site-packages location, it can add directories to the interpreter search path and, if it contains executable import statements, trigger code before the application begins normal execution.
That dual behaviour is what makes the file format powerful and dangerous. In ordinary use, it helps Python locate installed packages cleanly. In malicious or careless use, it can become an automatic execution hook that runs on interpreter startup regardless of whether the application intended to import that code path.
Why the mechanism is security-sensitive
The security issue is not the file extension itself, but the trust placed in the Python startup environment. A .pth file can convert a package installation, dependency drop, or filesystem write into persistent execution at every Python launch. That means compromise can survive across sessions and affect multiple applications that share the same interpreter environment.
This is especially relevant in supply-chain scenarios, where an attacker seeks to hide code in a dependency, wheel, or environment artifact rather than in the application’s visible source tree. The malicious payload may execute before application-level integrity checks, logging, or imports have a chance to intervene. That makes the mechanism attractive for stealthy persistence and for triggering further payloads early in process startup.
For a broader identity and privilege lens, the same pattern often pairs with over-privileged build, package, or automation paths. When attacker-controlled files can be written into interpreter search locations, the execution boundary is already weakened, and a simple file write becomes a code execution path.
NHIMG’s GitHub Action tj-actions Supply Chain Attack illustrates the same practical danger of supply-chain compromise turning trusted automation into a secret-exposure and execution channel.
How attackers abuse .pth files in real environments
Attackers typically rely on one of two outcomes: code execution or persistence. If they can place a crafted .pth file into a directory that Python reads during startup, the file can cause their code to run automatically whenever a Python process starts in that environment. If the file only alters search paths, it can still redirect imports toward attacker-controlled code.
The abuse pattern is often subtle because the malicious content can look like ordinary environment configuration. That is why .pth abuse fits cleanly into package-pollution and dependency-tampering narratives. The problem is not limited to a single application, either, because shared virtual environments, global site-packages paths, and build tooling can all inherit the same startup behaviour.
NHIMG’s 230M AWS environment compromise is a useful parallel for how exposed configuration and credentials in a trusted runtime can become a large-scale compromise path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | A .pth file exploits startup configuration and software trust boundaries. |
| CIS 2 — Inventory and Control of Software Assets | Detecting unexpected .pth files depends on knowing what software and paths are present. | |
| CIS 10 — Malware Defenses | Malicious .pth content can deliver code execution and persistence through trusted startup paths. | |
| Recommendation — Harden Python environments and review startup-affecting files as part of secure configuration management. Inventory interpreter environments so unexpected startup files and packages can be identified quickly. Scan Python startup paths and dependencies for malicious code and persistence mechanisms. | ||
| MITRE ATT&CK | T1059.006 — Command and Scripting Interpreter: Python | The term involves Python execution as the attacker’s runtime for payload launch. |
| T1037 — Boot or Logon Initialization Scripts | A .pth file functions like an initialization trigger that runs automatically at startup. | |
| Recommendation — Hunt for unexpected Python execution paths and startup-triggered script behavior. Monitor initialization locations for startup-triggered code that executes before normal application logic. | ||
Practitioner Guidance
Why practitioners should care: .pth files are a startup-time trust boundary, not a harmless packaging detail. Review them as executable artifacts whenever you inspect Python environments, dependencies, or build outputs, especially in CI/CD and shared runtimes.
What to watch for: Any unexpected .pth file, any .pth content that contains import statements, and any package installation path writable by untrusted users should be treated as a potential execution foothold. A legitimate path extension entry is normal; executable startup code in a .pth file is the red flag.
Practitioner takeaway: Treat Python startup directories as part of your code-execution surface, because once a .pth file is writable by an attacker, the environment can execute their code before your application logic even begins.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
