Article mis à jour le 29 juillet 2026.
Complianz, un plugin installé sur plus d’un million de sites
Complianz – GDPR/CCPA Cookie Consent est l’une des extensions WordPress les plus utilisées pour gérer le consentement aux cookies et aux différents services tiers. La fiche officielle de Complianz sur WordPress.org indique plus d’un million d’installations actives.
Le plugin permet d’afficher une bannière de consentement, de conserver le choix de l’internaute et de bloquer certains contenus avant son accord. Il peut notamment empêcher le chargement immédiat de Google Analytics, de Google Maps, de vidéos YouTube, de publicités ou de tout autre service susceptible de déposer des cookies.
Complianz propose également des intégrations avec des outils très répandus tels que WooCommerce, Google Tag Manager, Matomo, Divi, Elementor ou Contact Form 7.
Lorsqu’une vulnérabilité touche une extension aussi répandue, elle concerne potentiellement un nombre très important de sites. Cela ne signifie cependant pas que tous ces sites peuvent être piratés automatiquement. Le niveau de risque dépend de la nature de chaque faille et des conditions nécessaires à son exploitation.
Trois vulnérabilités publiées en juillet 2026
Trois vulnérabilités affectant Complianz ont été rendues publiques le 22 juillet 2026 par Patchstack. Elles ont ensuite été enregistrées dans le système international CVE, qui attribue un identifiant unique aux vulnérabilités informatiques rendues publiques.
La première, référencée sous le numéro CVE-2026-65497, concerne une injection d’objet PHP. La deuxième, CVE-2026-65496, est une requête serveur forcée, généralement appelée SSRF. La troisième, CVE-2026-65498, concerne une exposition d’informations potentiellement sensibles.
Le sigle CVE signifie Common Vulnerabilities and Exposures. L’identifiant ne constitue pas lui-même une alerte ou une évaluation du danger. Il sert avant tout à permettre aux chercheurs, aux éditeurs de logiciels et aux professionnels de la sécurité de parler de la même vulnérabilité sans ambiguïté.
Les fiches publiées dans la base américaine NVD reprennent les informations transmises par Patchstack. Elles indiquaient initialement que les versions de Complianz allant jusqu’à la version 7.5.0 étaient concernées. Patchstack et Wordfence ont ensuite actualisé leurs propres fiches pour inclure également la version 7.5.1.
Wordfence signale également les trois vulnérabilités
Les vulnérabilités ne sont pas uniquement répertoriées par Patchstack. Elles apparaissent également dans la base de données de Wordfence Intelligence, le service de veille de sécurité de Wordfence.
Wordfence indique que les versions de Complianz allant jusqu’à la version 7.5.1 incluse sont concernées et qu’aucun correctif connu n’est encore disponible. La base Wordfence attribue un score de 6,6 sur 10 à l’injection d’objet PHP, un score de 6,4 à la SSRF et un score de 5,3 à l’exposition d’informations.
Les trois fiches peuvent être consultées directement sur le site de Wordfence : l’injection d’objet PHP nécessitant un compte administrateur, la faille SSRF accessible à partir du rôle auteur et l’exposition d’informations ne nécessitant aucune authentification.
Wordfence ne présente donc pas la situation comme une prise de contrôle immédiate de tous les sites utilisant Complianz. Ses fiches permettent toutefois de confirmer que la dernière version disponible au 29 juillet 2026 reste considérée comme vulnérable.
Une injection d’objet PHP accessible aux administrateurs
La vulnérabilité la plus sévèrement évaluée est référencée sous le numéro CVE-2026-65497. Elle concerne la manière dont Complianz traite certaines données PHP.
Pour conserver ou transmettre des informations complexes, PHP peut transformer un objet en une suite de données enregistrables. Cette opération est appelée la sérialisation. Lorsque le programme relit ensuite ces données pour reconstituer l’objet d’origine, il effectue une désérialisation.
Le problème apparaît lorsqu’un utilisateur peut modifier les données qui seront désérialisées. Il peut alors tenter de faire reconstruire par le serveur un objet différent de celui qui était prévu. C’est ce que l’on appelle une injection d’objet PHP.
Cette injection ne permet pas systématiquement d’exécuter une action dangereuse. Pour y parvenir, l’attaquant doit généralement trouver dans le code du site une succession de fonctions qu’il pourra détourner. Cette succession est appelée une chaîne POP, pour Property-Oriented Programming.
Pour un non-spécialiste, on peut comparer une chaîne POP à un enchaînement de dominos déjà présents dans le code. Chaque domino correspond à une fonction parfaitement normale d’un plugin ou d’un thème. Utilisées séparément, ces fonctions ne sont pas dangereuses. Mais si un attaquant réussit à les déclencher dans un ordre précis, la première fonction peut appeler la suivante, puis une autre, jusqu’à provoquer une action qui n’était pas prévue.
Cette action pourrait, selon les composants présents sur le site, permettre de lire des informations, de supprimer un fichier ou d’exécuter du code sur le serveur. L’injection d’objet fournit donc le moyen de déclencher la chaîne, mais elle ne crée pas elle-même les fonctions nécessaires à l’attaque.
La fiche publiée par Wordfence précise qu’aucune chaîne POP directement exploitable n’a été identifiée dans Complianz. Une attaque plus grave nécessiterait donc qu’une chaîne utilisable soit présente dans un autre plugin ou dans le thème installé sur le site.
L’exploitation de cette vulnérabilité exige également de disposer d’un compte administrateur WordPress. Elle ne peut pas être déclenchée par un simple visiteur ni par un abonné.
Un administrateur possède déjà des droits particulièrement élevés. Il peut généralement installer une extension, modifier la configuration du site, créer d’autres comptes ou accéder à de nombreuses informations. La vulnérabilité reste néanmoins importante, car un compte administrateur compromis pourrait s’en servir pour tenter d’agir au-delà du fonctionnement habituel de WordPress, notamment au niveau du serveur.
La fiche Patchstack consacrée à l’injection d’objet PHP lui attribue un score CVSS de 7,2 et la classe malgré tout en priorité faible, en raison des privilèges nécessaires et de l’absence de chaîne POP connue. Wordfence lui attribue pour sa part un score de 6,6.
Une faille SSRF accessible aux auteurs
La deuxième vulnérabilité, CVE-2026-65496, est une faille de type SSRF, abréviation de Server-Side Request Forgery.
En temps normal, lorsqu’un internaute consulte un site, son navigateur adresse directement des requêtes aux ressources dont il a besoin. Dans le cas d’une SSRF, un attaquant parvient à demander au serveur du site d’effectuer lui-même une requête vers une adresse choisie.
Le serveur peut parfois accéder à des ressources qui ne sont pas directement visibles depuis Internet. Il peut s’agir d’un service interne, d’une interface technique, d’une adresse locale ou de certaines informations liées à l’hébergement. Une SSRF peut donc servir à interroger des zones qui devraient normalement rester inaccessibles à un visiteur extérieur.
Dans le cas de Complianz, l’exploitation nécessite au minimum un compte WordPress disposant du rôle d’auteur. Là encore, la faille n’est pas directement exploitable par n’importe quel internaute.
Elle mérite davantage d’attention sur les sites qui permettent à plusieurs personnes de publier du contenu. Cela peut concerner un magazine collaboratif, un site d’actualité, une association donnant un accès à plusieurs rédacteurs ou un site sur lequel des intervenants extérieurs disposent de leur propre compte.
La fiche Wordfence consacrée à cette SSRF lui attribue un score CVSS de 6,4 et indique que toutes les versions allant jusqu’à la version 7.5.1 incluse sont concernées.
Une exposition d’informations sans authentification
La troisième vulnérabilité est référencée sous le numéro CVE-2026-65498. Elle peut permettre à un visiteur non connecté d’accéder à des informations qui ne devraient normalement pas être rendues publiques.
Il s’agit de la seule des trois failles qui ne nécessite pas de compte WordPress. Son impact est toutefois considéré comme limité par les organismes qui l’ont analysée.
Wordfence lui attribue un score CVSS de 5,3. Sa fiche consacrée à l’exposition d’informations indique que la vulnérabilité peut permettre l’extraction de données relatives aux utilisateurs ou à la configuration du site, sans préciser publiquement la nature exacte de toutes les informations exposées.
Une exposition d’informations ne doit pas pour autant être négligée. Même lorsqu’une donnée ne permet pas directement de compromettre un site, elle peut renseigner un attaquant sur sa configuration, son fonctionnement ou les technologies qu’il utilise. Ces renseignements peuvent ensuite être combinés avec une autre vulnérabilité.
Complianz 7.5.1 ne corrige pas clairement les trois vulnérabilités
La version 7.5.1 de Complianz a été publiée le 27 juillet 2026, quelques jours après la divulgation des vulnérabilités. Son journal des modifications peut être consulté sur la fiche officielle du plugin dans le répertoire WordPress.
Le journal mentionne plusieurs corrections, dont une amélioration de sécurité concernant l’installateur de la version Premium. Cet installateur exige désormais que l’utilisateur possède le droit WordPress d’installer des extensions et limite le téléchargement des fichiers à l’API officielle de Complianz.
La mise à jour corrige également un problème lié au scanner du site, qui pouvait écrire le contenu HTML analysé dans les réglages statistiques.
Ces corrections concernent bien la sécurité du plugin. Toutefois, le journal des modifications ne présente pas explicitement la version 7.5.1 comme corrigeant les vulnérabilités CVE-2026-65496, CVE-2026-65497 et CVE-2026-65498.
Au 29 juillet 2026, Patchstack et Wordfence Intelligence considèrent toujours que la version 7.5.1 est concernée. Les fiches Wordfence indiquent expressément qu’aucun correctif connu n’est disponible.
Il serait donc incorrect d’affirmer qu’une mise à jour vers la version 7.5.1 suffit à résoudre l’alerte.
Il reste préférable d’installer cette version, car elle contient d’autres améliorations et corrections. Elle ne doit simplement pas être présentée comme le correctif définitif des trois vulnérabilités.
Faut-il désactiver Complianz ?
Une désactivation immédiate et systématique de Complianz ne paraît pas nécessaire sur tous les sites.
Pour un site vitrine correctement maintenu, administré par une ou deux personnes de confiance, sans compte auteur et sans inscription publique, les conditions nécessaires à l’exploitation des deux principales vulnérabilités réduisent fortement le risque.
La situation est différente sur un site possédant de nombreux auteurs, éditeurs ou administrateurs. Le risque augmente également lorsque des accès ont été confiés à plusieurs prestataires, lorsque des comptes ne sont plus utilisés ou lorsque certains utilisateurs disposent de droits supérieurs à leurs besoins réels.
Une désactivation temporaire ou un remplacement peut être envisagé pour un site qui traite des informations particulièrement sensibles, qui possède de nombreux contributeurs ou qui doit respecter des exigences de sécurité renforcées.
Cette décision ne doit cependant pas être prise sans examiner le rôle joué par Complianz.
Le plugin peut empêcher le chargement de services tiers avant l’accord de l’internaute. S’il est désactivé sans solution de remplacement, Google Analytics, des vidéos, des cartes, des publicités ou d’autres contenus externes pourraient se charger immédiatement.
La suppression précipitée du plugin pourrait donc réduire un risque de sécurité tout en créant un problème en matière de consentement et de protection des données.
Avant une désactivation, il est nécessaire de vérifier quels scripts sont réellement bloqués par Complianz. Il faut ensuite les désactiver provisoirement, mettre en place un autre outil de consentement ou prévoir un blocage manuel. Toute modification devrait être testée sur un environnement de préproduction avant d’être appliquée au site public.
Vérifier et réduire les droits des utilisateurs
La première précaution consiste à examiner les comptes enregistrés dans WordPress.
Les comptes d’anciens collaborateurs ou prestataires doivent être supprimés lorsqu’ils ne sont plus nécessaires. Les utilisateurs disposant de droits trop élevés doivent être rétrogradés vers un rôle correspondant réellement à leurs besoins.
Une personne chargée de modifier des pages n’a généralement pas besoin d’être administratrice. De même, un intervenant qui ne publie plus d’articles ne devrait pas conserver indéfiniment un compte auteur.
Cette vérification est particulièrement importante dans le cas présent puisque deux des vulnérabilités nécessitent précisément un compte doté de privilèges particuliers.
Chaque utilisateur devrait disposer de son propre compte. Les comptes partagés rendent plus difficile l’identification d’une connexion anormale et empêchent de savoir qui a réalisé une action.
Protéger les comptes administrateurs
Les comptes administrateurs doivent utiliser des mots de passe longs, uniques et impossibles à deviner. Un mot de passe déjà utilisé sur un autre site ou service représente un risque, même s’il paraît complexe.
La double authentification apporte une protection supplémentaire. Même si un attaquant obtient le mot de passe, il lui manque encore le second facteur nécessaire pour se connecter.
L’adresse électronique associée au compte administrateur doit elle aussi être correctement sécurisée. Une personne ayant accès à cette messagerie pourrait utiliser la procédure de réinitialisation du mot de passe WordPress.
Il est également utile de consulter l’historique des connexions lorsque cette fonction est disponible. Une connexion depuis un pays inhabituel, une adresse IP inconnue ou à une heure étrange peut révéler la compromission d’un compte.
Mettre à jour et nettoyer l’ensemble du site
La vulnérabilité d’injection d’objet PHP devient plus dangereuse lorsqu’une chaîne POP exploitable est présente dans un autre composant.
Il ne suffit donc pas de surveiller Complianz. WordPress, le thème actif et toutes les autres extensions doivent être maintenus à jour.
Les plugins qui ne sont plus utilisés devraient être supprimés. Une extension simplement désactivée reste présente sur le serveur. Si ses fichiers sont directement accessibles et contiennent une vulnérabilité, elle peut parfois rester exploitable.
Les thèmes inutilisés devraient également être supprimés, à l’exception éventuelle d’un thème WordPress officiel conservé pour les tests ou le dépannage.
Une attention particulière doit être portée aux extensions qui ne reçoivent plus de mises à jour ou dont l’éditeur a abandonné le développement. Elles peuvent contenir des fonctions vulnérables et fournir les éléments nécessaires à une chaîne POP.
Surveiller les modifications inhabituelles
Une compromission de compte ne provoque pas toujours un dysfonctionnement visible du site.
Il faut surveiller la création de nouveaux administrateurs, les changements de rôles, l’installation d’extensions inconnues et les modifications de fichiers PHP.
Les journaux du serveur peuvent également révéler des requêtes répétitives ou inhabituelles. Un plugin de sécurité ou le pare-feu proposé par l’hébergeur peut faciliter cette surveillance.
La présence récente d’un compte inconnu, d’une tâche planifiée inexpliquée ou d’un fichier PHP dans un répertoire où il ne devrait pas se trouver doit être examinée rapidement.
Conserver une sauvegarde réellement exploitable
Une sauvegarde récente permet de restaurer le site si une attaque entraîne la modification ou la suppression de fichiers.
Elle doit comprendre les fichiers WordPress et la base de données. Elle doit également être stockée en dehors de l’hébergement principal. Une sauvegarde conservée uniquement sur le même serveur pourrait être supprimée ou chiffrée en même temps que le site.
La simple existence d’un fichier de sauvegarde ne garantit pas qu’il soit utilisable. Il est nécessaire de vérifier régulièrement que les archives sont complètes et qu’elles peuvent être restaurées.
Surveiller la publication du correctif
Les prochaines versions de Complianz devront être examinées attentivement.
La version réellement corrective sera celle que l’éditeur ou les bases de vulnérabilités identifieront explicitement comme résolvant les trois CVE. La simple présence du mot « sécurité » dans le journal des modifications ne suffira pas, car une mise à jour peut corriger un autre problème sans traiter les vulnérabilités concernées.
En attendant ce correctif, la meilleure protection repose sur la limitation des comptes utilisateurs, la sécurisation des administrateurs, la mise à jour de l’ensemble du site, la surveillance des comportements inhabituels et la conservation de sauvegardes fiables.
Pour la majorité des sites vitrines correctement sécurisés, Complianz peut donc rester actif. Une désactivation temporaire se justifie surtout lorsque le site comporte de nombreux comptes, traite des données sensibles ou ne permet pas de réduire rapidement les risques liés aux utilisateurs.
