Si vous avez reçu de ma part un courriel renvoyant vers cette page, c’est parce que votre site semble utiliser une version de Link Library (l’extension WordPress de Yannick Lefebvre, qui se trouve dans vos fichiers sous /wp-content/plugins/link-library/) qui entre dans la plage concernée par un problème de sécurité connu. Cette page explique en quoi consiste ce problème, comment vérifier quelle version vous utilisez, comment mettre à jour et quoi faire ensuite.

Le problème est CVE-2026-16532, une faille d’injection SQL exploitable sans authentification, atteignable via le traitement des propositions de liens de l’extension. Elle concerne toutes les versions antérieures à la 7.9.3 et elle est corrigée dans la 7.9.3. La version courante au moment où j’écris est la 7.9.4, qui porte également le correctif. Si vous utilisez une version plus ancienne que la 7.9.3, mettez Link Library à jour vers la 7.9.3 ou une version ultérieure.

Un point mérite d’être posé clairement : il n’existe aucune version ancienne qui soit saine. Il ne s’agit pas d’une faille introduite à un moment de l’histoire de l’extension puis corrigée. Le code vulnérable est présent dans toutes les versions publiées que j’ai pu examiner, jusqu’à la plus ancienne que le répertoire WordPress.org distribue encore. « Mon installation est trop ancienne pour être concernée » n’est pas une issue ici. Les seules versions non concernées sont la 7.9.3 et les suivantes.

Tout aussi important : cet avis ne dépend pas de la façon dont votre site est configuré. Link Library comprend un formulaire qui permet aux visiteurs de proposer des liens, et l’hypothèse naturelle est qu’un site n’est exposé que s’il a effectivement placé ce formulaire sur une page quelque part. Cette hypothèse est fausse. Le code concerné s’exécute à chaque requête ordinaire côté public, que vous ayez publié le formulaire de proposition ou non, et les réglages par défaut de l’extension ne l’empêchent pas. Si votre site utilise une version concernée, elle est atteignable. Point final.

Il s’agit d’une faille de l’extension, et non du noyau WordPress. Un WordPress parfaitement à jour ne vous protège pas si l’extension Link Library elle-même est dans une version concernée.

Ce message est-il légitime ?

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

Je me suis contenté de consulter des fichiers publics que votre site sert à tout visiteur (de la même manière que votre page d’accueil est publique) et de relever le numéro de version que publie l’extension. Je n’ai en particulier rien soumis à la fonctionnalité de proposition de liens de l’extension, ni sur votre site ni sur aucun autre, et rien dans cette vérification ne touche à vos données, à votre espace d’administration ni à aucune 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, voyez les coordonnées au bas de cette page et la page À propos.

Pourquoi cela compte

Link Library construit et affiche des répertoires de liens sur votre site, et elle peut accepter des propositions de liens de la part des visiteurs. C’est dans le traitement de ces propositions que se loge ce problème.

Dans les versions concernées, lorsque l’extension traite un lien proposé, sa vérification de l’existence éventuelle de ce lien construit une requête de base de données en y collant directement les valeurs soumises. Ces valeurs sont nettoyées pour l’affichage, mais elles ne sont pas échappées pour un usage en SQL, et la requête s’exécute sans instruction préparée. La conséquence est qu’un visiteur non connecté peut modifier cette requête et lire des données dans la base de votre site. La version 7.9.3 réécrit la requête sous forme d’instruction préparée, ce qui ferme le problème.

Pour répéter le point énoncé en haut de page, car c’est celui qui risque le plus de donner un faux sentiment de sécurité : l’exposition ne dépend pas de la publication du formulaire de proposition où que ce soit sur votre site. Le chemin de code qui traite les propositions écoute à chaque requête côté public, et tout ce dont une requête a besoin pour l’atteindre peut être obtenu depuis l’extension elle-même, sans qu’aucun formulaire existe sur aucune page. Savoir si votre site est exposé tient à une seule chose : la version que vous utilisez.

