Oups ! Une faille de type « injection SQL » a contraint les développeurs à publier un correctif d'urgence pour le cœur de WordPress la semaine dernière.
Le 17 juillet, WordPress a publié une mise à jour d'urgence afin de corriger une faille de sécurité dans le cœur du logiciel permettant l'exécution de code à distance sans authentification, accessible via une injection SQL qu'un attaquant anonyme peut exploiter sur une installation par défaut. WordPress.org a même activé les mises à jour automatiques obligatoires en raison de la gravité de cette faille. Searchlight Cyber, qui a signalé cette faille, estime que plus de 500 millions de sites utilisent WordPress. Si vous êtes concerné, passez à la version 7.0.2, ou à la version 6.9.5 pour la branche plus ancienne.
L'injection SQL, également désignée par l'acronyme SQLi, est une vulnérabilité ancienne dont la correction est aisée, ce qui laisse penser qu'elle a disparu. Mais comme on vient de nous le rappeler, ce n'est pas le cas.
L'injection SQL : de ses modestes débuts à nos jours
L'injection SQL et ses solutions font partie du programme d'initiation à l'informatique. Je me souviens avoir étudié l'injection de ligne de commande à l'université il y a plus de dix ans, et honnêtement, c'est la seule vulnérabilité liée aux applications dont je me souvienne avoir entendu parler en cours (je pense qu'ils sont passés à d'autres sujets après l'avoir abordée, ou peut-être que je n'ai plus prêté attention par la suite).
Le phénomène d'injection SQL a été rendu public en 1998 par le chercheur connu sous le pseudonyme de « rainforest puppy ». La solution permettant de résoudre la plupart des problèmes liés à l'injection SQL, à savoir les instructions préparées, a été mise au point environ un an plus tard. Cette solution est plus ancienne que bon nombre d'ingénieurs de l'entreprise. Il convient d'utiliser des requêtes paramétrées et de traiter les données saisies par l'utilisateur comme de simples données. Cependant, même avec cette solution à disposition, les injections SQL continuent de se produire.
D'après les données de la base de données des avis de sécurité de GitHub, en filtrant les avis par CWE et en effectuant un décompte annuel :
Le nombre d'alertes relatives aux injections SQL a augmenté chaque année entre 2023 et 2025, passant de 2 096 à 2 850. Les trois types d'injection les plus anciens – à savoir l'injection SQL, l'injection de commande et le parcours de chemin – représentent encore, à eux trois, plus d'un cas sur dix parmi l'ensemble des incidents signalés.
L'OWASP a fait passer l'injection de la troisième à la cinquième place de son Top 10 de 2025, mais pas parce que les failles ont été corrigées. La catégorie générale des injections compte toujours plus de CVE signalés que toute autre, avec plus de 60 000 signalements. Parmi ceux-ci, les injections SQL représentaient à elles seules plus de 14 000 cas. Lors des analyses menées par Mackenzie sur des dépôts de code fermés, 20 % des projets présentaient au moins une faille d'injection SQL dès la première analyse.
Pourquoi les injections SQL ne disparaissent pas
Tout d'abord, pour mettre les choses au clair, il arrive que l'on commette des erreurs lorsqu'on écrit du code. C'est inévitable. Il arrive donc de temps en temps qu'une faille SQLi passe entre les mailles du filet. Mais les systèmes modernes censés nous aider ne le font pas à 100 %, et peuvent même nous amener à commettre d'autres erreurs.
Par exemple, les frameworks les plus récents intègrent des méthodes permettant de prévenir les injections SQL. Les ORM tels que Django, Hibernate et ActiveRecord utilisent par défaut la paramétrisation, ce qui conduit de nombreuses équipes à croire que le problème est résolu. Mais si un utilisateur recourt à une requête brute ou utilise une méthode non sécurisée, la protection disparaît.
La vulnérabilité CVE-2024-42005 de Django en est un exemple. Deux des méthodes de requête propres à Django, utilisées pour lire les champs d'une colonne JSON, inséraient directement dans le code SQL les noms de champs fournis sans les valider au préalable. Ainsi, un attaquant contrôlant un nom de champ pouvait prendre le contrôle d'une partie de la requête, via une méthode que les équipes considéraient comme sûre.
D’un autre côté, le code très ancien pose également problème, le code hérité perpétuant ces failles depuis des décennies. Les équipes s’appuient sur un WAF et partent du principe (en espérant) qu’il détecte tout. Bien que la solution existe depuis plus de 25 ans, l’appliquer à chaque requête, chaque point de terminaison et chaque recoin du code hérité, à chaque fois, représente un travail fastidieux qui n’a jamais été mené à bien dans l’intégralité de toutes les bases de code. Comme le souligne Mackenzie Jackson, notre directeur technique sur le terrain, cela a cessé d’être un problème technique pour devenir un enjeu de culture, de processus et de formation.
Et bien sûr, l'IA.
L'IA rédige également des SLQi
On pourrait évidemment espérer que les assistants de programmation basés sur l'IA, formés à partir d'exemples accumulés depuis des décennies, cessent de reproduire un bug datant de 1998. Mais comme on le sait, l'IA n'écrit pas de code parfait.
Nous pouvons examiner cela d’un point de vue quantitatif. L’étude « Asleep at the Keyboard » de 2021, menée par l’université de New York (NYU) et l’université Cornell, a généré 1 689 programmes à partir de GitHub Copilot pour différents scénarios de failles courantes et a révélé qu’environ 40 % d’entre eux étaient vulnérables, les injections SQL et les injections de commandes figurant parmi les plus fréquentes. Les propres tests de Mackenzie aboutissent à des résultats similaires. En soumettant une même requête à ChatGPT plusieurs centaines de fois, environ 12 % des résultats se sont révélés susceptibles d’être exploités par injection, un taux proche de celui observé dans l’open source.
Mais pourquoi ? Les modèles apprennent à partir de code public qui comporte ces failles, ce qui les amène à les reproduire à une fréquence similaire. L'IA gère mieux les injections SQL que les failles fortement liées au contexte, comme le cross-site scripting, pour lesquelles le même rapport a révélé que la plupart des résultats n'étaient pas sécurisés. L'IA ne cesse de s'améliorer, ces chiffres seront donc obsolètes d'ici six mois, mais on peut s'attendre à ce que l'IA continue d'écrire ce genre de code par inadvertance, tout comme nous le faisons.
Aujourd’hui, de plus en plus de développeurs « créatifs » et de personnes ayant une formation technique limitée écrivent du code. Ils sont moins à même de détecter les injections SQL (à supposer même qu’ils sachent qu’il faut les rechercher), ce qui fait que davantage de code peut être intégré à la base de code de l’entreprise sans qu’un œil averti ne vérifie que ce problème a bien été pris en compte.
C'est pour ça qu'il faut prévoir un filet de sécurité
Même si vous faites tout correctement, comme utiliser des requêtes paramétrées partout, mettre en place des listes blanches sur chaque entrée, etc.… Vous avez tout de même besoin protection en temps d’exécution. Une désinfection parfaite sur tous les points d’accès, en permanence, n’existe pas. Une attaque SQLi peut même se produire dans une dépendance vulnérable que vous ne contrôlez pas (ou, par exemple, sur le site par défaut d’un hébergeur de sites web), ce qui dépasse largement ce que vous pouvez raisonnablement gérer.
Aikido est un pare-feu intégré à l’application s’exécute au sein de celle-ci et surveille les entrées utilisateur à mesure qu’elles sont transmises vers un récepteur de données, comme une requête de base de données ou la lecture d’un fichier.
Lorsqu'une charge utile malveillante est sur le point d'atteindre l'un de ces emplacements, Zen la bloque immédiatement, en disposant d'un contexte d'application suffisant pour distinguer une attaque d'une chaîne de recherche qui lui ressemble par hasard.
Il couvre également les failles provenant des dépendances, là où vos propres normes de codage ne suffisent pas. Considérez-le comme un filet de sécurité à l'exécution lorsque le codage sécurisé présente des lacunes, ce qui est toujours le cas dans la pratique. Zen est un système RASP, qui identifie les entrées dangereuses au niveau du code. Cela diffère d'un WAF qui bloque les entrées suspectes au niveau du réseau, une approche moins précise qui a donc tendance à bloquer trop d'éléments. J'aborde ce sujet de manière beaucoup plus détaillée dans notre article consacré à la comparaison entre WAF, RASP et ADR.
Un pare-feu intégré à l’application Zen, pare-feu intégré à l’application , fait office de barrière entre wp2shell et un site WordPress non mis à jour. Zen est conçu pour bloquer l’injection SQL sur laquelle repose cette faille ; ainsi, un site en attente de mise à jour disposait toujours d’une protection pendant le déploiement du correctif.
Détectez les injections SQL dans votre branche de développement
Le contrôle d'exécution constitue un filet de sécurité, mais la prévention reste bien sûr la solution idéale. Dans l'idéal, il faudrait détecter et supprimer toutes les injections SQL présentes dans le code.
L'analyse statique, comme SAST de nombreuses injections SQL, notamment celles de type simple où les données saisies sont intégrées directement dans une requête sans instruction paramétrée. Elle n'aurait pas détecté celle-ci. Le cœur de WordPress est l'un des logiciels les plus analysés qui soient, et ce bug n'a pas été détecté. Dans ce cas précis, l’injection ne devient exploitable que lorsqu’une requête batch mal formée perturbe le fonctionnement interne de WordPress, de sorte que la valeur parvient à la base de données par un chemin qui contourne le mécanisme de nettoyage. Il s’agit d’une interaction entre requêtes qu’un analyseur statique n’est pas en mesure de détecter. La découverte de cette vulnérabilité a nécessité un modèle de pointe exécutant quatre agents pendant six heures.
Les injections courantes relèvent de la responsabilité de votre scanner. Celles qui sont cachées et dépendent de la logique nécessitent de plus en plus souvent qu’une IA les détecte avant que quelqu’un d’autre ne le fasse, ce qui est le cas pour Aikido pentest IA et de l’orienter vers votre propre code, à l’instar de ce chercheur qui en a orienté un vers WordPress. Aikido pentest continu Aikido , qui peut vous aider à vérifier régulièrement l’existence de nouvelles vulnérabilités SQLi susceptibles de passer entre les mailles code review lors de code review.
Le petit Bobby Tables est toujours bien vivant. Prenez-le au sérieux et sécurisez votre code, même les parties les plus ennuyeuses.
