Le ticket WordPress n° 30465 a été ouvert il y a 10 ans – 2025 sera-t-il l'année où il sera enfin résolu ?

En novembre 2014, un développeur WordPress nommé Sergej Mueller a soulevé ce qui semblait être une préoccupation raisonnable : les utilisateurs n'avaient aucun moyen de savoir si un plugin qu'ils utilisaient avait été supprimé du référentiel officiel – même s'il avait été supprimé pour des raisons de sécurité. Son ticket – officiellement numéro 30465 – a été clôturé relativement peu de temps après, mais sans résolution. Sergej ne savait pas qu'il serait rouvert près de dix ans plus tard .

Et nous voilà, début 2025, en train d’écrire une mise à jour à ce sujet.

Pourquoi?

Pour plusieurs raisons.

Premièrement, cela est très pertinent pour certains événements de sécurité des plugins survenus récemment – ​​en octobre de l'année dernière pour être exact. J'en parlerai sous peu. Et, deuxièmement, la volonté et l’élan pour résoudre le problème ont pris de l’ampleur – la dernière activité sur le ticket remonte à moins d’un mois :

Il semble donc que la patience de Sergej pourrait bientôt porter ses fruits…

Commençons par retracer l’évolution du ticket. Ensuite, nous pouvons passer à ce qui s’est passé ces dernières semaines :

De « ne résoudra pas » à monter sur scène au WCEU 2023 🙅‍♂️

Lorsque le ticket a été ouvert pour la première fois, il a reçu quelques réponses mais a été fermé assez rapidement par le développeur principal de WordPress, Andrew Nacin. Il l'a fermé et l'a marqué comme « ne sera pas réparé », expliquant que les suppressions de plugins ont eu lieu pour diverses raisons, et pas seulement pour des problèmes de sécurité :

Il y a eu une vague de commentaires par la suite, mais cela s'est ensuite réduit à un commentaire une fois par an (parfois même moins que cela) de quelqu'un qui tentait de relancer le problème.

Puis, en mars 2023 , quelque chose d’intéressant s’est produit. Joost de Valk, figure bien connue de la communauté WordPress, a officiellement rouvert le ticket . Son argument était que WordPress a la responsabilité de dire aux utilisateurs si un plugin est maintenu ou non.

Il a également souligné que WordPress.org affichait déjà ces informations sur la plateforme elle-même, mais seulement après une période d'attente de 60 jours. Sa suggestion était d’apporter la même transparence au backend WordPress où les utilisateurs gèrent réellement leurs plugins.

Cela a déclenché une nouvelle vague d’enthousiasme à travers le fil. Le ticket est devenu si populaire qu'Oliver Sild, PDG et co-fondateur de Patchstack, l'a même mentionné dans son discours au WCEU 2023 :

Non seulement il l'a mentionné, mais il a encouragé les participants du WCEU à laisser des commentaires sur le fil de discussion en utilisant le code QR personnalisé qu'il a ajouté à sa présentation. Il a également utilisé ce plug comme alley-oop retardé pour un concours que Patchstack organiserait l'année suivante.

Événement Patchstack d'octobre 2024 🪲

En octobre 2024, Patchstack a lancé un événement Bug Bounty dans le cadre du Mois de la cybersécurité. Si la mention par Oliver du ticket #30465 dans son discours à la WCEU était une ruelle, alors les résultats de cet événement en seraient un slam dunk.

Les chercheurs en sécurité qui ont participé à l’événement ont fini par découvrir un nombre impressionnant de 1 571 rapports valides de vulnérabilités de sécurité en un seul mois. Il ne s’agissait pas non plus de simples problèmes mineurs – nous parlons de :

• 73 cas où les attaquants pourraient télécharger des fichiers malveillants.
• 67 vulnérabilités d’injection SQL qui pourraient compromettre des bases de données entières.
• 58 façons permettant aux attaquants d’élever leurs privilèges.
• 17 vulnérabilités d’exécution de code à distance (oui !)

