> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # Durcir WordPress après wp2shell : sept mesures qui comptent vraiment > Deux incidents WordPress critiques en quinze jours, par deux chemins opposés. Checklist concrète : mises à jour, hygiène des extensions, moindre privilège. 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](/fr/wp2shell-cve-2026-63030) é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](/fr/arve-backdoor-cve-2026-18072) 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. ```php theme={null} // wp-config.php — versions mineures uniquement, le défaut et le bon choix define( 'WP_AUTO_UPDATE_CORE', 'minor' ); ``` Vérifiez ce qui s'applique réellement, plutôt que ce que vous croyez avoir configuré : ```bash theme={null} wp config get WP_AUTO_UPDATE_CORE wp core version ``` 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. ```bash theme={null} # Tout ce qui est installé, actif ou non — une extension désactivée reste sur le disque wp plugin list --fields=name,status,version,update # Supprimer ce qui est inactif wp plugin list --status=inactive --field=name | xargs -r -n1 wp plugin delete ``` 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. ```bash theme={null} # Qui détient les droits administrateur, et depuis quand wp user list --role=administrator --fields=ID,user_login,user_email,user_registered # Rétrograder quelqu'un qui n'a besoin que de publier wp user set-role 12 editor ``` Activez l'authentification à deux facteurs sur les comptes restants. Sur la [console OnetSolutions](https://help.onetsolutions.net/fr/console/security), 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 : ```nginx theme={null} # Dans le bloc server du site location ~* /wp-content/uploads/.*\.php$ { deny all; } ``` Pour Apache, un `.htaccess` à la racine de `wp-content/uploads` : ```apache theme={null} Require all denied ``` 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](https://help.onetsolutions.net/fr/web-hosting/php-version), 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. ```php theme={null} // wp-config.php define( 'DISALLOW_FILE_EDIT', true ); ``` 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é](https://help.onetsolutions.net/fr/web-hosting/backup) comme les [snapshots VPS](https://help.onetsolutions.net/fr/vps/snapshot) 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 : ```bash theme={null} # 1. Le cœur est-il sur une version corrigée ? 6.9.5, 7.0.2 ou ultérieure wp core version # 2. Un compte administrateur que vous ne sauriez pas nommer ? wp user list --role=administrator --fields=user_login,user_email,user_registered # 3. Du PHP écrit sous wp-content ces 30 derniers jours ? find wp-content -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort -r | head -20 # 4. L'extension ARVE est-elle présente ? wp plugin get advanced-responsive-video-embedder --field=version 2>/dev/null || echo "absente" ``` 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](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.