Coder Legion - Recent posts tagged pypi

The evolution of Shai-Hulud-style worms

Fri, 14 Aug 2026 08:32:08 +0000

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating worm campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as TeamPCP) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: Shai-Hulud, Hades, and Miasma.

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the TanStack compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the Runner.Worker process via /proc/<pid>/mem). Depending on the target ecosystem, it then exchanged these temporary workflow credentials for registry-specific publish tokens, using OIDC token exchange endpoints for npm and PyPI, or harvesting raw API keys for RubyGems and container registries like Docker Hub.

This allowed the published packages, container images, and extensions to carry valid SLSA Build track provenance signatures. To defenders, the updates appeared completely legitimate and officially attested across all affected registries. It’s the equivalent of deepfakes for the software supply chain.

Perhaps the most malicious aspect of this multi-registry wave was its defence mechanism. Once inside a developer's local machine or build server (whether pulled via a Python pip install, a Ruby gem, an npm package, or a VS Code extension) the payload established a background daemon named gh-token-monitor. This daemon monitored whether its stolen tokens had been rotated or revoked, acting as a dead man’s switch. If a defender revoked the token, the daemon immediately triggered a local script that executed rm -rf ~/ and rm -rf ~/Documents, wiping the victim's entire home directory to eliminate forensic traces and punish the developer.

Miasma

Discovered on June 4th, 2026, Miasma represents the third evolution of the Shai-Hulud family of worm attacks, compromising hundreds of npm components (including packages within the @redhat-cloud-services and @asyncapi namespaces).

In this workflow, a simple npm install forces a node-gyp rebuild which executes a binding.gyp command that drops the Miasma payload. Again, the tactics and techniques of this Shai-Hulud worm have changed multiple times so far this year. Most security scanners and manual reviewers focus closely on scripts blocks in package.json (watching for preinstall or postinstall triggers).

Miasma bypassed this completely by abusing binding.gyp. The binding.gyp, for context, is a legitimate config file used to compile native C++ Node.js add-ons. When a package containing this file is installed, the npm client automatically spawns node-gyp rebuild. The attackers embedded direct command execution wrappers inside the binding.gyp target configs. The system executes the malicious payload during compilation, completely avoiding the need for suspicious package.json lifecycle scripts.

Miasma focused heavily on capturing cloud identities instead of static keys, implementing collectors specifically designed to steal active GCP and Azure SSO credentials. Furthermore, if the infected CI container had access to the host's Docker socket (/var/run/docker.sock), the malware would’ve performed a Docker escape. It identifies and terminates security monitoring containers (such as Step Security’s harden-runner), creating a privileged Alpine container to write passwordless sudo access to the host's /etc/sudoers.d, and altered local DNS resolution to block telemetry reporting domains.

Hades

Discovered on June 8th, 2026, straight after the Miasma variant, the campaign expanded to the Python ecosystem, targeting critical academic genomics and phenotype analysis packages on PyPI (ensmallen, embiggen, pyphetools).

In this attack, a simple Python Import loads a .so extension which executes embedded javascript. The embedded javascript code executes a final Bun payload which exfiltrates to a GitHub endpoint.

In a major evasion upgrade, the attackers did not modify any Python source files. Instead, they embedded the malicious JavaScript loader inside the compiled Rust/C++ binary extension (.abi3.so).

When a researcher imports the package via Python (import ensmallen), it triggers dlopen() on the trojanised .so file. The shared object discreetly initialises and runs an embedded JavaScript engine to execute the payload. This makes the new attack completely invisible to code-reviewers looking at Python source files.

The payload's primary file, _index.js, contains a massive block of comment text representing a fake LLM jailbreak prompt. The decoy simulated classified briefings, asking for technical steps on weaponising biological agents and designing nuclear devices. This was a deliberate attempt to pollute static analysers and AI-assisted tooling, causing them to choke, flag false positives on safety boundaries, or even worse, misclassify the file as a prompt-injection experiment rather than a credential-stealing worm.

Instead of a standard server, the Hades variant registered dozens of GitHub repositories using the compromise-controlled user account felixEvora. The repositories used underworld-themed naming conventions (like lethean-tartarus-61322 and abyssal-acheron-97481) and were described as Hades – The End for the Damned. The exfiltrated data was stored in an encrypted envelope format, signed with GPG keys.

