Breeze Cache WordPress faille critique que vérifier maintenant

Breeze Cache n’est pas le plugin WordPress à garder sans contrôle. Fin avril 2026, une faille critique a placé ce plugin de cache Cloudways dans une alerte sécurité sérieuse. Le nom à retenir est CVE 2026 3844. Le souci touche les versions jusqu’à la 2.4.4 incluse, avec un score CVSS 9.8 et des tentatives d’exploitation déjà observées par Wordfence.

Le point gênant, c’est le type de faille. On parle d’upload de fichier sans connexion admin. Si le bon réglage est actif, un attaquant peut pousser un fichier sur le serveur, puis viser l’exécution de code à distance. Sur un WordPress public, ça peut vite finir en webshell, fichiers suspects dans les uploads, accès à la base, spam SEO ou pages modifiées sans bruit.

Breeze Cache compte plus de 400 000 installations actives d’après WordPress.org. Tous ces sites ne sont pas forcément exposés, car le réglage vulnérable est désactivé par défaut. Mais si tu utilises Breeze sur un site client, une boutique ou un site qui reçoit du trafic Google, le bon réflexe est simple. Tu vérifies maintenant, sans reporter.

Pourquoi la faille Breeze Cache fait parler

Breeze Cache sert à accélérer WordPress avec du cache, de l’optimisation de fichiers, du nettoyage de base et des réglages CDN. Dit autrement, il tourne sur des sites qui veulent gagner en vitesse. C’est exactement le genre de plugin qu’on installe puis qu’on oublie, surtout quand il ne casse rien au quotidien.

La faille CVE 2026 3844 a été publiée le 22 avril 2026 dans la base Wordfence Intelligence. Elle vient d’un manque de validation dans la fonction fetch_gravatar_from_remote, placée dans le fichier class-breeze-cache-cronjobs.php. Cette fonction sert à récupérer des images Gravatar distantes pour les stocker localement.

Le bug vient du contrôle trop faible sur ce qui est récupéré. Si le serveur va chercher un fichier contrôlé par l’attaquant et le dépose dans un répertoire accessible, l’image attendue peut devenir un fichier PHP. Si ce fichier est ensuite exécutable côté serveur, le site n’est plus seulement vulnérable, il devient pilotable.

Le réglage Gravatar qui change tout

Le détail rassurant, mais à manier proprement, concerne l’option Host Files Locally Gravatars. Wordfence indique que l’exploitation demande ce réglage actif. Il est désactivé par défaut. Donc non, tous les sites avec Breeze ne sont pas automatiquement ouverts à cette attaque.

Le risque concret, c’est la vraie vie des sites WordPress. Un réglage peut avoir été activé pour améliorer les performances, alléger les appels externes ou suivre une vieille recommandation d’optimisation. Sur une agence, un réseau multisite ou un hébergement Cloudways, tu peux avoir plusieurs configurations différentes. Un inventaire de plugins ne suffit pas si personne ne vérifie les options.

Va dans les réglages Breeze et cherche l’option liée aux Gravatars locaux. Si elle est active et que la version est trop ancienne, tu as une priorité nette. Tu mets à jour, tu désactives ce réglage le temps du contrôle, puis tu passes aux traces serveur.

Ce que l’attaque peut faire sur ton site

Un upload de fichier arbitraire n’a rien d’un bug cosmétique. Dans le scénario le plus sévère, l’attaquant dépose un webshell. Ce petit fichier lui donne ensuite des commandes à distance sur ton hébergement. À partir de là, il peut lire des fichiers, chercher les identifiants dans wp-config.php, modifier des thèmes, ajouter un mu plugin ou poser du spam SEO.

Le danger SEO est souvent sous-estimé. Un WordPress compromis peut afficher une page propre à l’admin et servir autre chose à Googlebot ou aux visiteurs non connectés. Tu peux alors voir débarquer des titres bizarres, des URL qui n’ont rien à faire là, des extraits en langue étrangère ou des pages qui s’indexent depuis des dossiers techniques.

Si tu veux un contrôle propre, pense en deux temps. D’abord tu coupes la possibilité d’exploitation. Ensuite tu cherches si quelqu’un est déjà passé. Mettre à jour sans regarder les traces, c’est parfois garder des fichiers déjà déposés avec les dégâts encore en place.

Versions touchées et correctifs

Cloudways a corrigé le problème avec Breeze Cache 2.4.5. WordPress.org affiche maintenant la version 2.4.7, avec un changelog qui mentionne la correction Gravatar en 2.4.5, puis plusieurs corrections techniques après. Si ton tableau de bord propose 2.4.7, prends cette version. Elle inclut le correctif et évite de rester sur un palier déjà dépassé.