Les conséquences ont entraîné la fermeture temporaire de près de 1 000 plugins. Et lorsque Patchstack a essayé de contacter les développeurs de plugins à propos de ces problèmes, près de 74 % étaient totalement inaccessibles. Soit leurs formulaires de contact étaient cassés, soit leurs e-mails rebondissaient ou leurs domaines avaient expiré.

Le plus intéressant, c'est que bon nombre de ces plugins vulnérables se trouvaient dans le référentiel depuis 6 à 11 ans. Certains dataient d’aussi loin que 17 ans ! Et oui, il existe encore des sites Web en direct qui dépendent de ces plugins.

Inutile de dire que toutes ces données ont permis à Oliver de tirer parti du fil de discussion pour faire avancer le ticket n° 30465 vers son achèvement. Il en a profité avec plaisir et a publié certains détails deux semaines avant la publication du billet de blog officiel de Patchstack discutant de l'événement :

De la discussion à l'action 🛠️

L'activité sur le fil faisait déjà boule de neige quand Oliver a ajouté son commentaire, il est donc difficile d'évaluer son impact individuel. Cependant, il n’est pas déraisonnable de supposer que cela a alimenté une flamme grandissante. Surtout avec d'autres utilisateurs (dont au moins un est un employé de Patchstack) soutenant ouvertement son commentaire.

En réponse, le développeur principal de WordPress, Dion Hulse (@dd32), a donné quelques réticences sur plusieurs points, mais a également intensifié ses efforts en créant un plugin expérimental qui implémente la fonctionnalité tant attendue :

La mise en œuvre est magnifiquement simple : lorsqu'un plugin a été fermé dans le référentiel WordPress.org, les utilisateurs voient une notification claire mais mesurée. Pas d'alertes rouges provoquant la panique, juste des informations simples sur l'état du plugin.

Quelqu'un trouve Sergej et lui dit : "Maman, nous avons réussi !"

Eh bien… presque.

Cela ne fait pas encore partie du noyau de WordPress, mais j'ai l'impression que nous sommes proches de la ligne d'arrivée ici !

Maintenant que cela s’est avéré possible, la prochaine étape consiste à décider d’une mise en œuvre finale. Ensuite, il peut être intégré au noyau de WordPress.

Quelle est la prochaine étape ? 🎯

Au moment d’écrire ces lignes, l’inclusion de cette fonctionnalité est envisagée dans WordPress 6.8 (selon Dion Hulse), bien qu’il reste encore quelques obstacles à surmonter. Ceux-ci incluent :

• Finalisation du calendrier de notification (il y a une discussion sur une éventuelle prolongation de la fenêtre de 60 jours).
• Standardisation de la documentation sur les motifs de fermeture.
• Équilibrer la sensibilisation des utilisateurs et la charge de support des développeurs.
• Décider de l'emplacement exact (l'écran de santé du site ou directement sur le plugin, comme indiqué dans l'exemple de capture d'écran du plugin).

La grande image 🌐

L’évolution du ticket WordPress #30465 nous apprend quelque chose de fascinant sur l’évolution de la sécurité de WordPress au cours de la dernière décennie. Ce qui était autrefois considéré comme un cas limite est devenu de plus en plus critique à mesure que l’écosystème s’est développé et que les défis de sécurité se sont multipliés.

Bien qu'il ait fallu dix ans pour en arriver là, le plugin expérimental suggère que nous approchons enfin d'une solution qui équilibre la sensibilisation à la sécurité et l'expérience utilisateur. Avec des millions d’installations WordPress potentiellement affectées par des plugins vulnérables, cette fonctionnalité ne peut pas arriver assez tôt.

Si vous souhaitez suivre le développement, consultez le plugin expérimental sur GitHub ou gardez un œil sur le ticket #30465. Il s’agit peut-être de l’un de ces rares moments où nous assistons à la transformation d’une conversation d’une décennie en un résultat tangible. 💡

Que pensez-vous de cette fonctionnalité ? Pensez-vous qu’il serait utile pour vous, en tant qu’utilisateur de WordPress, d’être informé de la fermeture d’un plugin ? Faites-le-moi savoir dans les commentaires. Je te verrai là-bas.