Redis ou cache objet qui ressert encore le JavaScript pirate
Après un nettoyage de fichiers, Redis ou le cache objet peut encore resservir une option WordPress sale, un fragment de HTML, un JS pirate. Flush. Oublié, il ramène ce que vous venez de retirer — même logique que le cache page, moins visible.
Flush du cache objet après nettoyage. Oublié, il ramène une option sale. Même logique que le cache page, moins visible.
Pourquoi les fichiers propres ne suffisent pas
WordPress range des options, des transients, des objets en mémoire (Redis, Memcached, un fichier). Vous avez remis un `header.php` officiel. La home, elle, sort encore d'un objet `alloptions` qui contient un script. Vous jurez que le FTP est clean. Le visiteur, lui, charge le skimmer. C'est particulièrement vrai après un « on a tout réinstallé » qui a laissé le démon Redis allumé : le nouveau cœur boit encore l'ancienne option.
C'est le dossier « nettoyé hier, recommencé ce matin » le plus sous-estimé avec le CDN. Moins spectaculaire qu'un cron, plus fréquent sur les stacks « perf » (Litespeed, Redis object cache, Kinsta, etc.).
Les premiers gestes ne parlent pas Redis. À la clôture, si. Demandez au prestataire s'il y a un cache objet. S'il ne sait pas, le panel ou un `object-cache.php` dans `wp-content` répond.
Objet, page, opcode : trois tiroirs
Objet : options, queries, fragments PHP. Page : HTML entier (plugin cache, Varnish, Litespeed). Opcode (OPcache) : PHP compilé en mémoire — un fichier remplacé peut encore s'exécuter « l'ancien » jusqu'au reload. Les trois se vident après un nettoyage de fichiers. En oublier un, c'est le symptôme qui revient.
CDN : un quatrième tiroir, autre article. CDN. On purge large, pas une URL.
GTM n'est pas un cache. S'il est sale, flush Redis n'y fera rien. GTM.
- Cache objet (Redis / Memcached / fichier).
- Cache page (plugin, Litespeed, Varnish).
- OPcache : reload PHP-FPM / panel « redémarrer PHP ».
Flush : où, dans quel ordre
Fichiers et base d'abord (le sale retiré à la source), puis flush objet, puis cache page, puis OPcache, puis CDN. Inverser : vous recachez du sale, ou vous servez du propre cinq minutes puis l'objet recrache l'option.
Panel : bouton Redis / Memcached flush s'il existe. Plugin object cache : « Flush ». WP-CLI `cache flush` si vous l'avez. Litespeed / WP Super Cache / WP Rocket : purge all. Ne « videz pas » seulement la home.
Woo : un cache d'objet tient aussi des sessions / fragments checkout. Tester le tunnel après, comme un client. Skimmer Woo.
Object cache drop-in et le plugin
`wp-content/object-cache.php` est un drop-in. Après incident, comparez-le au fichier officiel du plugin Redis / Memcached. Un drop-in réécrit est une porte élégante, hors liste « Extensions ». Must-use : même idée, autre dossier.
Désactiver le plugin sans retirer le drop-in laisse parfois un PHP qui tente Redis et échoue — ou qui exécute encore trop. Relisez le dossier après.
Ne réinstallez pas un object-cache « nulled ». Circuit officiel, après clôture.
Ce que le flush ne répare pas
Une option encore sale en base : le flush la rechargera sale. D'où l'ordre, source puis mémoire. Un `alloptions` injecté se nettoie en base, pas seulement en Redis.
Un mu-plugin, un cron, un utilisateur admin. Le cache n'est pas l'entrée. Réinfection.
Un HTML cuit en headless (SSG) : rebuild + purge edge, pas seulement Redis WP. Headless.
Redis exposé, un autre incident
Un Redis sans mot de passe sur une IP publique n'est pas « le cache qui ressert ». C'est une base ouverte. Bind localhost, mot de passe, pas de 6379 au monde. Si c'était ouvert, tournez ce qui a pu y vivre, constatez. Autre volet que le malware JS.
Nous ne détaillons pas comment s'y connecter. Le geste ops : plus d'écoute publique, secret, flush après durcissement.
Memcached : même famille, souvent encore plus nu. Même revue.
Vérifier que le sale ne revient pas
Après flush : navigation privée, mobile, checkout, inspection GSC. Si le JS pirate revient sans nouveau fichier, c'est encore un tiroir (CDN, autre Redis, page cache d'un plugin oublié, Litespeed au niveau serveur).
Attendez une heure, retester : un TTL long, un second nœud de cache. Les stacks « cluster » ont plusieurs mémoires.
Litespeed et malware caché : cas fréquent en France / chez certains hébergeurs.
Dans la checklist de clôture
Une ligne du constat : caches flushés (lesquels). Un devis qui oublie Redis sur un site « performance » est incomplet.
Surveillance : le JS ne doit pas réapparaître. Si si, on reliste les tiroirs avant de tout réinstaller.
Déclarer : « on a Redis / Litespeed / Rocket » oriente la dernière heure d'intervention. Dites-le. Ce n'est pas un détail de perf, c'est un détail de clôture.