Contrôles à faire sans attendre

Si tu as WP CLI, commence par une vérification simple.

wp plugin list | grep breeze

Regarde ensuite les fichiers qui n’ont rien à faire dans les uploads. Les extensions à surveiller en priorité sont .php, .phtml et .phar.

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)

Si Breeze a créé un dossier dédié aux Gravatars, contrôle-le aussi.

find wp-content/uploads/breeze/gravatars -type f

Dans les logs, cherche les appels à fetch_gravatar_from_remote, les requêtes étranges vers admin-ajax.php, puis les téléchargements sortants vers des domaines inconnus juste après. Ce dernier point est utile, car l’attaque pousse ton serveur à aller chercher un fichier ailleurs.

Sans SSH, passe par le gestionnaire de fichiers de l’hébergeur. C’est moins agréable, mais ça suffit pour repérer un fichier PHP placé dans wp-content/uploads. Si tu vois un nom aléatoire, un fichier récent ou un PHP dans un dossier d’images, tu ne supposes rien. Tu sauvegardes la preuve, tu isoles le fichier et tu nettoies.

Nettoyage si tu repères une trace

Si tu trouves un fichier suspect, ne te limite pas à le supprimer. Commence par sauvegarder une copie hors webroot pour analyse, puis retire l’accès public. Mets Breeze à jour, coupe le réglage Gravatar local, vide le cache Breeze, le cache serveur et le CDN si tu en as un.

Ensuite, vérifie les zones classiques de persistance. Passe dans wp-config.php, .htaccess, le dossier mu-plugins, le thème actif, le thème enfant et la table wp_options. Cherche aussi les comptes administrateurs récents et les tâches cron inconnues. Une faille d’upload sert parfois à poser un premier fichier, puis un second mécanisme reste caché ailleurs.

Réduire le risque côté serveur

Le meilleur correctif reste la mise à jour. Mais tu peux aussi réduire le risque côté serveur. Bloque l’exécution PHP dans wp-content/uploads quand ton hébergeur le permet. Sur Apache, ça passe souvent par une règle dans le dossier uploads. Sur Nginx, ça se règle plutôt dans la configuration du vhost. Si tu es sur un mutualisé, demande au support.

Un WAF peut aussi aider. Tu peux filtrer les requêtes qui tentent de faire récupérer un fichier distant par WordPress, surtout autour des endpoints Gravatar. Wordfence a indiqué avoir bloqué des attaques sur cette faille. Si tu utilises déjà Wordfence, vérifie que le pare feu est actif et que les règles se mettent à jour.

Sur un parc de sites, ajoute Breeze Cache à ton inventaire de plugins sensibles. Note la version, le réglage Gravatar, la date de contrôle et le résultat du scan uploads. Ça prend quelques minutes par site, mais ça évite la recherche d’infos quand une alerte repart.

Impact SEO et Search Console

Après une faille WordPress, Search Console devient ton tableau de contrôle. Va dans Pages, regarde les URL indexées, les pages exclues, les variations soudaines et les requêtes bizarres. Si un attaquant a servi du spam via ton domaine, tu peux le voir dans les requêtes, les titres de résultats ou les URL inspectées.

Inspecte les pages clés une par une. Demande une nouvelle exploration uniquement après nettoyage. Sinon, tu risques de pousser Google à revoir une page encore polluée. Vérifie aussi le sitemap, les redirections et les pages en cache si tu utilises un CDN.

Si tu repères du contenu parasite, nettoie d’abord le site, renvoie un sitemap propre, puis utilise l’inspection d’URL sur les pages stratégiques. Pour les URL parasites, un code 404 ou 410 propre est souvent plus net qu’une redirection vers l’accueil.

Maillage interne pour continuer le ménage

Si tu veux pousser l’audit plus loin, lis aussi notre article sur le backdoor WordPress dans Quick Page Post Redirect. Les deux sujets parlent d’un point commun très concret, un plugin peut sembler banal et quand même servir à injecter du code ou du spam.

Tu peux aussi vérifier les permissions CHMOD WordPress après un nettoyage. Et si ton site subit beaucoup de tentatives de connexion, garde sous la main la méthode pour protéger WordPress des attaques brute force.

Sources utilisées

• Wordfence Intelligence, fiche Breeze Cache publiée le 22 avril 2026.
• BleepingComputer, article de Bill Toulas publié le 23 avril 2026.
• CyCognito, note Emerging Threat publiée le 29 avril 2026.
• WordPress.org, fiche Breeze Cache consultée le 3 mai 2026.

FAQ sur Breeze Cache