If the package is published only as source, pip can run setup.py during the download process and execute whatever code is embedded there. That means a developer may trigger malware simply by fetching a package for inspection. The safest response is to verify whether a wheel exists, review the files listed on PyPI, and avoid blind download workflows for untrusted packages.
Why a Source-Only PyPI Package Can Execute Code During Download
When a package is published only as source, pip may need to inspect packaging metadata by invoking the build or setup path before installation. If that source tree contains malicious code in setup logic, the act of downloading and inspecting the package can become an execution event, not a passive file transfer. That is why package format matters, even before installation begins.
Source distributions are more risky than many developers assume because the packaging workflow itself can run arbitrary Python. A wheel, by contrast, is a built artifact that does not require executing package setup code to understand what files are present. The difference is operationally important: source-first handling can turn curiosity or validation into an exposure path.
One useful way to think about this is that the package manager is not just retrieving content, it is often participating in package preparation. If the publisher has not provided a wheel, pip may fall back to source processing, and that fallback can expose the developer machine, build system, or CI runner to code that was never meant to be trusted. The safest assumption is that an unreviewed source package is executable until proven otherwise.
For background on real-world Python package abuse, see PyPI Breach and LiteLLM PyPI package breach, both of which show how package distribution can be used to reach developer systems and secrets.
Risk and Threat Considerations
Blindly fetching source-only packages creates a supply chain exposure because code can execute before a human has reviewed it. The threat is not limited to malware hidden in the package contents, it also includes credential theft, persistence on developer endpoints, and exposure of CI/CD secrets if the download happens in an automated environment.
Failure mechanism: pip may execute package setup or build logic while resolving a source distribution, and that logic can contain arbitrary commands, file reads, or outbound network activity. If the package is untrusted, the attacker only needs a developer to initiate the fetch or inspection path.
Impact: The result can be local code execution, token or secret theft, contaminated build workflows, and downstream supply chain compromise through poisoned dependencies or stolen publishing credentials. In higher-trust environments, a single unsafe package inspection can become an entry point for broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 15 — Service Provider Management | Source-only package fetching is a third-party supply chain exposure. |
| CIS 2 — Inventory and Control of Software Assets | Knowing which packages and formats enter the environment is central to safe dependency handling. | |
| CIS 8 — Audit Log Management | Download-time execution and package fetches should be detectable for investigation. | |
| Recommendation — Assess package providers and constrain trust before allowing dependency ingestion. Inventory approved packages and block unreviewed source-only dependency intake. Log package retrieval and build activity so suspicious execution can be investigated. | ||
| NIST CSF 2.0 | PR.IP-1 — Configuration Management | Artifact format and build handling are part of secure software configuration practice. |
| PR.DS-6 — Data is protected in accordance with risk strategy | Source-only package execution can expose secrets and other sensitive data during fetch or build. | |
| Recommendation — Require controlled artifact formats and review build inputs before use. Prevent package handling workflows from exposing sensitive data or secrets. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Package setup execution can steal credentials embedded in developer environments. |
| NHI-03 — Overprivileged Non-Human Identities | Compromised package workflows can abuse overly broad machine or service credentials. | |
| NHI-05 — Unsafely Stored Secrets | Developers often fetch packages from environments where secrets are stored locally or in CI. | |
| Recommendation — Keep secrets out of package build paths and rotate any exposed credentials immediately. Minimise package-build privileges and remove unnecessary access from automation identities. Store secrets away from package-processing environments and enforce short-lived credentials. | ||
Practitioner Guidance
What to verify: Check whether a wheel exists before touching an unfamiliar package, and treat a source-only release as higher risk until you have reviewed its packaging files and build instructions. If the package must be evaluated, do it in an isolated environment with no reusable secrets, no production tokens, and no access to sensitive developer state.
Common mistake: Many teams assume “download only” is safe and reserve security review for installation time. For Python packaging, that assumption is wrong when build-time hooks or setup logic can execute during retrieval, so the review gate has to move earlier in the workflow.
Practitioner takeaway: The real decision point is not install versus no install, it is trusted artifact versus executable source path, and source-only packages should be handled as code execution risks until proven otherwise.
Related resources from NHI Mgmt Group
- What breaks when a registry authorizes access without checking package visibility and requester scope?
- What breaks when organisations install a compromised Python package without pinning versions or verifying provenance?
- How do organisations reduce Python application risk without slowing developers down?
- How should security teams reduce the blast radius when a malicious Python package can execute at startup without any import?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
