RSAC 2026 : Comment les assistants de code IA contournent l’EDR via plugins, hooks et configurations

Tu pensais que l’endpoint était une forteresse, EDR partout, règles, durcissement, inventaire des postes, chasse aux malwares. Sauf que le point d’entrée a bougé, il s’est glissé là où tu ne regardais pas assez, l’IDE et les assistants de code. Quand l’outil qui écrit, exécute et automatise des tâches tourne sur le poste du développeur, la frontière entre “aide à coder” et “exécution de commandes” devient très fine.

Les recherches présentées à la RSAC 2026, notamment par Oded Vanunu de Check Point Software, décrivent une série de vulnérabilités corrigées depuis par les éditeurs, dans plusieurs outils populaires. Le fil rouge est simple, l’attaquant n’a pas forcément besoin d’un binaire suspect, il vise des flux de configuration, des plugins, des hooks, des invites manipulées. Résultat, l’endpoint security se retrouve contournée par des mécanismes considérés comme légitimes par l’environnement de développement.

Les assistants de code IA ouvrent une brèche dans l’endpoint security, via RCE et prompt injection

Check Point détaille six failles, et l’IDE devient une cible

À la RSAC 2026 à San Francisco, le message est frontal, avec des assistants de code, le poste développeur redevient un terrain d’attaque de premier ordre. Oded Vanunu, chief technologist chez Check Point Software, parle d’une “nouvelle ère” d’attaques côté client, parce que les outils d’IA s’exécutent localement, interagissent avec le système, et manipulent des dépôts, des scripts et des dépendances. L’IDE n’est plus un simple éditeur, c’est un orchestrateur.

Dans ce tableau, l’attaque ne passe pas forcément par un fichier “malware. exe”. Le chercheur insiste sur un changement d’approche, l’adversaire peut se contenter de fichiers de configuration et de mécanismes d’automatisation déjà présents. Pour un SOC, c’est un vrai problème de lecture du signal, une commande lancée par un outil de dev peut ressembler à une action normale, surtout si elle est déclenchée par un workflow approuvé.

Les outils cités dans la présentation couvrent des acteurs majeurs, Anthropic avec Claude Code, OpenAI avec Codex, Google avec Gemini. Le point commun n’est pas la marque, c’est la logique “agentique”, l’assistant propose, modifie, exécute, et s’intègre à des plugins. Quand tu ajoutes des connecteurs, des serveurs MCP, ou des hooks shell, tu ajoutes de la puissance, et tu élargis l’attaque surface.

Ce déplacement de la surface d’attaque rejoint une idée de plus en plus partagée dans l’AppSec, sécuriser uniquement après le commit ne suffit plus. Des acteurs comme Checkmarx défendent une approche “dans l’IDE”, au moment où le risque est introduit, parce que la vitesse de l’IA réduit le temps entre suggestion et déploiement. La nuance est importante, cette intégration peut améliorer la sécurité, mais elle crée aussi un nouveau point de concentration des risques si elle est mal gouvernée.

Cursor et la CVE-2025-54136 exposent le scénario du “swap attack”

Un cas concret a marqué les esprits, la CVE-2025-54136, une vulnérabilité de gravité élevée de type RCE identifiée dans Cursor, une plateforme d’aide au code par IA. Le mécanisme décrit repose sur l’autorisation accordée par le développeur à une commande d’un serveur MCP. Là où tu t’attends à une validation liée au contenu exact approuvé, l’autorisation était liée au nom du plugin, ce qui ouvre une porte.

Le scénario, c’est le “swap attack”. L’attaquant soumet d’abord une commande bénigne, suffisamment anodine pour être approuvée. Une fois l’accord donné, il met à jour le plugin avec une charge malveillante, sans que l’utilisateur refasse nécessairement tout le processus de vérification. La faille n’est pas un détail théorique, elle illustre un angle mort classique, tu approuves une intention, mais l’exécution finale peut diverger si l’intégrité n’est pas ancrée sur un hash de contenu.

Ce type de chaîne d’événements est redoutable sur les postes dev, parce que les droits sont souvent plus élevés, accès à des secrets, tokens, environnements de build, parfois des clés cloud. Un EDR peut détecter un comportement franchement anormal, mais si la commande passe via un outil approuvé et un flux de plugin “normal”, le tri devient plus difficile. Et dans une équipe pressée, l’étape “je relis tout” saute vite.

La critique à poser, c’est que l’UX de ces outils pousse à la fluidité. On te demande d’approuver vite, d’enchaîner, de faire confiance à l’automatisation. C’est pratique, mais ça transforme l’approbation en geste réflexe. La correction côté éditeur est indispensable, mais côté entreprise, tu dois aussi traiter l’IDE comme un composant sensible, avec des politiques de plugins, des contrôles d’intégrité, et une traçabilité des actions exécutées.

Claude Code et la CVE-2025-59536 contournent le trust dialog via Hooks

Autre exemple documenté, la CVE-2025-59536 dans Claude Code, également de gravité élevée. Le principe est simple à comprendre, l’attaquant parvient à amener l’outil à exécuter du code malveillant contenu dans un projet avant que l’utilisateur n’ait accepté le “startup trust dialog”. Autrement dit, la boîte de dialogue censée poser une barrière arrive trop tard dans la séquence d’exécution.

