Erreur 500 après un piratage : distinguer panne et infection

La 500 ne veut pas dire « site piraté »

Une erreur 500 est une erreur fatale côté serveur : PHP a planté, Apache/Nginx n’a plus rien de présentable. Les causes honnêtes sont nombreuses : extension incompatible après update, mémoire, `.htaccess` avec une directive inconnue, timeout, droit de fichier cassé. Les causes malhonnêtes aussi : un payload syntaxiquement pourri, un `auto_prepend_file` vers un PHP manquant, un ionCube sur un shell.

Donc « erreur 500 site piraté » est une hypothèse, pas un diagnostic. On tranche avec le journal, les dates, et un deuxième canal (Google, comptes, redirection). Sans ça, on réinstalle, on perd les logs, et on ne sait toujours pas si quelqu’un était entré.

Si la 500 est apparue dans l’heure d’une action à vous (update, migration PHP 8.1 → 8.3, plugin de cache), commencez par le journal et un rollback de cette action. Si elle est apparue un dimanche à 3 h sans personne, avec un fichier à la racine daté de 3 h 02, changez d’hypothèse.

• Toujours : copier error.log + le fichier cité, hors serveur.
• Souvent : panne après une action connue.
• Parfois : infection qui casse en prod (encodeur, conflit).
• Jamais : réinstaller pour « voir si ça revient » avant copie.

Ouvrir le journal, pas le FTP au hasard

cPanel : Errors, ou `logs/`. Plesk : Journaux. o2switch / OVH : souvent un onglet Statistiques ou un fichier `error.log` à la racine du compte, pas du site. Cherchez la dernière ligne `PHP Fatal` ou `Uncaught` horodatée comme votre 500. Elle cite un fichier et une ligne.

Activez temporairement `WP_DEBUG_LOG` (pas `WP_DEBUG` affiché aux visiteurs) si le log serveur est vide. Rechargez une fois, lisez `wp-content/debug.log`. Désactivez l’affichage public ensuite : un debug en ligne après piratage est un cadeau.

La ligne typique d’infection : `eval()`, `assert()`, `include` vers `uploads/2024/09/x.php`, `auto_prepend` dans `.user.ini`. La ligne typique de panne : `require_once` d’une classe manquante après update, `Allowed memory size`, `Maximum execution time`, syntax error dans un fichier que vous venez d’éditer.

Comparer la date du fichier qui casse

Dans le gestionnaire de fichiers, propriétés du chemin cité. Modifié il y a vingt minutes, alors que l’extension officielle date de trois mois : quelqu’un a écrit. Modifié au moment de votre update, taille identique au zip WordPress.org : probablement l’update lui-même.

Un `wp-includes` touché hors release est un signal fort. Un `functions.php` de thème enfant touché le jour où un prestataire a travaillé l’est moins — jusqu’à ce que vous lisiez un `file_get_contents` remote au milieu.

Notez date, taille, chemin. Ne supprimez pas encore. Isoler = renommer en `.php.off` ou déplacer hors web, après copie. Supprimer un fichier CMS nécessaire transforme une 500 lisible en site définitivement mort. Voir ne pas supprimer au hasard.

Signatures d’infection dans une 500

Le fichier en cause n’appartient pas au CMS (`wp-tmp.php`, `about.php`, un nom aléatoire). Ou il est dans `uploads`. Ou `.htaccess` contient `php_value auto_prepend_file`. Ou `.user.ini` / `php.ini` local pointe vers un prepend. Ou la 500 n’apparaît que pour certains user-agents (le payload plante sur desktop, pas sur le bot — ou l’inverse).

Un `index.php` de 80 Ko à la place des 2 Ko du cœur. Un ionCube / un `eval(base64_decode` en tête de `wp-blog-header.php`. Un plugin « helper » que personne n’a installé et qui fatale en PHP 8.

Croisez : `site:` bizarre, compte admin fantôme, email d’abus. Deux canaux, vous n’êtes plus sur une panne. L’article comment savoir si le site est piraté donne l’arbre. La 500 n’est alors que le bruit du payload.

Signatures de simple panne

Fatal juste après la mise à jour d’Elementor, WooCommerce, PHP. Le fichier cité est une classe de cette extension, date d’update cohérente, zip officiel identique. Rollback de l’extension ou de la version PHP : la 500 part. Rien dans `site:`, rien dans les utilisateurs.

Quota disque : parfois des 500 d’écriture (sessions, cache). Inode saturés. Certificat ou backend down derrière un proxy : plutôt 502/504, mais certains fronts affichent 500. Un plugin de sécurité qui « met en maintenance » mal : 500 au lieu d’un 503.

Ces pannes se réparent sans changer tous les mots de passe. Si vous n’êtes pas sûr, changez quand même le panel : le coût est bas. Ne restaurez pas tout le compte « pour la 500 ». Trop large.

Page blanche, 500, timeout : pas le même objet

Page blanche : souvent la même fatal PHP, display_errors off. Traitez-la comme une 500 sans badge. Timeout / 504 : script trop long — mineur, générateur, ou requête SQL, ou HTTP externe. 503 : maintenance ou WAF. 403 : permissions ou règle abuse.

Ne les fusionnez pas dans « le site est down donc piraté ». Un timeout CPU à 3 h du matin sans trafic oriente vers minage ou générateur. Une blanche après update oriente vers panne PHP.

Notez le code HTTP réel (onglet réseau, pas seulement l’œil). Les clients disent « page blanche » pour une alerte Safe Browsing, une 500, ou une redirection. La capture avec barre d’adresse tranche.

Isoler le fichier sans tout réinstaller

Copie du fichier + du log. Renommer le coupable (`.off`). Recharger. Si le site revient, vous avez le levier. Ensuite seulement : lire, comparer à l’original, décider suppression ou restauration du fichier sain. Réinstaller le cœur WordPress par-dessus sans ça laisse le prepend et le mu-plugin.

Si la 500 vient d’un `.htaccess` : restaurez un `.htaccess` minimal WordPress (les trois lignes Rewrite), pas un fichier vide — les permaliens partent, seconde 500. Gardez l’ancien sous `htaccess.pirate.20260827`.

Si vous cassez plus en isolant, revenez à la copie d’avant votre intervention, pas à une réinstall complète. La 500 d’origine était un indice. Un site vide n’en a plus.

Après le silence : vérifier que ce n’était pas un leurre

Une 500 peut être le payload qui plante, alors qu’un second fichier, lui, redirige encore sur mobile. Site « réparé » chez vous, clients encore envoyés ailleurs. Refaites les trois tests : privée, téléphone, clic Google. Inspection Search Console.

Cherchez `auto_prepend`, crons, mu-plugins, voisins de compte. La 500 n’était peut-être que la partie visible. Changez le panel si l’hypothèse infection a tenu plus de cinq minutes.

Vous pouvez déclarer le dossier avec le log et le chemin : c’est déjà plus que « ça affiche 500 ». L’ordre global reste celui de que faire dans l’heure.