The Fork Bomb Saved Us

The malware in LiteLLM 1.82.8 contained a .pth file that ran on any Python startup. It collected SSH keys, cloud credentials, cryptocurrency wallets, and CI/CD secrets, encrypted them with a 4096-bit RSA key, and exfiltrated the archive to an attacker-controlled domain. The payload was well-engineered. The encryption was sound. The exfiltration was clean.¹

The .pth file also spawned a child Python process to do its work. That child process triggered the .pth file again. Which spawned another child process. Which triggered it again. An exponential fork bomb that consumed 100% CPU and 5+ GB of RAM within seconds.²

The fork bomb was a bug. The attacker did not intend for the malware to be visible. A correctly implemented version would have run silently on every Python invocation on every infected system, potentially for weeks. Instead, developers noticed their machines grinding to a halt, investigated, and found the credential stealer. PyPI quarantined both versions 46 minutes after publication.¹

Forty-six thousand installations in forty-six minutes. The detection mechanism was an implementation error in the malware.

TL;DR

• The bug: LiteLLM 1.82.8’s credential stealer had a fork bomb bug that made infected machines grind to a halt. Without the bug, the stealer would have run silently for weeks.
• The gap: Static analysis, behavioral monitoring, and code review all missed the attack. Every detection layer assumed another layer would catch it. None did.³
• The curve: Attacker quality improves with iteration. The .pth technique is now publicly documented. The next attacker inherits it without the bug.
• What works without luck: Domain age checking on egress, behavioral baselining for package installs, file system canaries, installation isolation. Each works regardless of payload quality.
• The asymmetry: The defender chooses the environment. If the installation environment has no credentials to steal, a perfect payload harvests nothing.

We Got Lucky

Strip the fork bomb from the payload and the attack succeeds silently. The .pth file runs before any import, before any application code, before any Python-level sandbox. There is no hook point. There is no log entry. The credential stealer runs, encrypts, exfiltrates, and the Python process continues normally. The developer sees nothing. The CI pipeline sees nothing. The security scanner sees nothing, because the security scanner was the attack vector in the first place.³

The detection story for LiteLLM 1.82.8 is not “our monitoring caught it.” The detection story is “the attacker shipped a bug.”

This is not a comfortable foundation for supply chain security.

The Attacker Quality Curve

Software quality improves with iteration. This is true for attackers as well as defenders. TeamPCP’s campaign hit five ecosystems in one week: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI.⁴ Each ecosystem compromise used credentials harvested from the previous one. The campaign demonstrated operational sophistication: domain registration 24 hours before payload delivery, tag hijacking on mutable references, and credential rotation evasion through incomplete Aqua Security key changes.

The fork bomb was the one mistake in an otherwise competent operation. The next campaign will not make that mistake. The .pth file technique is now publicly documented, analyzed by CrowdStrike, Microsoft, Wiz, and Palo Alto.³ The next attacker inherits the technique without the bug.

Adversarial capability follows the same improvement curve as defensive capability. The technique is public. The analysis is public. The next attacker starts where TeamPCP finished.

Detection Cannot Depend on Attacker Mistakes

The current supply chain detection model has three layers, and all three failed for LiteLLM:

Static analysis missed it. The .pth file is a legitimate Python feature. The payload was double base64-encoded and decoded at runtime. Static scanners that look for known malicious patterns find nothing because the pattern is new.

Behavioral monitoring missed it. The credential stealer made one outbound HTTPS POST to a domain that looked like a legitimate service (models.litellm.cloud). Egress monitoring that inspects destination domains would need to know that this specific domain was registered 24 hours ago. Most egress monitors do not check domain age.

Code review missed it. The malicious versions were published directly to PyPI, bypassing the GitHub CI/CD pipeline entirely. There was no pull request to review. There was no diff to inspect. The attacker used stolen publishing credentials to upload pre-built packages.

Every detection layer assumed a different part of the attack chain would catch the problem. None did. The fork bomb caught the problem.

What Actually Detects Silent Malware

If you cannot rely on attacker mistakes, you need detection mechanisms that work regardless of implementation quality.

Domain age checking on egress requests. The exfiltration domain was registered 24 hours before the attack. A firewall rule that flags outbound requests to domains less than 7 days old would have caught this. The rule is simple, the false positive rate is manageable, and it catches the most common exfiltration pattern.

Behavioral baselining for Python processes. A pip install that suddenly makes HTTPS POST requests to an unknown domain is anomalous. Process-level behavioral monitoring that tracks network activity during package installation would flag this.

File system canaries. Place a fake SSH key at a canary path and a fake AWS credential at another canary path. Monitor for any process that reads these files. A credential stealer that sweeps standard paths will read the canaries. A legitimate process will not. The canary triggers an alert before the exfiltration completes.

Installation isolation. Run pip install in an environment with no access to real credentials. Copy the installed packages to the production environment afterward. The .pth file fires during pip’s own Python process, which means the credential stealer runs during installation. If the installation environment has no credentials to steal, the attack harvests nothing.

None of these mechanisms require the attacker to make a mistake. They work regardless of payload quality.

The Asymmetry

Defense has one structural advantage: the defender chooses the environment. The attacker must work within whatever environment the package is installed into. If that environment has no credentials, no network access, and file system canaries, the payload succeeds technically but fails operationally.

The LiteLLM attack worked because the installation environment was the same environment that held publishing credentials, SSH keys, and cloud tokens. The fork bomb was irrelevant to the security architecture. It was relevant to the timeline.

Next time, the fork bomb will not be there. The credentials will still be in the same environment as the package manager. The question is whether you will have changed the environment before the next attacker ships a clean payload.

FAQ

Why didn’t the attacker test for the fork bomb?

The .pth file spawning a child process is a reasonable implementation choice for running a payload without blocking the parent. The recursive trigger is a subtle interaction between .pth and Python’s site.py initialization. It is the kind of bug that appears in integration testing but not in unit testing, and malware authors have limited opportunity to integration-test in realistic environments.

Could the fork bomb have been intentional?

Unlikely. The fork bomb made the malware immediately visible, which is the opposite of the attacker’s goal. A silent credential stealer that runs for weeks harvests orders of magnitude more credentials than one that is detected in 46 minutes.

Is domain age checking practical at scale?

Yes. Domain age is available via WHOIS or DNS registration date APIs. The check adds milliseconds of latency per request. Most organizations can whitelist known new domains.

Sources