Le vecteur mis en avant concerne les Claude Code Hooks, des commandes shell définies par l’utilisateur et conçues pour s’exécuter automatiquement. Dans un environnement de dev, les hooks sont un confort, formatage, tests, génération, tâches répétitives. Mais si un projet embarque des hooks piégés, ou si l’assistant est manipulé pour les activer, tu obtiens une exécution locale qui ressemble à de l’automatisation standard.

Le point qui pique, c’est le contournement d’outils de EDR évoqué dans les recherches. L’idée n’est pas que l’EDR “ne sert à rien”, mais qu’il est calibré pour repérer des familles de comportements et des artefacts. Quand l’exécution passe par des scripts attendus, déclenchés dans un contexte développeur, tu risques un bruit de fond énorme, donc des réglages plus permissifs, donc des angles morts. C’est là que l’attaquant gagne.

Ce cas met aussi en lumière une règle opérationnelle, l’assistant IA ne doit pas être traité comme un simple autocomplete. Il interagit avec le système, il peut déclencher des commandes, et il consomme un contexte projet. Si ton organisation autorise l’IA sur des dépôts internes, tu dois cadrer les hooks, limiter les exécutions automatiques, et exiger des garde-fous avant toute commande système. Sinon, tu transformes une fonctionnalité de confort en surface d’attaque.

Prompt injection et supply chain, le risque se propage aux entreprises clientes

Les assistants de code ne vivent pas dans le vide. Ils lisent des tickets, des README, des issues, des commentaires, des snippets copiés, et ils peuvent être influencés par du contenu que tu n’as pas écrit. C’est là que la prompt injection devient un problème concret, tu penses guider l’outil, mais un texte dans le projet, ou dans une dépendance, peut détourner ses priorités, lui faire ignorer une règle, ou l’amener à proposer une action dangereuse.

Le deuxième volet, c’est la supply chain. Fortune souligne que les failles et quasi-incidents observés n’ont pas encore déclenché une attaque massive, mais ils montrent ce qui pourrait mal tourner. Une compromission ou une manipulation dans un outil utilisé par de nombreux développeurs peut impacter des entreprises en aval, parce que le code, les dépendances et les pratiques se répliquent. Les attaques supply chain sont “efficaces” par design, un point d’entrée, beaucoup de victimes potentielles.

Des chiffres donnent une idée du décalage entre adoption et contrôle. Selon Black Duck, 95% des organisations utilisent désormais des outils d’IA pour le développement. 76% déclarent vérifier le code IA pour des risques de sécurité, mais seulement 24% mènent des évaluations complètes couvrant sécurité, qualité, licences et IP. Le trou n’est pas seulement technique, il est organisationnel, tu industrialises la production, mais tu n’industrialises pas les garde-fous.

Un responsable AppSec, appelons-le Marc, me résumait le problème de manière très terre-à-terre, “on a mis un turbo à la livraison, mais on a laissé les freins d’origine”. C’est une image, mais elle colle. Plus tu accélères la génération de code et l’intégration de dépendances, plus une erreur minuscule peut se diffuser vite. Et si tu ajoutes des agents capables d’agir, pas seulement de suggérer, tu dois penser “contrôle d’exécution”, pas juste “revue de code”.

Palo Alto Networks et Checkmarx poussent une défense en temps réel

Face à ces attaques, l’endpoint security ne disparaît pas, elle doit évoluer. Palo Alto Networks rappelle que l’IA dans la sécurité endpoint peut rendre la détection plus prédictive, plus adaptative, plus réactive, notamment via des solutions de type NGAV et EDR augmentées par l’analyse comportementale. L’idée est d’identifier des signaux faibles, des enchaînements anormaux, et de réagir plus vite, y compris automatiquement.

Mais l’enjeu, c’est le point d’observation. Si l’attaque naît dans l’IDE, attendre le post-commit ou le scan en CI/CD peut coûter cher, vulnérabilités plus difficiles à corriger, cycles d’urgence, et propagation dans plusieurs branches. Checkmarx insiste sur la nécessité de pousser la protection “au moment où le risque est introduit”, directement dans l’environnement de dev, en surveillant l’activité des plugins, en analysant les suggestions IA, et en interceptant des changements suspects.

Concrètement, ça ressemble à des contrôles d’intégrité sur les plugins, des politiques d’autorisation sur les serveurs MCP, des alertes quand un assistant tente d’exécuter des commandes shell, et une corrélation avec les signaux endpoint. Tu ne peux pas te contenter d’un unique filet. Le poste, l’IDE, le dépôt, la pipeline, tout doit partager une vision. Sinon, l’attaquant se glisse dans les interstices, là où chaque équipe pense que l’autre couvre le risque.

La nuance à garder, c’est que l’IA peut aider les deux camps. Palo Alto Networks note aussi la montée d’attaques “superchargées” par l’IA, phishing plus convaincant, analyse rapide de données, exploitation plus rapide avant patch. Donc oui, mettre de l’IA dans la défense est logique, mais ça ne remplace pas les décisions humaines, la gouvernance, et la discipline sur les outils de dev. Si tu laisses les assistants agir sans cadre, tu ajoutes un opérateur invisible à ton système d’information.