keyv and cachable packages compromised

In August 2026, the open-sourced Mini Shai-Hulud codebase was weaponised in one of the most widespread multi-registry campaigns to date. The outbreak began with the compromise of npm maintainer Jared Wray's account. This was the primary developer behind popular, heavily downloaded packages like keyv and cachable.

From this single entry point, the worm exponentially expanded into over 444 packages across 2,000+ published releases, hit 100 packages in the ServiceTitan ecosystem alone, and aggressively turned every infected machine into an automated propagation node.

The execution chain relies on the preinstall hook inside the package.json (addressed in npm v.12) to trigger a setup.mjs dropper. To evade standard JavaScript static analysis tuned for Node.js patterns, the setup.mjs file detected the host architecture, downloaded a bundled Bun 1.3.13 runtime, and proceeded to execute a massive, heavily obfuscated payload named math_init.js.

Rather than stopping at passive credential dumping, this variant actively probed and harvested deeper infrastructure credentials: It actively queried AWS IMDSv2 and ECS endpoints, enumerated AWS SecretsManager paths, read mounted Kubernetes ServiceAccount tokens, and extracted HashiCorp Vault secrets across KV v1 & v2 mounts. It even hunted local crypto wallets like bitcoin wallet files. It was observed that exfiltration calls were routed to a dynamic domain endpoint. Crucially, if the server returned an execute payload in its JSON response, the worm immediately executed it using eval, giving the threat actors live remote code execution on infected dev machines and CI runners. Finally, if the primary C2 server failed, the worm fell back to using stolen GitHub tokens to automatically create public GitHub repos containing base64-encoded stolen data, tagging the repo descriptions with a distinctive campaign marker. This time Shai-Hulud: Here We Go Again.

To ensure propagation, the worm scraped npm creds or even exchanged GitHub Actions OIDC tokens to auto-publish patch updates of packages the maintainer controlled. It inserted @opensearch/setup as an optional dependency, allowing the payload to silently cascade into downstream installs without causing build failures. Furthermore, it even expanded on the infection vectors directly inside dev workflows by writing malicious GitHub Actions workflows disguised with the name "Run Copilot", as well as altering AI-related dev tooling via poisoned .claude and .vscode config files.

Shai-Hulud-style worms will continue to change shape

The open-sourcing or leaking of a complex piece of malware like the Shai-Hulud worm typically triggers a significant shift in the threat landscape. When a sophisticated framework (originally tightly controlled by an advanced group like TeamPCP) becomes publicly accessible, it lowers the barrier to entry for a much wider, more disorganised pool of actors. Independent operators, smaller cybercriminal syndicates, and even security researchers looking to understand its mechanics can dissect the original codebase. This democratisation of advanced tech means that features previously requiring high-level engineering, such as automated supply-chain propagation or complex credential harvesting, become plug-and-play modules for anyone with basic development skills.

Without a centralised command structure like TeamPCP directing its deployment, the evolution of Shai-Hulud has naturally fragmented into highly specialised or experimental variants (such as IronWorm). Newer threat actors are combining Shai-Hulud’s core self-propagating mechanisms with different payloads or evasion techniques tailored to their specific objectives. For instance, some variants strip away the heavier components to create lightweight stealth tools, while others swap out the exfiltration methods to target different developer ecosystems beyond npm or GitHub, such as PyPI and Cargo. This fragmentation complicates defense strategies, as defenders can no longer rely on a single set of behavioural signatures or specific infrastructure indicators associated with the original group.

Furthermore, this post-TeamPCP era accelerated the timeline of dual-use engineering, where threat actors repurpose and optimise techniques from Shai-Hulud in unexpected ways (as seen in the Suno breach). Independent devs often modify the codebase to patch flaws left by the original authors (such as fixing loud fallback routines or refining how the worm handles OIDC token exchanges). Because these new variants are built and deployed by completely unrelated clusters of users, the attribution of attacks becomes incredibly muddy. The signature architecture of Shai-Hulud is no longer a reliable indicator of who is attacking, but rather a reflection of a shared, open-source repository of commodity supply-chain threats. This is glaringly the case with alleged supply chain competitions organised by BreachForums.

