Phantom Gyp Wave 2 in 2026: How the Miasma npm Worm Hit @vapi-ai/server-sdk, ai-sdk-ollama & 57 Packages Through Developer WorkstationsPhantom Gyp Vague 2 en 2026 : Comment le Ver npm Miasma a Compromis @vapi-ai/server-sdk, ai-sdk-ollama & 57 Packages via les Postes Développeurs

Two days after the Miasma worm compromised 32 Red Hat npm packages via a hijacked GitHub Actions pipeline, it struck again. On June 3, 2026 at 23:30 UTC, @vapi-ai/server-sdk — the official Vapi.ai voice AI server SDK with over 408,000 monthly downloads — was poisoned. Within the next 60 minutes, the worm had self-propagated to 56 more packages across multiple unrelated maintainer accounts, publishing over 286 malicious versions. Snyk now tracks this as a distinct incident: Node-gyp Supply Chain Compromise — June 2026.

Deux jours après que le ver Miasma a compromis 32 packages npm Red Hat via un pipeline GitHub Actions détourné, il a frappé à nouveau. Le 3 juin 2026 à 23h30 UTC, @vapi-ai/server-sdk — le SDK officiel Vapi.ai pour les API vocales avec plus de 408 000 téléchargements mensuels — a été empoisonné. Dans les 60 minutes suivantes, le ver s'était auto-propagé à 56 autres packages appartenant à plusieurs mainteneurs différents, publiant plus de 286 versions malveillantes. Snyk suit désormais cet incident séparément : Node-gyp Supply Chain Compromise — June 2026.

This second wave reveals something more alarming than Wave 1: the worm no longer needs to breach a CI/CD pipeline. It propagates through developer workstations. Any developer whose machine previously touched a poisoned package from Wave 1 may have had their npm authentication token harvested — and the worm used those tokens to publish poisoned versions of every package that developer maintained.

Cette deuxième vague révèle quelque chose de plus alarmant que la vague 1 : le ver n'a plus besoin de compromettre un pipeline CI/CD. Il se propage via les postes de développement. Tout développeur dont la machine avait précédemment touché un package empoisonné de la vague 1 a pu voir son token d'authentification npm exfiltré — et le ver a utilisé ces tokens pour publier des versions empoisonnées de chaque package géré par ce développeur.

Attack Timeline: 57 Packages in Under 60 Minutes

Chronologie : 57 Packages Compromis en Moins de 60 Minutes

StepSecurity, which first detected the campaign, reconstructed the following timeline based on npm registry publish logs and credential exfiltration artifacts found in GitHub dead-drop repositories:

StepSecurity, qui a détecté la campagne en premier, a reconstruit la chronologie suivante à partir des logs de publication du registre npm et des artefacts d'exfiltration trouvés dans les dépôts GitHub utilisés comme relais de données :

How Phantom Gyp Works: The binding.gyp Attack Vector Explained

Comment Phantom Gyp Fonctionne : Explication du Vecteur d'Attaque binding.gyp

The technique that makes this attack particularly dangerous is Phantom Gyp — named by StepSecurity. The attacker adds a 157-byte binding.gyp file to the published npm tarball. When npm install detects this file, it automatically runs node-gyp rebuild — behavior designed to compile native C/C++ addons — even when the package has no native code at all and no preinstall or postinstall scripts defined in package.json.

La technique qui rend cette attaque particulièrement dangereuse est le Phantom Gyp — nommé ainsi par StepSecurity. L'attaquant ajoute un fichier binding.gyp de 157 octets dans l'archive npm publiée. Lorsque npm install détecte ce fichier, il exécute automatiquement node-gyp rebuild — comportement prévu pour compiler des addons natifs C/C++ — même si le package ne contient aucun code natif et n'a ni script preinstall ni postinstall dans son package.json.

This is critical: npm install --ignore-scripts does NOT block this execution path. The --ignore-scripts flag prevents lifecycle scripts (preinstall, install, postinstall, prepare) from running, but it does not prevent node-gyp from being invoked when a binding.gyp file is present. Most supply-chain security tools — including many SAST scanners that flag packages with suspicious lifecycle scripts — never inspect binding.gyp content.

C'est critique : npm install --ignore-scripts ne bloque PAS ce chemin d'exécution. Le flag --ignore-scripts empêche les scripts de cycle de vie (preinstall, install, postinstall, prepare) de s'exécuter, mais n'empêche pas l'invocation de node-gyp quand un fichier binding.gyp est présent. La plupart des outils de sécurité supply chain — y compris de nombreux scanners SAST qui signalent les packages avec des scripts de cycle de vie suspects — n'inspectent jamais le contenu de binding.gyp.

