Cache LiteSpeed ou WP Super Cache qui ressert le malware

Le malware n'est plus là, la copie l'est

Un cache de page enregistre le HTML déjà rendu. Si ce HTML contenait un redirect, un script de skimmer ou des liens spam, le retirer du thème ou de `wp_options` ne change rien pour quiconque est encore servi depuis le cache. Vous, en admin, voyez souvent une version dynamique (bypass). Le client et Googlebot, non. C'est le même décalage que « chez moi ça marche ».

Le test n'est pas « j'ai cliqué Purge All ». C'est : navigation privée + mobile + inspection Search Console, source HTML, après purge de chaque étage. Tant qu'un étage ressert le vieux document, le site n'est pas propre pour les autres.

Crier victoire et déposer un réexamen le jour même, cache encore chaud, c'est enregistrer un refus. Le délai suivant est plus long. Voir retrait blacklist Google.

Les étages : plugin, serveur, CDN, navigateur

Plugin WordPress (LSCache, Super Cache, Rocket, W3TC, Hummingbird). Cache du serveur (module LiteSpeed, Nginx FastCGI, Varnish chez l'hébergeur). CDN (Cloudflare, Bunny, KeyCDN) avec cache HTML parfois activé par erreur. Service worker / cache navigateur sur une PWA. Object cache (Redis) pour options et transients — autre nature, même ordre : vider après correctif.

Purger le plugin et oublier Cloudflare, c'est le cas le plus fréquent. Purger Cloudflare et oublier le dossier `wp-content/cache` du plugin, le deuxième. Faites une liste, cochez, puis retestez. Un seul bouton « tout vider » du plugin ne parle pas à l'hébergeur.

Les images et le JS minifié ont leur propre cache. Un skimmer dans un `bundle.min.js` généré survit à la purge HTML. Purgez aussi les assets, ou changez le hash / la query string des fichiers après nettoyage.

• Plugin de cache : purge + dossier `cache/` contrôlé.
• Panel hébergeur : « flush cache » LiteSpeed / NGINX.
• CDN : purge tout, ou au moins checkout / home / pages touchées.
• Object cache : flush Redis / Memcached.

LiteSpeed Cache et le cache disque

LSCache écrit sur disque et parle au serveur LiteSpeed. « Purge All » dans l'admin devrait suffire ; après un incident, vérifiez `wp-content/litespeed/` et les dossiers de cache. Un fichier HTML figé avec le payload, non invalidé (règle d'exclusion bizarre, URL avec et sans slash, http vs https, www), continue de se servir.

Les crawler / preload LSCache régénèrent les pages. Si la source (option, mu-plugin) n'est pas morte, le preload reconstruit du sale. Coupez le crawler le temps du nettoyage, puis relancez-le sur un HTML déjà relu.

ESI, cache mobile séparé, cache géolocalisé : trois copies. Purgez-les. Un skimmer « mobile only » vit dans la variante mobile du cache. Testez les deux.

Object cache Redis / Memcached

Il ne sert pas le HTML public, il sert les options et objets PHP. Une option nettoyée en base mais encore en Redis réinjecte le script au prochain rendu, qui se recache ensuite en page cache. Flush object cache après chaque UPDATE d'option. Détail voisin : object cache qui ressert.

Un `object-cache.php` drop-in pirate n'est pas Redis. Comparez le drop-in au fichier officiel du plugin. Les deux problèmes peuvent cohabiter.

Quand le cache est aussi le logement du payload

Parfois le malware n'est pas « dans » le cache par accident : une option du plugin (extra JS, HTML inject, CDN rewrite) porte le script. Purger ne suffit pas ; l'option régénère. Grep les options LiteSpeed / Rocket comme dans JS wp_options.

Des fichiers de cache exécutables (rare, mauvais MIME, dossier cache accessible en PHP) sont une porte. Interdisez l'exécution PHP dans les dossiers de cache. Ce n'est pas théorique sur des comptes mal configurés.

Vider sans croire le bouton unique

Après correctif : purge plugin, contrôle disque, flush hébergeur, purge CDN, flush Redis, test privé, test mobile, inspection URL. Si une page checkout est critique, ouvrez-la avec un query param unique (`?nocache=1`) seulement si votre cache ignore ce param — sinon vous validez une variante, pas la page réelle. Préférez une purge ciblée de `/checkout/`.

Ne désinstallez pas LiteSpeed « pour être sûr » au milieu d'un pic de trafic sans plan : le site tiendra moins, et vous perdez des réglages. Purgez et lisez les options. Désinstaller est un dernier recours si le plugin lui-même est la souche (nulled, extra inconnu).

Google, Safe Browsing et le cache bot

Certains caches servent une version « bot ». Si cette version était cloquée (spam SEO), Google continue de la voir jusqu'à purge + recrawl. L'inspection Search Console doit montrer votre HTML. Tant que non, pas de réexamen.

Les extraits en cache chez Google (cache: URL) ne se vident pas avec LiteSpeed. Seul le recrawl compte. Inutile de « vider le cache Google » par des outils douteux.

Refermer : qui régénère une page sale

Preload, cron, un hit visiteur, un 404 qui retombe sur un template injecté. Source morte, puis caches vides, puis preload. Inverser remplit le cache avec du sale. Surveillez 48 h le HTML public.

Si les pages sales reviennent avec le même script, l'enregistreur vit encore (option, voisin, admin). Ce n'est plus un problème de cache. Déclarer le site si la chasse tourne en rond.

• Tous les étages purgés, disque contrôlé.
• HTML privé = HTML Search Console.
• Preload relancé seulement après.
• Checkout relu si boutique.