Quick recap of what you’ve read

If the evolution of Shai-Hulud proves anything, it's that attackers are exceptionally creative and relying purely on reactive remediation is a losing strategy. When malware can pass SLSA attestations, bypass package.json inspection via native builds, and hide inside compiled binaries, you simply cannot predict every vector. It only takes one compromised token to trigger a massive downstream disaster. While rapid incident response remains essential, putting heavy effort into proactive preventions, such as universal package cooldown policies and strict pipeline boundaries is the only way to neutralise these threats before they execute. Stopping the attack at the gate will always be easier than cleaning up the damage after a worm gets through.

LibKill: Scan Your Machine for Compromised npm, pip, and Bun Packages

Wed, 13 May 2026 11:02:12 +0000

Over the last few weeks, supply chain security has once again become a very real problem for developers.

We keep seeing the same attack pattern:

CI/CD token stolen
→ malicious package version published
→ developers install or update dependencies
→ compromised code lands on real machines

And the worst part is simple:

You may already have one of those compromised packages on your machine without knowing it.

That is why I built LibKill.

What is LibKill?

LibKill is an open-source supply chain security scanner.

It checks your local development environment against a database of known compromised package artifacts.

Currently, it scans:

npm global packages
pip packages
Bun cache

Then it cross-references what it finds against 2,672+ known compromised package artifacts.

If something suspicious is detected, LibKill can help you remove it interactively.

Why I built it

Most developers hear about compromised packages after the damage is already done.

A package gets reported.
A malicious version is removed.
A GitHub advisory appears.
A security company publishes an analysis.

But then comes the real question:

“Is any of this already on my machine?”

That question should be easy to answer.

LibKill is my attempt to make that check fast, local, and simple.

Features

LibKill currently supports:

Scanning npm global packages
Scanning installed pip packages
Scanning Bun cache
Cross-checking against known compromised artifacts
Interactive removal when threats are found
Background daemon mode
Desktop notifications
macOS, Linux, and Windows support
Single binary
Zero runtime dependencies

It is written in Go and distributed as a small standalone binary.

Installation

You can install it with one command:

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

Or build it manually:

git clone https://github.com/firfircelik/libkill.git
cd libkill
make install

Example usage

After installation, run:

libkill scan

To start background monitoring:

libkill daemon

If compromised artifacts are found, LibKill will show the results and offer interactive cleanup options.

Threat coverage

LibKill currently covers known compromised artifacts related to campaigns and threat clusters such as:

Mini Shai-Hulud
Contagious Interview
StegaBin
SANDWORM_MODE
CanisterWorm
W4SP
TeamPCP
and many others

The threat database is built from public security sources including:

Socket.dev
GitHub Advisory Database
OSV.dev
Public security research

Why local scanning matters

A lot of supply chain security tools focus on repositories, lockfiles, or CI pipelines.

That is useful, but it does not fully answer what is already installed locally.

Developers often install tools globally.

They test packages.

They use temporary scripts.

They work across multiple languages and package managers.

They forget what was installed weeks ago.

A compromised package does not need to be in your current production repository to be a problem.

It may already exist somewhere in your local environment.

Project details

Language: Go
License: MIT
Binary size: around 14 MB
Dependencies: zero runtime dependencies
Platforms: macOS, Linux, Windows

GitHub:

https://github.com/firfircelik/libkill

Final note

LibKill is still evolving.

My goal is to make it a practical local security tool for developers who work with open-source packages every day.

If you work with npm, Python, Bun, or modern JavaScript tooling, you should not have to guess whether a known compromised artifact exists on your machine.

You should be able to check it quickly.

That is what LibKill is for.

Feedback, issues, and contributions are welcome.

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

Just Launched: My New Project is Live

Fri, 08 Aug 2025 08:09:08 +0000

Hey everyone!

Let’s connect!
Portfolio Website
GitHub
Hugging.Face-TamilAI-ChatBot
LinkedIn
Dev.To/Tamil-Lang
PyPi Python Tamil language

After weeks of learning, experimenting, and late-night debugging, I'm excited to finally share my latest project with you all:

TamilLang – A Programming Language in Tamil

A beginner-friendly, experimental language that brings the logic of Python with the power of native Tamil syntax!

