A Poisoned Xinference Package Targets AI Inference Servers

Part 4 of the TeamPCP Supply Chain Series

Part 1 covered CanisterWorm. Part 2 covered the malicious LiteLLM package. Part 3 covered the Telnyx WAV steganography attack. This post covers the latest wave: three malicious versions of xinference on PyPI, carrying the same credential-stealing playbook and a plot twist.

On April 22, 2026, Mend.io’s threat detection identified malicious versions of xinference on PyPI: 2.6.0, 2.6.1, and 2.6.2. Xinference is an open-source distributed AI model inference framework built by Xorbits, used to self-host LLMs, embedding models, and image generation at scale. The malicious versions are aimed squarely at the infrastructure teams running it.

The payload is structurally similar to prior TeamPCP attacks, double base64 encoding, detached subprocess on import, exhaustive credential sweep, but there is one notable wrinkle: TeamPCP publicly denies this one is theirs.

The denial

Shortly after public reporting surfaced the # hacked by teampcp marker inside the decoded payload, the TeamPCP Twitter account (@pcpcats) posted the following:

What changed in this wave

The Xinference payload shares the same double-layer base64 architecture and the same exhaustive credential harvester as LiteLLM and Telnyx. A few things are different:

No persistence. Unlike LiteLLM (.pth file, systemd service) and telnyx (Windows Startup folder binary), this payload is a single-fire-and-forget exfiltration payload. Once the stolen data is sent, nothing remains on disk.

No encryption. LiteLLM and Telnyx encrypted stolen data with AES-256-CBC and an RSA-2048 public key before exfiltration. This payload does not. The collected data is gzipped as love.tar.gz and POSTed in the clear over HTTPS with a custom tracking header.

New C2 domain. Previous waves used models.litellm.cloud, checkmarx.zone, and 83.142.209.203:8080. This payload uses whereisitat.lucyatemysuperbox.space.

The harvester targets everything documented in prior waves, SSH keys, AWS/GCP/Azure/Kubernetes credentials, .env files, Docker configs, database passwords, shell histories, /etc/passwd, /etc/shadow, plus a particularly broad sweep of cryptocurrency wallet files: Bitcoin, Ethereum keystores, Solana validator keypairs, Cardano signing keys, Zcash, Ripple, Litecoin, and Dogecoin. The Solana sweep is notably thorough, hunting validator-keypair.json, vote-account-keypair.json, authorized-withdrawer-keypair.json, and keystore files across /home/sol, /home/solana, /opt/solana, and /solana.

Indicators of compromise

Network

Filesystem

Remediation

Any environment that imported Xinference 2.6.0, 2.6.1, or 2.6.2 should treat all credentials as compromised. Rotate: SSH keys, AWS IAM credentials, Kubernetes service account tokens, GCP and Azure credentials, Docker registry tokens, database passwords, .npmrc and .pypirc tokens, and any crypto wallet keys accessible from that machine.

Because this payload leaves no persistence artifacts, there is no backdoor to remove beyond the package itself. However, the absence of persistence does not mean the data has not already left the machine.

Conclusion

Whether this is TeamPCP directly, a copycat operating with their tools, or a deliberate false flag, the Xinference attack follows the same playbook that has defined this campaign since March 2026: supply chain entry, import-time execution, exhaustive credential harvest, and silent exfiltration. The targeting of AI inference infrastructure continues a pattern, Trivy, LiteLLM, telnyx, and now Xinference are all tools common in ML engineering and AI deployment pipelines, environments that routinely hold cloud credentials with broad access.