xinference PyPI Compromise 2026: How a Hijacked Release Line Put a Credential Stealer Inside an AI Inference Server

On 22 April 2026 three consecutive releases of xinference, an open source framework for serving large language models and other AI models, were published to PyPI with a two-stage credential stealer. Versions 2.6.0, 2.6.1 and 2.6.2 ran the malware as soon as the package was imported. It collected cloud keys, Kubernetes tokens, SSH keys, registry tokens and wallet files, and sent them unencrypted to an attacker's server. The maintainers yanked all three versions after users reported suspicious behaviour. OX Security says the payload arrived through a commit from the project's XprobeBot automation account, which it believes was compromised. The decoded payload begins with the comment "# hacked by teampcp", and StepSecurity and JFrog attribute it to TeamPCP. The group denied involvement on X and blamed a copycat, so attribution remains disputed. AI inference servers usually hold cloud and model-provider credentials, which makes them a rich target.

At a glance

What happened

Xinference is an open source framework for serving AI models through an API, and Mend describes the target as AI inference servers. Such servers can hold cloud credentials, storage keys and API tokens. On 22 April 2026 three new releases appeared on PyPI in quick succession. StepSecurity found that the injection point moved between versions, from module scope with a detached process in 2.6.0, to a synchronous call in 2.6.1, and back to a detached process in 2.6.2. It called this "a clear sign of live operational refinement." OX Security reports that the payload was added to __init__.py by a commit from the XprobeBot account at 04:08:08 UTC. The bot appears to have been active since October 2025, and OX believes it was compromised.

The first stage decoded a second script and piped it into a fresh Python interpreter, so the collector was never written to disk. According to StepSecurity, it gathered SSH and host keys, AWS credentials from disk, environment and the instance metadata service, then queried AWS Secrets Manager and SSM Parameter Store with them. It also took Kubernetes service account tokens and kubeconfigs, GCP, Azure and Docker credentials, .env files, npm, PyPI, Cargo and Vault tokens, TLS private keys, Terraform state and cryptocurrency wallets. Everything was packed into an archive and posted to an attacker domain. StepSecurity noted: "There is no encryption layer in this campaign." That differs from the LiteLLM and telnyx payloads. Mend reports no persistence either.

JFrog says the maintainers yanked the versions after users reported suspicious behaviour, and OX says the developers confirmed the breach. JFrog's advice is blunt: "If you installed or imported these versions, you must assume your environment is compromised." On attribution, OX wrote: "TeamPCP's name appears inside the code, but on their official X account they denied responsibility for this hack." JFrog and StepSecurity still link it to TeamPCP, citing the marker, the injection pattern and the rapid multi-version cadence. StepSecurity notes that the missing encryption is the main evidence for the copycat theory.

Timeline

How it happened: the identity attack path

1. An automation account with commit rights. The project used a bot account, XprobeBot, that could commit to the repository. OX Security says the payload came in through that account.
2. A trusted release line hijacked. The malicious versions were published under the real xinference project, not a typosquat, so every user and mirror saw them as official.
3. Import-time execution. The code ran on import, CLI start, service start and even when another library checked xinference's version.
4. Cloud identity harvested live. On AWS hosts the collector called the instance metadata service for role credentials and used them to list and read secrets, turning one server identity into access to stored secrets.
5. Secrets exported in the clear. The collected credentials went to the attacker unencrypted, ready to be used for the next compromise.

Impact

• Confirmed: three malicious xinference releases published to PyPI and yanked by the maintainers on 22 April 2026.
• Potential: theft of cloud role credentials, stored cloud secrets, Kubernetes tokens, SSH keys and registry tokens from any server, notebook or pipeline that imported the affected versions. No victim count has been published.
• Disputed: attribution. The payload names TeamPCP, but the group denied it and the payload lacks the encryption used in its earlier attacks.
• Wider: registry tokens taken from victims could be used to publish further malicious packages.

What this means for NHI and AI agent security

AI infrastructure is now a standard target for credential theft. An inference server runs with cloud roles to read model weights and storage, and often holds API keys for model providers and vector databases. A stealer that lands there does not need to break anything. It asks the metadata service for the server's own identity and spends it. As JFrog put it, "It wants your secrets, not your compute."

The entry point matters too. If OX Security is right, the payload came through a bot account, a non-human identity that projects often create once and then forget. Bots that can commit or release need an owner, the narrowest scope, signed commits and branch protection that applies to them as well as to humans. See our Service Account Security Guide, AI Infrastructure Workload Identity Guide and AI Supply Chain and AI-BOM Guide.

Recommendations

• Find and remove the affected versions. Check every image, server and pipeline for xinference 2.6.0, 2.6.1 or 2.6.2, rebuild from a trusted baseline and pin a known-good version.
• Rotate everything the host could reach. Rotate cloud role credentials, Secrets Manager and SSM values, Kubernetes tokens, SSH keys and registry tokens, and review cloud logs for their use. See our Leaked Credential Response Playbook.
• Lock down instance metadata and role scope. Require IMDSv2, restrict metadata access from application containers, and scope inference server roles to the buckets and secrets they need. See our AI Infrastructure Workload Identity Guide.
• Govern project bot accounts. Give every bot an owner, minimum permissions and short-lived credentials, and require signed, reviewed commits on release branches. See our Service Account Security Guide.
• Use trusted publishing. Publish from a single protected workflow with OIDC rather than stored registry tokens. See our CI/CD Pipeline Identity Security Guide.
• Restrict egress from AI servers. Inference servers rarely need to reach arbitrary domains; an egress allow list would have blocked the exfiltration.

Frequently asked questions

Which xinference versions were compromised?

xinference 2.6.0, 2.6.1 and 2.6.2 on PyPI, all published on 22 April 2026 and yanked by the maintainers. OX Security names 2.5.0 as the latest safe version at the time.

Was the xinference attack carried out by TeamPCP?

It is disputed. The payload starts with "# hacked by teampcp" and StepSecurity and JFrog link it to the group's earlier attacks. TeamPCP denied involvement on X and blamed a copycat, and the payload lacks the encryption used in the LiteLLM and telnyx attacks.

What should I do if I installed xinference 2.6.x?

Treat the environment as compromised. Isolate it, check for traffic to the attacker's domain, rotate every credential the host could reach, including cloud role and stored secrets, audit cloud and registry logs, and rebuild from a trusted image.

Related NHI Mgmt Group resources

LiteLLM PyPI Package Breach 2026 · telnyx PyPI compromise 2026 · Checkmarx KICS supply chain attack 2026 · AI Infrastructure Workload Identity Guide · Service Account Security Guide

How NHI Mgmt Group can help

AI platforms run on cloud roles, model keys and bot accounts that few teams inventory. We help organisations map those identities, scope them down and prepare for the day a dependency turns hostile. See our NHI and AI agent security training.

References

• StepSecurity: TeamPCP Injects Two-Stage Credential Stealer into xinference PyPI Package (22 April 2026)
• OX Security: Xinference allegedly hacked by TeamPCP, Malicious Package In PyPi (22 April 2026)
• JFrog: TeamPCP strikes again: Xinference PyPI package compromised (22 April 2026)
• Mend.io via Security Boulevard: A Poisoned Xinference Package Targets AI Inference Servers (22 April 2026)
• GitGuardian: No Off Season: Three Supply Chain Campaigns Hit npm, PyPI, and Docker Hub in 48 Hours (23 April 2026)