Si vous avez reçu un courriel de ma part vous renvoyant vers cette page, c’est que votre site web semble exécuter une version de Content Views – Post Grid & Filter (l’extension WordPress par Content Views / PT Guy, située dans vos fichiers à /wp-content/plugins/content-views-query-and-display-post-page/) qui se situe dans la plage de versions affectées par un problème de sécurité connu. Cette page explique en quoi consiste le problème, comment déterminer à quel point il compte pour votre site, comment lire votre version sans être induit en erreur, et comment procéder à la mise à jour.

Le problème correspond au CVE-2026-15361, une injection SQL dans la gestion de l’aperçu de l’extension. Il affecte toutes les versions antérieures à 4.5 et est corrigé dans la version 4.5, publiée le 28 juillet 2026. Si vous utilisez une version antérieure à 4.5, mettez à jour Content Views vers la version 4.5.1 ou une version ultérieure, qui est la version actuelle au moment de la rédaction (4 août 2026). Aucun score CVSS n’a été publié pour ce problème, je ne vais donc pas vous en citer un, et je n’ai connaissance d’aucun code d’exploitation public pour celui-ci.

Il n’existe aucune version plus ancienne qui soit sûre. Il ne s’agit pas d’une faille introduite au milieu de l’histoire de l’extension et corrigée par la suite. J’ai vérifié chaque étiquette de version publiée dans l’historique de l’extension, de la toute première en 2014 jusqu’à la 4.4, et le code affecté est présent dans toutes. « Mon installation est trop ancienne pour être affectée » n’est pas une échappatoire ici. Les seules versions qui ne sont pas affectées sont la 4.5 et les versions ultérieures.

Avant toute chose, la qualification qui détermine à quel point cela compte pour votre site, car je préfère l’énoncer plutôt que de laisser cet avis paraître plus grave qu’il ne l’est : cette faille ne peut être exploitée que par une personne connectée à votre site. Peu importe ce que son compte peut normalement faire, le rôle le plus bas de WordPress suffit, mais elle a besoin d’un compte. La question qui détermine votre exposition n’est donc pas un paramètre de l’extension, c’est qui peut obtenir un compte sur votre site. Je peux lire la version de votre extension à partir d’un fichier public, et je peux voir si WordPress sert sa page d’inscription standard, mais je ne peux pas voir qui détient des comptes sur votre site, cet avis est donc un avertissement de précaution plutôt qu’un constat confirmé vous concernant.

Notez ce que cette qualification n’est pas. Il n’y a aucune option à désactiver, aucune fonctionnalité à dépublier, et aucune configuration qui vous retire de la plage de risque. Le gestionnaire affecté est enregistré sur toute installation d’une version affectée, que vous ayez ou non déjà placé une grille d’articles sur une page. Si vous cherchez une case à décocher, vous n’en trouverez pas, car il n’y en a pas. La mise à jour est la correction.

Un mot sur l’urgence, car il s’agit d’un avis conditionnel. Si vous êtes la seule personne disposant d’un compte sur le site et que personne d’autre ne peut en obtenir un, la mise à jour relève de la maintenance ordinaire de l’extension. Si votre site accepte les inscriptions d’autres personnes, veuillez la traiter comme une priorité, et notez que les inscriptions prennent des formes plus nombreuses que la plus évidente : une boutique WooCommerce, une extension d’adhésion ou de forum, un blog à plusieurs auteurs, et une page d’inscription personnalisée créent tous des comptes sans que le formulaire d’inscription propre à WordPress soit jamais impliqué.

Si la page d’inscription de WordPress est bien ouverte aux visiteurs et que vous n’en avez pas besoin, la désactiver est une mesure provisoire raisonnable, car elle réduit le nombre de personnes pouvant atteindre cette faille. Veuillez toutefois ne pas y voir un blanc-seing. Fermer l’inscription ne ferme qu’une des plusieurs portes menant à un compte, et cela ne change rien aux comptes qui existent déjà. C’est la mise à jour de l’extension qui supprime réellement le problème.

Il vaut aussi la peine d’être précis sur ce que ce problème est et n’est pas. Il permet à une personne disposant d’un compte à faibles privilèges de lire des données de la base de données de votre site que son compte ne devrait pas pouvoir voir. Cela mérite d’être corrigé, car une base de données WordPress contient des éléments tels que les adresses e-mail des utilisateurs et les mots de passe hachés, et sur certains sites des fiches de membres ou de clients. Mais ce n’est pas une prise de contrôle administrateur, ce n’est pas un moyen pour quelqu’un de s’octroyer un compte administrateur, et ce n’est pas une exécution de code à distance. C’est plus restreint que les problèmes de compromission totale dont je parle ailleurs, et je préfère présenter honnêtement l’ampleur du problème plutôt que de vous laisser une impression plus alarmante que ce que les faits ne justifient.

