Mises à jour WordPress : la base de votre sécurité

by | WordPress

Si vous avez déjà vu un plugin « abandonné » qui continue de marcher… vous avez probablement déjà porté une bombe à retardement sans le savoir.

Prérequis : une sauvegarde récente (fichiers + base de données), un accès administrateur WordPress, et idéalement un accès FTP/SFTP + au panneau d’hébergement. Les exemples ci-dessous ciblent WordPress 6.9.4 (avril 2026) et PHP 8.1+. Ne modifiez jamais les fichiers du cœur WordPress (le “core”) : tout durcissement doit se faire via la configuration serveur, wp-config.php, ou du code dans un plugin dédié.

La menace

Une mise à jour WordPress, thème ou plugin n’est pas un “confort”. C’est souvent un correctif de sécurité qui ferme une porte connue. Et quand une porte est connue, elle est testée en continu par des bots.

Ce qu’un attaquant peut faire si votre site est en retard

  • Prendre le contrôle d’un compte admin (via une faille d’escalade de privilèges ou un vol de session).
  • Injecter du spam SEO (pages cachées, liens sortants, redirections), ce qui finit par plomber votre trafic.
  • Déposer une porte dérobée (webshell, faux plugin, mu-plugin) pour revenir même après un “nettoyage” superficiel.
  • Voler des données (emails, formulaires, commandes WooCommerce) selon ce que vous stockez.
  • Utiliser votre serveur pour attaquer d’autres sites (envoi de spam, scans), ce qui peut mener à un blocage de l’hébergeur.

Pourquoi c’est si fréquent en pratique

Les attaques opportunistes (non ciblées) dominent largement : des robots scannent Internet à la recherche de versions connues et de fichiers typiques. Dans mon expérience, les sites compromis “sans raison” le sont presque toujours pour une de ces raisons :

  • un plugin populaire non mis à jour depuis des mois ;
  • un thème premium mis à jour “à la main” mais jamais réellement synchronisé ;
  • une version PHP trop ancienne qui force à rester sur de vieilles versions de plugins ;
  • un environnement de staging absent, donc on repousse les updates “par peur de casser”.

Le risque expliqué simplement

Quand une faille est corrigée, l’information finit souvent par devenir publique (notes de version, CVE, changelog, commits). Les attaquants n’ont pas besoin d’inventer : ils rejouent. Si vous n’appliquez pas le correctif, vous restez sur la version vulnérable, avec une cible très facile à identifier.

Résumé rapide

  • Mettre à jour, c’est fermer des failles déjà documentées. Les bots cherchent précisément les versions en retard.
  • WordPress 6.9.4 + PHP 8.1+ : si votre hébergement bloque PHP, vous bloquez aussi vos correctifs.
  • Les plugins/thèmes sont la surface d’attaque n°1 sur la majorité des sites de blogueurs.
  • Automatisez au moins les mises à jour de sécurité, et testez le reste sur un staging.
  • Surveillez : logs, comptes admin, fichiers modifiés, plugins inconnus, tâches cron suspectes.
  • Si vous êtes compromis : isolez, restaurez depuis une sauvegarde saine, puis patch + rotation des secrets.

Code vulnérable — ce qu’il ne faut PAS faire

Le sujet ici, ce sont les mises à jour. Le piège classique côté “code” : désactiver des protections ou implémenter un mécanisme d’update maison (souvent pour des thèmes premium) qui télécharge et installe du code sans vérification stricte.

Voici un exemple réaliste que j’ai déjà vu sur des sites : un snippet qui télécharge un ZIP de “mise à jour” depuis une URL et l’installe. Ça part d’une bonne intention (“je veux auto-mettre à jour mon thème”), mais c’est une catastrophe.

<?php
/**
 * EXEMPLE DANGEREUX : ne faites pas ça.
 * Problèmes :
 * - Téléchargement depuis une URL non fiable
 * - Aucune vérification de signature / hash
 * - Aucune capacité vérifiée
 * - Peut être déclenché via une requête si mal protégé
 * - Risque d'installation de code arbitraire (RCE)
 */

