WordPress corrige une vulnérabilité de sécurité de gravité critique

WordPress a corrigé ce qu’il a décrit comme une vulnérabilité de sécurité de gravité critique qui permettrait à un attaquant non authentifié de bénéficier de capacités complètes d’exécution de code à distance (RCE). Des attaques dans la nature ont déjà été signalées.

Compte tenu de sa popularité, WordPress a été fréquemment attaqué et a corrigé un autre bug de gravité maximale autorisant le RCE en juillet. WordPress a déclaré que la faille actuelle, identifiée comme CVE-2026-87902, avait été découverte et signalée à l’entreprise par le chercheur en sécurité basé en Suisse, Robert Ressl.

Le message annonçant la version de sécurité de WordPress 7.1.2 indiquait que le correctif résolvait un problème dans lequel « un attaquant non authentifié peut, sous certaines conditions, faire en sorte que la résolution du modèle de page inclue un fichier PHP local lisible choisi en dehors des répertoires de thème actif. Si les conditions préalables pertinentes pour l’environnement du serveur et le thème actif sont remplies, cela peut conduire à l’exécution de code à distance (RCE). »

Il a exhorté les utilisateurs à mettre à jour leurs sites immédiatement et a déclaré que le correctif avait été rétroporté jusqu’à la version 4.7, car le trou affecte également de nombreuses anciennes versions de WordPress.

Noah Kenney, consultant principal chez Digital 520, a déclaré que sa principale préoccupation était l’ampleur des dégâts qu’un attaquant pourrait infliger avec ce trou.

« Une fois que les attaquants ont exécuté PHP, ils peuvent lire, obtenir les informations d’identification de la base de données et les clés d’authentification, créer des comptes d’administrateur, modifier les formulaires de paiement ou de capture de prospects, rediriger les visiteurs et installer du code persistant », a-t-il déclaré. « La partie la moins évidente est de savoir comment ils y parviennent. est un outil de gestion de paquets PHP légitime, mais les attaquants peuvent abuser de ses commandes de configuration pour écrire le contenu de leur choix sur le disque. Les attaques actuelles l’utilisent pour placer du PHP malveillant dans , puis utilisent la faille WordPress pour charger et exécuter ce fichier. Une équipe de sécurité surveillant uniquement les modifications du répertoire WordPress pourrait complètement rater cette première étape. « 

Nouvelle réalité du risque

Mais IDC et d’autres ont vu la rapidité avec laquelle les attaques ont commencé comme l’élément le plus préoccupant de ce rapport.

« Cette vulnérabilité WordPress est un exemple classique de la nouvelle réalité du risque : les attaquants exploitent des bogues critiques quelques heures après leur divulgation, et la plupart des entreprises ne mettent pas à jour les correctifs assez rapidement pour suivre le rythme », a déclaré Philip Harris, directeur de recherche d’IDC, citant les rapports de la société de sécurité Patchstack selon lesquels les attaquants avaient exploité la faille peu de temps après que WordPress ait publié le correctif.

Patchstack a déclaré: « Lorsque ce message a été publié pour la première fois, chaque demande que nous avions vue était une reconnaissance contre des fichiers de base inoffensifs. Ce n’est plus vrai. Les attaquants l’incluent et l’utilisent maintenant pour écrire des fichiers PHP sur le disque et des outils d’analyse publics pour ce CVE sont en circulation. « 

Harris d’IDC a noté que la télémétrie de Patchstack illustrait la nouvelle réalité, avec une reconnaissance des attaquants dans les cinq heures suivant l’application du correctif et une exploitation complète dans un délai d’environ une journée. « La fenêtre entre la divulgation et l’exploitation s’est effondrée au point que le temps moyen d’exploitation des vulnérabilités critiques est désormais négatif dans certains cas, ce qui signifie que le code d’exploitation apparaît avant ou immédiatement après la livraison d’un correctif », a-t-il déclaré. « Ce bug WordPress suit de près ce modèle : Patchstack a enregistré le premier trafic d’analyse moins de cinq heures après la sortie de WordPress 7.1.2, et le volume du trafic a été multiplié par dix en une journée alors que les attaquants passaient de l’analyse à la livraison réelle de la charge utile. »

Aman Mahapatra, directeur de la stratégie de la société de conseil en technologie Tribeca Softech, basée à New York, est d’accord.