Il s’agit d’une faille de l’extension, et non du noyau de WordPress. Un WordPress entièrement à jour ne vous protège pas si l’extension Content Views elle-même est sur une version affectée.

Ce message est-il légitime ?

Oui. Il s’agit d’un avis de divulgation responsable et de bonne foi émis par un chercheur en sécurité indépendant. Je ne vous demande pas d’argent, de mots de passe ou d’accès à votre site, et je n’ai pas tenté de pénétrer dans votre site, de m’y inscrire, ou d’exploiter quoi que ce soit.

Tout ce que j’ai fait, c’est examiner des pages et des fichiers que votre site web sert à chaque visiteur (de la même manière que votre page d’accueil est publique) et noter le numéro de version que l’extension publie. L’une des pages que j’ai lues était la page d’inscription standard de WordPress de votre site, pour voir si elle est ouverte aux visiteurs, et la lire est tout ce que j’ai fait avec. Je n’ai spécifiquement pas soumis ce formulaire, je n’ai pas créé de compte, je ne me suis pas connecté, et je n’ai rien envoyé à la fonctionnalité affectée. Rien dans cette vérification ne touche vos données, votre espace d’administration ou toute partie privée de votre site (plus de détails sous Ce que j’ai fait et n’ai pas fait ci-dessous).

Si vous souhaitez vérifier qui je suis, consultez les coordonnées en bas de cette page et la page À propos.

Pourquoi cela compte

Content Views construit des grilles, des listes et des carrousels d’articles sur votre site, afin que vous puissiez afficher une sélection filtrée d’articles ou de pages sans écrire de code. Une partie de son fonctionnement repose sur un gestionnaire de requêtes qui affiche un aperçu d’une grille à partir des paramètres qui lui sont fournis.

Dans les versions affectées, ce gestionnaire vérifie un jeton de sécurité et s’arrête là. Il ne vérifie jamais si la personne qui envoie la requête est autorisée à l’utiliser, et le jeton en question n’est pas un secret : l’extension le publie à chaque visiteur du site. Le gestionnaire construit ensuite une requête de base de données à partir de paramètres pris directement dans la requête. La conséquence est qu’une personne ne disposant de rien de plus que le compte le moins privilégié de votre site peut orienter cette requête et lire, dans votre base de données, des données que son compte n’a aucune raison de voir.

La précondition, à répéter car c’est la partie la plus susceptible d’être mal comprise dans un sens comme dans l’autre : un compte, pas une configuration. Rien n’a besoin d’être activé pour que le gestionnaire soit atteignable, et aucun paramètre ne retire une version affectée de la plage de risque. Ce qui sépare une installation affectée de ce problème est simplement de savoir si quelqu’un d’autre que vous peut se connecter. Sur un site où n’importe qui peut s’inscrire, ce n’est pas une barrière importante. Sur un site où vous êtes le seul utilisateur, c’en est une réelle.

Et l’inverse, qui compte tout autant : un site dont le formulaire d’inscription de WordPress est fermé n’est pas pour autant sûr. Les comptes arrivent par de nombreuses voies, et n’importe laquelle suffit.

Je décris cela au niveau dont un propriétaire de site a besoin pour agir, et pas davantage. Je ne publie pas les détails qui permettraient à quelqu’un de le reproduire, et je vous demande de ne pas essayer contre votre propre site ou celui de quelqu’un d’autre. Lire votre numéro de version, comme décrit ci-dessous, vous donne tout ce dont vous avez besoin pour décider quoi faire.

Si mon courriel a cité ce problème, cela signifie que la version que votre site indique est antérieure à 4.5. Je n’ai pas testé si votre site en particulier est exploitable, et je ne peux pas voir qui possède des comptes dessus. Tout ce que j’ai observé, c’est la version, et si votre page d’inscription est servie aux visiteurs.

Suis-je concerné ?

Tout se résume à une seule question : quelle version de Content Views utilisez-vous ?

Un mot rapide sur l’identité de cette extension, car le nom est partagé. Cet avis concerne l’extension gratuite publiée sur WordPress.org, celle dont le dossier est content-views-query-and-display-post-page. Le même éditeur vend également une gamme Pro distincte. Si votre dossier d’extension est celui-ci, poursuivez votre lecture.

Depuis l’administration WordPress (faisant foi) :

  1. Connectez-vous à votre tableau de bord WordPress (généralement à yourdomain.com/wp-admin).
  2. Allez dans Extensions puis Extensions installées.
  3. Trouvez Content Views – Post Grid & Filter, l’entrée dont le dossier est content-views-query-and-display-post-page, et notez la version affichée sous son nom.