add_action('init', function () {
	// Erreur fréquente : une "clé" faible ou exposée dans le code
	if (!isset($_GET['force_update']) || $_GET['force_update'] !== '1') {
		return;
	}

	$zip_url = isset($_GET['zip']) ? $_GET['zip'] : '';

	// Erreur : aucune validation d'URL, aucune liste blanche
	$tmp = download_url($zip_url);
	if (is_wp_error($tmp)) {
		return;
	}

	// Erreur : upgrader sans vérifier les droits
	require_once ABSPATH . 'wp-admin/includes/file.php';
	require_once ABSPATH . 'wp-admin/includes/misc.php';
	require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';

	$upgrader = new Plugin_Upgrader();
	$upgrader->install($zip_url);
});

Comment l’attaque fonctionne (sans “mode d’emploi”)

Ce type de code ouvre une porte à deux niveaux :

  • Déclenchement : si l’attaquant trouve un moyen d’appeler l’URL avec les bons paramètres (ou si un autre bug permet d’appeler ce hook), il force une installation.
  • Charge utile : si l’URL du ZIP peut être contrôlée, l’attaquant peut faire installer un plugin contenant une backdoor.

Le point clé : ce n’est pas WordPress qui est “faible” ici. C’est un contournement des mécanismes d’update de WordPress, qui eux incluent des garde-fous (capabilités, nonces, sources, API WordPress.org, etc.).

Autre variante fréquente : désactiver les mises à jour automatiques parce que “ça casse des choses”, puis oublier. Résultat : vous accumulez des versions vulnérables pendant des mois.

Code sécurisé — la bonne implémentation

Objectif : rester à jour sans se tirer une balle dans le pied. La bonne approche se découpe en trois blocs :

  • utiliser les mécanismes natifs de WordPress (auto-updates, WP-Cron, WP-CLI) ;
  • appliquer une politique : auto pour la sécurité, staging pour le reste ;
  • ajouter une couche de contrôle : logs, alertes, et garde-fous.

Mesure 1 : activer les mises à jour automatiques (au bon niveau)

WordPress gère les mises à jour automatiques via plusieurs constantes et filtres. Pour un blog débutant, je recommande en général :

  • auto-update du core pour les versions mineures et sécurité ;
  • auto-update des plugins (au minimum ceux critiques : sécurité, cache, SEO, formulaires) ;
  • auto-update des thèmes seulement si vous êtes sur un thème “stable” et que vous avez un staging (sinon, mise à jour manuelle planifiée).

Où mettre le code ? Le plus propre : un mu-plugin (plugin “must-use”), chargé automatiquement et non désactivable depuis l’admin. Chemin : wp-content/mu-plugins/. Créez le dossier s’il n’existe pas, puis un fichier par exemple security-updates-policy.php.

<?php
/**
 * Plugin Name: MU - Politique de mises à jour (sécurité)
 * Description: Politique de mises à jour pour WordPress 6.9.4+ (core/plugins/thèmes) + journalisation.
 * Author: Votre équipe
 * Version: 1.0.0
 *
 * À placer dans : wp-content/mu-plugins/security-updates-policy.php
 */

defined('ABSPATH') || exit;

/**
 * 1) Autoriser les mises à jour automatiques du core.
 * WordPress gère finement les mises à jour de sécurité ; on évite de bloquer.
 */
add_filter('allow_major_auto_core_updates', '__return_true');
add_filter('allow_minor_auto_core_updates', '__return_true');

/**
 * 2) Politique plugins/thèmes : activer par défaut les auto-updates des plugins,
 * mais laisser les thèmes en manuel (souvent plus risqué côté design).
 *
 * Note : l’UI WordPress permet aussi d’activer plugin par plugin.
 * Ici, on définit une base cohérente.
 */