{
  "targets": [{
    "target_name": "x",
    "sources": ["<!(node -e 'require(\"./p\")')" ]
  }]
}

The obfuscated payload is hidden under four layers: a ROT cipher applied to the script name, then AES-128-GCM encryption on the main dropper (4.29 MB), a runtime-switching trick that downloads the Bun JavaScript runtime in under one second to execute the final stage outside of Node.js, and polymorphic code that generates a unique hash per installation to evade static signature detection.

Le payload obfusqué est caché sous quatre couches : un chiffrement ROT appliqué au nom du script, puis un chiffrement AES-128-GCM sur le dropper principal (4,29 Mo), une astuce de commutation de runtime qui télécharge le runtime JavaScript Bun en moins d'une seconde pour exécuter la phase finale hors de Node.js, et du code polymorphique qui génère un hash unique par installation pour échapper à la détection de signatures statiques.

Wave 2 vs Wave 1: Developer Workstation Propagation vs CI/CD Pipeline Hijack

Vague 2 vs Vague 1 : Propagation par Poste Développeur vs Détournement Pipeline CI/CD

The two Miasma waves used fundamentally different propagation vectors, which has significant implications for detection and containment:

Les deux vagues Miasma ont utilisé des vecteurs de propagation fondamentalement différents, avec des implications importantes pour la détection et le confinement :

The Wave 2 propagation model is far more scalable: every developer who installed a poisoned package from Wave 1 on a workstation with npm publish access potentially gave the worm a new set of tokens to use. The Chainguard team confirmed that the npm tokens were harvested from ~/.npmrc, the npm credential cache, and active npm login sessions — targets that only exist on developer machines, not typically in ephemeral CI/CD runners.

Le modèle de propagation de la vague 2 est bien plus évolutif : chaque développeur ayant installé un package empoisonné de la vague 1 sur un poste avec accès npm publish a potentiellement donné au ver un nouveau jeu de tokens. L'équipe Chainguard a confirmé que les tokens npm ont été collectés depuis ~/.npmrc, le cache de credentials npm et les sessions npm login actives — des cibles qui n'existent que sur les machines des développeurs, et non dans les runners CI/CD éphémères.

The AI Coding Assistant Backdoor: .claude, .cursor & .gemini Config Poisoning

La Porte Dérobée des Assistants IA : Empoisonnement des Configs .claude, .cursor & .gemini

Beyond credential theft, the Miasma Wave 2 payload introduces a new persistence mechanism: it injects backdoor instructions into AI coding assistant configuration files found in the repository. Specifically, the malware searches for and modifies:

Au-delà du vol de credentials, le payload de la vague 2 Miasma introduit un nouveau mécanisme de persistance : il injecte des instructions de porte dérobée dans les fichiers de configuration des assistants de codage IA trouvés dans le dépôt. Plus précisément, le malware recherche et modifie :

• .claude/settings.json — Claude Code project configuration (MCP servers, tool permissions)
• .claude/settings.json — Configuration projet Claude Code (serveurs MCP, permissions outils)
• .cursor/rules — Cursor AI coding rules injected with attacker-controlled context
• .cursor/rules — Règles IA Cursor injectées avec un contexte contrôlé par l'attaquant
• .gemini/settings.json — Gemini CLI workspace settings
• .gemini/settings.json — Paramètres workspace Gemini CLI
• CLAUDE.md / AGENTS.md — Project-level AI instruction files
• CLAUDE.md / AGENTS.md — Fichiers d'instructions IA au niveau projet

The injected content follows a prompt injection pattern: instructions that instruct the AI to include attacker-controlled URLs in generated code, exfiltrate file content when certain file patterns are opened, or suggest installing additional compromised packages when the developer asks about dependencies. Since these configuration files are committed to repositories, the backdoor persists across reinstalls and spreads to every developer who clones the repository.

Le contenu injecté suit un pattern d'injection de prompt : des instructions demandant à l'IA d'inclure des URLs contrôlées par l'attaquant dans le code généré, d'exfiltrer le contenu des fichiers lorsque certains patterns sont ouverts, ou de suggérer l'installation de packages compromis supplémentaires quand le développeur pose des questions sur les dépendances. Comme ces fichiers de configuration sont commités dans les dépôts, la porte dérobée persiste après réinstallation et se propage à chaque développeur qui clone le dépôt.

The Dead-Man's Switch: Why Token Rotation Can Make Things Worse

L'Interrupteur Homme-Mort : Pourquoi La Rotation de Token Peut Aggraver les Choses

One of the most dangerous features of the Miasma worm is its dead-man's switch. After harvesting credentials and establishing persistence, the worm installs a daemon called gh-token-monitor that runs in the background and checks every 60 seconds whether the stolen GitHub token is still valid.

