Xinference PyPI Supply Chain Attack

In my previous posts, I focused on kernel vulnerabilities and exploitation primitives such as use-after-free, page cache corruption, and metadata confusion.

This case is different, is not a vulnerability in code is a compromise of trust.

In early 2026, multiple malicious versions of the xinference package were published on PyPI, targeting developers, CI/CD pipelines, and production-like environments.

What makes this incident dangerous is not technical complexity.

It is how normal it looks:

1

pip install xinference

Behind that command, attacker-controlled code can become part of a trusted Python environment.

And once the package is imported, malicious logic can execute automatically.

The interesting part is not only the payload.

It is the primitive:

trusted package installation → trusted import → attacker-controlled execution

TL;DR

At a high level, the attack chain is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

pip install xinference
      ↓
malicious package downloaded from PyPI
      ↓
package installed locally
      ↓
import xinference
      ↓
__init__.py executed
      ↓
hidden payload triggered
      ↓
system reconnaissance
      ↓
credential harvesting
      ↓
data exfiltration

flowchart LR
    A["pip install xinference"]
        --> B["Malicious package version"]
        --> C["Installed in environment"]
        --> D["import xinference"]
        --> E["__init__.py executed"]
        --> F["Payload runs"]
        --> G["Secrets collected"]
        --> H["Exfiltration"]

flowchart LR
    A["pip install xinference"]
        --> B["Malicious package version"]
        --> C["Installed in environment"]
        --> D["import xinference"]
        --> E["__init__.py executed"]
        --> F["Payload runs"]
        --> G["Secrets collected"]
        --> H["Exfiltration"]

flowchart LR
    A["pip install xinference"]
        --> B["Malicious package version"]
        --> C["Installed in environment"]
        --> D["import xinference"]
        --> E["__init__.py executed"]
        --> F["Payload runs"]
        --> G["Secrets collected"]
        --> H["Exfiltration"]

1
2
3
4
5
6
7
8
9

flowchart LR
    A["pip install xinference"]
        --> B["Malicious package version"]
        --> C["Installed in environment"]
        --> D["import xinference"]
        --> E["__init__.py executed"]
        --> F["Payload runs"]
        --> G["Secrets collected"]
        --> H["Exfiltration"]

About

The goal of this post is not to reverse engineer every line of the malware.

The goal is to understand how a trusted package distribution mechanism can become a direct execution primitive.

Incident Overview

The Xinference incident is a supply chain compromise, not a traditional CVE.

Attackers did not need to exploit a memory corruption bug, a parsing issue, or a race condition.

Instead, the attacker abused the trust placed in the package release pipeline.

Public reporting described malicious xinference releases on PyPI affecting versions:

1
2
3

2.6.0
2.6.1
2.6.2

The malicious code was reportedly placed in the package initialization path, making import-time execution possible.

That means a developer could install the package normally and trigger the malicious logic later through a normal import:

1

import xinference

This is what makes the incident so dangerous.

Nothing needs to look suspicious.

No exploit needs to be launched.

The normal workflow is the trigger.

Timeline (Simplified)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Attacker gains release access
      ↓
malicious versions are published
      ↓
users install or update dependencies
      ↓
package is imported
      ↓
payload executes
      ↓
secrets are collected
      ↓
incident is discovered
      ↓
malicious releases are removed / blocked

sequenceDiagram
    participant A as Attacker
    participant P as PyPI
    participant D as Developer / CI
    participant E as Environment

    A->>P: Publish malicious xinference release
    D->>P: pip install xinference
    P->>D: Serve malicious package
    D->>E: import xinference
    E->>E: Execute __init__.py
    E->>A: Exfiltrate secrets / metadata

sequenceDiagram
    participant A as Attacker
    participant P as PyPI
    participant D as Developer / CI
    participant E as Environment

    A->>P: Publish malicious xinference release
    D->>P: pip install xinference
    P->>D: Serve malicious package
    D->>E: import xinference
    E->>E: Execute __init__.py
    E->>A: Exfiltrate secrets / metadata

sequenceDiagram
    participant A as Attacker
    participant P as PyPI
    participant D as Developer / CI
    participant E as Environment

    A->>P: Publish malicious xinference release
    D->>P: pip install xinference
    P->>D: Serve malicious package
    D->>E: import xinference
    E->>E: Execute __init__.py
    E->>A: Exfiltrate secrets / metadata

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

