Technique et prévention · 7 min · publié le 24 août 2026

Le CDN d'images sert encore un vieux HTML ou un PHP

Le CDN d'images — ou le proxy « tout le site » — ressert encore un vieux HTML, parfois un PHP qu'il n'aurait jamais dû prendre. Purge large après incident. Vérifiez qu'il ne proxy pas des chemins exécutables. Une purge d'une URL ne suffit pas si le générateur a créé 10 000 adresses.

Réponse directe

Purge large après incident. Vérifiez que le CDN ne proxy pas des chemins PHP. Une purge « une URL » ne suffit pas si le générateur a créé 10 000 adresses.

purge cdn après hack cdn ressert malware cloudflare purge all

Ce que le CDN a encore en mémoire

Vous avez nettoyé l'origine. Tokyo et Francfort servent encore le footer d'hier, un JS de checkout, une page spam en 200. Les visiteurs et Googlebot ne tapent pas tous l'origine. Ils tapent le bord. Un constat « fichiers clean » sans purge est un constat à moitié.

Les TTL d'images sont longs (jours, semaines). Les TTL HTML aussi chez ceux qui cachent tout. Distinguez : une image pirate (rare) vs un HTML / JS cuit (fréquent).

Les premiers gestes n'incluent pas Cloudflare. La clôture, si vous en avez un, si.

Images seulement, ou tout le domaine

Un CDN « médias » (sous-domaine `cdn.`, rewrite d'uploads) : purgez ce host, et vérifiez qu'il ne sert pas autre chose que des images (un `.php` dans uploads proxyfié). Un proxy orange sur tout le domaine (Cloudflare, etc.) : purgez tout, et relisez les règles Page Rules / Cache Rules qui auraient pu figer l'admin ou le checkout « pour la perf ».

Headless : l'edge du front (Vercel, Netlify) EST le CDN du HTML. Rebuild + purge. Headless.

Deux CDN (images + proxy) : deux consoles, deux purges. En oublier un, c'est le symptôme qui reste « selon le pays ».

Purge : une URL, un préfixe, tout

Une URL : inutile si 10 000 slugs spam ont été vus. Un préfixe : utile pour `/wp-content/uploads/2024/03/` ou `/ja/`. Tout : le plus sûr après un générateur ou un cloaking, le plus brutal pour la perf (quelques heures). Après un piratage, on assume le brutal.

« Purge by tag » si vous en avez : encore faut-il que les tags existent. En doute, purge all.

Attendez la propagation (souvent minutes, parfois plus). Retestez depuis un réseau hors bureau, mobile. Le bureau peut encore tenir un cache d'entreprise.

  • Générateur / cloaking : purge all.
  • Un fichier thème : l'URL + le HTML qui l'embarque.
  • Checkout : HTML + JS, pas seulement le logo.

PHP et chemins dangereux derrière le proxy

Un CDN mal réglé qui cache ou proxy `*.php` : il peut servir une ancienne réponse, ou, pire, exposer un script que l'origine ne voulait plus. Les chemins d'uploads exécutables + CDN = double peine. Interdisez PHP dans uploads à l'origine, et ne cachez pas ces chemins comme des images.

Nous ne donnons pas de config d'attaque. Le geste : listez ce que le CDN est autorisé à prendre (extensions, chemins), ôtez PHP, ôtez `.env`, ôtez les zip. Uploads.

Un WAF CDN n'est pas une purge. Il peut même cacher un 200 à vous et le servir à d'autres. Testez comme Googlebot / visiteur, pas seulement logué.

Cloudflare, Bunny, KeyCDN : le même geste

Le bouton s'appelle Purge Everything / Purge All / Flush. Les règles s'appellent Page Rules, Cache Rules, Pull zones. Le geste métier est le même. Un compte CDN avec un utilisateur inconnu se révoque comme GTM. Accès.

Cloudflare Workers / snippets : du code à la bordure, hors FTP. Relisez-les. Un worker peut réécrire le HTML après votre nettoyage d'origine. C'est le GTM du DNS.

Les certificats et le proxy : renouveler Let's Encrypt ne purge pas. Certificat.

Après : règles plus étroites

Moins cacher l'HTML du checkout et de wp-admin. Plus cacher les images immuables (hash dans le nom). Bypass cache sur les cookies de session boutique.

Ne « profitez pas » pour tout mettre en cache agressif le soir du piratage. La perf revient la semaine suivante.

Surveillance : un HTML différent selon le POP (pays) après clôture = encore un trou de purge ou un cloaking vivant. Surveillance.

Clôture avec Redis et le cache page

Ordre déjà dit : origine, objet, page, opcode, CDN. Redis. Un devis qui purge Cloudflare et oublie Redis (ou l'inverse) laisse un tiroir.

Les 410 sur le spam doivent être vus par le CDN (ne pas servir un 200 cuit). Purge des préfixes morts, ou all.

Déclarer : nommez le CDN. On ne devine pas un Worker. Cinq mots, une clôture plus courte.

Questions fréquentes

Development Mode Cloudflare, c'est une purge ?

+
Ça contourne le cache un temps, ça ne l'efface pas. À l'expiration du mode, l'ancien peut revenir. Purge all, puis éventuellement le mode dev le temps des tests.

Je n'ai qu'un CDN d'images. Je purge quand même ?

+
Oui si des images ou des JS y ont vécu, ou si le rewrite touche plus que des jpg. Si c'est vraiment uniquement des médias statiques et que le malware était du PHP à la racine, le risque est plus bas — une purge reste bon marché. Vérifiez qu'aucun HTML n'y est tiré.

Googlebot voit encore le spam après purge. C'est le CDN ?

+
Pas forcément : cache Google, autre hôte (`www` vs nu), cloaking encore vivant. Inspectez l'URL, testez l'origine en contournant le CDN (hôte, IP) si vous savez le faire sans casser le DNS. Distinguez les caches.

Une purge all va casser le SEO ?

+
Elle ralentit un peu le TTFB le temps du remplissage. Elle n'efface pas l'index. Un 200 spam cuit, lui, pourrit l'index. On purge.

Le prestataire CDN refuse de tout purger. Je fais quoi ?

+
Préfixes des dossiers pirates, puis les gabarits (home, checkout, JS). Si le contrat interdit purge all, documentez, multipliez les préfixes. Changez de règle la prochaine fois. Un CDN que l'on ne peut pas vider après incident est un mauvais CDN pour une boutique.
À lire ensuite
Redis / cache objet Litespeed et malware caché WAF Cloudflare après piratage Interdire PHP dans les uploads Blacklist Google Déclarer mon site