« Le chiffre qui devrait ancrer cette histoire n’est pas le score CVSS de 9,2, mais c’est l’écart entre le correctif et l’exploit. Avec cette vulnérabilité, cet écart était effectivement nul », a-t-il déclaré. « WordPress a livré la version 7.1.2 le 22 septembre et Patchstack a bloqué la première tentative d’exploitation à 11h49 UTC le même jour, en utilisant des charges utiles qui correspondaient exactement à l’encodage pour lequel le correctif était écrit. Les attaquants n’ont pas découvert ce bug. Ils ont lu le correctif. Publier un correctif équivaut désormais à publier fonctionnellement un guide d’exploitation, et toute entreprise exécutant encore un cycle de correction mesuré en semaines fonctionne sur une chronologie qui a cessé d’exister depuis quelque temps. « 

Des correctifs plus rapides sont nécessaires

Une réponse à la rapidité des actions des attaquants consiste à automatiser les mises à jour, mais ce n’est pas nécessairement une bonne option. Certains RSSI d’entreprise s’inquiètent de l’automatisation excessive des correctifs ; ils souhaitent examiner et approuver toute modification du système, principalement pour éviter des catastrophes telles que l’incident Crowdstrike de 2024.

Ressl a déclaré dans une interview qu’une autre préoccupation concernant les mises à jour automatisées est que de nombreuses entreprises ne vérifient pas suffisamment que les mises à jour sont correctement exécutées.

« Activer les mises à jour automatiques n’est pas la même chose que vérifier que le correctif est installé », a-t-il déclaré. « Les problèmes de compatibilité et de disponibilité sont des raisons légitimes de tester les mises à jour. Ma recommandation est un déploiement rapide et testé avec vérification sur toutes les installations exposées, y compris les sites de test. »

Mahapatra a ajouté que le problème de l’automatisation des mises à jour est particulièrement grave dans les grandes entreprises.

« WordPress applique automatiquement par défaut des versions de sécurité mineures, ce qui signifie que le blog amateur moyen est probablement déjà corrigé », a-t-il souligné.  » Les sites d’entreprise désactivent régulièrement ces mises à jour automatiques pour appliquer le contrôle des modifications, de sorte que les organisations ayant la gouvernance la plus mature sont les plus susceptibles d’être encore exposées cette semaine, car leur propre processus maintient le correctif dans une file d’attente pendant que les attaquants analysent. Le contrôle des modifications qui ne peut pas distinguer une faille d’exécution de code à distance non authentifiée d’une mise à jour de routine du plugin protège le processus plutôt que l’entreprise, et c’est la vulnérabilité qui rend cette distinction coûteuse. « 

Et, a noté Nidhi Luthra, conseiller exécutif chez Acceligence : « Une version de sécurité peut devenir une feuille de route pour un attaquant presque immédiatement, donc l’application de correctifs d’urgence pour les systèmes connectés à Internet nécessite une réponse de plusieurs heures. »

Les sites WordPress oubliés ne peuvent pas être corrigés

Mahapatra a ajouté qu’une autre préoccupation, peut-être plus importante, est le fait que de nombreux déploiements WordPress en entreprise se déroulent inaperçus. Il ne s’agit pas d’un shadow IT typique, car ils sont entièrement autorisés à l’époque, mais ils sont encore souvent inconnus de la direction informatique.

Dans les entreprises, a-t-il déclaré, « l’exposition est sensiblement plus grande que la plupart des organisations ne le supposent, car la plupart des entreprises ne se considèrent pas comme des boutiques WordPress, et presque toutes le sont. Le risque réside dans le domaine Web que l’informatique n’a jamais inventorié : les microsites marketing, les pages de destination des campagnes, les sites nationaux régionaux, les pages de relations avec les investisseurs construites par une agence extérieure et les propriétés des entreprises acquises il y a trois ans et que personne n’a eu le temps de migrer. La gamme concernée (version WordPress) s’étend de 4.7.0 à 7.1.1, presque une décennie d’installations, et les sites oubliés sont précisément ceux qui reposent encore sur d’anciennes branches.

Mahapatra a déclaré qu’il avait particulièrement constaté cela dans les entreprises du secteur financier.

« Lorsque j’examine les surfaces d’attaque externes avec les RSSI du secteur bancaire, les instances WordPress qui apparaissent ne sont presque jamais le site de l’entreprise », a-t-il déclaré. « Il s’agit de sites appartenant au marketing, à une filiale ou à un contrat d’agence qui a expiré, et aucun d’entre eux n’apparaît dans la CMDB contre laquelle l’équipe de sécurité applique le correctif. »