Depuis le manifeste public (aucune connexion requise) : ouvrez

yourdomain.com/wp-content/plugins/content-views-query-and-display-post-page/README.txt

dans un navigateur, et lisez la ligne Stable tag: près du haut. C’est l’une des deux sources publiques que j’ai lues.

Faites attention aux majuscules dans ce nom de fichier. Les extensions WordPress livrent conventionnellement un readme.txt en minuscules, et c’est l’URL que la plupart des gens tapent par habitude. Les paquets 4.x de cette extension livrent le fichier sous le nom README.txt en majuscules, donc sur un hébergeur sensible à la casse, l’adresse en minuscules renvoie une erreur 404 et cela donne l’impression que le fichier n’existe pas. Il existe bel et bien. Essayez l’orthographe en majuscules avant de conclure quoi que ce soit.

Depuis le code source de votre page (aucune connexion requise) : affichez le code source de votre page d’accueil et recherchez les propres ressources frontales de l’extension à exactement ces chemins :

/wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js?ver=...
/wp-content/plugins/content-views-query-and-display-post-page/public/assets/css/cv.css?ver=...

Le numéro ?ver= attaché à ces fichiers est la version propre de l’extension. Sur une installation par défaut, ils se chargent sur chaque page frontale, qu’une grille d’articles y apparaisse ou non, donc votre page d’accueil suffit généralement. Sur les installations très anciennes, ces deux mêmes fichiers sont nommés public.js et public.css, et la même règle s’applique à eux.

Le piège à éviter ici, et il est facile d’y tomber. Cette extension embarque des copies groupées de plusieurs bibliothèques tierces à l’intérieur de son propre dossier d’extension, et chacune d’elles porte son propre numéro de version, entièrement sans rapport. Le code source de votre page peut afficher Bootstrap en 3.3.5 ou 3.3.0, Select2 en 3.4.5, html5shiv en 3.7.0, respond.js en 1.4.2, et bootstrap-paginator en 0.5, tous sur des chemins qui commencent par le dossier de l’extension Content Views. Un exploitant qui recherche le dossier de l’extension dans le code source de la page et lit la première valeur ?ver= qui apparaît peut facilement finir par croire que l’extension est en « 3.3.5 », puis se demander comment cela se compare à la 4.5. Cela ne se compare pas du tout. Un numéro comme 3.3.5 ou 0.5 situé sur un chemin bootstrap ou select2 est la version d’un tout autre logiciel. Ne lisez la version que sur cv.js ou cv.css (ou public.js / public.css sur une installation très ancienne), et ignorez tout autre ?ver= présent sur la page.

Si vous ne parvenez pas du tout à obtenir un numéro lisible dans le code source de la page, c’est fréquent et ce n’est le signe de rien de particulier : les extensions de cache et d’optimisation suppriment régulièrement la valeur ?ver= des URL de ressources, ou regroupent les fichiers en un script combiné. Dans ce cas, le README.txt est la lecture publique fiable, et l’écran d’administration de la première vérification a toujours la réponse.

Appliquez ensuite cette règle, en notant que les versions se comparent numériquement, et non alphabétiquement, de sorte que 4.10 serait plus récente que 4.9 même si cela paraît plus petit sous forme de texte :

  • Toute version antérieure à 4.5 : affectée. Mettez à jour. Il n’existe aucun seuil en dessous duquel une version plus ancienne redevient sûre.
  • 4.5 ou plus récente : déjà corrigée en ce qui concerne ce problème. La version actuelle au moment de la rédaction est 4.5.1, et prendre la dernière version disponible est le meilleur choix.

Comment mettre à jour

L’extension est gratuite, toujours publiée et activement maintenue, la correction consiste donc en une mise à jour normale. La méthode la plus sûre est d’effectuer la mise à jour via WordPress lui-même, après avoir d’abord réalisé une sauvegarde :

  1. Sauvegardez votre site (fichiers et base de données) avant d’apporter des modifications. La plupart des hébergeurs proposent des sauvegardes en un clic, ou vous pouvez utiliser une extension de sauvegarde WordPress.
  2. Dans l’administration WordPress, accédez à Tableau de bord puis Mises à jour, ou à Extensions puis Extensions installées. Si une mise à jour de Content Views est indiquée, installez-la depuis cet emplacement.
  3. Si vous préférez utiliser la ligne de commande, WP-CLI effectue la même opération : wp plugin update content-views-query-and-display-post-page (la commande utilise le nom du dossier, pas le nom affiché).
  4. Si aucune mise à jour n’apparaît, vous pouvez télécharger la dernière version directement depuis la page de l’extension sur le répertoire WordPress.org, Content Views – Post Grid & Filter, et procéder à la mise à jour via Extensions puis Ajouter une extension puis Téléverser une extension.
  5. Après la mise à jour, confirmez le nouveau numéro de version (4.5.1 ou ultérieur) à l’aide des étapes ci-dessus, et vérifiez que vos grilles d’articles et tout filtre associé s’affichent toujours normalement.

