An emerging supply chain campaign targeting AI developers and CI/CD environments.

TL;DR

A newer PyPI wave tied to the broader Mini Shai-Hulud, Miasma, and Hades supply chain activity shows how malware is adapting to the AI development ecosystem.

The campaign used malicious Python wheels, startup hooks, native extensions, staged JavaScript stealers, and MCP themed package names to target developer workstations and CI/CD environments. The payload focused on high value secrets: GitHub tokens, package registry credentials, cloud credentials, Kubernetes material, SSH keys, Docker configuration, .env files, shell histories, and AI developer tool configuration.

The most important AI native twist is not just that some package names referenced MCP, LangChain, OpenAI, or tokenization tooling. The malware also included fake prompt injection style content inside a JavaScript comment, apparently designed to confuse naive LLM assisted malware scanners before they reached the real obfuscated payload.

This is the emerging pattern: attackers are no longer only targeting code, dependencies, and credentials. They are also beginning to target the AI tools defenders use to analyze code.

27 malicious packages were uploaded to PyPI, resulting in more than 14,100 downloads before they were removed.

The Core Attack Pattern

Socket Threat Research identified a newer PyPI wave connected to Mini Shai-Hulud, Miasma, and Hades supply-chain attacks.

The newer wave added 23 PyPI package version artifacts beyond an earlier set of 37 malicious PyPI wheels. The packages included bioinformatics packages, AI and MCP themed packages, typosquat style packages, and a notable langchain-core-mcp variant.

The campaign used multiple delivery patterns:

1. .pth startup hooks that execute automatically during Python startup (if a line inside a .pth file starts with import, Python executes that line during interpreter startup).
2. Trojanized native .abi3.so extensions that execute malicious code when imported.
3. A loader and payload split in which langchain-core-mcp searched Python’s sys.path for _index.js and attempted to execute it using Bun.
4. A heavily obfuscated JavaScript stealer staged through Bun.
5. A fake prompt injection header inside the JavaScript payload, apparently intended to pollute AI assisted malware analysis.

The malware targeted developer and CI/CD environments, where a single stolen token can enable package publishing, repository access, cloud access, workflow modification, or further supply-chain propagation.

The attacker placed malicious packages into the Python package ecosystem and used legitimate package-execution mechanics to trigger malicious behavior.

In the .pth based execution path, the package installed a Python startup hook. Python processes executable .pth lines during interpreter startup, meaning the malicious code could run when Python starts, even if the victim did not explicitly import the compromised package.

In the native extension branch, the visible Python source could appear normal while the compiled .abi3.so extension executed the JavaScript payload as a side effect of module initialization. This is especially dangerous in scientific computing, genomics, machine learning, and performance-heavy packages, where native extensions are common and may not look suspicious.

In the langchain-core-mcp variant, the package did not bundle the expected _index.js payload. Instead, it installed a loader that searched Python’s module path for _index.js and attempted to execute it with Bun. This split design could evade detection rules that expect the loader and payload to live together inside the same wheel.

Once executed, the malware attempted to collect secrets from developer machines and CI/CD environments. Targeted material included GitHub, npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic, AWS, GCP, Azure, Kubernetes, Vault, SSH, Docker, .env, .npmrc, .pypirc, Claude/MCP configuration, and other local or runner accessible credentials.

The campaign also included AI analysis disruption. The malicious _index.js payload started with a large non-executing JavaScript comment containing fake system instructions and safety triggering content. The runtime ignores the comment, but an LLM first malware scanner or analyst copilot might process the comment as instruction like content instead of treating it strictly as untrusted code data.

‍

The Attack Progression Across the AI Kill Chain

1. Reconnaissance — Ecosystem Targeting / Targeted Ecosystem Selection. The campaign targeted package ecosystems used by bioinformatics, Python, AI, MCP, LangChain, OpenAI, tokenization, Flask, and requests-style developers.
2. Trust Manipulation — Package Trust Abuse / Trusted Ecosystem Impersonation. The attacker used established package themes, compromised or malicious package releases, MCP themed names, and typosquat style names to benefit from open source trust.
3. Input & Instruction Weaponization — Semantic Boundary Abuse / Instruction Smuggling. The JavaScript payload included fake system instruction content inside a non executing comment, apparently to confuse AI assisted scanners.
4. Reasoning-Time Execution — Premise Control / False-Premise Anchoring. If naive scanners fed the file header to an LLM without isolating it as untrusted content, the fake instruction block could cause refusal, confusion, or premature classification.
5. Tool Invocation — Process Exploitation / Workflow Abuse. .pth files abused Python startup behavior to execute code automatically. Trojanized .abi3.so extensions executed payload logic during module import. Python package execution was used to bootstrap Bun and run the obfuscated _index.js JavaScript stealer.
6. Privilege Escalation — Capability Expansion / Tool Scope Escalation. The attacker used system tools (Python and JavaScript) to execute payload that targeted credentials and tokens with access to repositories, package registries, cloud accounts, Kubernetes, Vault, Docker, SSH, and AI developer tooling.
7. Lateral Movement — Bypassed entirely. Stolen package publishing, GitHub, CI/CD, and cloud credentials could enable movement into repositories, workflows, package registries, or downstream environments.
8. Persistence — Dependency Abuse / Supply Chain Abuse. The campaign used Python startup hooks and run once markers such as .bun_ran; earlier Hades analysis also described persistence and follow-on artifacts.
9. AI Native C2 — Bypassed entirely. The payload used GitHub centric exfiltration and included traffic to an Anthropic API looking path assessed as network log camouflage, but this should not be overstated as fully AI native C2.
10. Action on Objectives — Data Theft / Data Exfiltration. The campaign targeted developer secrets, cloud credentials, package-registry tokens, source-control access, CI/CD tokens, and AI developer tool configuration.