add_filter('auto_update_plugin', function ($update, $item) {
	// $item->plugin ressemble à "akismet/akismet.php"
	// Exemple : on force l’auto-update pour tous les plugins
	return true;
}, 10, 2);

add_filter('auto_update_theme', function ($update, $item) {
	// Par défaut, on n’auto-update pas les thèmes pour éviter une casse visuelle non détectée.
	return false;
}, 10, 2);

/**
 * 3) Journaliser les mises à jour réalisées (utile pour audit).
 * WordPress déclenche des actions lors des upgrades.
 */
add_action('upgrader_process_complete', function ($upgrader, $hook_extra) {
	if (empty($hook_extra['type']) || empty($hook_extra['action'])) {
		return;
	}

	$type   = sanitize_text_field($hook_extra['type']);   // plugin|theme|core
	$action = sanitize_text_field($hook_extra['action']); // update|install|delete

	// On limite au "update"
	if ($action !== 'update') {
		return;
	}

	$message = sprintf(
		'[MAJ] Type=%s | Détails=%s | Date=%s',
		$type,
		wp_json_encode($hook_extra),
		gmdate('c')
	);

	// error_log écrit souvent dans le log PHP de l’hébergeur.
	// Alternative : envoyer vers un système de logs (Sentry, syslog, etc.).
	error_log($message);
}, 10, 2);

Explication simple

Un hook est un point d’extension : WordPress “appelle” votre code à un moment précis. Une action exécute du code (ex : après une mise à jour). Un filtre modifie une valeur (ex : autoriser ou non une auto-update).

Explication technique (ce qui se passe en coulisses)

WordPress décide si une mise à jour automatique est autorisée en combinant des constantes, des options et des filtres. En forçant auto_update_plugin à true, vous dites : “si WordPress estime que la mise à jour est applicable, alors vas-y”. Vous ne contournez pas les vérifications natives, vous les accompagnez.

Mesure 2 : ne jamais “updater” via un téléchargement arbitraire

Si vous utilisez un thème premium (Avada, Divi 5, etc.), utilisez leur mécanisme officiel (licence + API) et évitez les “ZIP depuis un Dropbox”. Un ZIP fourni par email finit souvent :

  • stocké sur un poste infecté ;
  • réuploadé sans contrôle ;
  • installé en prod sans test.

Pour Divi 5 / Elementor / Avada : les mises à jour passent par WordPress + leur connecteur/licence. C’est le chemin qui bénéficie des contrôles WordPress (capabilités, nonces, permissions).

Mesure 3 : surveiller les versions et bloquer les environnements trop vieux

J’ai souvent croisé des sites “bloqués” parce que PHP était en 7.x, donc certains plugins refusaient de se mettre à jour. Résultat : on reste sur une version vulnérable “par contrainte technique”. Mieux vaut afficher un avertissement clair en admin.

Où mettre le code ? Même mu-plugin, ou un plugin custom. Évitez functions.php si vous débutez : une erreur de syntaxe peut casser le site.

<?php
defined('ABSPATH') || exit;

add_action('admin_notices', function () {
	if (!current_user_can('manage_options')) {
		return;
	}

	$php = PHP_VERSION;
	if (version_compare($php, '8.1.0', '<')) {
		echo '<div class="notice notice-error">';
		echo '<p><strong>Sécurité : votre PHP est trop ancien (' . esc_html($php) . ').</strong> ';
		echo 'WordPress 6.9.4 fonctionne mieux en PHP 8.1+ et beaucoup de correctifs plugins exigent une version récente. ';
		echo 'Planifiez une mise à niveau PHP côté hébergeur.</p>';
		echo '</div>';
	}
});

Configuration serveur

Les mises à jour réduisent le risque, mais n’éliminent pas tout. Une bonne configuration serveur limite l’impact si un composant est vulnérable.

.htaccess (Apache) : bloquer l’exécution PHP dans les dossiers sensibles