️ Built With:
– Python
– Unicode parsing
– CLI tool design
– setuptools + PyPI

✨ Why I Built It:
Many beginners fear coding because of language barriers. TamilLang helps break that barrier by letting you code in your native language. Logic has no language — and this proves it!

Available on PyPI:

pip install tamil-lang

Project Link: https://pypi.org/project/tamil-lang/

Blog soon on: dev.to/kamalnaths
I'd love your feedback! Feel free to test it, break it, or contribute. Let’s make tech more accessible, one line of code at a time.

My AI Learning Journey: From .NET Developer to AI Enthusiast

Fri, 08 Aug 2025 08:08:19 +0000

Hello CoderLegion Community!

Let’s connect!
Portfolio Website
GitHub
Hugging.Face-TamilAI-ChatBot
LinkedIn
Dev.To/Tamil-Lang
PyPi Python Tamil language

I’m Kamalnath S, a software engineer with 2 years of .NET development experience (ASP.NET Core, C#, SQL) and a deep interest in Artificial Intelligence.

After a short health-related break in my career, I made a decision — instead of waiting for the “perfect” course or mentor, I started self-learning AI and Python through free online resources like YouTube, documentation, and open-source projects.

What I’ve Learned So Far

Python fundamentals and object-oriented programming

AI basics: NLP, machine learning models, and data preprocessing

Using Hugging Face and Gradio to build interactive AI tools

Experimenting with AI chatbots (including a Tamil AI chatbot idea)

Projects Along the Way

TamilLang – A Tamil-based programming language (PyPI)

Student Score Predictor – Simple ML model to predict exam scores

Small Python scripts to automate repetitive tasks

My Learning Approach

Free Resources – YouTube tutorials, official docs, GitHub projects

Hands-on Practice – Build small projects immediately after learning a concept

Community Engagement – Platforms like CoderLegion, dev.to, GitHub to share and get feedback

Why I’m Sharing This

I believe in learning in public — sharing not just successes, but also struggles.
If my journey inspires even one developer to start learning AI without fear or expensive courses, it’s worth it.

I’d love to hear your AI learning stories, tips, and project ideas. Drop a comment or message me anytime!

AMEN CLI

Tue, 27 May 2025 21:12:35 +0000

Are you a Python developer tired of the boilerplate when starting a new web project? Do you admire the elegant development experience offered by tools like Laravel's Artisan or Composer? Then look no further than AMEN CLI!

What is AMEN CLI?
AMEN CLI is a command-line tool designed to streamline the creation of Python web applications. Inspired by the best features of Laravel and Composer, AMEN CLI provides a simple, intuitive way to scaffold new projects with a consistent, well-structured architecture.

Key Features
Interactive Project Setup: AMEN CLI guides you through the project creation process with interactive prompts, making it easy to choose your framework, application type, and project name.
Multiple Framework Support: Whether you prefer the lightweight simplicity of Flask or the modern speed of FastAPI, AMEN CLI has you covered. Support for Bottle and Pyramid is also in the works!
Web App and API Templates: Create both traditional web applications and RESTful APIs with ease, thanks to AMEN CLI's flexible template system.
Modular Project Structure: AMEN CLI generates projects with a clean, modular structure, making it easy to organize your code and maintain your application over time.
Automatic Virtual Environment Setup: Say goodbye to manual virtual environment creation! AMEN CLI automatically sets up a virtual environment for your project, ensuring that your dependencies are isolated and managed correctly.
Dependency Management: AMEN CLI generates a requirements.txt file and installs the necessary packages for your chosen framework, saving you time and effort.
JWT Authentication: Secure your routes with ease using AMEN CLI's built-in JWT (JSON Web Token) authentication.
Configuration Management: Easily manage your project's configuration settings with the amen config command, which opens the .env file in a simple text editor.

Getting Started
Installation:

Create a New Project:

Follow the Interactive Prompts:

Select a framework (Flask, FastAPI, etc.)
Choose an application type(webapp or api)
Name your project

Run Your Application:
amen run <app-name>

Additional Commands
AMEN CLI provides several additional commands to help you manage your project:

amen run : Starts the development server for your application.
amen test : Runs the test suite for your application.
amen check-update: Checks for updates to the AMEN CLI tool itself.
amen config : Manages the configuration settings for your application.