sequenceDiagram
    participant A as Attacker
    participant P as PyPI
    participant D as Developer / CI
    participant E as Environment

    A->>P: Publish malicious xinference release
    D->>P: pip install xinference
    P->>D: Serve malicious package
    D->>E: import xinference
    E->>E: Execute __init__.py
    E->>A: Exfiltrate secrets / metadata

Attack Surface

The attack relies on a simple but powerful execution chain:

1

package repository → installation → import → execution

flowchart LR
    A["PyPI"]
        --> B["pip install"]
        --> C["Local environment"]
        --> D["Python import"]
        --> E["Code execution"]

flowchart LR
    A["PyPI"]
        --> B["pip install"]
        --> C["Local environment"]
        --> D["Python import"]
        --> E["Code execution"]

flowchart LR
    A["PyPI"]
        --> B["pip install"]
        --> C["Local environment"]
        --> D["Python import"]
        --> E["Code execution"]

1
2
3
4
5
6

flowchart LR
    A["PyPI"]
        --> B["pip install"]
        --> C["Local environment"]
        --> D["Python import"]
        --> E["Code execution"]

The key idea:

installing a package is equivalent to trusting and executing its code.

This is not specific to Xinference.

This is a general property of package ecosystems.

A Python dependency may execute code during:

• installation hooks,
• import-time initialization,
• dynamic module loading,
• subprocess calls,
• plugin discovery,
• runtime configuration loading.

For developers, this is normal behavior.

For attackers, it is an execution surface.

Root Cause (Trust Model Failure)

The root cause is not a software bug in Xinference itself.

It is a trust model failure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

trusted project
      ↓
compromised release path
      ↓
malicious package version
      ↓
trusted installation
      ↓
trusted import
      ↓
attacker code execution

There is no memory corruption.

There is no kernel primitive.

There is no exploit chain in the traditional sense.

The system behaves exactly as designed.

That is the problem.

Execution Model

In Python, importing a module executes its top-level code.

A simplified package layout looks like this:

1
2
3
4

xinference/
├── __init__.py
├── core.py
└── ...

When Python runs:

1

import xinference

it loads and executes xinference/__init__.py.

If malicious logic is embedded there, it runs automatically.

flowchart TD
    A["import xinference"]
        --> B["Python resolves package"]
        --> C["Load xinference/__init__.py"]
        --> D["Execute top-level code"]
        --> E["Payload triggered"]

flowchart TD
    A["import xinference"]
        --> B["Python resolves package"]
        --> C["Load xinference/__init__.py"]
        --> D["Execute top-level code"]
        --> E["Payload triggered"]

flowchart TD
    A["import xinference"]
        --> B["Python resolves package"]
        --> C["Load xinference/__init__.py"]
        --> D["Execute top-level code"]
        --> E["Payload triggered"]

1
2
3
4
5
6

flowchart TD
    A["import xinference"]
        --> B["Python resolves package"]
        --> C["Load xinference/__init__.py"]
        --> D["Execute top-level code"]
        --> E["Payload triggered"]

This creates the core primitive:

1

trusted import → arbitrary code execution

The attacker does not need the developer to run a suspicious script.

The developer only needs to import a package that they already trust.

Payload Behavior (Simplified)

Public analysis described heavily obfuscated code, including base64-encoded payload layers and child process execution.

A simplified model looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import base64
import subprocess

payload = "base64_encoded_stage"
decoded = base64.b64decode(payload)

subprocess.Popen(
    ["python3", "-c", decoded.decode()],
    stdout=subprocess.DEVNULL,
    stderr=subprocess.DEVNULL,
)

The exact implementation may differ, but the idea is the same:

1
2
3
4
5
6
7
8
9

obfuscated blob
      ↓
decode
      ↓
execute
      ↓
collect data
      ↓
exfiltrate

flowchart LR
    A["Obfuscated payload"]
        --> B["Decode"]
        --> C["Spawn child process"]
        --> D["Collect secrets"]
        --> E["Compress / stage data"]
        --> F["Exfiltrate"]

flowchart LR
    A["Obfuscated payload"]
        --> B["Decode"]
        --> C["Spawn child process"]
        --> D["Collect secrets"]
        --> E["Compress / stage data"]
        --> F["Exfiltrate"]