Il vaut aussi la peine d’être précis sur ce que ce problème est et n’est pas. Il permet à un attaquant de lire des données de la base. C’est grave en soi, puisqu’une base WordPress contient des choses comme les adresses électroniques des comptes et les empreintes de leurs mots de passe, et sur certains sites des dossiers de clients ou de membres. Mais ce n’est pas, en soi, une exécution de code à distance, une prise de contrôle du site, ni un moyen pour un attaquant de s’octroyer un compte administrateur. C’est plus étroit que les compromissions totales dont je parle ailleurs, et je préfère fixer l’ampleur honnêtement plutôt que de vous laisser une impression plus alarmante que les faits ne le justifient.

Je décris tout ceci au niveau dont un propriétaire de site a besoin pour agir, et pas au-delà. Je ne publie pas les détails qui permettraient à quelqu’un de reproduire la faille, et je vous demande de ne pas l’essayer contre votre propre site ni contre celui d’autrui. Lire votre numéro de version, comme décrit ci-dessous, vous dit tout ce dont vous avez besoin pour décider quoi faire.

Si mon courriel citait ce problème, cela signifie que la version annoncée par votre site est plus ancienne que la 7.9.3. Je n’ai pas testé si votre site en particulier était exploitable ; tout ce que j’ai observé, c’est la version.

Suis-je concerné ?

Tout tient à une question : quelle version de Link Library utilisez-vous ?

Depuis l’espace d’administration WordPress (source faisant foi) :

  1. Connectez-vous à votre tableau de bord WordPress (généralement votredomaine.fr/wp-admin).
  2. Allez dans Extensions puis Extensions installées.
  3. Repérez Link Library, l’entrée dont le dossier est link-library, et notez la version affichée sous son nom.

Depuis le manifeste public (sans connexion) : ouvrez votredomaine.fr/wp-content/plugins/link-library/readme.txt dans un navigateur. La ligne Stable tag:, près du début, indique la version annoncée par votre installation : c’est ce même fichier public que j’ai lu. Pour cette extension, j’ai vérifié qu’elle correspond au code réellement publié dans toutes les versions récentes, c’est donc une vérification fiable.

Une vérification qui ne fonctionne pas pour cette extension, merci donc de ne pas vous y fier. Si vous avez l’habitude de lire les versions d’extensions dans le numéro ?ver= accolé à un script ou à une feuille de style dans le code source de vos pages, cela vous induira en erreur ici. Les numéros de version portés par les URL des ressources de cette extension sont les versions figées de bibliothèques tierces incluses (des valeurs comme 4.0.1, 1.0.0 ou 1.3.9), ou bien la version du noyau WordPress. Aucun d’eux n’est la version de l’extension, et comparer l’un quelconque d’entre eux à la 7.9.3 n’a aucun sens. Utilisez l’écran d’administration ou readme.txt.

Un dernier cas particulier : certaines installations très anciennes affichent Stable tag: trunk dans leur readme.txt. Ce n’est pas du tout un numéro de version. Si vous le voyez, utilisez plutôt l’écran des extensions de l’administration, et considérez l’installation comme concernée jusqu’à preuve du contraire par cet écran, car une installation assez ancienne pour indiquer trunk est à coup sûr plus ancienne que la 7.9.3.

Appliquez ensuite cette règle :

  • Toute version plus ancienne que la 7.9.3 : concernée. Mettez à jour. Il n’y a pas de seuil en dessous duquel une version plus ancienne redeviendrait saine.
  • 7.9.3 ou plus récente : déjà corrigée. La 7.9.4, version courante, porte aussi le correctif.

Comment mettre à jour

L’extension est gratuite, toujours publiée et activement maintenue : le correctif s’obtient donc par une mise à jour ordinaire. La voie la plus sûre est de mettre à jour depuis WordPress lui-même, après avoir fait une sauvegarde :

  1. Sauvegardez votre site (fichiers et base de données) avant toute modification. La plupart des hébergeurs proposent des sauvegardes en un clic, sinon utilisez une extension de sauvegarde WordPress.
  2. Dans l’administration WordPress, allez dans Tableau de bord puis Mises à jour, ou dans Extensions puis Extensions installées. Si une mise à jour de Link Library est proposée, installez-la depuis là.
  3. Si vous préférez la ligne de commande, WP-CLI fait la même chose : wp plugin update link-library.
  4. Si aucune mise à jour n’apparaît, vous pouvez récupérer la dernière version directement depuis la page de l’extension dans le répertoire WordPress.org, Link Library, et mettre à 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 (7.9.3 ou ultérieure) en suivant les étapes ci-dessus, et vérifiez que vos répertoires de liens s’affichent et se comportent toujours normalement.

