Mettre à jour cœur et extensions après un hack, sans tout casser

Mettre à jour un site propre, pas un site sale

Une mise à jour du cœur WordPress, Joomla ou Drupal réécrit des fichiers officiels. Si un attaquant a posé un fichier à côté, ou modifié une option en base, la maj ne l'enlève pas. Elle peut en revanche casser un thème enfant, un override, ou un module métier — et vous passerez la nuit à « réparer la maj » au lieu de chercher l'entrée.

Dans les dossiers que nous reprenons, le réflexe « je mets tout à jour, ça va partir » revient souvent. Le site affiche une erreur 500, le propriétaire restaure une sauvegarde déjà infectée, et l'horloge a perdu une journée. L'ordre utile : constater, copier, nettoyer, refermer, puis seulement rattraper les versions. Le guide WordPress piraté pose le même principe.

Exception étroite : une faille publique activement exploitée, déjà corrigée par l'éditeur, et un site dont vous venez de retirer les ajouts. Là, la maj est un verrou, pas un balai. Elle ne remplace pas la comparaison des fichiers au zip d'origine.

• Pas de « tout mettre à jour » le soir de l'alerte Chrome.
• Pas de maj sur un FTP encore ouvert avec l'ancien mot de passe panel.
• Pas de maj core si vous n'avez pas de copie hors serveur.

Inventaire avant la première maj

Listez ce qui est installé : extensions, thèmes, version du cœur, PHP de l'hébergeur. Notez la date de dernière mise à jour de chaque composant. Deux ans sans commit, avis « incompatible avec la version actuelle », auteur introuvable : ce n'est plus une maj, c'est un remplacement. Dressez cette liste à froid, pas sous le ticket d'abus.

Sur WordPress, l'écran « Extensions » ment parfois : un plugin désactivé reste sur le disque et reste une porte. Sur Joomla, les paquets dans `/administrator` et les overrides du template. Sur Drupal, les modules contrib et le dossier custom. Un site PHP sur mesure n'a pas cet écran : on lit `composer.lock` et les librairies oubliées. Voir site PHP sur mesure piraté.

Cet inventaire sert aussi au constat pour l'hébergeur. « Nous avons mis à jour » ne dit rien. « Extension X retirée, cœur 6.4.3, PHP 8.2 » est une phrase que le support OVH ou o2switch comprend. La page compte suspendu rappelle ce qu'ils attendent.

Staging, copie, point de retour

Si l'hébergeur offre un staging (o2switch, certains VPS, PlanetHoster), clonez le site propre — après nettoyage — et jouez les maj là. Sinon, une copie complète hors compte (fichiers + base) suffit comme point de retour. La sauvegarde Updraft la plus récente contient souvent déjà le backdoor : on ne la restaure pas « pour tester ».

Une maj qui casse le checkout un vendredi soir n'est pas un détail. Prévenez les utilisateurs internes. Baissez le TTL DNS seulement si vous prévoyez une bascule ; pour une maj sur place, ce n'est pas nécessaire.

Si le FTP est encore coupé, demandez l'archive au support, traitez-la comme preuve, puis travaillez sur une copie saine. Restaurer l'archive de suspension et « mettre à jour par-dessus » replace l'infection à l'heure du ticket. Voir archive déjà infectée.

Cœur d'abord, extensions ensuite

Une fois le site comparable à l'officiel (ajouts retirés), mettez à jour le cœur, puis les extensions encore maintenues, une famille à la fois si le site est fragile (constructeur + WooCommerce + SEO). Notez ce qui casse. Un plugin de cache ou d'optimisation est souvent le premier à protester : videz-le après, ne le « réparez » pas en réinstallant une archive douteuse.

WordPress propose des maj automatiques. Après un incident, désactivez-les le temps de la fenêtre de surveillance (trente jours). Une maj automatique qui réécrit un fichier pendant que vous comparez les dates brouille la chronologie. Vous les rallumerez ensuite, composant par composant.

PHP : si l'hébergeur propose 8.1 et que vous êtes encore en 7.4, planifiez le saut après le nettoyage, pas la même nuit. Une extension abandonnée cassera ; c'est précisément l'information dont vous avez besoin, à froid. Repérer les extensions abandonnées détaille les signaux.

