Drupal piraté : modules contrib et fichiers hors profil

Mettre à jour ne lave pas un dépôt déjà là

Drupal a connu des failles massivement exploitées. Les équipes s'en souviennent sous des noms d'époque. Ce qui compte aujourd'hui : si le site a vécu une période non patchée, partez du principe qu'un accès a pu poser un module, un fichier dans `files`, une ligne dans `settings.php`. La maj d'aujourd'hui ferme la fenêtre ; elle n'aspire pas le contenu déposé.

Le guide Drupal piraté le dit en une page. Ici l'ordre opérationnel : copie hors serveur, inventaire, comparaison, puis cœur. Inverser, c'est une 500 sur le back-office et une backdoor intacte.

Un ticket d'abus qui cite un chemin sous `files` est un point de départ, pas le périmètre. Compte suspendu.

Cœur, historique des failles, branche réelle

Identifiez la branche (7, 9, 10, 11). Drupal 7 en production en 2026 est un CMS oublié qui tourne encore : le coût est la reconstruction du métier, pas seulement un patch. TYPO3, SPIP, CMS oublié — Drupal 7 y entre de plain-pied.

Comparez le cœur au paquet officiel ou au dépôt de la version déployée. Un fork « pour nos besoins » non documenté se cartographie comme un site PHP sur mesure : pas de zip magique.

Ne lancez pas une maj majeure (9 → 10) le soir de l'incident. C'est un projet. Nettoyez sur la branche actuelle, puis planifiez. Maj sans casser.

Modules contrib et custom : deux traitements

Contrib : même critère que WordPress — plus de deux ans sans release, mainteneur introuvable, incompatible avec le cœur. `composer show` et la page Drupal.org. Désinstaller en UI ne retire pas toujours le code du disque. Extensions abandonnées.

Custom : pas de zip officiel. Dates de modification, fichiers PHP isolés, fonctions qui n'ont rien à voir avec le métier. On ne « réinstalle » pas un module métier. On le lit, on compare à Git s'il existe. Pas de Git ? La copie d'avant incident est votre seul référentiel — d'où l'importance de copier avant d'effacer.

Un module « security » ou « fixer » installé pendant l'attaque : on le retire après analyse, on ne s'y fie pas comme nettoyage.

• Contrib : comparer à la version officielle, retirer les morts.
• Custom : cartographier, ne pas supprimer au jugé.
• Uninstall + absence réelle du dossier.

Fichiers hors profil : /sites/default/files

C'est le `/images` de Joomla : dépôt fréquent de PHP, parfois sous des sous-dossiers au nom de cache. Interdire l'exécution PHP dans `files` après nettoyage est le minimum. Les médias légitimes n'ont pas besoin de PHP.

`.htaccess` dans `files` : parfois réécrit. Un `.private` mal exposé, un dump SQL oublié. Notez, copiez hors web, retirez. Fichiers .zip publics — le principe est le même.

Multi-site Drupal : chaque `sites/domaine/files`. Nettoyez tous les sites du compte, pas le seul vhost du mail d'abus. Isolation.

settings.php, services, clés

`settings.php` et `settings.local.php` : credentials, parfois `$settings` ajoutés, reverse proxy, config de mail. Une ligne inconnue n'est pas « Drupal moderne » par défaut. Comparez à un settings issu d'une install propre de la même branche, puis réinjectez vos secrets neufs.

Clés, consumers, users avec `administer modules` : revue après copie. Moindre privilège. Un user uid=1 dont le mail a changé est un signal, pas une anecdote.

Si `.env` ou un hors-Drupal existe (stack mixte), traitez-le. `.env` exposé.

Composer, vendor, et ce que « drush up » ne voit pas

Beaucoup de Drupal modernes vivent par Composer. Un paquet compromis dans `vendor` n'apparaît pas comme un module contrib dans l'UI. Relisez `composer.lock`, comparez aux hashes connus, ne réinstallez pas depuis un cache local douteux. Dépendances Composer ou npm.

`drush up` ou une maj UI ne réécrit pas un one-liner dans un thème custom ni un PHP dans `files`. Ce n'est pas un audit.

Node / front (thèmes compilés) : un script tiers compromis est un autre sujet. CDN JavaScript.

Remettre un Drupal propre sans tout jeter

Contenus, config (CML), médias : on préserve. On retire les ajouts. Une réinstall « pour être sûr » coûte les contenus récents et les vues. Restaurer un dump d'il y a trois semaines sans le lire peut ramener l'injection et perdre les nœuds du mois.

Cron Drupal et cron système : un import qui réécrit un fichier. Lisez-les avant de republier.

Tests : mobile, privé, clic Google, `site:`, inspection Search Console. Drupal n'y échappe pas. Tests avant victoire.

Après l'incident : files sans PHP, moins d'admins

Exécution PHP interdite dans `files`, modules morts retirés du disque, cœur rattrapé, secrets tournés, isolation du compte. WAF ensuite. WAF.

Fenêtre de trente jours : nouvelles URI, users, dates dans `files`. Garantie 30 jours.

Si le métier n'est pas documenté et que le seul développeur est parti, copiez avant toute bravoure. Créer un espace.