The Difference With Traditional Systems

Traditional supply chain malware usually abuses package installation, build scripts, dependency confusion, typosquatting, or maintainer compromise.

This campaign does those things, but adds an AI era dimension.

First, the targets are increasingly AI adjacent: MCP developers, LangChain style developers, OpenAI related tooling users, tokenization users, and developers whose local environments may contain AI provider keys or Claude/MCP configuration.

Second, the malware does not only target runtime systems. It also appears to target analysis systems. The fake prompt injection header inside a JavaScript comment is not meant for Python, JavaScript, Bun, or the operating system. It is meant for the LLM that might be asked to analyze the file.

That is the important shift. The attacker is treating AI assisted security tooling as part of the defender’s attack surface.

In traditional malware analysis, comments are inert. In LLM assisted analysis, comments can become context. If the scanner or analyst copilot does not separate code as data from instruction as control, malware can attempt to influence the reasoning process before the real payload is analyzed.

How to Prevent This Class of Attack

Startup Hook Detection

Python environments should be inspected for executable .pth files, especially those that perform network access, subprocess execution, temp directory writes, or JavaScript handoff. A .pth file that downloads a runtime and launches a payload should be treated as high confidence malicious behavior.

Native Extension Review

Compiled extensions should not be treated as automatically trusted. Review pipelines should inspect newly introduced .abi3.so, .pyd, .dylib, .so, and other native artifacts, especially when paired with JavaScript payloads or unexpected runtime bootstrapping.

Runtime Behavioral Detection

Defenders should alert on unusual chains such as:

• python spawning bun
• python downloading Bun from GitHub
• python writing temporary Bun binaries
• bun executing _index.js
• package installation followed by credential discovery
• CI runners accessing package-publishing credentials unexpectedly
• unexpected .github/workflows modifications
• unexpected Docker socket access
• unexpected SSH propagation artifacts

Credential Rotation

Any organization that installed affected package versions should rotate credentials available to developer machines and CI/CD jobs. Priority should go to GitHub tokens, package registry tokens, cloud credentials, Kubernetes tokens, Vault tokens, SSH keys, Docker credentials, AI provider keys, Claude/MCP configuration secrets, and CI/CD secrets.

AI Scanner Hardening

LLM assisted scanners must treat source files, comments, READMEs, package metadata, PR text, and issue content as untrusted data, never as instructions.

Security scanners should not let an LLM decide whether to continue analysis based only on the beginning of a file. They should use deterministic parsing, YARA rules, entropy checks, AST analysis, string extraction, deobfuscation, sandbox behavior, and policy driven execution guards.

CI/CD Isolation

Build runners should use least privilege tokens, short lived credentials, network egress controls, isolated workspaces, and secrets that are unavailable to untrusted package installation steps. Package installation should not run with broad access to production adjacent cloud or source control credentials.

Dependency Controls

Organizations should block or quarantine known affected package versions and inspect dependency graphs for the malicious artifacts. Package allowlisting, signed provenance, lockfile enforcement, and private package mirrors should be used for sensitive build environments.

Sourcing matters at the front of the pipeline. Pulling from a vetted, lineage-attested catalog of known-good components — such as Lineaje Gold Open Source, where each package and its transitive dependencies are vetted across more than 100 attributes with pre-attested provenance — keeps malicious typosquats, trojanized wheels, and fake framework packages like the ones in this campaign out of the build before any install-time execution can run.

Lesson / Conclusion

This campaign shows that AI era supply chain risk is not limited to malicious model files or prompt injection in chatbots.

The attacker path now runs through developer machines, CI/CD pipelines, package registries, AI framework packages, MCP tooling, and even AI-assisted malware scanners.

The most important lesson is that AI security cannot be separated from software supply chain security. If an attacker compromises the developer environment, they can steal the credentials that publish packages, modify workflows, access cloud infrastructure, and poison the tools used to build and analyze AI systems.

The new defensive rule is simple: treat AI developer tooling as production attack surface.

The real danger is not only that attackers can compromise dependencies. It is that compromised dependencies can now reach AI tools, developer secrets, CI/CD automation, and the reasoning systems defenders increasingly rely on.

UnifAI's prompt-inspection, execution-control, and secrets-and-egress policies enforce these guardrails outside the model — so a fake instruction buried in a comment or pulled in from an untrusted file can't steer an AI scanner, a poisoned package can't turn model output into shell execution, and the credentials these stealers hunt for are never sitting in code or free to call out to an attacker's endpoint.