Ce n’est pas un bug
Tous les autres avis que nous publions décrivent une erreur : un contrôle oublié, une hypothèse fausse, un décalage d’indice. Celui-ci décrit une intention. Le 28 juillet 2026, la version 10.8.7 de l’extension Advanced Responsive Video Embedder — environ 20 000 installations actives — a été publiée avec une fonction nommée_arve_uc_init(), accrochée à l’action init de WordPress en priorité 1, donc exécutée avant presque tout le reste.
La fonction lit un jeton dans le paramètre de requête _wplogin ou _wpm et le compare à une empreinte SHA-256 codée en dur dans le source de l’extension. En cas de correspondance, la requête est authentifiée comme n’importe quel compte administrateur existant désigné par l’attaquant. Aucune vérification de nonce. Aucun contrôle de capacité. Aucun mot de passe.
Une empreinte inscrite dans un code source que tout le monde peut télécharger n’est pas un secret. C’est un identifiant universel, valable sur tous les sites qui exécutent cette version. La classification le dit sans ambiguïté : CWE-506, code malveillant embarqué.
Ce qui a limité la casse
Deux éléments ont évité la catastrophe. La détection a pris moins de deux heures. L’analyse automatisée de Wordfence a signalé le code malveillant le 28 juillet, moins de deux heures après sa publication. Le dépôt de l’extension a été fermé au téléchargement le jour même. Les mises à jour automatiques ne l’avaient pas encore propagé. L’équipe WordPress.org a confirmé que la version malveillante n’avait pas été largement distribuée par mise à jour automatique avant le retrait. La grande majorité de ces 20 000 sites n’a jamais reçu la 10.8.7. L’ironie mérite d’être relevée : la mise à jour automatique, le mécanisme qui vous protège d’ordinaire, est précisément le canal qu’emprunte une compromission de la chaîne d’approvisionnement. Ici, c’est sa lenteur qui a limité les dégâts.Mesurer votre exposition
Vérifier vos sites
Déterminez si l’extension est présente, et dans quelle version :Si la porte dérobée était présente
Supprimer l’extension ferme la porte. Cela ne vous dit rien sur qui l’a franchie avant. Procédez dans cet ordre :- Supprimer l’extension.
wp plugin deactivate advanced-responsive-video-embedder && wp plugin delete advanced-responsive-video-embedder - Auditer les comptes administrateurs, dates de création et adresses e-mail comprises. La porte dérobée s’authentifie comme un administrateur existant : un compte pirate n’est donc pas garanti, mais les attaquants en ajoutent couramment un pour la persistance.
- Chercher les fichiers ajoutés ou modifiés depuis le 28 juillet, en particulier le PHP sous
wp-content. - Renouveler tous les secrets : mots de passe administrateurs, mots de passe d’application, clés d’API, identifiants de base, et tout secret stocké dans
wp-config.php. Régénérez les salts au passage. - Invalider toutes les sessions pour qu’un cookie volé cesse de fonctionner :
wp user session destroy --all --all-users
Ce que cela change sur la confiance accordée aux extensions
La conclusion inconfortable, c’est qu’auditer le code d’une extension une fois vous renseigne sur la version auditée, pas sur celle que vous recevrez mardi prochain. Faire confiance à une extension, c’est faire confiance à qui détient les droits de commit dessus — indéfiniment, et le plus souvent sans le voir. Cela ne rend pas les extensions inutilisables. Cela rend quelques habitudes payantes :- Moins d’extensions. Chaque extension est une autorisation permanente d’exécuter du code accordée à un tiers. La meilleure défense est une liste plus courte.
- Privilégier les extensions maintenues et largement installées, à plusieurs mainteneurs plutôt qu’un seul. Une extension à mainteneur unique, c’est un seul compte à compromettre.
- Supprimer ce qui est désactivé. Une extension désactivée reste sur le disque et continue de recevoir des mises à jour. C’est de l’exposition sans bénéfice.
- Différer de quelques jours les mises à jour non liées à la sécurité sur les sites de production. C’est exactement la fenêtre dans laquelle cette porte dérobée a été détectée.
- Garder des sauvegardes dont vous avez réellement testé la restauration. Les sauvegardes d’hébergement mutualisé et les snapshots VPS ne servent que si vous savez que la restauration fonctionne.