L'IA a trouvé 300 vulnérabilités de plugins WordPress en 72 heures
L'IA trouve des bugs en quelques secondes. Cela change tout pour les développeurs.
Un récent scan de sécurité a découvert plus de 300 vulnérabilités critiques de type zero-day dans des plugins WordPress en seulement 72 heures. Les chercheurs appellent cela le « vibe coding ». Cela se produit lorsque les développeurs publient du code généré par l'IA sans l'auditer.
Une agence a trouvé 100 problèmes de sécurité dans un seul plugin généré par l'IA.
L'IA agit des deux côtés. Elle écrit du code rapidement, mais elle saute souvent des étapes de sécurité comme l'échappement (escaping) et les vérifications de permissions. Parallèlement, les attaquants utilisent l'IA pour trouver ces mêmes failles instantanément.
Les anciens filets de sécurité ont disparu. L'obscurité et le temps ne protègent plus votre code. Les données montrent que l'exploitation massive survient environ cinq heures après qu'un bug est devenu public. Ce n'est pas assez de temps pour réagir.
J'ai appris cela à mes dépens. J'ai conçu un plugin de chatbot IA. Une revue de sécurité a révélé 35 bugs dans mon code. Le pire était une injection HTML. J'ai fait confiance au résultat de l'IA. Je pensais que parce que l'IA l'avait écrit, c'était sûr.
Ce n'était pas le cas. La sortie de l'IA peut contenir du contenu malveillant provenant d'utilisateurs ou de sites web externes. Si vous considérez la sortie de l'IA comme sûre, vous créez une faille.
J'ai changé mon flux de travail. Je ne suppose plus que « ça fonctionne » signifie « c'est sûr ». Je révise désormais manuellement chaque gestionnaire (handler) écrit par l'IA dans trois domaines :
• Entrée (Input) : Comment les données entrent dans le système.
• Sortie (Output) : Comment les données sortent du système. Je traite les réponses de l'IA comme des entrées non fiables. J'utilise des fonctions comme esc_html et wp_kses.
• Permissions : Je vérifie les capacités des utilisateurs et les nonces à chaque point d'entrée.
Le vrai problème n'est pas seulement le code. C'est le temps de réponse. De nombreux développeurs ne publient pas de correctif avant qu'un bug ne devienne public. De nombreux plugins n'ont aucun correctif disponible.
Si vous êtes un développeur solo, vous ne pouvez pas simplement écrire avec soin et espérer que tout se passe bien. Vous avez besoin d'un moyen pour que les gens vous signalent les bugs avant qu'ils ne deviennent publics.
D'ici la fin de 2026, les lois de l'UE exigeront des programmes de divulgation de vulnérabilités. Pour les auteurs solos, cela peut être simple. Ajoutez un contact de sécurité à votre fichier readme. Donnez aux gens un endroit privé pour envoyer des rapports.
N'attendez pas un exploit public. Construisez des systèmes pour détecter les bugs avant que le compte à rebours de cinq heures ne commence.
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi