aBlocks : élévation de privilèges jusqu'à la 2.17.0, correctif non précisé

En bref

• Produit : aBlocks, extension WordPress (blocs Gutenberg, tableau de bord utilisateur, popups, formulaires, animations).
• Versions affectées : toutes les versions jusqu'à la 2.17.0 incluse.
• Version corrigée : non précisé par l'éditeur.
• Sévérité : élevée, score CVSS 8.8.
• CVE : CVE-2026-110018.
• Exploitation active : inconnu.
• Date de l'avis : 24 octobre 2026.

Une vulnérabilité d'élévation de privilèges a été publiée le 24 octobre 2026 dans l'extension WordPress aBlocks, sous l'identifiant CVE-2026-110018. Selon la fiche de la base nationale des vulnérabilités américaine (NVD), un utilisateur déjà connecté avec un rôle de contributeur peut obtenir un rôle supérieur sur le site, jusqu'à celui d'éditeur, et recevoir une session authentifiée à ce nouveau niveau.

La faille se situe dans le module de formulaires d'inscription de l'extension : un contrôle de cohérence n'est appliqué qu'à l'enregistrement du contenu, et non au moment où le rôle est attribué. Les rôles d'administration restent hors d'atteinte, car l'extension refuse d'attribuer un rôle disposant des droits de gestion du site, des utilisateurs ou des thèmes. Sur une installation WordPress standard, le rôle le plus élevé accessible est donc celui d'éditeur.

Qui est concerné ?

Tous les sites WordPress sur lesquels l'extension aBlocks est installée et active dans une version jusqu'à la 2.17.0 incluse. Le risque concerne surtout les sites qui ouvrent des comptes à des tiers : rédacteurs invités, blogs multi-auteurs, sites associatifs ou éditoriaux où des contributeurs externes disposent d'un compte. Un éditeur peut publier, modifier ou supprimer l'ensemble des contenus du site, y compris ceux des autres auteurs, ce qui ouvre la voie à des défigurations, à l'insertion de liens malveillants ou à la suppression de pages.

Les sites qui n'accordent aucun compte contributeur ou supérieur à des personnes extérieures sont moins exposés, puisque l'attaque suppose un compte authentifié. La version corrigée n'est pas précisée par l'éditeur dans les sources consultées : il faut vérifier le journal des modifications de l'extension avant de considérer un site comme protégé.

Que faire ?

• Mettre à jour aBlocks dès qu'une version postérieure à la 2.17.0 est disponible, en vérifiant dans le journal des modifications qu'elle corrige cette faille.
• En attendant, si les formulaires d'inscription de l'extension ne sont pas utilisés, envisager de la désactiver, ou limiter les comptes contributeurs aux personnes de confiance.
• Passer en revue la liste des utilisateurs : tout compte devenu éditeur sans raison connue doit être examiné et son rôle rétabli.
• Vérifier les journaux d'activité et les contenus récemment modifiés ou publiés à la recherche de changements inattendus.
• En cas de compromission avérée, restaurer une sauvegarde saine antérieure à l'incident, puis changer les mots de passe des comptes concernés.

Aucune exploitation active n'est signalée dans les sources consultées, mais les failles d'élévation de privilèges des extensions WordPress sont généralement recherchées peu après leur publication. Mieux vaut traiter le sujet sans attendre.

Sources

• NVD : fiche CVE-2026-110018 (avis de référence, score CVSS 8.8).
• Wordfence Threat Intelligence : fiche de la vulnérabilité aBlocks (recoupement).