L'une des fonctionnalités les plus dangereuses du ver Miasma est son interrupteur homme-mort. Après avoir collecté les credentials et établi une persistance, le ver installe un démon appelé gh-token-monitor qui tourne en arrière-plan et vérifie toutes les 60 secondes si le token GitHub volé est toujours valide.

If the token is revoked, the daemon immediately executes a destructive command that wipes the user's home directory. This creates a hostage situation: the attacker weaponizes the threat of total workstation destruction to discourage incident response teams from revoking credentials as a first step. Security researchers at Corgea documented at least three confirmed cases where developers triggered the dead-man's switch by rotating their GitHub PAT before removing the daemon, resulting in complete loss of local development environments.

Si le token est révoqué, le démon exécute immédiatement une commande destructrice qui efface le répertoire home de l'utilisateur. Cela crée une situation de prise d'otage : l'attaquant utilise la menace de destruction totale du poste de travail pour décourager les équipes de réponse aux incidents de révoquer les credentials en premier. Les chercheurs de Corgea ont documenté au moins trois cas confirmés où des développeurs ont déclenché l'interrupteur homme-mort en faisant tourner leur PAT GitHub avant de supprimer le démon, entraînant la perte complète des environnements de développement locaux.

Detection: How to Check If You Were Affected

Détection : Comment Vérifier si Vous Avez Été Affecté

Run the following checks to determine whether the Miasma Wave 2 worm touched your system. These checks work on macOS and Linux developer workstations:

Exécutez les vérifications suivantes pour déterminer si le ver Miasma Vague 2 a touché votre système. Ces vérifications fonctionnent sur les postes développeurs macOS et Linux :

# Check for running daemon
ps aux | grep -i gh-token-monitor

# Check systemd / launchd persistence
systemctl list-units | grep -i gh-token
ls ~/Library/LaunchAgents/ | grep -i gh-token   # macOS

# If found — kill before rotating any credentials
pkill -f gh-token-monitor
systemctl stop gh-token-monitor.service 2>/dev/null
rm -f ~/Library/LaunchAgents/gh-token-monitor.plist

# Check if affected packages are installed globally
npm list -g @vapi-ai/server-sdk ai-sdk-ollama 2>/dev/null

# Snyk tracks all 57 affected packages — scan your project
npx snyk test --all-projects

# Check lockfile integrity (any unexpected binding.gyp entries)
grep -r "binding\.gyp" node_modules/ --include="binding.gyp" -l

# Check npm publish history (if you maintain packages)
npm access ls-packages YOUR_ORG 2>/dev/null | head -20

# The exfil goes to repos of the user liuende501
# Check network logs for github.com/liuende501
# On macOS
log show --predicate 'process == "curl"' --last 7d | grep liuende501

# On Linux (if using auditd)
ausearch -k network-connections | grep liuende501

# Check ~/.config/bun/install/cache for unexpected Bun runtime installs
ls ~/.bun 2>/dev/null && echo "WARNING: Bun runtime detected"

Protection Guide: 7 Steps to Harden Against Phantom Gyp Attacks

Guide de Protection : 7 Étapes pour Se Défendre Contre les Attaques Phantom Gyp

Traditional supply chain defenses (audit lifecycle scripts, enforce --ignore-scripts) are insufficient against Phantom Gyp. Here is a layered protection strategy that addresses the binding.gyp vector specifically:

Les défenses supply chain traditionnelles (auditer les scripts de cycle de vie, enforcer --ignore-scripts) sont insuffisantes contre Phantom Gyp. Voici une stratégie de protection en couches qui adresse spécifiquement le vecteur binding.gyp :

1. Disable node-gyp automatic builds (most effective)

1. Désactiver les builds automatiques node-gyp (plus efficace)

For projects that don't require native addons, disable node-gyp entirely. Set ignore-scripts=true in your .npmrc AND disable the node-gyp build path via npm configuration:

Pour les projets qui n'ont pas besoin d'addons natifs, désactivez node-gyp entièrement. Définissez ignore-scripts=true dans votre .npmrc ET désactivez le chemin de build node-gyp via la configuration npm :

# .npmrc — project level
ignore-scripts=true

# Also set in your CI/CD pipeline
npm config set ignore-scripts true
npm config set node-gyp-binary ""   # Removes the node-gyp binary path

# For workstations with no native addons needed
npm install --ignore-scripts --no-optional

2. Add binding.gyp scanning to your CI/CD pipeline

2. Ajouter le scan de binding.gyp dans votre pipeline CI/CD

