Xinference PyPI Supply Chain Compromise — TeamPCP-Marked Credential Harvester (v2.6.0–2.6.2)

Xinference PyPI Supply Chain Compromise (TL-2026-0438), also tracked as TeamPCP Part 4, is a critical-severity supply-chain compromise scored CVSS 9.4, first published 2026-04-30. It is attributed to TeamPCP with medium confidence, affects Xorbits xinference (PyPI), maps to 20 MITRE ATT&CK techniques (T1005, T1027, T1036), and is covered by 9 detection rules and 20 indicators of compromise.

Key facts for TL-2026-0438

Threat ID
TL-2026-0438
Also known as
TeamPCP Part 4, Xinference PyPI Compromise, Xorbits xinference Trojan, love.tar.gz exfil
Severity
CRITICAL
CVSS
9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N)
Status
MONITORING
Category
SUPPLY_CHAIN
First published
2026-04-30
Last reviewed
2026-04-30
Attribution
TeamPCP
Attribution confidence
MEDIUM
Motivation
FINANCIAL
Target sectors
technology, ai-ml, research, financial, saas, cloud-services, media, education
Target regions
Global, North America, Europe, Asia
Detection rules
9
Indicators of compromise
20

Malware and tooling in Xinference PyPI Supply Chain Compromise

Malware and tooling: Custom Python credential harvester (Stage 2)