Pendant que vous y êtes, il est utile de confirmer que le noyau WordPress et vos autres extensions sont à jour, car le même principe s’applique à toutes.

Après la mise à jour

La mise à jour vers la version 4.5.1 ou ultérieure résout le problème, et pour la plupart des sites, cela constitue la totalité de la tâche. Cette page est un avis de précaution, et non un rapport d’incident : je n’ai aucune visibilité sur ce qui aurait pu se produire sur votre site, et je ne l’ai pas vérifié.

Deux petites choses valent la peine d’être faites pendant que la mise à jour est récente :

  • Confirmez que la version a bien changé, en utilisant celle des vérifications ci-dessus qui vous semble la plus simple, et chargez une page qui affiche une de vos grilles d’articles pour vous assurer qu’elle s’affiche toujours correctement.
  • Si vous aviez l’inscription WordPress ouverte et que vous n’en avez pas besoin, envisagez de la fermer. C’est une mesure d’hygiène générale plutôt qu’une correction de ce problème, qui a déjà été traité par la mise à jour, et il vaut la peine de se rappeler que d’autres extensions de votre site peuvent malgré tout créer des comptes.

Vous remarquerez qu’il n’y a pas de liste de vérification « supposez que vous avez été compromis » sur cette page, et c’est délibéré, non un oubli. Ce que ce problème produit est une lecture de base de données atteignable depuis un compte à faibles privilèges. Cela ne donne à personne un compte administrateur et cela n’exécute pas de code sur votre serveur, donc l’audit administrateur et l’exercice de rotation des mots de passe que je recommande après une faille de type prise de contrôle ne seraient pas proportionnés ici. Mettez à jour, confirmez, et poursuivez.

Ce que j’ai fait et n’ai pas fait

Pour être entièrement transparent sur la vérification qui a précédé mon courriel, en voici l’intégralité. J’ai lu des pages et des fichiers que votre site sert déjà à chaque visiteur :

  • votre page d’accueil, et les adresses de ressources qui y sont inscrites ;
  • le README.txt public de l’extension, à l’intérieur de wp-content/plugins/content-views-query-and-display-post-page/ ;
  • la page d’inscription standard de WordPress de votre site, à /wp-login.php?action=register, pour voir si elle est ouverte aux visiteurs. C’est une page publiée, et la lire est tout ce que j’ai fait.

Je n’ai pas soumis ce formulaire d’inscription, je n’ai pas créé de compte, et je ne me suis pas connecté à votre site. Je n’ai rien envoyé à la fonctionnalité affectée. Ce dernier point est celui sur lequel je tiens à être le plus clair : le problème est un point d’injection SQL, et envoyer une charge utile vers la base de données de quelqu’un d’autre n’est pas quelque chose que ce projet fait, que ce soit en laboratoire ou en production. Rien n’a été soumis, testé ou exploité, et rien n’a touché votre espace d’administration WordPress, votre base de données, ou toute partie privée du site.

Je m’abstiens également, délibérément, de publier les détails qui aideraient quelqu’un à agir sur ce problème. La description ci-dessus s’arrête au niveau dont un propriétaire de site a besoin, et je ne lie aucun code de preuve de concept.

Il s’agit d’une observation basée sur la version : votre site indique une version antérieure à 4.5. Ce n’est pas une affirmation selon laquelle votre site était exploitable au moment de ma vérification. Comme l’exploitation de ce problème nécessite que quelqu’un soit connecté, et que je ne peux pas voir qui détient des comptes sur votre site, un site dans la plage affectée peut très bien ne pas être exposé du tout, et un site dans cette plage peut par ailleurs être protégé par d’autres moyens tels qu’un pare-feu applicatif web ou un correctif rétroporté.

Je n’ai pas de webmestre / je suis bloqué

Si vous n’êtes pas la personne qui maintient le site, veuillez transférer cette page à celle qui s’en charge (votre développeur web, votre agence ou votre hébergeur). Elle reconnaîtra rapidement les étapes ci-dessus.

Si vous maintenez le site vous-même et que vous êtes bloqué, je suis heureux de vous aider à vous orienter dans la bonne direction, sans frais. Contactez-moi en utilisant les coordonnées ci-dessous.

Contact

Evan Harris, chercheur en sécurité

Je prends contact au sujet de ce genre de problème uniquement pour aider les exploitants à sécuriser leurs sites. Si vous préférez ne plus être contacté, faites-le-moi simplement savoir et je le respecterai.

Références

Avis officiels et suivi

Éditeur / extension