# GitHub Actions step to detect unexpected binding.gyp files
- name: Scan for suspicious binding.gyp
  run: |
    MALICIOUS=$(find node_modules -name "binding.gyp" \
      -not -path "*/node_modules/node-gyp/*" \
      -exec grep -l "node -e\|require\|\!\(" {} \;)
    if [ -n "$MALICIOUS" ]; then
      echo "ALERT: Suspicious binding.gyp detected:"
      echo "$MALICIOUS"
      exit 1
    fi

3. Enforce lockfile integrity with hash verification

3. Enforcer l'intégrité du lockfile avec vérification des hashes

A lockfile with integrity hashes (npm's package-lock.json or yarn's lockfile) will fail a npm ci install if a package's content changes — even if the version number stays the same. The Miasma worm publishes a new version, so this doesn't catch a version bump, but it prevents tampered re-publications of the same version.

Un lockfile avec des hashes d'intégrité (package-lock.json de npm ou le lockfile yarn) fera échouer un npm ci si le contenu d'un package change — même si le numéro de version reste identique. Le ver Miasma publie une nouvelle version, donc cela ne bloque pas un bump de version, mais empêche les re-publications falsifiées de la même version.

# Always use ci instead of install in production/CI
npm ci   # Strict: fails on lockfile mismatch, ignores package.json ranges

# Pin major versions in your package.json (avoid ^ for critical deps)
# Instead of: "vapi-ai-server-sdk": "^2.1.0"
# Use:        "vapi-ai-server-sdk": "2.1.0"

4. Protect npm tokens on developer workstations

4. Protéger les tokens npm sur les postes développeurs

Wave 2 propagated entirely through npm tokens harvested from developer workstations. Treat your npm token like an SSH private key:

La vague 2 s'est propagée entièrement via les tokens npm collectés sur les postes développeurs. Traitez votre token npm comme une clé SSH privée :

• Use granular access tokens with publish scope limited to specific packages only (npm now supports package-scoped tokens)
• Utilisez des tokens d'accès granulaires avec scope publish limité à des packages spécifiques uniquement (npm supporte désormais les tokens à portée de package)
• Enable npm automation tokens for CI/CD — they are separate from your human token and can be revoked independently
• Activez les tokens d'automatisation npm pour CI/CD — ils sont séparés de votre token humain et peuvent être révoqués indépendamment
• Never store tokens in ~/.npmrc in plaintext — use keychain integration or a secrets manager
• Ne jamais stocker les tokens en clair dans ~/.npmrc — utilisez l'intégration keychain ou un gestionnaire de secrets
• Require two-factor authentication for npm publish — even if tokens are stolen, the worm cannot publish without the OTP
• Exiger une authentification à deux facteurs pour npm publish — même si les tokens sont volés, le ver ne peut pas publier sans l'OTP

5. Monitor your npm publish cadence

5. Surveiller la cadence de publication npm

The worm's publish pattern is distinctive: many packages from the same maintainer within seconds, with version numbers jumping unexpectedly. Set up alerting on npm publish events for your organization:

Le pattern de publication du ver est distinctif : de nombreux packages du même mainteneur en quelques secondes, avec des numéros de version qui sautent de façon inattendue. Mettez en place des alertes sur les événements npm publish pour votre organisation :

# Subscribe to npm package change feeds for your dependencies
# Using socket.dev for real-time supply chain monitoring
npx @socketsecurity/cli report:dep package.json

# Or use CVE OptiBot to monitor all your lockfile dependencies
# and receive alerts when any dep publishes unexpected new versions

6. Audit AI coding assistant configurations in your repositories

6. Auditer les configurations des assistants de codage IA dans vos dépôts

# Audit all AI config files for unexpected content
git log --all --full-history -- .claude/settings.json CLAUDE.md AGENTS.md \
  .cursor/rules .gemini/settings.json | head -50

# Diff against known-good state
git show HEAD~10:.claude/settings.json 2>/dev/null | diff - .claude/settings.json

# Check for suspicious URLs or external references in AI configs
grep -E "http[s]?://" .claude/settings.json CLAUDE.md AGENTS.md 2>/dev/null

7. Add .npmrc to your repository's .gitignore

7. Ajouter .npmrc au .gitignore de votre dépôt

If a project-level .npmrc containing authentication tokens is accidentally committed, every developer who clones the repo has their machine exposed. Ensure .npmrc is always in .gitignore and use environment variables for token injection in CI/CD:

Si un .npmrc au niveau projet contenant des tokens d'authentification est accidentellement commité, chaque développeur qui clone le dépôt expose sa machine. Assurez-vous que .npmrc est toujours dans .gitignore et utilisez des variables d'environnement pour l'injection de tokens en CI/CD :

# .gitignore
.npmrc

# CI/CD: inject token via environment variable
# package-lock.json or .npmrc generated at runtime:
echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
npm ci
rm .npmrc

Frequently Asked Questions

Questions fréquentes