Avada Builder WordPress corrige CVE-2026-4782 et CVE-2026-4798

Si ton site tourne avec Avada Builder, traite cette alerte sans attendre. Deux failles viennent d’être documentées et elles touchent un plugin annoncé autour du million d’installations actives. La première permet à un compte connecté, même simple abonné, de lire des fichiers du serveur. La seconde peut permettre à un visiteur non connecté d’extraire des données via une injection SQL dans un cas précis lié à WooCommerce.

Le correctif complet est arrivé avec Avada Builder 3.15.3, dans le paquet Avada 7.15.3 publié le 12 mai 2026. La version 3.15.2 corrigeait déjà une partie du souci, mais elle restait concernée par la lecture de fichier. Tu ne te contentes donc pas d’un bouton de mise à jour affiché comme terminé dans l’admin. Tu vérifies la version exacte, tu regardes les comptes, puis tu contrôles le contexte WooCommerce.

Pourquoi cette alerte Avada Builder compte vraiment

Avada n’est pas une petite extension posée sur trois blogs de test. C’est un écosystème complet avec thème, constructeur visuel, éléments, modèles, options globales et compatibilité WooCommerce. Quand une faille touche Avada Builder, elle peut concerner des sites vitrines, des boutiques, des pages de vente, des portfolios, des sites d’agence et des installations maintenues depuis des années.

Le risque varie selon ton site. Si les inscriptions sont ouvertes, un simple compte abonné peut devenir gênant pour la faille de lecture de fichier. Si tu as déjà utilisé WooCommerce puis désactivé l’extension, le scénario SQL mérite un contrôle sérieux. Si ton site est géré par une agence avec des accès clients, rédacteurs et comptes de test, le tri des rôles devient prioritaire.

L’erreur classique consiste à regarder uniquement le thème Avada dans Apparence. Ici, tu dois aussi regarder le plugin Avada Builder, parfois affiché sous le nom Fusion Builder selon l’historique du site. Un vieux site migré, une licence pas remise à jour ou un paquet installé manuellement peut garder une version en retard.

La faille CVE-2026-4782 expliquée simplement

CVE-2026-4782 concerne la lecture arbitraire de fichier. Le bug passe par un paramètre lié aux SVG personnalisés dans un élément de séparation de section. Dans les versions vulnérables, le plugin peut être amené à charger autre chose qu’un fichier SVG prévu pour l’affichage. Le rendu de shortcode peut alors lire un fichier local du serveur.

Ce point change le niveau de risque, car l’accès demandé reste faible. Le scénario publié parle d’un compte authentifié avec le rôle abonné ou plus. Sur beaucoup de sites, ce rôle paraît limité. Un abonné ne peut pas publier un article, gérer les extensions ou modifier les options. Mais si une fonction AJAX laisse ce compte déclencher un rendu sensible, le rôle faible ne protège plus assez.

Le fichier le plus cité dans ce genre d’alerte reste wp-config.php. Il contient les accès à la base, les clés de sécurité, le préfixe de table et parfois des réglages maison. Lire ce fichier ne donne pas toujours un accès administrateur direct, mais ça donne assez d’informations pour préparer une attaque plus grave. Si la base accepte les connexions depuis ailleurs, si les identifiants sont réutilisés, ou si les sauvegardes sont mal protégées, le risque augmente vite.

La faille CVE-2026-4798 côté injection SQL

CVE-2026-4798 vise un paramètre nommé product_order dans une fonctionnalité de cartes de produits. Le paramètre est nettoyé, mais il se retrouve dans un morceau de requête qui trie les résultats. Le nettoyage de texte ne suffit pas à bloquer une injection SQL quand la requête n’est pas préparée comme il faut.

Le scénario publié mentionne une injection SQL aveugle basée sur le temps. En clair, l’attaquant ne voit pas directement un affichage avec les données. Il envoie des requêtes préparées pour provoquer des temps de réponse différents, puis il reconstruit peu à peu ce qu’il cherche. C’est lent, technique, mais connu et exploitable quand la cible répond comme attendu.

Le contexte WooCommerce compte beaucoup. La faille devient exploitable dans le cas où WooCommerce a déjà été utilisé puis désactivé. Ce cas peut se produire sur un site réel. Une boutique peut fermer, un module e-commerce peut être retiré après une refonte, ou une installation de test peut garder des tables en base. Si les tables restent là, la requête vulnérable peut rester exploitable.

Les versions Avada à regarder sans traîner

La cible de ton contrôle est simple. Avada Builder doit être en 3.15.3 ou dans une version plus récente. Si ton tableau de bord parle surtout d’Avada 7.15.3, vérifie aussi les extensions liées dans la zone Avada, puis dans Extensions. Les anciens noms Fusion Builder ou Fusion Core peuvent encore apparaître sur des sites qui ont beaucoup vécu.

Si tu vois Avada Builder 3.15.2, tu n’as pas le correctif complet. Cette version a corrigé la partie SQL, mais la lecture de fichier a demandé le correctif complet en 3.15.3. Si tu vois 3.15.1 ou moins, tu dois traiter les deux failles. Dans le doute, tu sauvegardes, tu mets à jour, tu vides les caches et tu testes les pages clés.