• Cœur officiel depuis le zip éditeur, pas depuis une copie « premium gratuite ».
• Extensions encore maintenues, une à une sur un site métier.
• Thème parent officiel ; le enfant se compare à la main.

Celles qu'on ne met plus à jour

Une extension sans mise à jour depuis deux ans n'aura pas de correctif. « La mettre à jour » n'existe plus. Il faut la remplacer ou retirer la fonction. La laisser désactivée sur le disque est une porte pour le prochain bot qui cherche un fichier connu.

Les add-ons de constructeurs (Elementor, Divi) et les plugins « pack 50 extensions » sont sur-représentés dans nos constats. Un add-on abandonné suffit. Ne remplacez pas le soir de l'incident si la home dépend de lui : isolez, documentez, planifiez le remplacement la semaine suivante. Casser le site pour « être sûr » crée un second incident, métier celui-là.

Thèmes nulled, « GPL club », archives Telegram : une maj officielle ne s'applique pas, et recoller une licence ne retire pas le code déjà là. Il faut changer de thème ou racheter proprement, puis comparer fichier à fichier. Voir thèmes hors circuit.

Thème enfant, mu-plugins, must-use

Une maj du thème parent n'écrase pas le thème enfant — c'est le but. Si l'attaquant a écrit dans le enfant, la maj ne le voit pas. Comparez `functions.php`, les templates copiés, les JS. Les must-use plugins (`wp-content/mu-plugins`) ne s'affichent pas comme les autres : ouvrez le dossier.

Sur Joomla, les overrides du template survivent à une maj du cœur. Sur Drupal, un thème custom et un module dans `/modules/custom`. Sur un site Laravel, `app/` n'est pas dans le vendor : Composer update ne le touchera pas. Cartographiez avant d'effacer. Le guide site PHP piraté insiste sur ce point.

Un drop-in WordPress (`object-cache.php`, `advanced-cache.php`) n'est pas une extension. Une maj de plugin de cache peut le régénérer — parfois avec un reste injecté si le générateur n'a pas été coupé. Vérifiez le contenu, pas seulement la date.

Base, options, et ce que la maj ne touche pas

Les options de site (adresse, scripts d'en-tête, widgets) ne sont pas mises à jour par le zip du cœur. Un pied de page injecté en base survit à toutes les maj. Idem pour un utilisateur admin fantôme, une clé d'application WordPress, un employé PrestaShop. La maj n'est pas un audit des comptes.

Passez les rôles en revue après l'incident. Un graphiste n'a pas besoin d'être administrateur. C'est gratuit et rarement fait. Moins de comptes admin décrit la revue.

Les cron (WordPress, système, panel) ne se mettent pas à jour. Une tâche qui régénère un fichier à 3 h du matin rend toute maj inutile. Lisez-les avant de crier victoire. Les tests à faire avant de déclarer le site propre incluent un contrôle 48 h plus tard.

Vérifier que rien n'a cassé — et que rien n'est revenu

Après les maj : home, une page intérieure, le formulaire, le checkout s'il existe, l'admin, un mail de test. Puis les tests visiteurs (mobile, navigation privée, clic Google). Une maj peut « réparer » l'affichage admin et laisser un cloaking pour Googlebot.

Si quelque chose casse, ne restaurez pas « la dernière sauvegarde » par réflexe. Identifiez le composant, revenez en arrière sur celui-là. Une restauration globale ramène souvent l'infection. Si vous bloquez, créez un espace : un technicien reprend en jours ouvrés, sans accès demandé à l'inscription.

Documentez les versions post-maj dans le constat. C'est utile pour l'hébergeur, pour l'assureur, et pour vous dans six mois quand une extension criera de nouveau. La fenêtre de surveillance de trente jours commence une fois les maj posées sur un site déjà nettoyé, pas avant.

• Affichage métier + tests visiteurs.
• Caches vidés (plugin, hébergeur, CDN).
• Liste des composants remplacés, pas seulement « tout à jour ».