WordPress récent et piratages actuels : ce qui a changé
Le cœur WordPress se durcit. Les portes se déplacent vers les extensions, les thèmes hors circuit, et les chaînes d'approvisionnement. « J'ai la dernière version » n'est plus un argument suffisant — c'était déjà rarement le bon.
Le cœur se durcit, les portes se déplacent vers les extensions et les chaînes d'approvisionnement. « J'ai la dernière version » n'est plus un argument suffisant.
Ce qui a vraiment changé côté cœur
Les versions 6.x ferment des classes de failles qui, il y a dix ans, ouvraient un site en une requête. L'éditeur, l'API REST, les mots de passe d'application, les mises à jour auto du cœur : le socle est moins souvent la rampe. Dans les dossiers récents, un cœur à jour et un `index.php` officiel sont devenus la norme — pas l'exception.
Ça ne rend pas WordPress « safe ». Ça rend le discours « WordPress c'est fragile » inexact. WordPress est partout ; on attaque ce qui n'est pas le cœur : l'extension oubliée, le constructeur et ses add-ons, le thème nulled, le compte admin de 2019, le voisin de panel.
La page WordPress piraté pose encore les quatre portes classiques. Elles tiennent. Seul le centre de gravité a glissé. « J'ai WordPress 6.7 » ne clôt aucun de ces quatre sujets.
Là où les portes se sont déplacées
Les bots scannent les slugs d'extensions, pas le numéro du cœur. Une faille publique sur un formulaire, un file manager, un slider, un add-on Elementor, et le même payload se dépose sur des milliers de sites à jour. Désactiver l'extension après coup ne retire pas ce qui a déjà été copié à la racine ou en mu-plugin.
Deuxième déplacement : la chaîne. Un zip « premium » hors WordPress.org, un compte wp.org de mainteneur repris, une dépendance npm dans un thème buildé. Vous n'avez rien « mal configuré ». Vous avez installé un paquet déjà habité. Voir thème nulled et add-ons Elementor abandonnés.
Troisième : les accès légitimes. Application passwords oubliés, REST trop ouverte, ancien freelance encore administrateur. Pas d'exploit. Une session. WordPress 6 n'a pas inventé le problème ; il l'a juste rendu plus visible une fois le cœur moins poreux.
- Extension à jour… sauf l'add-on de 2021 qui la prolonge.
- Cœur auto-updaté, thème enfant jamais relu.
- Compte « agence » encore admin, 2FA nulle part.
« À jour » ne dit rien des add-ons
L'écran Mises à jour de WordPress est un bon tableau de bord, un mauvais constat. Il ne liste pas un must-use déposé à la main, un drop-in, un `radio.php` à la racine, un plugin « discontinued » que personne n'a retiré. Il ne dit pas si Rank Math ou Yoast a un sitemap pirate à côté du sien.
Après un incident, on compare aux zips officiels, on lit les dates, on liste ce qui n'a plus de mainteneur. « Tout est à jour » dans l'admin est le premier mot des dossiers que nous reprenons à J+5. Le second est « ça a recommencé ».
Gardez le cœur à jour, évidemment. Ne vous en servez pas comme bouclier rhétorique auprès d'un client ou d'un assureur. Le constat dit quelles extensions, quels fichiers, quelles dates — pas le numéro de WordPress.
Chaîne d'approvisionnement : zip, compte, CI
Un site headless qui rebuild depuis Git n'est pas « plus WordPress 6 donc plus sûr ». Si le token de build ou le webhook est pris, le front propre cache une API sale. Voir WordPress headless piraté.
Composer, npm, un sous-module : relisez les verrous après incident. Une dépendance compromise n'apparaît pas dans « Extensions ». Elle apparaît dans `vendor` ou dans le bundle du thème. On ne « réinstalle pas WordPress par-dessus » pour ça : on identifie le paquet, on le remplace, on tourne les jetons.
Les comptes wordpress.org, Packagist, npm du prestataire font partie du périmètre si c'est lui qui pousse en prod. Ce n'est plus du folklore. C'est devenu un angle banal des piratages « alors que tout était à jour ».
Ce que WordPress 6 n'a pas arrêté
Le voisin de compte sur mutualisé. Le `.git` ou le `.env` laissé à la racine. phpinfo, Adminer, une sauvegarde zip publique. xmlrpc encore ouvert « parce que l'appli mobile ». Un objet cache Redis qui ressert le JavaScript pirate après un nettoyage de fichiers. Rien de tout cela n'est une faille du cœur 6.x.
Les pages spam générées par IA n'ont pas besoin d'une CVE WordPress. Elles ont besoin d'un PHP qui fabrique des URL et d'un sitemap soumis. Le générateur a changé de style, pas de protocole. Voir pages spam IA.
Akismet et les anti-spam de commentaires n'ont jamais vu un shell. Ils sont utiles ; ils ne sont pas un argument « on est en 6 donc protégés ». Akismet pendant l'incident.
Après un incident : le cœur n'est pas le chantier
Mettre à jour le cœur pendant l'attaque ajoute du bruit et parfois une 500. On nettoie, on compare, on referme l'entrée, on tourne les secrets, puis on rattrape les versions. L'ordre est le même qu'en 2018. Seule la liste des extensions à jeter s'est allongée.
Réinstaller un WordPress 6 « vierge » et recoller `wp-content` est le geste qui ramène l'infection le plus souvent. Le contenu n'est pas innocent. Les uploads, les mu-plugins, les drops-in non plus.
Si vous déléguez, un devis lisible ne se résume pas à « passage en dernière 6.x ». Il dit fichiers, base, index, listes.
Le filet utile une fois le site propre
Mises à jour auto du cœur : oui, sur une vitrine. Sur une boutique, un créneau, une copie avant. Extensions : celles qui ont un mainteneur vivant. Les autres sortent, elles ne « restent désactivées ». DISALLOW_FILE_EDIT, 2FA sur les admins, plus de compte agence éternel.
Surveillance : fichiers nouveaux, utilisateurs admin, pics d'URL inconnues. Moins spectaculaire qu'un WAF payant, plus utile au deuxième mois. Voir surveillance continue.
Un plugin de sécurité se pose à la fin, comme filet, pas comme nettoyage. Wordfence « tout réparer » sur un thème enfant casse parfois plus que le malware.
Décider sans se rassurer tout seul
Si votre seul argument envers un client ou un associé est le numéro de WordPress, vous n'avez pas d'argument. Listez les extensions, les derniers comptes admin, le voisin de panel, la date de la dernière vraie comparaison aux zips. Ça tient dans une page.
Un site en 6.x piraté n'est pas une honte, ni une preuve que « il fallait Drupal ». C'est presque toujours une extension, un accès, ou un fichier hors cœur. On traite ça, on ne change pas de CMS le soir même — encore moins en mélangeant refonte et nettoyage.
Vous pouvez ouvrir un dossier en indiquant la version et la liste d'extensions. Nous n'en ferons pas un argument marketing. Nous en ferons une carte pour chercher l'entrée.