Vibe coding : quand le code généré par IA multiplie les vulnérabilités

En trois mois, 74 vulnérabilités ont été directement attribuées à du code généré par intelligence artificielle. Le "vibe coding", qui consiste à décrire les fonctionnalités souhaitées en langage naturel et à laisser l'IA générer le code correspondant, s'est largement répandu en 2026. Si cette approche offre une productivité considérable, elle pose un risque majeur lorsque le code généré est déployé en production sans passer par un processus de vérification adapté.

Des vulnérabilités de plus en plus nombreuses dans le code généré par IA

Le projet Vibe Security Radar, lancé en 2025 par le Systems Software & Security Lab de Georgia Tech, traque les CVEs directement introduites par du code généré par IA. Sa méthodologie repose sur l'analyse des bases de vulnérabilités et le traçage de chaque correctif jusqu'au commit d'origine, pour déterminer si un outil de coding IA a introduit la faille.

Les résultats sont parlants. En janvier 2026, 6 CVEs étaient directement attribuées à du code généré par IA. En février, 15, et en mars, 35. Soit 74 vulnérabilités confirmées en trois mois, avec une courbe d'accélération qui suit celle de l'adoption des outils de coding IA. Et les chercheurs estiment que le chiffre réel est 5 à 10 fois supérieur, la plupart des commits générés par IA ne portant pas de signature permettant de les identifier comme tels.

Pourquoi le vibe coding pose un problème de sécurité

Le risque ne vient pas tant de l'intelligence artificielle elle-même que du volume de code qu'elle produit sans vérification suffisante. Cela se traduit par des vulnérabilités récurrentes (injections SQL, XSS, stockage non sécurisé, secrets hardcodés, authentification insuffisante, cryptographie faible) qui atteignent la production à une échelle et une vitesse inédites. Les développeurs assistés par IA produisent du code 3 à 4 fois plus vite, et introduisent des failles de sécurité à un rythme proportionnel.

Ce constat est amplifié par un biais de confiance. Le code généré compile, passe les tests fonctionnels, et se retrouve souvent intégré avec moins de revue humaine qu'un code écrit manuellement. L'OWASP a d'ailleurs mis à jour son Top 10 en 2026 en y intégrant pour la première fois les risques liés à la supply chain logicielle, un vecteur directement amplifié par le code généré par IA.

Un autre vecteur de risque provient de la tendance de l'IA à référencer des dépendances qui n'existent pas. Selon une étude USENIX Security, près de 20 % des packages référencés dans le code généré par IA sont purement fictifs. Les attaquants exploitent ce phénomène, appelé "slopsquatting", en enregistrant ces noms de packages inventés par l'IA pour y placer du code malveillant, créant ainsi un vecteur de supply chain attack entièrement nouveau.

Quand les outils de coding IA deviennent eux-mêmes des cibles

Le risque ne se limite pas au code que l'IA produit. Les outils de coding IA eux-mêmes sont devenus des cibles d'attaques, ouvrant un nouveau vecteur de compromission de la chaîne d'approvisionnement logicielle.

En juillet 2025, un attaquant avait notamment exploité un token GitHub mal configuré pour injecter du code malveillant dans l'extension Amazon Q Developer, l'assistant de coding IA d'Amazon, pour VS Code. L'extension compromise avait été distribuée via le VS Code Marketplace pendant plusieurs jours avant qu'AWS ne publie un correctif. Le code injecté visait à exécuter des commandes sur la machine du développeur, et seule une erreur de syntaxe dans le payload a évité l'exploitation.

L'éditeur de code IA Cursor, utilisé par plus d'un million de développeurs, avait également fait l'objet de plusieurs CVEs en 2025. La vulnérabilité CurXecute permettait à un attaquant d'exécuter du code à distance via une injection de prompt à travers un serveur MCP connecté. MCPoison exploitait un mécanisme similaire en empoisonnant un fichier de configuration MCP dans un dépôt partagé, un développeur approuvant une configuration légitime pouvait être silencieusement redirigé vers une configuration malveillante.

GitHub Copilot n'est pas épargné. Des chercheurs avaient déjà démontré qu'il était possible d'injecter des caractères Unicode invisibles dans les fichiers de règles de Copilot et Cursor, dirigeant silencieusement l'IA pour insérer du code malveillant dans toute sortie générée, sans que le développeur ne puisse le détecter visuellement.

Comment Yagaan sécurise les applications construites avec du code IA

Le code généré par l'IA finit dans des applications web et mobiles déployées en production. Et la recommandation des chercheurs est claire : il doit être traité avec la même rigueur que n'importe quel code tiers non vérifié.
C'est justement le cœur de métier de Yagaan, powered by Pradeo, dont les solutions de sécurité applicative permettent d'analyser et sécuriser le code des applications, qu'il soit écrit par un développeur ou généré par intelligence artificielle.

• Le Static Application Security Testing de Yagaan s'intègre dans les pipelines CI/CD pour analyser le code source à chaque itération et détecter les vulnérabilités introduites avant la mise en production. La solution utilise le machine learning pour prioriser les vulnérabilités selon leur criticité réelle et fournir une aide contextuelle à la remédiation, permettant aux développeurs de corriger efficacement sans ralentir le cycle de développement.
• Pour les applications mobiles construites avec du code IA, Yagaan Mobile Application Security Testing permet d'auditer la sécurité à partir du code binaire (Android et iOS), identifiant les composants tiers et les vulnérabilités, y compris celles introduites par des dépendances fictives générées par l'IA.

À mesure que le code généré par l'IA représente une part croissante des applications en production, l'analyse statique systématique n'est plus optionnelle. Elle devient la première ligne de défense avant la mise sur le marché.