Pendant que vous y êtes, il vaut la peine de confirmer que le noyau WordPress et vos autres extensions sont à jour, car le même principe vaut pour tous.

Après la mise à jour

Passer à la 7.9.3 ou à une version ultérieure ferme le problème : la vérification des propositions s’exécute désormais comme une instruction préparée, si bien que les valeurs soumises sont traitées comme des données et non comme une partie de la requête.

Ce que la mise à jour ne peut pas faire, formulé avec soin. La mise à jour empêche toute lecture future de votre base de données. Elle ne peut pas « dé-lire » ce qui aurait déjà pu être lu pendant que le site utilisait une version concernée. Je n’ai aucune visibilité sur ce qui s’est produit ou non sur votre site, et je n’ai pas regardé ; la plupart des sites dans la plage concernée n’ont probablement jamais été inquiétés. Mais comme je ne peux pas vous l’affirmer avec certitude, un peu de précaution est raisonnable, en proportion de ce que contient votre base de données :

  • Si votre site est un site de publication simple, dont la base contient vos articles, vos pages et une poignée de comptes, la mesure sensée est de faire changer leur mot de passe à vos utilisateurs (et surtout à vos administrateurs). WordPress enregistre les mots de passe sous forme d’empreintes et non en clair, mais les empreintes de mots de passe faibles peuvent être cassées hors ligne : un mot de passe neuf écarte donc ce souci.
  • Si votre site conserve des éléments plus sensibles (dossiers de membres, données de clients, clés d’API ou autres identifiants gardés par des extensions), considérez qu’ils méritent eux aussi d’être renouvelés.
  • Régénérer les clés secrètes et « salts » de WordPress dans wp-config.php (de nouvelles valeurs sont à un clic sur le générateur officiel) déconnecte tous les utilisateurs une fois et invalide tout jeton de session dérobé.

Pour être clair sur le cadrage : il s’agit d’une précaution, et non d’une déclaration que vos données ont été prises. Cet avis se fonde sur un numéro de version, et non sur la moindre preuve d’une attaque.

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

Pour être parfaitement transparent sur la vérification à l’origine de mon courriel : je n’ai lu que des fichiers publics que votre site sert déjà à tout visiteur, précisément le readme.txt public de l’extension et votre page d’accueil. Je n’ai pas accédé à votre espace d’administration WordPress, à votre base de données, ni à aucune partie privée du site.

En particulier, je n’ai jamais rien soumis à la fonctionnalité de proposition de liens de l’extension, ni sur votre site ni ailleurs. Rien n’a été soumis, enregistré, testé ni exploité. Cela compte davantage ici que sur la plupart de ces pages, car le traitement des propositions est précisément l’objet de ce problème : « je n’y ai pas touché » fait toute la différence entre une divulgation et une intrusion.

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 renvoie vers aucun code de démonstration.

Il s’agit d’une observation fondée sur la version : votre site annonce une version plus ancienne que la 7.9.3. Un site dans cette plage peut déjà être protégé par d’autres moyens, comme un pare-feu applicatif web ou un correctif rétroporté. Cet avis n’affirme pas que votre site était exploitable au moment où je l’ai vérifié.

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

Si vous n’êtes pas la personne qui maintient le site, transmettez cette page à celle qui s’en charge (votre développeur, votre agence ou votre hébergeur). Ces étapes lui parleront immédiatement.

Si vous maintenez le site vous-même et que vous êtes bloqué, je vous oriente volontiers, gratuitement. Écrivez-moi via 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é, dites-le-moi simplement et je le respecterai.

Références

Avis officiels et suivi

Éditeur / extension