Sur beaucoup d’hébergements mutualisés, Apache est encore courant. L’idée : empêcher l’exécution de PHP dans wp-content/uploads. Beaucoup de malwares s’y cachent.

Où coller ? Créez un fichier .htaccess dans wp-content/uploads/ (si votre hébergeur l’autorise).

# wp-content/uploads/.htaccess
<FilesMatch ".php$">
  Require all denied
</FilesMatch>

Si votre hébergeur utilise une vieille config Apache, vous verrez parfois des variantes avec Deny from all. Préférez la syntaxe moderne (Require) quand disponible.

wp-config.php : désactiver l’éditeur de fichiers (réduit l’impact d’un compte admin compromis)

Si un attaquant obtient un accès admin, l’éditeur de thème/plugin dans l’admin devient un raccourci pour injecter du code. Le couper ne remplace pas les mises à jour, mais ça enlève une arme.

Où coller ? Dans wp-config.php, au-dessus de /* That's all, stop editing! */.

define('DISALLOW_FILE_EDIT', true); // Empêche l'édition de fichiers via l'admin

Headers HTTP : réduire des attaques “classiques” côté navigateur

Ces en-têtes ne corrigent pas une faille plugin, mais ils réduisent des risques annexes (clickjacking, injections). Sur Apache, vous pouvez les ajouter dans le vhost ou parfois dans .htaccess si mod_headers est activé.

# Exemple Apache (dans .htaccess si autorisé)
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Pour une politique CSP (Content-Security-Policy), allez progressivement : sur des sites avec Elementor/Divi/Avada, une CSP trop stricte casse vite l’éditeur. Je commence souvent par un mode “report-only” côté serveur, puis je durcis.

HTTPS et mises à jour : vérifiez la chaîne complète

Les mises à jour WordPress reposent sur des connexions TLS. Si votre serveur a des certificats cassés, une heure système fausse, ou des restrictions réseau, vous verrez des erreurs de téléchargement. Avant de bricoler, corrigez la cause.

Vérifier si votre site est vulnérable

Vous ne cherchez pas “une faille précise”. Vous cherchez des indicateurs : composants en retard, fichiers modifiés, comptes suspects, erreurs répétées.

WP-CLI : l’outil le plus fiable pour auditer rapidement

WP-CLI est une interface en ligne de commande pour WordPress. Si votre hébergeur le propose, c’est un gain de temps énorme.

# Version WordPress
wp core version

# Vérifier les mises à jour disponibles (core)
wp core check-update

# Lister plugins et mises à jour
wp plugin list
wp plugin list --update=available

# Lister thèmes et mises à jour
wp theme list
wp theme list --update=available

# Mettre à jour (à faire d'abord en staging si possible)
wp plugin update --all
wp theme update --all
wp core update

Piège courant : lancer ces commandes en production sans sauvegarde. Faites au minimum un snapshot, ou export DB + archive des fichiers.

Vérifier l’intégrité des fichiers du core

Si vous suspectez une compromission, commencez par vérifier si des fichiers du core ont été modifiés.

# Vérifie les checksums officiels du core WordPress
wp core verify-checksums

Si cette commande remonte des différences, ne paniquez pas : certains hébergeurs ajoutent parfois des fichiers. Mais des fichiers core modifiés sont un signal fort.

SQL : repérer des admins inattendus (diagnostic)

Si vous avez accès à phpMyAdmin, vous pouvez vérifier la liste des comptes admin. Le but n’est pas de “supprimer au hasard”, mais d’identifier l’inconnu.

# Remplacez wp_ par votre préfixe si nécessaire
# Liste des utilisateurs ayant la capacité admin (approximation via meta)
# À exécuter dans un client MySQL (ou phpMyAdmin)
SELECT u.ID, u.user_login, u.user_email, um.meta_value
FROM wp_users u
JOIN wp_usermeta um ON um.user_id = u.ID
WHERE um.meta_key = 'wp_capabilities'
AND um.meta_value LIKE '%administrator%';

