Fin 2024, l’équipe de sécurité de WordPress.org a commencé à imposer la double authentification aux comptes disposant d’un accès de publication (« commit access ») sur des extensions ou des thèmes hébergés sur le répertoire officiel. Cette mesure ne concerne pas les millions de comptes WordPress.org classiques utilisés pour poser des questions sur les forums, mais spécifiquement les développeurs qui publient du code exécuté sur des millions de sites à chaque mise à jour.
Pour qui maintient une extension, même modeste, comprendre ce changement et l’appliquer correctement évite un blocage de publication surprise, et surtout referme une porte d’entrée exploitée à plusieurs reprises par le passé pour distribuer du code malveillant via des mises à jour légitimes en apparence.
Le problème que cette mesure vise à corriger
Un compte de développeur d’extension compromis, par phishing ou par réutilisation d’un mot de passe fuité ailleurs, permet à un attaquant de publier une nouvelle version malveillante d’une extension existante. Cette version malveillante est alors distribuée automatiquement à tous les sites qui appliquent les mises à jour, sans qu’aucune vérification manuelle supplémentaire n’intervienne côté utilisateur final, puisque l’extension reste techniquement signée par le compte officiel de son éditeur habituel. Ce scénario s’est déjà produit sur le répertoire officiel par le passé, touchant des dizaines de milliers de sites en une seule mise à jour empoisonnée.
Ce que la double authentification change concrètement
Un compte disposant d’un accès de publication doit désormais activer un second facteur d’authentification pour se connecter à son compte WordPress.org, en plus du mot de passe habituel. Ce second facteur prend la forme d’une application d’authentification standard générant un code temporaire (compatible TOTP), suivant le même principe que la 2FA déjà répandue sur GitHub ou les services bancaires en ligne.
Sans cette activation, le compte perd progressivement la capacité à publier de nouvelles versions de ses extensions ou thèmes, ce qui a créé une vague de connexions et de réactivations de comptes anciens au moment de l’annonce, certains développeurs n’ayant plus utilisé leur compte de publication depuis plusieurs années.
Le mot de passe SVN dédié
Deuxième changement notable : le dépôt du répertoire officiel WordPress.org repose techniquement sur Subversion (SVN), un système de gestion de versions plus ancien que Git, utilisé historiquement pour la publication des extensions et thèmes. Or SVN, dans son usage courant, ne prend pas en charge nativement la double authentification lors des opérations en ligne de commande.
La solution mise en place consiste à générer un mot de passe SVN spécifique, distinct du mot de passe principal du compte, utilisé uniquement pour les opérations de publication en ligne de commande, pendant que la connexion au tableau de bord WordPress.org elle-même reste protégée par la 2FA classique. Ce mot de passe dédié se génère depuis les réglages de sécurité du compte, dans une section spécifique aux accès de publication.
svn commit -m "Version 2.4.1 : correctif de sécurité" \
--username mon-identifiant-wp \
--password "mot-de-passe-svn-dedie-genere"Ce que cela implique pour une équipe qui maintient plusieurs extensions
- Chaque développeur disposant d’un accès de publication doit configurer sa propre 2FA, il n’existe pas de compte partagé d’équipe pour cette opération.
- Le mot de passe SVN dédié doit être stocké dans un gestionnaire de secrets de l’équipe, pas dans un script de déploiement en clair versionné par erreur.
- Si l’équipe utilise une automatisation (intégration continue) pour publier des mises à jour d’extensions, cette automatisation doit être adaptée pour utiliser le mot de passe SVN dédié plutôt qu’un identifiant de compte classique désormais insuffisant seul.
Ce que cette mesure ne couvre pas
Cette obligation concerne exclusivement les comptes de publication sur le répertoire officiel WordPress.org. Elle ne remplace pas la nécessité de sécuriser par ailleurs les comptes administrateurs de vos propres sites WordPress, ni les accès aux dépôts de code source privés (GitHub, GitLab) où le développement a réellement lieu avant publication. La chaîne de confiance reste aussi solide que son maillon le plus faible : un dépôt de développement privé mal protégé, même avec un compte de publication WordPress.org parfaitement sécurisé, reste une porte d’entrée possible.
Notre conseil aux clients qui maintiennent une extension publiée, même à faible diffusion : traitez ce compte de publication avec la même rigueur qu’un accès administrateur de production, gestionnaire de mots de passe dédié compris, plutôt que comme un simple compte de forum.
En résumé
L’imposition de la double authentification et des mots de passe SVN dédiés aux comptes de publication de WordPress.org referme une porte d’entrée réelle et déjà exploitée par le passé : la compromission d’un compte de développeur pour distribuer une mise à jour malveillante à grande échelle. Pour qui maintient une extension ou un thème publié, l’activation de cette 2FA n’est plus optionnelle et mérite d’être traitée sans délai, avant que le compte ne perde sa capacité de publication.
