Ally : votre plugin d'accessibilité WordPress exposait les données de 400 000 sites

Ally est le plugin d'accessibilité web d'Elementor - celui que vous installez pour rendre votre site conforme aux normes WCAG, adapter les contrastes, les polices, la navigation au clavier. Un outil de conformité, discret, que personne ne soupçonne. En février 2026, une faille a été découverte dans ce plugin : un attaquant anonyme pouvait interroger la base de données de votre site et en extraire les mots de passe, sans aucun compte, sans aucun mot de passe. Plus de 400 000 sites étaient concernés. Trois semaines après la publication du correctif, les deux tiers n'avaient toujours pas mis à jour. Sans suivi de sécurité actif, un correctif publié en février ne s'applique pas avant que vous y pensiez - ce qui peut prendre des mois.

Ally, le plugin d'accessibilité d'Elementor

Ally - anciennement distribué sous le nom One Click Accessibility - est le plugin d'accessibilité web d'Elementor. Il propose un panneau de configuration côté visiteur permettant d'ajuster le contraste, la taille des polices, l'espacement, ou d'activer une navigation optimisée pour les lecteurs d'écran. Plus de 400 000 sites l'utilisent, souvent parce qu'ils doivent répondre à des obligations légales (RGAA en France, WCAG au niveau européen) ou parce qu'un prestataire l'a installé lors de la création du site.

Personne ne pense à surveiller un plugin d'accessibilité. Ally est perçu comme un outil de conformité - discret, sans risque, dans la liste des extensions depuis le lancement du site. La plupart des propriétaires ne savent même pas qu'il est installé. Dans notre pratique, c'est ce type de plugins "utilitaires" - confiés à un prestataire lors de la création du site et jamais revisités - qui reste le plus souvent en retard de plusieurs versions. C'est Drew Webber, ingénieur en sécurité offensive chez Acquia, qui a découvert la faille le 4 février 2026 et l'a signalée via le programme de bug bounty de Wordfence. Sa prime : 800 dollars.

La faille : une requête SQL construite sans filet de sécurité

Le problème vient de la méthode get_global_remediations(), chargée de récupérer les données de remédiation d'accessibilité pour une page donnée. Cette méthode construit une requête SQL de type JOIN en utilisant le paramètre d'URL de la page courante. Le code applique bien esc_url_raw() pour nettoyer l'URL - mais cette fonction est conçue pour valider des URLs, pas pour protéger des requêtes SQL. Elle ne filtre pas les métacaractères SQL : guillemets simples, parenthèses, tirets doubles.

La règle fondamentale pour protéger une requête SQL dans WordPress est d'utiliser $wpdb->prepare(), qui paramétrise la requête et sépare le code SQL des données. Ally ne le faisait pas. Le paramètre d'URL était directement concaténé dans la clause JOIN, laissant un attaquant libre d'y insérer n'importe quelle commande SQL.

La condition d'exploitation à connaître

Avant de paniquer, un point important : la faille n'est exploitable que si deux choses sont vraies en même temps. Le plugin doit être connecté à un compte Elementor - configuration standard pour les utilisateurs d'Elementor Pro, moins courante pour ceux qui ont installé Ally seul. Et le module Remediation doit être actif dans les paramètres.

Si l'une des deux manque, personne ne peut déclencher la faille depuis l'extérieur. C'est pourquoi l'estimation des sites réellement exposés tourne plutôt autour de 250 000 que des 400 000 installations totales. La mise à jour reste obligatoire dans tous les cas - mais le risque réel est plus ciblé que les gros titres ne le laissent entendre.

Ce qu'un attaquant peut extraire concrètement

La technique d'exploitation est une injection SQL aveugle temporelle (time-based blind SQL injection). L'attaquant ne peut pas lire directement les réponses de la base - la requête ne renvoie rien d'utilisable en clair. Il procède autrement : il injecte des expressions CASE WHEN couplées à la fonction SLEEP(), puis observe le temps de réponse du serveur. Un délai plus long signifie que la condition testée est vraie. Bit par bit, caractère par caractère, il peut ainsi reconstituer n'importe quel contenu de la base.

Ce que cela permet d'extraire en pratique : les hachages de mots de passe de tous les utilisateurs WordPress (table wp_users), leurs adresses email, leurs noms d'utilisateur. Ces hachages peuvent ensuite être soumis à des attaques par dictionnaire hors ligne. Sur des sites WooCommerce, les données de commandes et les adresses des clients sont également accessibles. C'est long, mais automatisable - des outils comme SQLMap le font sans intervention humaine.

Indicateurs à surveiller dans vos logs Apache ou Nginx :

250 000 sites encore exposés trois semaines après le patch