Piège courant : confusion sur le préfixe (wp_). Beaucoup de sites ont un préfixe personnalisé. Vérifiez dans wp-config.php la variable $table_prefix.

Logs : ce que vous devez chercher

  • des POST répétés vers /wp-admin/admin-ajax.php (normal parfois, mais suspect si volumineux et venant d’IP variées) ;
  • des appels à /wp-json/ sur des routes que vous n’utilisez jamais ;
  • des erreurs 404 sur des fichiers typiques : wp-content/uploads/*.php, wp-content/mu-plugins/, etc. ;
  • des connexions admin à des heures inhabituelles.

Tableau diagnostic (symptômes courants)

Symptôme Cause probable Vérification Solution
Redirections vers des sites douteux Injection JS/PHP via plugin vulnérable ou fichier modifié Comparer fichiers, inspecter header.php, vérifier plugins récents Restaurer depuis backup sain, mettre à jour, changer mots de passe
Pages de spam indexées Création automatique de contenus (compte compromis) ou injection DB Rechercher des posts inconnus, vérifier comptes admin Supprimer contenus, corriger faille, demander réindexation
Impossible de mettre à jour (timeout / téléchargement échoue) Problème TLS/DNS, droits fichiers, quota disque Logs PHP, espace disque, test HTTPS sortant Corriger serveur, puis relancer updates
Site lent soudainement Cryptominer, spam, tâches cron malveillantes Observer CPU, vérifier cron, plugins inconnus Nettoyage + durcissement + monitoring
Écran blanc après update Conflit plugin/thème, PHP trop ancien, cache Logs d’erreur, désactiver plugins via FTP, vérifier PHP Mettre PHP 8.1+, staging, rollback si nécessaire

Erreurs de sécurité fréquentes

Erreur Risque Solution
Repousser les mises à jour “par peur de casser” Exposition prolongée à des failles connues Mettre en place un staging + sauvegardes + fenêtre de maintenance
Copier un snippet trouvé sur un forum dans functions.php Fatal error, ou création d’une porte dérobée involontaire Utiliser un mu-plugin / plugin custom, relire, tester en staging
Oublier un point-virgule / parenthèse Site HS (erreur 500), parfois en pleine mise à jour Éditer via un IDE, activer logs, déployer proprement
Utiliser un hook inadapté (ex: exécuter du code d’admin sur init) Code déclenché côté public, surface d’attaque élargie Utiliser admin_init, vérifier current_user_can(), nonces
Tester directement en production Interruption, perte de données, rollback compliqué Staging + procédure de déploiement
Oublier de vider le cache (plugin/CDN/navigateur) Vous pensez que “ça ne marche pas”, vous refaites des manips risquées Purger cache plugin + CDN + navigateur après update
Installer un thème/plugin “nulled” (piraté) Backdoor intégrée, compromission quasi certaine N’utiliser que des sources officielles et licences valides
Rester sur PHP trop ancien Bloque les correctifs, augmente les vulnérabilités Passer en PHP 8.1+ (idéalement plus récent si possible)
Confondre actions et filtres Protection non appliquée (ex : auto-update jamais activée) Vérifier la doc du hook, tester et logger
Snippet cassé par un plugin de snippets / thème enfant Politique de sécurité désactivée sans que vous le voyiez Centraliser dans un mu-plugin versionné
Permaliens non régénérés après une mise à jour majeure de structure 404, comportements bizarres qui poussent à des “fix” dangereux Réenregistrer les permaliens et purger les caches

Checklist de durcissement

  • Sauvegardes : quotidiennes (DB) + hebdo (fichiers), test de restauration réel.
  • Staging : un clone pour tester mises à jour thèmes/plugins lourds (Divi 5, Avada, gros bundles).
  • Core à jour : vous êtes en 6.9.4 ou plus récent, et vous appliquez les mineures rapidement.
  • Plugins : supprimer ceux inutilisés (désactiver ne suffit pas toujours pour réduire la surface).
  • Thèmes : supprimer les thèmes inactifs non nécessaires (garder un thème par défaut peut aider au dépannage).
  • PHP : minimum 8.1, idéalement la version stable proposée par l’hébergeur compatible.
  • Comptes : 1 admin principal, le reste en éditeur/auteur ; activer 2FA si possible.
  • Clés secrètes : renouveler les SALTs si suspicion (wp-config.php).
  • Accès : SFTP plutôt que FTP ; mots de passe uniques ; pas de partage de comptes.
  • Uploads : bloquer l’exécution PHP dans wp-content/uploads.
  • Logs : conserver au moins 7–30 jours, surveiller les anomalies.
  • WAF/CDN : activer un pare-feu applicatif si disponible (Cloudflare, Sucuri, etc.).

Que faire si le site est déjà compromis ?

Si vous suspectez une compromission, évitez le réflexe “je mets à jour et ça va passer”. Une mise à jour ferme une faille, mais ne supprime pas forcément la backdoor déjà déposée.

  1. Isolez : mettez le site en maintenance (ou bloquez l’admin), limitez l’accès si possible (IP allowlist sur /wp-admin).
  2. Sauvegardez pour preuve : faites une copie des fichiers + DB avant nettoyage. Ça aide à comprendre l’entrée.
  3. Changez les accès critiques : mots de passe WordPress, FTP/SFTP, base de données, compte hébergeur, clés API. (Oui, tout.)
  4. Vérifiez le core : wp core verify-checksums. Si le core est modifié, remplacez-le par une version propre.
  5. Réinstallez proprement :
    • téléchargez une copie saine de WordPress,
    • remplacez wp-admin et wp-includes,
    • ne gardez dans wp-content que ce que vous contrôlez.
  6. Auditez wp-content : cherchez des fichiers récemment modifiés, des .php dans uploads, des mu-plugins inconnus, des plugins “random”.
  7. Nettoyez la base : options suspectes, utilisateurs admin inconnus, contenus injectés.
  8. Mettez à jour : core/plugins/thèmes vers les versions actuelles. Supprimez tout ce qui est abandonné.
  9. Durcissez : bloquez PHP dans uploads, coupez l’éditeur, activez 2FA, WAF.
  10. Surveillez 72h : logs, nouveaux fichiers, nouvelles tâches cron, nouveaux admins.

Si vous avez un e-commerce ou des données sensibles, impliquez votre hébergeur et, selon votre juridiction, regardez vos obligations (ex : notification). Ne minimisez pas : une compromission est souvent silencieuse.

Conseils de maintenance et compatibilité

Rythme réaliste (débutant)

  • Chaque semaine : mises à jour plugins + core mineur, purge cache, vérification rapide du front.
  • Chaque mois : audit des plugins (supprimer ce qui ne sert plus), vérification des admins, test de restauration.
  • Chaque trimestre : revue des performances, revue sécurité, durcissement serveur si possible.

Compatibilité Divi 5 / Elementor / Avada : ce qui casse vraiment

Les page builders cassent rarement “à cause de WordPress”. Ils cassent parce que :

  • un plugin annexe injecte du JS/CSS incompatible ;
  • un cache agressif sert des fichiers anciens ;
  • un minifier combine mal des scripts ;
  • une mise à jour majeure du builder change un module.

Ma routine sur des sites Elementor/Divi/Avada :

  • staging obligatoire pour les mises à jour du builder et du thème ;
  • mise à jour des plugins de sécurité/correctifs en priorité ;
  • après update : purge cache (plugin + serveur + CDN) et vérification de 3 pages clés (home, article, contact).

SEO et performance : la sécurité “évite” des catastrophes

Un site infecté finit souvent avec :

  • des pages spam indexées,
  • des redirections mobiles,
  • une baisse brutale de Core Web Vitals (scripts injectés),
  • une alerte “site piraté” dans la Search Console.

Mettre à jour régulièrement, c’est aussi éviter des semaines de récupération SEO.

Deux conseils très concrets pour éviter les mauvaises surprises

  • Versionnez votre politique : un mu-plugin simple (comme ci-dessus) vaut mieux que 10 snippets dispersés.
  • Évitez les tutoriels anciens : beaucoup de snippets 2018–2022 utilisent des patterns dépassés, ou ignorent PHP 8.1+. Si un code vous pousse à modifier le core, passez votre chemin.

Ressources

FAQ

Dois-je activer toutes les mises à jour automatiques ?

Pour un blog débutant, je recommande au minimum : auto-updates du core (mineures/sécurité) et des plugins. Pour les thèmes (surtout avec Divi 5 / Avada), faites plutôt une mise à jour planifiée avec staging, sauf si vous avez un process de test solide.

Pourquoi les plugins sont-ils plus risqués que WordPress lui-même ?

Le core WordPress est très audité, et les correctifs sont rapides. Les plugins ont des niveaux de qualité variables, et certains sont abandonnés. Un plugin populaire mais non maintenu devient une cible parfaite.

Une mise à jour peut-elle “casser” mon site ?

Oui, surtout sur des sites avec beaucoup d’extensions, du cache agressif, ou des builders. La réponse n’est pas de ne pas mettre à jour : c’est de tester en staging, de sauvegarder, et de mettre en place une fenêtre de maintenance.

Où dois-je coller le code de sécurité : functions.php, plugin, ou mu-plugin ?

Pour la sécurité, je privilégie le mu-plugin : il se charge toujours, et un thème ne peut pas le désactiver. functions.php est acceptable pour du visuel, mais une erreur de syntaxe y casse facilement le site.

Je n’ai pas WP-CLI. Je fais comment ?

Vous pouvez gérer les mises à jour depuis l’admin WordPress (Tableau de bord → Mises à jour). Pour l’audit “fichiers modifiés”, c’est plus dur sans WP-CLI : demandez à l’hébergeur s’il peut l’activer, ou utilisez un plugin de sécurité réputé pour scanner.

Que signifie “nonce” et pourquoi on en parle en sécurité ?

Un nonce WordPress est un jeton anti-CSRF (attaque qui force un admin connecté à effectuer une action). Si vous avez des formulaires d’admin (ex : bouton “mettre à jour”), un nonce empêche une action déclenchée à votre insu.

Est-ce que désactiver un plugin vulnérable suffit ?

Pas toujours. Si le plugin a déjà servi de porte d’entrée, il peut rester une backdoor ailleurs. Désactiver réduit la surface, mais si vous suspectez une compromission, faites un audit complet.

Pourquoi bloquer PHP dans uploads ?

Parce que uploads est censé contenir des médias (images, PDF), pas du code exécutable. Beaucoup d’infections déposent un .php dans ce dossier et l’exécutent ensuite via le navigateur.

Mon hébergeur est en PHP 8.0. Je dois vraiment passer en 8.1+ ?

Oui. En 2026, rester sous 8.1 vous met régulièrement en situation de blocage de mises à jour (plugins qui montent leur prérequis) et vous prive de correctifs côté runtime. Regardez la page officielle des versions supportées : php.net.

Comment savoir si un plugin est “abandonné” ?

Sur le répertoire WordPress.org, regardez la date de “Dernière mise à jour”, la compatibilité testée, et le support. Si un plugin n’a pas bougé depuis longtemps, remplacez-le. Source : WordPress.org Plugins.

Mettre à jour améliore-t-il la performance ?

Souvent oui : corrections de bugs, améliorations de requêtes, compatibilité PHP. Mais le gain principal reste la sécurité : éviter une infection vous économise énormément de temps et de pertes SEO.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.