JFrog and Mend.io disclosed on April 22, 2026 that PyPI versions 2.6.0, 2.6.1, and 2.6.2 of xinference (Xorbits' distributed AI model inference framework) were trojanized via a base64-encoded payload injected into xinference/__init__.py. Importing the package spawns a detached Python subprocess that runs a two-stage harvester targeting SSH keys, AWS/GCP/K8s credentials, IMDSv2 tokens, AWS Secrets Manager and SSM (via SigV4-signed requests), .env files, registry tokens, TLS keys, and crypto wallets, exfiltrating the loot as love.tar.gz to whereisitat.lucyatemysuperbox.space. The payload carries the '# hacked by teampcp' actor marker; TeamPCP (@pcpcats) publicly denied involvement and called it a copycat campaign.

How Xinference PyPI Supply Chain Compromise works

Overview

On April 22, 2026, JFrog Security Research, Mend.io, and Ox Security simultaneously disclosed an active supply chain compromise of xinference, the open-source Xorbits Inference framework widely used to serve LLMs and other generative AI models in distributed environments. PyPI versions 2.6.0, 2.6.1, and 2.6.2 — published in rapid succession in the days leading up to disclosure — were found to contain a trojanized xinference/__init__.py that executes an exhaustive credential harvester the moment any downstream code imports the xinference package. PyPI yanked all three versions on the day of disclosure, but anyone who pulled them into a virtualenv, container image, CI/CD step, or Jupyter notebook prior to that point should treat their environment as fully compromised and rotate every credential reachable from the affected host.

Initial Access and Trojan Insertion

The trojanized __init__.py contains a small bootstrap that decodes a base64 blob and execs it via a detached subprocess. The bootstrap is appended to legitimate package init logic so the package continues to import normally — neither the test suite nor a casual diff against the prior 2.5.x release surfaces obvious red flags without inspecting the encoded payload. JFrog's analysis indicates the malicious release was pushed under the legitimate maintainer namespace on PyPI, suggesting either a stolen API token, a compromised maintainer account, or a session/CI artifact theft from an existing TeamPCP-style attack chain. The package authors (Xorbits) confirmed they did not publish 2.6.0–2.6.2 themselves and immediately rotated PyPI credentials and reissued a clean 2.6.3.

Payload Capabilities — Two-Stage Python Harvester

Stage 1 detaches itself from the parent Python process (so it survives import-time exceptions and is harder to attribute to the package import event) and downloads or decodes a larger Stage 2 collector. Stage 2 walks a curated list of credential locations across Linux, macOS, and Windows developer/CI hosts:

- SSH material: ~/.ssh/id_rsa, id_ed25519, id_ecdsa, known_hosts, config - AWS: ~/.aws/credentials, ~/.aws/config, AWS_* environment variables, IMDSv2 role tokens (PUT /latest/api/token then GET /latest/meta-data/iam/security-credentials/), and — once temporary role credentials are obtained — SigV4-signed requests against secretsmanager.<region>.amazonaws.com (ListSecrets / GetSecretValue) and ssm.<region>.amazonaws.com (GetParameter / GetParametersByPath) to siphon every secret the role can read - GCP: ~/.config/gcloud/credentials.db, application_default_credentials.json, service-account JSON keys - Kubernetes: ~/.kube/config and the in-pod service-account token at /var/run/secrets/kubernetes.io/serviceaccount/token, plus the cluster CA bundle - Container registries: ~/.docker/config.json, podman/auth.json - TLS / signing material: *.pem, *.key, *.p12, *.pfx files under common locations - .env files and local secret stores (walked across the home directory and cwd, with size and extension filters) - Crypto wallets: standard Electrum, Exodus, Metamask local-storage paths

Exfiltration

Collected material is staged under a temp directory, compressed into love.tar.gz, and POSTed to https://whereisitat.lucyatemysuperbox.space/ with a custom HTTP header X-QT-SR: 14 that the operators use to tag and route incoming uploads. The header value is consistent across the prior TeamPCP-marked litellm and telnyx PyPI campaigns, which is one of the strongest reasons researchers initially bucketed this disclosure under TeamPCP — even though the actual TeamPCP operator (@pcpcats) publicly denied this round and labelled it a copycat using their toolkit and infrastructure conventions.

Attribution

The payload includes the comment marker '# hacked by teampcp' that TeamPCP has historically left in their PyPI compromises. However, on April 22, @pcpcats posted on X/Twitter denying involvement and accusing an unknown copycat of reusing their TTPs and exfiltration domain naming pattern (subdomain.<food><animal>.space). Independent researchers note that the SHA-256 fingerprints of Stage 2 differ measurably from prior TeamPCP releases, supporting the copycat hypothesis. Attribution remains MEDIUM confidence: the TTPs and infrastructure pattern are consistent with TeamPCP, but operator denial and payload-level differences argue for a separate (possibly imitator) actor.

Impact

Xinference is broadly deployed as the model-serving layer for self-hosted GenAI stacks; its install base spans research clusters, CI runners that bake AI agents into container images, and developer laptops that pip install xinference for local experimentation. Each affected install yields not just static SSH and cloud credentials but also short-lived IMDSv2 role tokens that the harvester immediately upgrades into broad Secrets Manager / SSM reads — meaning a single poisoned import on an EC2 host can leak the entire organisation's secret store. Defenders should assume that any environment that resolved xinference 2.6.0–2.6.2 between the upload window and the April 22 yank has had every credential reachable from that host disclosed to the operator.

MITRE ATT&CK techniques used in TL-2026-0438

Collection

T1005 Data from Local System; T1560.001 Archive Collected Data: Archive via Utility

Defense Evasion

T1027 Obfuscated Files or Information; T1036 Masquerading; T1140 Deobfuscate/Decode Files or Information

Exfiltration

T1041 Exfiltration Over C2 Channel; T1567 Exfiltration Over Web Service

Execution

T1059.006 Command and Scripting Interpreter: Python; T1204.002 User Execution: Malicious File

Command and Control

T1071.001 Application Layer Protocol: Web Protocols

Discovery

T1083 File and Directory Discovery; T1526 Cloud Service Discovery

Initial Access

T1195 Supply Chain Compromise; T1195.002 Compromise Software Supply Chain

Credential Access

T1528 Steal Application Access Token; T1552.001 Unsecured Credentials: Credentials In Files; T1552.004 Unsecured Credentials: Private Keys; T1552.005 Unsecured Credentials: Cloud Instance Metadata API; T1552.007 Unsecured Credentials: Container API

Persistence

T1546 Event Triggered Execution

Affected products and versions in Xinference PyPI Supply Chain Compromise

  • Xorbits — xinference (PyPI)
    Vulnerable versions: 2.6.0; 2.6.1; 2.6.2
    Fixed in: 2.6.3
  • Xorbits — xinference (Docker images derived from poisoned PyPI release)
    Vulnerable versions: any image layer that pip installed xinference 2.6.0/2.6.1/2.6.2
    Fixed in: images rebuilt against xinference >=2.6.3

Remediation for Xinference PyPI Supply Chain Compromise

Patches

  • xinference 2.6.3 (clean reissue from Xorbits maintainers) — upgrade or pin to >=2.6.3.

Immediate actions

  • Audit every environment (dev laptops, CI runners, container images, K8s pods, EC2 hosts, notebook servers) for installed xinference 2.6.0, 2.6.1, or 2.6.2 — pip show xinference, conda list, or scan SBOMs and lock files (requirements.txt, poetry.lock, Pipfile.lock, conda-lock.yml).
  • Uninstall the affected versions and pin to xinference >=2.6.3 in all dependency manifests; rebuild and redeploy any container image whose layer history pulled the trojanized versions.
  • Treat any host that imported the package as compromised: rotate ALL SSH keys, AWS access keys, GCP service-account keys, K8s service-account tokens, registry tokens, TLS private keys, and .env secrets resident on that host, plus every secret the host's IAM role could read from AWS Secrets Manager and SSM Parameter Store.
  • Block egress to whereisitat.lucyatemysuperbox.space and the lucyatemysuperbox.space parent domain at perimeter firewalls, DNS RPZ / sinkhole, and proxy ACLs; drop any historical traffic to that host as a confirmed exfiltration event.
  • Hunt CloudTrail for sts:GetCallerIdentity, secretsmanager:ListSecrets, secretsmanager:GetSecretValue, ssm:GetParameter, and ssm:GetParametersByPath calls from instance roles immediately after the install/import window — the harvester chains IMDS -> SigV4 -> bulk secret read.

Workarounds

  • Pin xinference to <=2.5.x as a temporary measure until the 2.6.3 reissue is verified by SBOM scanners and EDR signature feeds.
  • Block xinference 2.6.0, 2.6.1, 2.6.2 explicitly in your private index, dependency policy, or Snyk/Mend/Socket allowlists.

Longer-term hardening

  • Adopt a private PyPI index or pull-through proxy (e.g., Artifactory, Sonatype, AWS CodeArtifact) configured to quarantine new releases for a soak period before they become visible to internal builds.
  • Pin and hash-verify dependencies (pip --require-hashes, poetry lock with verify-hash, uv with lockfile pinning) so that a silently re-uploaded version cannot replace a known-good artifact.
  • Migrate workloads off long-lived static cloud credentials onto short-lived workload identity (IAM Roles Anywhere, OIDC federation, GCP Workload Identity, K8s ServiceAccount + IRSA/Pod Identity) and scope the role to least-privilege so a stolen IMDSv2 token cannot enumerate the full Secrets Manager.
  • Deploy IMDSv2-only enforcement (instance metadata hop-limit = 1, IMDSv1 disabled at the account level) and monitor for anomalous IMDS calls from unexpected processes (Python interpreters that are not your application).
  • Stand up Sigstore / PEP 740 attestations and require build provenance for any package promoted into your private index; enforce supply chain policy in CI (e.g., cosign verify, in-toto, Kyverno or OPA admission).

Weaknesses (CWE) in Xinference PyPI Supply Chain Compromise

CWE-506, CWE-829, CWE-494, CWE-522

Timeline of Xinference PyPI Supply Chain Compromise

  • Trojanized xinference 2.6.0 uploaded to PyPI under the legitimate maintainer namespace, embedding a base64-encoded credential harvester in xinference/__init__.py.
  • xinference 2.6.1 uploaded with the same trojanized __init__.py — minor adjustments to the bootstrap to avoid early static-analysis flags.
  • xinference 2.6.2 uploaded; downstream installs in CI runners and developer laptops begin executing the harvester at import time.
  • Xorbits maintainers publish xinference 2.6.3, a clean reissue, and pin all build attestations under fresh PyPI tokens.
  • TeamPCP operator @pcpcats posts on X/Twitter denying involvement and labelling the incident a copycat that re-used their TTPs, infrastructure naming pattern, and actor marker.
  • PyPI yanks xinference 2.6.0, 2.6.1, and 2.6.2 from the public index after coordinated disclosure from JFrog, Mend, and Ox Security; Xorbits maintainers rotate publishing credentials.
  • Ox Security publishes parallel research describing the credential harvester's IMDSv2 -> Secrets Manager -> SSM chain and the love.tar.gz exfil archive.
  • Mend.io publishes 'TeamPCP Part 4: Malicious Xinference Packages on PyPI', linking the campaign to prior litellm and telnyx PyPI compromises via the '# hacked by teampcp' actor marker.
  • JFrog Security Research publishes the first public disclosure of the xinference compromise, including the base64 payload, exfil endpoint, X-QT-SR custom header, and SHA-256 hashes of the modified __init__.py and Stage 2 collector.
  • Security Boulevard and Cyberpress publish secondary coverage; SBOM scanners (Snyk, Socket, Mend) push the affected versions into their malicious-package feeds.
  • Threadlinqs Intelligence publishes TL-2026-0438 with full IOCs, MITRE mapping, detections, and simulation guidance.
  • As of 2026-05-29, the specific xinference compromise is contained: malicious v2.6.0-2.6.2 were yanked, credentials rotated, and clean 2.7.0-2.9.0 shipped (latest 2.9.0, May 23). But the TeamPCP/copycat campaign remains highly active (durabletask, Mini Shai-Hulud worm, open-sourced May 12), so the actor and tooling persist.

Sources cited for Xinference PyPI Supply Chain Compromise

Threats related to Xinference PyPI Supply Chain Compromise

Detection coverage for TL-2026-0438

As of 2026-04-30, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0438 across Splunk SPL, Microsoft KQL and Sigma, covering 20 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Further reading

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats