wp-cron désactivé, cron système sale : le malware change de rail

Pourquoi on coupe wp-cron

À chaque visite, WordPress peut déclencher des tâches (mails, publish, Woo). Sur un site chargé, on pose `DISABLE_WP_CRON` et un cron système toutes les cinq minutes vers `wp-cron.php`. Légitime. Documenté. Oublié dans le constat d'incident : tout le monde regarde `wp-content/plugins`, personne le crontab.

L'attaquant, lui, aime le rail que vous venez d'ouvrir : une ligne qui s'exécute sans visiteur, de nuit, avec les droits du site. Un wp-cron « off » ne l'empêche pas. Ça l'encourage à s'installer à côté.

Les tâches cron inconnues sont un symptôme classique de réinfection à J+2. Cet article fixe l'angle « on avait désactivé wp-cron, donc on était bien ». Non.

Ce que le rail système ouvre

Une entrée crontab, une tâche panel (o2switch, Plesk, cPanel), un systemd timer sur un VPS. Chacune lance un PHP, un wget, un curl. Après incident, on les liste toutes. Une seule ligne inconnue suffit.

Un `wget` vers une URL de votre site toutes les minutes n'est pas forcément sale (healthcheck). Un PHP dans `/tmp` ou un nom aléatoire, si. On ne publie pas de signatures. On compare à ce que VOUS avez posé, par écrit.

WordPress : les crons internes (Action Scheduler, Woo) continuent via le hit système. Relisez aussi les crons stockés en base (`cron` option) : un événement pirate y vit, même si le déclencheur est propre.

Lister sans tout arrêter

Panel : menu Cron / Tâches planifiées. VPS : l'utilisateur du site, pas seulement root. Notez, photographiez, ne videz pas le crontab d'un site e-commerce un vendredi (relances, stocks). Isolez l'inconnu.

Les premiers gestes : copie d'abord. Un crontab fait partie de la copie (texte collé dans le constat). Réinstaller WordPress ne l'efface pas.

Docker / CI : un cron dans l'image ou un GitHub Action « toutes les 5 min ». Autre liste. Headless.

• Panel hébergeur : toutes les tâches du compte.
• Crontab user du vhost.
• Option `cron` WP / Action Scheduler : événements bizarres.

Ce qui n'est pas « votre » tâche

Nom de fichier que vous ne reconnaissez pas, horaire à la minute improbable, URL externe, double de `wp-cron.php` avec un autre chemin. Ça sort. Le hit légitime vers `wp-cron.php` du site, documenté, reste — une fois le PHP propre.

Un cron qui relance un mineur ou un générateur explique les « ça revient à 3 h ». Coupez la tâche, puis le fichier, puis la porte. L'ordre inverse laisse la tâche recréer le fichier.

Cryptominage : souvent ce rail. Charge CPU + cron, pas un plugin visible.

DISABLE_WP_CRON n'est pas un antivirus

Ça évite que chaque visiteur déclenche des jobs. Ça n'empêche pas un mu-plugin, un utilisateur admin, un GTM. Certains articles « sécu » le vendent comme un durcissement. C'est une perf. Distinguez.

Laisser wp-cron ON après incident n'est pas non plus une défense. Choisissez un rail, documentez-le, surveillez-le. Deux rails (wp-cron + système) = deux endroits à relire, parfois des jobs en double, pas plus de sécu.

Un plugin « disable cron » en plus de la constante : bruit. Une source de vérité.

Remettre un rail propre

Site nettoyé, accès tournés, puis UNE tâche système vers le `wp-cron.php` officiel, fréquence raisonnable (5 min, pas 1 s). Rien d'autre que vous ne pouvez pas nommer.

Action Scheduler / Woo : laissez-les, relisez les files (failed, pending aberrants). Ne « truncate » pas la table cron pour vous rassurer : vous cassez les abonnements.

Si vous n'avez plus besoin du cron système (petit site), vous pouvez revenir à wp-cron natif. Dites-le, ôtez la tâche panel, ôtez la constante. Un rail, pas un fantôme.

Voisin de compte et cron partagé

Sur un panel, les crons de tous vos dossiers se listent au même endroit. Le blog abandonné a une tâche qui écrit chez Presta. Inspectez le compte, pas « le » site. WP + Presta.

Une tâche d'un ancien prestataire (backup vers son FTP) : révoquez, comme un utilisateur. Ancien développeur.

Les sauvegardes cron qui zippent dans le webroot recréent l'archive publique. Changez la destination.

Surveillance : la tâche de 3 h 17

Alerte : nouvelle ligne crontab, nouveau script lancé. C'est l'un des trois signaux utiles, trop souvent oublié au profit du seul scan de plugins. Surveillance.

Un mail « cron failed » de l'hébergeur : lisez-le. Parfois c'est le malware qui casse, parfois votre hit légitime après un 500. Ne le classez pas en spam.

Déclarer : « wp-cron est disabled, on a un cron panel » est une phrase utile. On ouvrira le panel avant de conclure « fichiers clean ».