Oups ! Un bug d'injection SQL vient de forcer un correctif d'urgence du cœur de WordPress la semaine dernière.
Le 17 juillet, WordPress a publié une version d'urgence pour corriger une faille d'exécution de code à distance non authentifiée dans le cœur, accessible via une injection SQL qu'un attaquant anonyme peut exploiter sur une installation standard. WordPress.org a même activé les mises à jour automatiques forcées en raison de sa gravité. Searchlight Cyber, qui l'a signalé, estime que plus de 500 millions de sites fonctionnent sous WordPress. Si vous êtes concerné, passez à la version 7.0.2, et à la 6.9.5 pour l'ancienne branche.
L'injection SQL, également stylisée en SQLi, est une ancienne vulnérabilité avec un correctif facile, donc les gens supposent qu'elle est morte. Mais comme on vient de nous le rappeler, ce n'est pas le cas.
Injection SQL : Des humbles débuts à nos jours
L'injection SQL et ses solutions font partie des cours d'informatique de base. Je me souviens avoir appris l'injection de prompt à l'université il y a plus de dix ans, et honnêtement, c'est la seule vulnérabilité basée sur les applications dont je me souvienne qu'ils aient enseignée (je pense qu'ils sont passés à d'autres sujets après l'avoir abordée, ou peut-être que je n'ai pas fait attention après cela).
L'injection SQL a été documentée publiquement en 1998 par le chercheur connu sous le nom de rainforest puppy. Le correctif qui résout la plupart des problèmes de SQLi, les requêtes préparées, a été trouvé environ un an plus tard. Le correctif est plus ancien que de nombreux ingénieurs de l'entreprise. Utilisez des requêtes paramétrées et traitez les entrées utilisateur comme des données. Mais même avec un correctif existant, les injections SQL se produisent toujours.
Basé sur les données de la base de données d'avis de GitHub, en filtrant les avis par CWE et en comptant par an :
Le nombre d'avis concernant les injections SQL a augmenté chaque année complète de 2023 à 2025, passant de 2 096 à 2 850. Les trois classes d'injection les plus anciennes combinées – injection SQL, injection de commandes et traversée de répertoires – représentent toujours plus d'un dixième de tous les éléments signalés.
L'OWASP a fait passer les injections de la troisième à la cinquième place de son Top 10 2025, mais pas parce que les problèmes sont résolus. La catégorie globale des injections compte toujours plus de CVE signalées que toute autre, avec plus de 60 000 rapports. Parmi celles-ci, l'injection SQL à elle seule en représentait plus de 14 000. Dans les analyses de Mackenzie des dépôts closed-source, 20 % des projets présentaient au moins une faille d'injection SQL lors de leur première analyse.
Pourquoi l'injection SQL refuse de mourir
Pour commencer, il faut admettre que les développeurs font des erreurs lors de l'écriture de code. Cela arrive. Ainsi, de temps en temps, une injection SQL va passer inaperçue. Mais les systèmes modernes censés nous aider ne sont pas efficaces à cent pour cent du temps, et peuvent même nous pousser à commettre d'autres erreurs.
Par exemple, les frameworks récents intègrent des méthodes pour prévenir les injections SQL. Les ORM comme Django, Hibernate et ActiveRecord paramètrent les requêtes par défaut, ce qui convainc de nombreuses équipes que le problème est résolu. Mais si quelqu'un recourt à une requête brute ou utilise une méthode non sécurisée, la protection disparaît.
La CVE-2024-42005 de Django en est un exemple. Deux des méthodes de requête de Django, utilisées pour extraire des champs d'une colonne JSON, inséraient directement les noms de champs fournis dans la requête SQL sans les nettoyer. Ainsi, un attaquant qui contrôlait un nom pouvait manipuler une partie de la requête, via une méthode que les équipes pensaient sûre.
D'un autre côté, le code très ancien pose également problème, le code hérité propageant ces failles pendant des décennies. Les équipes s'appuient sur un WAF et supposent (prient) qu'il intercepte tout. Bien que le correctif existe depuis plus de 25 ans, l'appliquer à chaque requête, chaque endpoint et chaque recoin hérité, à chaque fois, représente un travail fastidieux considérable qui n'a jamais été entièrement réalisé sur toutes les bases de code. Comme le formule Mackenzie Jackson, notre CTO terrain, ce n'est plus un problème technique, mais un problème de culture, de processus et de formation.
Et bien sûr, l'IA.
L'IA écrit aussi des SQLi
L'espoir évident est que les assistants de codage basés sur l'IA, entraînés sur des décennies d'exemples, cesseraient de reproduire un bug de 1998. Mais comme nous le savons, l'IA n'écrit pas de code parfait.
Nous pouvons l'examiner quantitativement. L'étude de 2021 Asleep at the Keyboard de NYU et Cornell a généré 1 689 programmes à partir de GitHub Copilot dans des scénarios de faiblesses courantes et a constaté qu'environ 40 % étaient vulnérables, les injections SQL et les injections de commandes étant parmi les plus fréquentes. Le propre test de Mackenzie se situe dans la même fourchette. En exécutant une seule invite via ChatGPT quelques centaines de fois, environ 12 % des résultats étaient injectables, un taux proche de celui observé dans l'open source.
Mais pourquoi ? Les modèles apprennent du code public qui contient ces failles, ils les reproduisent donc à une fréquence similaire. L'IA gère mieux les injections SQL que les bugs dépendants du contexte comme le cross-site scripting, où le même rapport a révélé que la plupart des sorties étaient non sécurisées. L'IA continue de s'améliorer, ces chiffres seront donc obsolètes dans six mois, mais nous pouvons nous attendre à ce que l'IA continue d'écrire cela accidentellement, tout comme nous.
Et maintenant, de plus en plus de « vibe-coders » et de personnes moins formées techniquement écrivent du code. Ils sont moins susceptibles de reconnaître les injections SQL (s'ils savent même les chercher), ainsi, plus de code peut intégrer la base de code de l'entreprise sans que des yeux experts ne s'assurent que ce problème est pris en compte.
C'est pourquoi il vous faut un filet de sécurité
Même si vous faites tout correctement, comme des requêtes paramétrées partout, des listes blanches sur chaque entrée, et ainsi de suite… Vous voulez toujours une protection en temps d'exécution. Une désinfection parfaite sur chaque endpoint, pour toujours, n'existe pas. Une injection SQL peut même survenir dans une dépendance vulnérable que vous ne contrôlez pas (ou, par exemple, le site par défaut d'un hébergeur), ce qui dépasse tout ce que vous pouvez raisonnablement gérer.
Aikido Zen est un pare-feu intégré à l'application qui s'exécute au sein de votre application et surveille les entrées utilisateur lorsqu'elles se dirigent vers un récepteur de données, comme une requête de base de données ou une lecture de fichier.
Lorsqu'une charge utile d'attaque est sur le point d'atteindre l'un de ces emplacements, Zen la bloque instantanément, avec suffisamment de contexte applicatif pour distinguer une attaque d'une chaîne de recherche qui y ressemble.
Il couvre également les failles qui proviennent des dépendances, là où vos propres standards de codage ne s'appliquent pas. Considérez-le comme un filet de sécurité en temps d'exécution lorsque le codage sécurisé est insuffisant, ce qui est toujours le cas en pratique. Zen est un RASP, qui comprend les entrées dangereuses au niveau du code. C'est différent d'un WAF qui bloque les entrées suspectes au niveau du réseau, ce qui est moins précis et a tendance à bloquer excessivement. J'approfondis ce sujet dans notre article sur WAF vs RASP vs ADR.
Un pare-feu intégré à l'application comme Zen se positionne entre wp2shell et un site WordPress non patché. Zen est conçu pour bloquer l'injection SQL sur laquelle repose cette faille, ainsi, un site en attente de la mise à jour disposait toujours d'une défense pendant le déploiement du correctif.
Détectez les injections SQL dans votre branche de développement
L'exécution est le filet de sécurité, mais la prévention est bien sûr la norme d'excellence. Idéalement, nous trouvons et supprimons toutes les injections SQL dans le code.
L'analyse statique comme le SAST détecte de nombreuses injections SQL, celles de type simple où l'entrée est directement insérée 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 scannés, et ce bug n'a pas été détecté. Dans ce cas, l'injection ne devient exploitable que lorsqu'une requête de lot mal formée désaligne la comptabilité interne de WordPress, permettant ainsi à la valeur d'atteindre la base de données par un chemin qui ignore le nettoyage. C'est une interaction inter-requêtes qu'un scanner statique n'est pas capable de suivre. La découverte de cette vulnérabilité a nécessité un modèle de pointe exécutant quatre agents pendant six heures.
L'injection courante est le travail de votre scanner. Le type enfoui, dépendant de la logique, nécessite de plus en plus une IA pour le trouver avant que quelqu'un d'autre ne le fasse, ce qui est le cas pour le pentest IA Aikido et le fait de le diriger vers votre propre code, comme ce chercheur l'a fait avec WordPress. Aikido propose le pentest continu avec Aikido Infinite, ce qui peut vous aider à vérifier régulièrement toute nouvelle injection SQL susceptible de passer à travers la code review.
Little Bobby Tables est toujours bien vivant. Prenez-le au sérieux, et sécurisez votre code, même les parties les plus banales.