Le réflexe propre consiste à ne pas séparer mise à jour et contrôle. Une mise à jour ferme la faille connue, mais elle ne prouve pas que personne n’a tenté quelque chose avant. Si ton site avait une version touchée pendant plusieurs semaines, regarde les comptes, les logs, les fichiers sensibles et le contexte WooCommerce.

wp plugin list | grep fusion
wp plugin get fusion-builder --field=version
wp user list --role=subscriber --fields=ID,user_login,user_email,user_registered
wp option get woocommerce_db_version

Si tu n’as pas WP CLI, fais le même travail depuis le tableau de bord. Tu vas dans Extensions, tu contrôles Avada Builder, tu regardes les utilisateurs, puis tu passes par l’hébergeur pour les logs et les fichiers. Pas besoin d’un énorme audit pour commencer. Il te faut une réponse nette sur la version, les comptes et WooCommerce.

Ce que tu dois vérifier côté fichiers

Commence par wp-config.php. Il doit être présent, avec une date cohérente et des permissions raisonnables. Si sa date de modification vient de changer sans action de ta part, compare avec une sauvegarde. Si le fichier a disparu, ne relance pas l’installation WordPress en cliquant partout. Restaure depuis une sauvegarde propre et change les accès sensibles.

Regarde aussi les journaux autour des requêtes AJAX WordPress. Selon l’hébergeur et le cache, tu ne verras pas toujours un détail exploitable. Tu peux malgré tout chercher des accès inhabituels à admin-ajax.php, des comptes abonnés créés récemment, des erreurs PHP autour d’Avada Builder et des appels qui contiennent des paramètres de shortcode étranges.

Si un attaquant a lu un fichier sensible, tu ne verras pas forcément un fichier modifié. Le contrôle doit donc se poursuivre côté base et comptes. Change les mots de passe des administrateurs, révoque les sessions, vérifie les nouveaux utilisateurs et regarde si un plugin ou un thème a été ajouté dans la même période.

Le cas WooCommerce à vérifier

La partie SQL mérite un contrôle dédié parce qu’elle peut toucher des sites qui ne vendent plus rien. Beaucoup de projets ont utilisé WooCommerce pendant une période, puis l’ont désactivé après une refonte. Les tables peuvent rester en base. Les anciens produits, commandes de test ou tables de lookup peuvent aussi rester là. Si Avada Builder interroge encore ces données dans certains éléments, le risque ne disparaît pas juste parce que l’extension WooCommerce n’est plus active.

Regarde si WooCommerce a été installé, si des tables commençant par wp_wc_ existent encore, et si des pages ou éléments Avada affichent des produits, cartes, grilles ou contenus liés à la boutique. Si tu as gardé des modèles de page e-commerce sans boutique active, nettoie ce qui ne sert plus.

Sur un site client, demande aussi ce qui a changé côté business. Une boutique arrêtée, un catalogue retiré ou un tunnel de paiement coupé peuvent laisser des traces techniques. La sécurité WordPress dépend souvent de ces traces anciennes. Le nettoyage est peu agréable, mais il réduit un risque concret.

Les liens utiles pour continuer ton tri WordPress

Si cette alerte te pousse à revoir tes accès, reprends la méthode pour protéger WordPress des attaques brute force. Le sujet n’est pas identique, mais le réflexe reste le même. Moins de comptes faibles, moins de connexions douteuses, moins de bruit dans les journaux.

Pour la partie fichiers, ajoute aussi les permissions CHMOD WordPress à ton plan de contrôle. Une faille de lecture de fichier devient bien plus inquiétante quand les droits, les sauvegardes et les copies de configuration sont mal rangés. Si tu dois nettoyer les caches après mise à jour, le dossier vider le cache WordPress peut t’aider à éviter les faux bugs d’affichage.

Cette alerte Avada arrive après une série chargée. Compare ton parc avec les dossiers sur WP-Optimize CVE-2026-7252, Essential Plugin WordPress piraté et Slider Revolution 7 CVE-2026-6692. Si tu retrouves toujours les mêmes sites en retard, c’est le moment de revoir la routine de maintenance.

Mon avis franc

Cette alerte Avada Builder demande une action rapide parce qu’elle combine volume, rôles faibles et base de données. La lecture de fichier avec un simple abonné suffit déjà à justifier un contrôle. L’injection SQL sans compte sur un contexte WooCommerce ancien ajoute un second risque sérieux. Et le tout concerne un constructeur présent sur un très grand nombre de sites.

La marche à suivre reste claire. Tu mets Avada Builder à jour en 3.15.3 ou plus récent. Tu regardes les comptes abonnés et admins. Tu contrôles wp-config.php. Tu vérifies si WooCommerce a laissé des tables derrière lui. Tu purges les caches. Tu regardes les logs récents. C’est court, carré, et ça évite de repérer le problème quand le site montre déjà des signes d’incident.

FAQ Avada Builder WordPress