Agents IA de code : le nouveau vecteur des attaques supply chain

En 2026, votre assistant IA de code est devenu une cible. Les attaquants ne visent plus seulement vos dépendances npm : ils empoisonnent les fichiers de configuration de Cursor, Claude Code ou Copilot pour que l'IA elle-même installe le malware. Décryptage d'un vecteur d'attaque émergent — et comment protéger un projet e-commerce.

Un changement de cible : l'IA comme complice involontaire

Jusqu'ici, une attaque supply chain visait un package que vous installiez. Le nouveau mode opératoire est plus retors : il cible l'agent IA qui écrit et installe du code à votre place. L'attaquant n'a plus besoin de vous tromper, il trompe votre assistant.

Le bilan 2026 est éloquent : 59 campagnes de supply chain, 657 packages malveillants identifiés, et surtout 0 CVE. Ces attaques passent sous le radar des scanners classiques parce qu'elles n'exploitent pas une faille logicielle au sens traditionnel — elles exploitent la confiance que vous accordez à votre outillage.

Deux campagnes illustrent le tournant :

• PromptMink (29 avril 2026) : attribuée au groupe nord-coréen Famous Chollima, elle utilise des packages npm conçus pour tromper les agents IA (Claude Code, Cursor, Gemini CLI) et les pousser à installer un voleur d'identifiants.
• Miasma / Mini Shai-Hulud : un ver npm qui se propage via les hooks de cycle de vie et binding.gyp, contournant tout scanner qui ne surveille que package.json. Sa seconde vague a touché 57 packages totalisant plus de 647 000 téléchargements mensuels.

Le fichier de config : le nouvel angle mort

Le cœur du problème est culturel autant que technique. Les développeurs considèrent un settings.json ou un .cursorrules comme de la simple configuration — pas comme du code. Ils ne le relisent pas, ne l'auditent pas, le commitent sans réflexion. C'est exactement ce blind spot que les attaques exploitent.

Or ces fichiers sont des vecteurs d'exécution. Les fichiers ciblés en pratique :

• .claude/settings.json et .mcp.json — déclarés vecteurs d'exécution par plusieurs CVE en 2026
• .cursorrules, configs YAML d'aider, Continue, opencode et équivalents
• Les fichiers d'instructions/règles que l'IA lit comme des consignes de confiance

L'attaque « Rule Files Backdoor » consiste à glisser des instructions cachées dans un fichier de règles. L'agent les lit, les considère comme légitimes, et génère du code malveillant — l'IA devient un complice involontaire. Des chercheurs ont même découvert des overrides de ANTHROPIC_BASE_URL routant le trafic de l'agent à travers un proxy MITM, et plus de 1 230 clés API et JWT en dur dans des fichiers d'instructions IA.

MCP : quand les outils de l'agent deviennent l'attaque

Le Model Context Protocol (MCP) connecte votre agent à des outils externes. Chaque serveur MCP que vous branchez élargit la surface d'attaque. Le mécanisme du tool poisoning est insidieux :

Une description d'outil empoisonnée peut être livrée dans un package, un fichier de config ou un serveur MCP distant. Elle agit à chaque invocation, silencieusement, sur chaque session, pour chaque utilisateur, jusqu'à ce que quelqu'un s'en aperçoive.

L'exemple type : un serveur MCP Postmark non officiel modifié pour ajouter un simple champ BCC à sa fonction d'envoi d'e-mails — copiant silencieusement chaque message vers l'attaquant. Les utilisateurs en auto-update fuitaient leurs e-mails sans le moindre changement visible de comportement.

En mai 2026, OX Security a divulgué une vulnérabilité systémique dans les implémentations MCP d'Anthropic (Python, TypeScript, Java, Rust), touchant une supply chain de plus de 150 millions de téléchargements et environ 200 000 instances vulnérables.

Pourquoi ça concerne un projet PrestaShop ou Symfony

Vous vous dites peut-être que tout ça concerne les « projets IA ». Faux. Dès que votre workflow inclut :

• un front headless Next.js/Nuxt qui tire des centaines de dépendances npm
• un build d'assets PrestaShop/Symfony via Webpack, Vite ou npm
• un agent IA (Cursor, Copilot, Claude Code) avec accès en écriture à votre repo

…vous êtes dans le périmètre. Un postinstall malveillant s'exécute avec vos droits, lit vos .env, vos tokens CI/CD, vos clés API de paiement. Pour une boutique, c'est l'accès aux identifiants Stripe, à la base client, aux secrets de déploiement.