flowchart LR
    A["Obfuscated payload"]
        --> B["Decode"]
        --> C["Spawn child process"]
        --> D["Collect secrets"]
        --> E["Compress / stage data"]
        --> F["Exfiltrate"]

1
2
3
4
5
6
7

flowchart LR
    A["Obfuscated payload"]
        --> B["Decode"]
        --> C["Spawn child process"]
        --> D["Collect secrets"]
        --> E["Compress / stage data"]
        --> F["Exfiltrate"]

Why This Works (Developer Perspective)

This attack works because it abuses normal developer workflows.

In a typical environment:

• dependencies are installed automatically (pip install -r requirements.txt)
• packages are trusted implicitly
• code is imported without manual inspection
• secrets are exposed through environment variables
• outbound network access is often unrestricted

From the attacker’s perspective:

1
2
3

developer machine = trusted execution environment
CI pipeline       = automated execution engine
cloud workload    = high-value credential source

The critical issue is implicit execution:

1

import xinference

This line is enough to trigger attacker-controlled code if the package is compromised.

There is no exploit.

The developer runs the payload voluntarily.

Real Impact

The impact depends on where the malicious package runs.

Developer Workstation

Developer machines often contain credentials that are valuable far beyond the local system.

Typical sensitive files include:

1
2
3
4
5
6

~/.aws/credentials
~/.ssh/id_rsa
~/.ssh/config
~/.docker/config.json
~/.kube/config
.env

A malicious dependency can:

• read local cloud credentials,
• steal SSH keys,
• extract API tokens from environment variables,
• inspect project files,
• discover internal endpoints,
• access package manager tokens.

flowchart TD
    A["Developer laptop"]
        --> B["Cloud credentials"]
        --> C["SSH keys"]
        --> D["Git tokens"]
        --> E[".env files"]
        --> F["Attacker"]

flowchart TD
    A["Developer laptop"]
        --> B["Cloud credentials"]
        --> C["SSH keys"]
        --> D["Git tokens"]
        --> E[".env files"]
        --> F["Attacker"]

flowchart TD
    A["Developer laptop"]
        --> B["Cloud credentials"]
        --> C["SSH keys"]
        --> D["Git tokens"]
        --> E[".env files"]
        --> F["Attacker"]

1
2
3
4
5
6
7

flowchart TD
    A["Developer laptop"]
        --> B["Cloud credentials"]
        --> C["SSH keys"]
        --> D["Git tokens"]
        --> E[".env files"]
        --> F["Attacker"]

CI/CD Pipeline

CI pipelines are even more attractive because they are automated and usually contain deployment credentials.

Typical CI configuration:

1
2
3
4

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

During a build:

1
2

pip install -r requirements.txt
python -c "import xinference"

If the dependency is compromised:

• secrets may be exposed instantly,
• attacker may gain cloud access,
• build artifacts may be tampered with,
• release pipelines may be abused,
• internal registries may be accessed.

flowchart LR
    A["CI job"]
        --> B["Install dependency"]
        --> C["Import package"]
        --> D["Secrets in env"]
        --> E["Payload reads env"]
        --> F["Exfiltration"]

flowchart LR
    A["CI job"]
        --> B["Install dependency"]
        --> C["Import package"]
        --> D["Secrets in env"]
        --> E["Payload reads env"]
        --> F["Exfiltration"]

flowchart LR
    A["CI job"]
        --> B["Install dependency"]
        --> C["Import package"]
        --> D["Secrets in env"]
        --> E["Payload reads env"]
        --> F["Exfiltration"]

1
2
3
4
5
6
7

flowchart LR
    A["CI job"]
        --> B["Install dependency"]
        --> C["Import package"]
        --> D["Secrets in env"]
        --> E["Payload reads env"]
        --> F["Exfiltration"]

Cloud / Production

In cloud environments, the attacker may not need static credentials.

If the workload has access to a metadata service or workload identity, the malicious package may attempt to access temporary credentials.

Examples of high-value targets:

1
2
3
4
5
6

AWS IAM role credentials
GCP service account tokens
Azure managed identity tokens
Kubernetes service account tokens
Docker registry credentials
Terraform state files

This changes the incident from “developer malware” into a potential cloud compromise.

Detection Ideas

