Un client, après avoir lu un article sur la signature cryptographique des paquets dans d’autres écosystèmes logiciels (Debian avec ses paquets signés, npm avec sa provenance de build), nous a demandé si WordPress vérifiait de la même façon l’authenticité de ses mises à jour avant de les appliquer. La réponse honnête est nuancée : WordPress dispose de mécanismes de vérification d’intégrité, mais pas encore d’un système de signature cryptographique généralisé à chaque paquet de mise à jour, cœur, thème ou extension, comparable à ce que proposent certains autres écosystèmes.
Ce qui existe aujourd’hui pour le cœur WordPress
Le cœur de WordPress distribue, pour chaque version publiée, un fichier de sommes de contrôle (checksums) accessible via l’API officielle. Ce mécanisme permet de vérifier que les fichiers présents sur un serveur correspondent exactement à ceux publiés par l’équipe de développement, sans modification intermédiaire, qu’elle soit accidentelle ou malveillante :
wp core verify-checksumsCette commande WP-CLI télécharge la liste officielle des sommes de contrôle pour la version installée, puis compare chaque fichier du cœur présent sur le serveur à cette référence. Elle signale toute différence, qu’il s’agisse d’un fichier modifié, ajouté ou manquant, ce qui en fait un outil précieux pour détecter une altération du cœur après un incident suspecté, en plus de son usage préventif régulier.
La différence entre checksum et signature cryptographique
Un checksum garantit l’intégrité d’un fichier : il prouve qu’un fichier téléchargé correspond bit à bit à celui référencé par la somme de contrôle. Il ne prouve en revanche pas, à lui seul, l’authenticité de la source : si la liste des sommes de contrôle elle-même était compromise à la source (sur le serveur qui la distribue), un fichier malveillant pourrait en théorie être accompagné d’un checksum correspondant, cohérent mais faux depuis l’origine.
Une signature cryptographique, à l’inverse, repose sur une paire de clés : le fichier est signé avec une clé privée détenue exclusivement par l’éditeur légitime, et vérifié avec la clé publique correspondante, largement diffusée et indépendante du canal de distribution du fichier lui-même. Ce mécanisme protège contre un scénario où le canal de distribution serait compromis, pas seulement le fichier final, une distinction qui compte particulièrement pour un logiciel aussi largement déployé que WordPress.
Ce qui existe côté extensions et thèmes
Pour les extensions et thèmes hébergés sur le répertoire officiel, la vérification d’intégrité repose principalement sur le contrôle d’accès au compte de publication lui-même : c’est notamment tout l’enjeu de l’obligation de double authentification imposée aux comptes de développeurs depuis fin 2024, qui vise justement à réduire le risque qu’un compte compromis publie une version malveillante d’une extension légitime. Il ne s’agit pas d’une signature cryptographique du paquet publié, mais d’un renforcement du contrôle d’accès à la source de publication, une approche complémentaire mais distincte.
Les travaux en cours sur une signature plus robuste
Des discussions et des propositions techniques circulent depuis plusieurs années au sein de la communauté de développement de WordPress autour d’un mécanisme de signature plus complet pour les mises à jour, inspiré d’approches déjà éprouvées dans d’autres écosystèmes open source de grande échelle. Ces travaux avancent progressivement, mais aucun mécanisme de signature cryptographique généralisé à l’ensemble des paquets (cœur, thèmes, extensions) n’est encore devenu la norme par défaut sur l’ensemble de l’écosystème à ce jour. La prudence reste donc de mise : ne considérez pas ce sujet comme définitivement clos, la situation continue d’évoluer version après version.
Ce que vous pouvez vérifier vous-même dès aujourd’hui
- Exécutez
wp core verify-checksumsrégulièrement sur vos sites, en particulier après tout incident suspecté touchant au cœur. - Téléchargez systématiquement le cœur, les thèmes et les extensions depuis les sources officielles (WordPress.org, dépôt officiel de l’éditeur), jamais depuis un miroir tiers non vérifié.
- Pour les extensions premium distribuées hors répertoire officiel, vérifiez que l’éditeur fournit lui-même un moyen de contrôle d’intégrité (checksum publié, mise à jour uniquement via un canal authentifié par clé API).
- Surveillez les journaux de fichiers modifiés sur votre serveur (avec un outil de détection d’intégrité au niveau du système de fichiers) pour repérer une altération qui contournerait les mécanismes applicatifs eux-mêmes.
Un mécanisme complémentaire, pas suffisant seul
Même un système de signature cryptographique parfaitement généralisé ne remplacerait pas les autres piliers de la sécurité d’une chaîne d’approvisionnement logicielle : une clé privée de signature elle-même compromise annulerait la protection offerte, tout comme un compte de publication compromis contourne le renforcement d’accès actuel. La signature de paquets s’ajoute aux pratiques existantes, elle ne les remplace jamais entièrement.
Notre position sur ce sujet reste pragmatique : en l’absence d’une signature cryptographique généralisée, la vigilance porte sur les sources de téléchargement et la vérification régulière par checksum, deux pratiques accessibles dès aujourd’hui sans attendre une évolution future du cœur.
En résumé
WordPress dispose aujourd’hui d’un mécanisme de vérification d’intégrité par checksum pour son cœur, complété par un renforcement du contrôle d’accès aux comptes de publication d’extensions, mais pas encore d’une signature cryptographique généralisée à l’ensemble de ses paquets de mise à jour. La situation continue d’évoluer, sans qu’un calendrier précis de généralisation ne soit à ce jour arrêté publiquement. En attendant, wp core verify-checksums et une discipline stricte sur l’origine de vos téléchargements restent les meilleurs outils disponibles.
