Supply Chain PyPI Install-Time Code Execution

How the attack works

A developer or CI job runs pip, uv, pipenv, poetry, or a setup.py/PEP-517 build. Within the same install session and within 10 minutes, that installer process spawns something suspicious: a download tool, a shell or Python one-liner that reaches the network or executes code, a scripting host, or a mechanism that persists across reboots. If the spawned process (not pip itself) then makes an HTTP request, that's flagged as a follow-on stage — likely fetching a second-stage payload. The rule tracks the exact process lineage from the install, so it only reports processes that actually descended from that specific install, not unrelated activity happening at the same time.

Netzilo detection

Why it matters

A single 'pip install' can silently hand code execution to whoever published the package, with the privileges of the developer or build system running it — potentially leading to credential theft, backdoors, or a compromised CI/build pipeline.

What you can do

• →Review any install-time process chain that spawns a downloader, shell one-liner, or scripting host, even if the package looks legitimate.
• →Pin package versions and use hash-verified lockfiles so build-time behavior can't change silently between installs.
• →Run package installs in isolated, network-restricted build environments so any unexpected download or exec attempt is contained.
• →Check flagged installs against the package's actual documented build requirements — legitimate CUDA/ffmpeg/tokenizer wheels do download binaries, but the destination and files fetched should be verifiable.

Known benign look-alikes

• Legitimate source distributions that download prebuilt binaries, model weights or test fixtures at build time (curl/wget invoked from setup.py or a PEP-517 backend) — common for CUDA, OpenCV, tokenizer and ffmpeg wrappers.
• Build scripts that chmod +x a compiled artifact staged under /tmp or /var/tmp before running it as part of a configure step.
• Container/CI provisioning where a dependency install is immediately followed in the same shell session by crontab, systemctl enable or launchctl calls.
• Developer shells where 'pip install -e .' is run and the same shell is then used to run an unrelated curl/base64 command within ten minutes.
• Internal package mirrors accessed by a wrapper script that is not named pip/python (the egress stage is escalation only and never fires alone).

References

• https://atlas.mitre.org/techniques/AML.T0010
• https://attack.mitre.org/techniques/T1195/002/
• https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

Related threats