Detection is difficult because the initial behavior looks legitimate.

A Python process importing a Python package is normal.

The suspicious part is what happens after the import.

Runtime Indicators

Monitor for unexpected outbound connections after package import:

1

ss -antp

Look for Python processes spawning unexpected child processes:

1
2

ps aux | grep python
pstree -ap | grep python

Check for temporary archive files or staging directories:

1

find /tmp -maxdepth 2 -type f -name "*.tar.gz" -o -name "*.zip" 2>/dev/null

Monitor DNS or network activity from build containers:

1

tcpdump -i any port 53

Code-Level Indicators

Look for suspicious patterns inside installed packages:

1
2
3
4

python - << 'EOF'
import site
print("\n".join(site.getsitepackages()))
EOF

Then inspect package files:

1
2
3
4

grep -R "base64" /path/to/site-packages/xinference 2>/dev/null
grep -R "subprocess" /path/to/site-packages/xinference 2>/dev/null
grep -R "exec(" /path/to/site-packages/xinference 2>/dev/null
grep -R "eval(" /path/to/site-packages/xinference 2>/dev/null

Common red flags:

• exec() / eval()
• base64-decoded blobs
• dynamic imports
• subprocess spawning
• unexpected network libraries
• code added directly to __init__.py

Example suspicious pattern:

1
2

import base64
exec(base64.b64decode(payload))

Dependency Inspection

Check installed versions:

1
2

pip show xinference
pip freeze | grep -i xinference

Check lockfiles:

1

grep -R "xinference" requirements.txt pyproject.toml poetry.lock Pipfile.lock 2>/dev/null

Check whether the package was recently installed in CI logs:

1

grep -R "xinference" ./logs 2>/dev/null

CI Monitoring

In CI/CD environments:

• log all dependency install steps,
• restrict outbound network during builds where possible,
• alert on unexpected package upgrades,
• use lockfiles,
• delay newly published versions before allowing installation,
• scan artifacts for unexpected payloads.

A useful policy is:

1

new package version published recently → block or require review

This protects against fast-moving supply chain attacks where malicious versions are detected only after publication.

Mitigations

Dependency Pinning

Avoid floating installs:

1

xinference

Prefer explicit versions:

1

xinference==2.5.0

When possible, use hashes:

1
2

pip-compile --generate-hashes
pip install --require-hashes -r requirements.txt

CI/CD Hardening

Recommended controls:

• do not expose production secrets to dependency installation jobs,
• split build and deploy stages,
• use short-lived credentials,
• restrict outbound network by default,
• review dependency updates before deployment,
• run dependency installation in isolated containers.

Incident Response Checklist

If a compromised version was installed or imported:

1
2
3
4
5
6
7
8

1. Remove the package version
2. Preserve logs and artifacts
3. Identify where it ran
4. Rotate exposed credentials
5. Check cloud audit logs
6. Check CI/CD tokens
7. Review outbound network logs
8. Rebuild affected environments

Key Insight

In supply chain attacks, the vulnerability is not the code — it is the trust placed in it.

The attacker does not need to break the runtime.

They only need to enter the trust path.

What I Learned

This incident is a reminder that modern exploitation is not always about primitives like arbitrary read, arbitrary write, or control flow hijacking.

Sometimes the primitive is simpler:

1

trusted dependency → trusted execution → trusted secrets

For developers, the lesson is uncomfortable but important:

dependency installation is part of the attack surface.

For defenders, the lesson is just as important:

CI/CD systems should be treated as production security boundaries, not just build automation.

Conclusion

This incident highlights a fundamental reality:

Modern attacks do not always exploit bugs sometimes, they exploit assumptions.

Here, the assumption is simple:

packages from a trusted repository are safe.

Once that assumption breaks, every pip install becomes a potential execution vector. This is not a bug to patch.

It is a model to rethink.

References

• https://www.ox.security/blog/xinference-allegedly-hacked-by-teampcp-malicious-package-in-pypi/
• https://nsfocusglobal.com/xinference-pypi-supply-chain-poisoning-warning/
• https://www.stepsecurity.io/blog/teampcp-injects-two-stage-credential-stealer-into-xinference-pypi-package
• https://blog.gitguardian.com/three-supply-chain-campaigns-hit-npm-pypi-and-docker-hub-in-48-hours/