Le correctif (version 4.1.0) a été publié le 23 février 2026. Trois semaines plus tard, à la date de cet article, les données de WordPress.org montrent que seulement 36% des sites utilisant Ally ont appliqué la mise à jour. Cela représente plus de 250 000 sites encore vulnérables, selon Bleeping Computer. Note éditoriale : certaines sources citent 400 000 sites "concernés" (total des installations) et d'autres 250 000 "exposés" (non patchés au moment de la publication). Les deux chiffres sont exacts - ils ne mesurent pas la même chose.

36% en trois semaines, c'est à peu près le rythme habituel. Une minorité de sites réagit vite, le reste attend - parfois des mois. Les attaquants ne s'intéressent pas aux sites patchés. Ils scannent les 64% qui ne l'ont pas encore fait, et ils ont tout leur temps.

Dans les audits post-incident que nous menons, c'est le même constat : la faille exploitée était connue, le patch était disponible, le site n'avait pas été mis à jour. Le problème n'est presque jamais l'absence de correctif. C'est le délai entre sa publication et son application.

Versions concernées et correctif

Ce qu'il faut faire maintenant

Si vous gérez plusieurs sites WordPress ou n'avez pas le temps de surveiller chaque mise à jour de sécurité, c'est exactement ce que couvre un contrat de maintenance WordPress : correctifs appliqués dès leur publication, surveillance continue et audit en cas de doute.

Chronologie de la divulgation

• 1
  4 février 2026

  Drew Webber (Acquia) découvre la faille CVE-2026-2413 dans la méthode get_global_remediations() du plugin Ally.
• 2
  13 février 2026

  Signalement via le programme de bug bounty de Wordfence. Bounty accordé : 800 dollars.
• 3
  15 février 2026

  Elementor accuse réception et commence à travailler sur le correctif.
• 4
  23 février 2026

  Publication de la version 4.1.0 qui corrige la faille. La méthode get_global_remediations() est mise à jour pour utiliser $wpdb->prepare() et paramétrer correctement la requête SQL.
• 5
  15 mars 2026

  Divulgation publique. Seulement 36% des sites ont appliqué la mise à jour - plus de 250 000 installations restent exposées.

FAQ - Faille Ally CVE-2026-2413

Mon site est-il exposé si j'utilise Ally sans le module Remediation ?

Non. La faille ne peut être exploitée que si deux conditions sont réunies : le plugin est connecté à un compte Elementor ET le module Remediation est actif. Si l'une manque, l'exploitation est impossible depuis l'extérieur. La mise à jour vers 4.1.0 reste recommandée dans tous les cas.

Qu'est-ce qu'une injection SQL et pourquoi est-ce dangereux ?

Une injection SQL consiste à insérer des commandes SQL malveillantes dans une requête légitime. Dans le cas d'Ally, un attaquant peut forcer la base de données à exécuter des requêtes non prévues et en extraire le contenu : mots de passe hashés, emails, données personnelles. Les outils pour automatiser ce type d'attaque sont publics et très répandus.

Pourquoi un plugin d'accessibilité représente-t-il un risque de sécurité ?

Tout plugin WordPress expose du code côté serveur accessible depuis internet. Ally gère des requêtes pour récupérer les données de remédiation d'accessibilité - c'est dans cette fonction que résidait la faille. La vocation d'un plugin ne préjuge pas de son niveau de risque.

Pourquoi 250 000 sites n'ont-ils pas encore mis à jour mi-mars ?

C'est le rythme habituel. Seulement 36% des sites avaient appliqué la mise à jour trois semaines après sa publication. Sur WordPress, une large part des propriétaires n'applique pas les mises à jour rapidement - par manque de temps, par méconnaissance, ou parce qu'ils font confiance à leur hébergeur pour le faire à leur place (ce qui n'est généralement pas le cas).

Wordfence protège-t-il contre cette faille ?

Wordfence Premium, Care et Response ont reçu une règle de pare-feu dès la divulgation. Les utilisateurs de la version gratuite reçoivent les règles avec un délai de 30 jours. Dans les deux cas, la mise à jour vers 4.1.0 reste la seule correction définitive.

Le plugin le moins suspect, la faille la plus discrète

Ce n'est pas le plugin le plus complexe ou le plus exposé qui pose problème, en général. C'est celui que personne ne surveille. Un outil d'accessibilité installé il y a deux ans, oublié dans la liste des extensions, mis à jour une fois de temps en temps. Personne ne va chercher une injection SQL là-dedans.

C'est pourtant là qu'elle était. Et 64% des sites ne l'avaient pas corrigée trois semaines après la publication du patch. Les scanners automatisés qui ratissent les versions de plugins WordPress le savent : les outils "utilitaires" sont des cibles de choix précisément parce que leurs propriétaires ne les surveillent pas.

Un WordPress sans maintenance expose chaque extension installée, quelle que soit sa fonction apparente. Notre guide sur les 7 risques concrets d'un WordPress sans maintenance le détaille - Ally en est une démonstration de plus.