Skip to main content
Durcir WordPress après wp2shell : mises à jour du cœur, moins d'extensions, uploads sans exécution PHP Publié le 8 août 2026 Juillet 2026 a livré deux incidents WordPress venus de directions opposées. wp2shell était une faille du cœur lui-même — exécution de code à distance non authentifiée, exploitée dans les heures suivant sa divulgation. La backdoor ARVE n’était pas une faille du tout, mais la compromission délibérée du canal de distribution d’une extension. Ils déjouent des défenses différentes. La discipline sur les extensions ne vous aurait pas sauvé de wp2shell. La mise à jour rapide est ce qui a livré la backdoor ARVE à ceux qui l’ont reçue. Une checklist qui ne traite qu’une seule forme d’incident n’est pas une checklist. Voici ce qui tient face aux deux, classé par ce que ça vous rapporte réellement.

​
1. Mises à jour automatiques du cœur, assumées

Les versions mineures du cœur portent les correctifs de sécurité, et elles sont conçues pour s’appliquer les yeux fermés. WordPress.org a poussé des mises à jour forcées pour wp2shell — mais uniquement vers les sites où les mises à jour auto étaient actives et les fichiers du cœur inscriptibles.
Vérifiez ce qui s’applique réellement, plutôt que ce que vous croyez avoir configuré :
Les sites déployés depuis Git avec des fichiers du cœur en lecture seule se retirent silencieusement de ce mécanisme. Si votre chaîne de déploiement possède wp-includes, alors c’est elle qui possède la correction — et elle doit se déclencher sur les publications de sécurité, pas au rythme de vos sprints.

​
2. Différer les mises à jour d’extensions, ne pas les désactiver

C’est le point contre-intuitif de la liste, et l’incident ARVE en est l’argument. Les portes dérobées dans les extensions sont détectées vite — celle-ci en moins de deux heures — mais elles le sont après publication. Appliquer chaque mise à jour d’extension à la minute où elle sort vous place en première ligne pour recevoir une version compromise. Ne jamais les appliquer vous laisse exposé aux vulnérabilités ordinaires, bien plus fréquentes. Le juste milieu : des mises à jour automatiques pour les extensions, volontairement décalées de quelques jours, avec les publications de sécurité exemptées du délai. Quel que soit l’outil avec lequel vous gérez vos sites à l’échelle, c’est le réglage à chercher. Si vous gérez quelques sites à la main, la même logique s’applique sans machinerie : vérifiez les mises à jour chaque semaine, appliquez immédiatement celles de sécurité et le reste à votre prochain passage.

​
3. Moins d’extensions

Chaque extension est une autorisation permanente d’exécuter du code accordée à un tiers, renouvelée à chaque mise à jour. Le contrôle le plus efficace reste une liste plus courte.
Préférez les extensions à plusieurs mainteneurs à celles qui n’en ont qu’un. Une extension maintenue par une seule personne est à un compte compromis de ce qui est arrivé à ARVE.

​
4. Moindre privilège sur les comptes

La chaîne wp2shell se termine par la création d’un administrateur. Beaucoup d’attaques se terminent en utilisant un administrateur qui traînait déjà. La plupart des gens qui se connectent à un site WordPress n’ont pas besoin d’installer des extensions. Le rôle Éditeur suffit pour publier. Administrateur devrait être détenu par une ou deux personnes, pas être le rôle par défaut de tous ceux qui ont un accès.
Activez l’authentification à deux facteurs sur les comptes restants. Sur la console OnetSolutions, elle protège le compte d’hébergement lui-même, c’est-à-dire la couche située sous le site.

​
5. Couper l’exécution de code dans les uploads

Un webshell doit atterrir quelque part, et wp-content/uploads est l’endroit habituel. Ce répertoire contient des images et des PDF. Il n’a aucune raison d’exécuter du PHP. Pour nginx :
Pour Apache, un .htaccess à la racine de wp-content/uploads :
C’est un contrôle peu coûteux et à risque quasi nul, qui transforme toute une classe d’exploitations réussies en un fichier inoffensif posé sur le disque. Si votre hébergement vous laisse choisir la version et le gestionnaire PHP, vérifiez que cette règle survit à la configuration.

​
6. Désactiver l’éditeur de fichiers du tableau de bord

L’éditeur d’extensions et de thèmes intégré permet à quiconque a les droits administrateur d’écrire du PHP directement sur le disque. C’est un confort qui ne vaut presque rien et un chemin d’escalade qui vaut beaucoup.
Pour aller plus loin, DISALLOW_FILE_MODS bloque aussi l’installation et la mise à jour d’extensions et de thèmes depuis le tableau de bord — adapté aux sites déployés depuis un dépôt, gênant pour les sites gérés à la main. Notez qu’elle désactive également les mises à jour automatiques d’extensions : à réserver aux cas où la chaîne de déploiement s’en charge.

​
7. Des sauvegardes que vous avez restaurées au moins une fois

Toutes les réponses à incident ci-dessus se terminent pareil : restaurer une sauvegarde antérieure à la compromission. Cette étape ne fonctionne que si la sauvegarde existe, remonte assez loin, et se restaure réellement. Trois propriétés comptent, et seule la première est habituellement contrôlée :
  • La sauvegarde tourne. Facile à vérifier, et c’est là que la plupart des gens s’arrêtent.
  • La rétention survit à la détection. Une compromission découverte en septembre exige une sauvegarde d’août. Sept jours de rétention, ce n’est pas une sauvegarde de sécurité, c’est un bouton d’annulation.
  • La restauration a été testée. Restaurez une fois sur un site de préproduction. C’est le seul moyen d’apprendre que le dump de la base était tronqué avant d’en avoir besoin.
Les sauvegardes d’hébergement mutualisé comme les snapshots VPS sont accessibles depuis la console. Prenez un snapshot manuel avant chaque mise à jour du cœur : cela coûte une minute et c’est le point de retour que vous voudrez.

​
Un contrôle de cinq minutes, tout de suite

Si vous ne faites rien d’autre après cette lecture, lancez ces quatre commandes :
Quatre commandes, et elles couvrent les deux incidents du mois écoulé plus les signes les plus courants d’un site compromis plus tôt et jamais remarqué.
Rien de tout cela ne rend un site inviolable. Cela raccourcit la liste de ce qui le casse, et rend ce qui passe quand même plus facile à repérer et moins coûteux à réparer. C’est précisément ce qu’est le durcissement.
Une question sur un site hébergé chez nous ? Notre équipe est disponible depuis votre espace client.