xinference PyPI Compromise: TeamPCP-Style Credential Stealer

Date Observed: April 22, 2026

Ecosystem: PyPI (Python)

Targets: AI/MLOps teams, CI/CD pipelines, cloud-connected LLM inference environments

Attack Type: Supply chain compromise

Impact: SSH keys, AWS/GCP/Azure/Kubernetes credentials, .env secrets, and CI/CD tokens exfiltrated to attacker-controlled infrastructure

Key Takeaways

• Versions 2.6.0, 2.6.1, and 2.6.2 of xinference on PyPI were compromised; all three have been yanked.

• The payload executes on import xinference, with no install hook or user interaction required.

• A two-stage collector harvests SSH keys, cloud credentials, Kubernetes tokens, .env files, Terraform state, and crypto wallet keys before exfiltrating via curl POST.

• All three malicious versions were published within a single day, a rapid release pattern consistent with recent TeamPCP-linked PyPI incidents.

• If any of these versions ran in your environment, treat all secrets on that host as compromised and rotate immediately.

On April 22, 2026, three consecutive releases of xinference versions 2.6.0, 2.6.1, and 2.6.2 were confirmed to carry a malicious two-stage credential-stealing payload injected directly into xinference/__init__.py. Xinference (Xorbits Inference) is a widely used open-source LLM inference framework supporting LLaMA, Mistral, Qwen, and multimodal models. Environments running xinference routinely hold elevated cloud credentials: IAM roles, model registry tokens, object storage keys, and Kubernetes service account tokens making it a deliberate, high-value target.

The threat injected a base64-encoded payload that executes the moment any application runs import xinference. All three versions have been yanked from PyPI. JFrog tracks this incident under advisory XRAY-96896.

Scope and Impact of the Attack

Three versions were compromised xinference==2.6.0, xinference==2.6.1, and xinference==2.6.2; all published within a single day on April 22, 2026. Any system that ran import xinference while one of these versions was installed must be treated as compromised.

The stage 2 credential collector targets common secret type in cloud-connected AI and CI/CD environments:

• SSH access credentials and server authentication keys

• Cloud provider credentials and access tokens (AWS, GCP, Azure)

• Cloud secret management and configuration data

• Kubernetes cluster access credentials and service account tokens

• Container registry and deployment credentials

• Environment configuration files containing sensitive application secrets

• Package publishing and software repository credentials (npm, PyPI, Cargo)

• Infrastructure and CI/CD pipeline configuration files

• TLS/SSL certificates and private encryption keys

• Cryptocurrency wallet keys and related sensitive wallet data

• System account information, password files, command history, and Vault access tokens

How the Attack Works

Stage 0: Injection into `__init__.py`

The attacker places a malicious base64 blob directly inside xinference/__init__.py. Because Python executes __init__.py on every import, the payload fires on import xinference, CLI startup, service initialisation, and any downstream dependency resolution that imports the package. There are no install hooks and no .pth files; the trigger is unconditional.

Stage 1: The Loader

The decoded base64 blob opens with the actor marker # hacked by teampcp. It defines a start() function that:

1. Creates a temporary working directory for execution

2. Decodes and runs a hidden secondary payload directly in memory

3. Avoids writing the main payload to disk to reduce detection

4. Captures command output and collected results into a temporary file

5. Compresses the collected data into an archive (love.tar.gz)

6. Exfiltrates the archive to an external remote server (https://whereisitat.lucyatemysuperbox.space/)

7. Uses temporary storage that is automatically deleted after execution, leaving minimal forensic evidence

Stage 2: The Credential Collector

Stage 2 is a self-contained Python harvester piped to a child interpreter via stdin. It begins with system reconnaissance (hostname, whoami, uname -a, printenv), then walks into the filesystem for every credential type listed above. Unlike prior TeamPCP campaigns against litellm and telnyx; which used encryption before exfiltration; the xinference payload sends credentials as a plain compressed archive.

Why This Matters to DevOps and DevSecOps Teams

This attack requires no user interaction. Any CI/CD pipeline, Docker build, or development environment that resolves xinference without a pinned, verified version is a valid execution target.

Xinference environments are specifically high-value. They hold GPU instance IAM roles, model registry tokens, and Kubernetes service account tokens; exactly the credentials needed to pivot into cloud infrastructure or downstream CI/CD systems. The stage 2 collector explicitly targets IMDSv2 endpoints, Kubernetes token paths, and Terraform state, well suited to AI inference and MLOps environments, where cloud and orchestration credentials are often present..

Standard software supply chain controls fail here if they rely solely on post-install scanning. The payload executes at import time, before most runtime detection tools engage. The three-versions-in-one-day publish cadence is designed to outpace manual review cycles. Teams relying on periodic audits rather than build-time enforcement are exposed during that window.

How InvisiRisk Protects Against This Attack

Stability Buffer blocks all three compromised versions before they enter the build. Attackers published xinference 2.6.0, 2.6.1, and 2.6.2 within a single day; an abnormal publishing cadence that is a strong signal of a supply chain attack. InvisiRisk’s BAF configurable stability window (default: 48 hours) flags and holds newly published package versions before they can be consumed in a build. Under the default 48-hour stability window, these versions would have been held before entering the build, blocking the attack before any code executes.

Build Proxy / Network Interception blocks the exfiltration call at the runner level. InvisiRisk’s BAF operates as a network proxy inside the CI/CD build environment. When the payload attempts to POST the collected archive to attacker-controlled infrastructure, InvisiRisk’s BAF intercepts and blocks the outbound connection before the archive leaves the runner. That stops the exfiltration path even if a compromised package version has already entered the build.

Encrypted Secret Detection in Transit provides a second layer against novel exfiltration paths. InvisiRisk’s BAF inspects outbound request headers and payload for encoded credentials: tokens, API keys, and environment variable blobs; blocking exfiltration even over TLS and even to previously unseen domains. If the attacker rotates infrastructure between campaigns, content inspection catches what domain filtering misses.