Se protéger : les mesures concrètes

1. Neutraliser les scripts d'installation

La majorité des charges utiles s'exécutent via les hooks postinstall/preinstall. Désactivez-les par défaut et n'autorisez que les packages qui en ont réellement besoin.

# Installation sans exécuter aucun script de cycle de vie
npm install --ignore-scripts

# Rendre le comportement permanent au niveau du projet (.npmrc)
echo "ignore-scripts=true" >> .npmrc

# Avec pnpm : allowlist explicite des scripts autorisés (pnpm 10+)
# pnpm.onlyBuiltDependencies dans package.json

2. Builds reproductibles et lockfile verrouillé

En CI, n'utilisez jamais npm install (qui peut résoudre de nouvelles versions). Utilisez npm ci, qui installe strictement le lockfile et échoue si celui-ci diverge.

# CI : installation déterministe à partir du lockfile uniquement
npm ci --ignore-scripts

# Vérifier l'intégrité et la provenance des packages
npm audit signatures

3. Traiter les fichiers de config IA comme du code

C'est le réflexe le plus important. Ces fichiers passent en revue de code au même titre que vos contrôleurs Symfony.

• Mettez .mcp.json, .claude/settings.json, .cursorrules sous contrôle de version et en revue obligatoire
• Interdisez les overrides d'environnement suspects (*_BASE_URL, proxys) dans ces fichiers
• Surveillez tout diff sur ces fichiers comme un changement de code sensible

# .gitattributes — forcer une revue humaine sur les fichiers sensibles
.mcp.json            merge=binary
.claude/settings.json merge=binary
.cursorrules         merge=binary

# CODEOWNERS — exiger une approbation d'un référent sécurité
.mcp.json            @votre-equipe/security
.cursorrules         @votre-equipe/security

4. Allowlist et isolation des serveurs MCP

N'ajoutez que des serveurs MCP dont vous contrôlez la source. Épinglez les versions, désactivez l'auto-update, et accordez le minimum de permissions à l'agent.

// .mcp.json — épingler une version précise, pas de "latest"
{
  "mcpServers": {
    "internal-tools": {
      "command": "npx",
      "args": ["-y", "@votre-org/[email protected]"],
      "env": {}
    }
  }
}
// ⚠️ Bannir : "@un-paquet/mcp-server" sans version figée
// ⚠️ Auditer toute description d'outil avant de l'autoriser

5. Sandboxer l'agent et protéger les secrets

• Faites tourner l'agent dans un conteneur isolé, sans accès aux secrets de production
• Jamais de credentials en dur : utilisez un coffre (Vault, secrets CI) injecté à l'exécution
• Scope minimal pour les tokens CI/CD — pas de token d'admin global accessible à un postinstall

Checklist de durcissement

• ignore-scripts=true dans .npmrc, exceptions documentées et justifiées
• CI en npm ci + npm audit signatures, jamais npm install
• Fichiers de config IA (.mcp.json, .cursorrules…) versionnés et en revue obligatoire
• Serveurs MCP en allowlist, versions épinglées, auto-update désactivé
• Agent IA exécuté en sandbox, sans accès direct aux secrets de prod
• Secrets injectés via coffre, jamais en dur dans le repo ou les configs

Conclusion

Le glissement est clair : l'attaquant ne cible plus seulement le code que vous écrivez, mais l'outil qui l'écrit pour vous. Tant que les fichiers de configuration des agents IA seront traités comme de la « simple config » et non comme du code exécutable, ils resteront l'angle mort idéal. Le bon réflexe à ancrer dès maintenant : tout fichier que votre agent IA lit ou exécute mérite le même niveau de scrutin qu'un contrôleur en production. La productivité de l'IA ne doit pas se payer en surface d'attaque.

Vous voulez auditer la sécurité de votre chaîne de build ou de votre setup d'agents IA ? Contactez-moi pour un point sur votre exposition aux attaques supply chain.

Sources

• PromptMink : comment la Corée du Nord a trompé Claude pour installer du malware npm — Barrack AI
• Miasma : le ver qui vit dans vos outils IA — Phoenix Security
• Vulnérabilité systémique au cœur du MCP — OX Security
• Malware dans les fichiers d'instructions IA — Mitiga
• MCP Tool Poisoning : sécurité des agents IA en entreprise — ITECS