Avada Builder : une faille expose vos fichiers et vos données sur un million de sites WordPress

Avada Builder équipe un million de sites WordPress dans le monde. C'est le constructeur de pages derrière Avada, numéro un des ventes sur ThemeForest depuis plus de dix ans. Deux failles viennent d'être entièrement corrigées dans la version 3.15.3, publiée le 12 mai 2026. La première - notée 6.5 au score CVSS - permet à n'importe quel abonné inscrit sur votre site de lire des fichiers arbitraires sur le serveur, y compris wp-config.php qui contient les accès à votre base de données. La seconde - notée 7.5 - permet à un visiteur anonyme d'extraire des données de votre base via une injection SQL aveugle, sous une condition précise : que WooCommerce ait un jour été actif sur le site. Sans veille de sécurité continue, le correctif ne s'applique pas dans les heures qui suivent la divulgation publique.

Mise à jour urgente requise. Si votre site utilise Avada Builder dans une version inférieure à 3.15.3, il est exposé à l'une ou aux deux failles décrites ici. Mettez à jour depuis Extensions → Mises à jour disponibles dans votre tableau de bord WordPress. Besoin d'aide ? Contactez-nous pour un audit →

Avada Builder et ses un million d'installations

Avada se revendique le thème WordPress le plus vendu de ThemeForest avec plus d'un million de licences. Le constructeur de pages intégré - distribué comme plugin autonome sous le slug fusion-builder - est donc actif sur un nombre de sites considérable. Sa popularité en fait une cible que les chercheurs en sécurité scrutent régulièrement.

Rafie Muhammad, chercheur au programme de bug bounty de Wordfence, a soumis deux rapports distincts le 21 mars 2026. Les deux ont été confirmés par l'équipe Wordfence qui a aussitôt notifié le développeur. Les primes versées donnent une idée de la gravité : 3 386 dollars pour la lecture de fichiers et 1 067 dollars pour l'injection SQL.

1 000 000
Sites WordPress concernés
6.5
CVSS - Lecture de fichiers (CVE-2026-4782)
7.5
CVSS - Injection SQL (CVE-2026-4798)
3.15.3
Version corrigée (12 mai 2026)

CVE-2026-4782 : lire wp-config.php depuis un simple compte abonné

6.5 Score CVSS

CVE-2026-4782 - Avada Builder (Lecture arbitraire de fichiers)

Abonné+ → lecture de tout fichier sur le serveur via le paramètre custom_svg → accès aux identifiants de base de données, clés cryptographiques, fichiers de configuration.

Le mécanisme technique

La faille vient de la fonction fusion_get_svg_from_file(), appelée par le shortcode fusion_section_separator lorsqu'un paramètre custom_svg est fourni. L'intention est de charger un fichier SVG - mais aucune vérification du type de fichier n'est effectuée dans les versions vulnérables. N'importe quel chemin fonctionne, y compris des chemins absolus vers des fichiers PHP ou de configuration.

// Aucune validation du type ou de la source du fichier function fusion_file_get_contents( $url ) { $wp_filesystem = Fusion_Helper::init_filesystem(); $file_content = $wp_filesystem->get_contents( $url ); // lit n'importe quel fichier ... return $file_content; }

La porte d'entrée est la méthode AJAX get_shortcode_render() dans la classe Fusion_Builder_Front. Elle est protégée par un nonce - mais ce nonce est accessible à tout utilisateur authentifié, y compris les abonnés. Il n'y a par ailleurs aucune vérification de capacité (capability check) dans cette fonction. Un abonné peut donc déclencher le rendu d'un shortcode arbitraire via AJAX, passer un chemin absolu en valeur de custom_svg, et recevoir le contenu du fichier dans la réponse.

Dans la pratique, cela signifie qu'un compte créé gratuitement sur un site WordPress avec Avada Builder peut lire wp-config.php en entier. La version 3.15.2 publiée en avril n'apportait qu'une correction partielle - le fait qu'Avada ait dû publier une seconde version corrective (3.15.3) indique que la vulnérabilité était plus profonde qu'elle ne l'apparaissait initialement, ce qui est fréquent sur les fonctions de lecture de fichiers imbriquées dans des shortcodes. La version 3.15.3 du 12 mai 2026 constitue le correctif définitif, selon Wordfence Intelligence.

CVE-2026-4798 : injection SQL sans identifiant (condition : ex-utilisateurs WooCommerce)

7.5 Score CVSS

CVE-2026-4798 - Avada Builder (Injection SQL aveugle)

Aucune authentification requise → injection SQL time-based via product_order → extraction de données sensibles (hachages de mots de passe, emails, données personnelles). Condition : tables WooCommerce présentes en base.

La condition qui change tout

Cette faille a une particularité qui mérite attention : elle ne peut être exploitée que si les tables wc_order_product_lookup et wc_orders existent dans la base de données. Ces tables sont créées par WooCommerce. Si vous n'avez jamais installé WooCommerce, votre site n'est pas exposé à cette vulnérabilité.

Mais voici le cas qui concerne probablement des centaines de milliers de propriétaires de sites : WooCommerce a été installé pour tester une boutique, utilisé quelques mois, puis désactivé - sans suppression des tables en base. Ces tables restent, WooCommerce n'est plus actif, et la faille reste exploitable par n'importe quel visiteur anonyme.

Pourquoi sanitize_text_field() ne suffit pas

Le problème vient de la méthode post_query() dans la classe FusionSC_PostCards. Le paramètre GET product_order est récupéré et traité avec sanitize_text_field() - une fonction correcte pour filtrer des données textuelles, mais qui ne protège pas contre l'injection SQL. Ce paramètre est ensuite inséré directement dans une clause ORDER BY, sans passer par $wpdb->prepare().

// sanitize_text_field() ne protège PAS contre l'injection SQL $args['order'] = isset( $_GET['product_order'] ) ? sanitize_text_field( wp_unslash( $_GET['product_order'] ) ) : $defaults['order']; // ORDER BY injecté directement, sans prepare() $query = "SELECT ... ORDER BY last_purchased {$args['order']} LIMIT %d"; $rows = $wpdb->get_results( $wpdb->prepare( $query, $limit ) );

Une injection en UNION n'est pas possible à cause de la structure de la requête. L'attaquant doit utiliser une approche temporelle (time-based blind) : des expressions CASE WHEN combinées à SLEEP(), en observant le temps de réponse du serveur pour extraire bit par bit le contenu de la base. C'est lent - mais ça fonctionne, et les outils automatisant ce type d'attaque sont publics. Selon OWASP, ce type d'injection aveugle permet d'extraire des données complètes sans jamais déclencher d'erreur SQL visible.

Ce qu'un attaquant peut faire concrètement

La cible évidente de CVE-2026-4782 est wp-config.php. Ce fichier contient le nom d'hôte de la base, l'utilisateur et son mot de passe, ainsi que les clés secrètes et salts cryptographiques de WordPress. Avec ces données, un accès direct à la base devient possible si MySQL accepte des connexions distantes - ce que certains hébergements mutualisés permettent par défaut. Dans les audits de sites compromis que nous conduisons, la lecture de wp-config.php est systématiquement l'une des premières actions documentées une fois qu'un attaquant a établi un point d'appui : les identifiants de base de données ouvrent l'accès à l'ensemble du contenu du site. Mais wp-config.php n'est pas le seul fichier exposé : les .env, les fichiers de configuration de plugins stockant des clés API, les .htpasswd sont tout autant lisibles.

CVE-2026-4798 vise différemment. L'extraction de la table wp_users donne accès aux hachages de mots de passe, aux adresses email et aux noms d'utilisateur de toute la base. Ces hachages peuvent être soumis à des attaques par dictionnaire hors ligne, sans que le site ne voie passer la moindre tentative de connexion suspecte. Les données personnelles WooCommerce (adresses, historiques de commandes) sont extractibles par la même voie.

Si votre site était exposé avant la mise à jour et que des inscriptions ouvertes étaient actives, changez les identifiants de base de données dans wp-config.php et régénérez les clés secrètes WordPress. Si vous avez besoin d'aide pour ces vérifications, notre service de réparation WordPress d'urgence peut intervenir rapidement.

Les indicateurs de compromission à surveiller dans vos logs serveur :

POST vers /wp-admin/admin-ajax.php?action=get_shortcode_render
Paramètre custom_svg contenant un chemin absolu (/var/www/, /home/, /etc/)
GET avec product_order contenant SLEEP() ou CASE WHEN
Temps de réponse anormalement longs sur les pages Post Cards
Comptes abonnés créés récemment sans invitation
Accès répétés à wp-config.php dans les logs Apache ou Nginx

Versions concernées et correctif

CVE Type de faille Versions vulnérables Version corrigée Auth. requise
CVE-2026-4782 Lecture arbitraire de fichiers ≤ 3.15.2 ≥ 3.15.3 Abonné+
CVE-2026-4798 Injection SQL aveugle (time-based) ≤ 3.15.1 ≥ 3.15.2 Aucune (si tables WC présentes)
Comment vérifier votre version : Tableau de bord WordPress → Extensions → recherchez "Avada Builder" ou "fusion-builder". La version affichée doit être 3.15.3 ou supérieure. Si le plugin est livré avec votre thème Avada, mettez aussi à jour le thème depuis son panneau de mise à jour dédié.

Ce qu'il faut faire maintenant

1 - Mettre à jour Avada Builder vers 3.15.3

C'est l'action prioritaire. Tableau de bord → Extensions → Mises à jour disponibles. Si Avada Builder est bundlé dans votre thème Avada, la mise à jour passe par le panneau Avada → Plugin Management, pas par les extensions WordPress standard.

2 - Vérifier l'historique des abonnés

Dans Utilisateurs → Tous les utilisateurs, filtrez par rôle Abonné. Cherchez des créations récentes inattendues. Tout compte non reconnu doit être supprimé et ses sessions révoquées via Utilisateurs → modifier le profil → Révoquer toutes les sessions.

3 - Vérifier les tables WooCommerce si pertinent

Si vous avez un jour utilisé WooCommerce puis désactivé le plugin, ouvrez phpMyAdmin et cherchez les tables wc_order_product_lookup et wc_orders. Si elles existent, examinez vos logs pour des GET avec un paramètre product_order suspect.

4 - Analyser les logs Apache ou Nginx

Cherchez des requêtes POST vers /wp-admin/admin-ajax.php avec l'action get_shortcode_render et des valeurs custom_svg contenant des chemins absolus (commençant par /var/, /home/, /etc/). Ces requêtes signalent des tentatives d'exploitation.

5 - Régénérer les clés secrètes si nécessaire

Si wp-config.php a pu être lu, régénérez vos clés secrètes via le générateur officiel WordPress, puis changez le mot de passe de votre base de données. Notre guide sur la sécurité des plugins WordPress →

Si vous gérez plusieurs sites ou n'avez pas le temps d'effectuer ces vérifications, c'est exactement ce que couvre un contrat de maintenance WordPress : mises à jour appliquées dans les heures suivant la publication des correctifs, vérifications de sécurité régulières et réaction rapide en cas d'incident.

Chronologie de la divulgation

  • 21/03
    21 mars 2026
    Rafie Muhammad soumet les deux rapports de vulnérabilité via le programme de bug bounty Wordfence.
  • 24/03
    24 mars 2026
    Wordfence valide CVE-2026-4782, confirme la preuve de concept et transmet les détails complets à l'équipe Avada.
  • 25/03
    25 mars 2026
    Wordfence valide CVE-2026-4798. L'équipe Avada accuse réception et commence à travailler sur les correctifs. Les utilisateurs Wordfence Premium, Care et Response reçoivent une règle de pare-feu pour CVE-2026-4782.
  • 13/04
    13 avril 2026
    Version 3.15.2 publiée : CVE-2026-4798 (injection SQL) est corrigée. CVE-2026-4782 (lecture de fichiers) n'est que partiellement traitée.
  • 24/04
    24 avril 2026
    Les utilisateurs de la version gratuite de Wordfence reçoivent la même règle de pare-feu pour CVE-2026-4782.
  • 12/05
    12 mai 2026
    Version 3.15.3 publiée : correction complète de CVE-2026-4782. Les deux failles sont désormais entièrement corrigées.

FAQ - Failles Avada Builder CVE-2026-4782 et CVE-2026-4798

Ma version d'Avada Builder est-elle concernée ?

CVE-2026-4782 affecte toutes les versions jusqu'à 3.15.2 inclus. CVE-2026-4798 affecte toutes les versions jusqu'à 3.15.1. La version 3.15.3, publiée le 12 mai 2026, corrige les deux. Vérifiez depuis Extensions → Mises à jour disponibles dans votre tableau de bord WordPress.

Suis-je concerné par l'injection SQL si je n'ai jamais utilisé WooCommerce ?

Non. CVE-2026-4798 nécessite la présence des tables WooCommerce (wc_order_product_lookup et wc_orders) dans votre base de données. Si vous n'avez jamais installé WooCommerce, ces tables n'existent pas. En revanche, si vous avez un jour utilisé WooCommerce puis désactivé le plugin sans supprimer ses tables, votre site reste exposé même sans WooCommerce actif.

La faille CVE-2026-4782 peut-elle être exploitée si les inscriptions sont fermées ?

Le risque est réduit mais pas nul. CVE-2026-4782 nécessite un accès Abonné. Si les inscriptions sont désactivées et qu'aucun compte non fiable n'existe sur votre site, un attaquant extérieur ne peut pas l'exploiter directement. Mais un compte client, partenaire ou contributeur avec droits minimaux suffit. La mise à jour vers 3.15.3 reste indispensable dans tous les cas.

Que contient wp-config.php et pourquoi est-ce grave ?

Ce fichier contient les identifiants de connexion à la base de données (hôte, nom, utilisateur, mot de passe) et les clés secrètes WordPress utilisées pour sécuriser les sessions et les tokens d'authentification. Avec ces informations, un attaquant peut accéder directement à votre base, lire ou modifier son contenu, et invalider toutes les sessions actives sur le site. C'est la clé principale de votre installation WordPress.

Wordfence gratuit protège-t-il contre ces deux failles ?

Pour CVE-2026-4782 : les utilisateurs Wordfence gratuit ont reçu la règle de pare-feu le 24 avril 2026, 30 jours après les utilisateurs Premium. Pour CVE-2026-4798 : tous les utilisateurs Wordfence (gratuit et premium) sont protégés par la détection anti-injection SQL intégrée. Dans les deux cas, le pare-feu est un filet de sécurité supplémentaire, pas un substitut à la mise à jour vers 3.15.3.

Deux failles, une leçon commune

Deux CVE, deux angles d'attaque différents. L'injection SQL est notée plus sévèrement (7.5 vs 6.5) - mais la condition "tables WooCommerce présentes" réduit son périmètre réel. La lecture de fichiers par un abonné est notée plus bas - pourtant sur un site avec les inscriptions ouvertes, elle est exploitable sans aucun prérequis. Quelqu'un peut s'inscrire, lire wp-config.php et repartir. Le score CVSS ne raconte pas tout.

Ce n'est pas la première fois qu'Avada Builder concentre ce type de failles. Les constructeurs de pages exposent beaucoup de fonctionnalités via des shortcodes et des endpoints AJAX - et chaque fonctionnalité exposée est une surface d'attaque. La double faille Breeze Cache et User Registration quelques semaines plus tôt suivait le même schéma : correction tardive, exploitation avant le patch, dizaines de milliers de sites touchés. Ces incidents se répètent à un rythme qui n'a plus rien d'exceptionnel.

Un profil en particulier devrait vérifier en priorité : les sites qui ont testé WooCommerce, l'ont désactivé, et pensent en être débarrassés. Les tables restent en base. CVE-2026-4798 peut être déclenchée par n'importe qui. Mettre à jour vers 3.15.3 ferme la porte - et supprimer les tables WooCommerce inutilisées via phpMyAdmin est une bonne occasion de nettoyer ce qui traîne.

Pour comprendre comment une faille comme CVE-2026-4782 s'inscrit dans une chaîne d'attaque complète, notre guide sur le déroulement d'un piratage WordPress détaille les étapes de la reconnaissance à la persistance. Si votre site a déjà été compromis, le protocole de réponse est décrit dans site WordPress piraté : que faire. Et si vous souhaitez que ces vérifications soient gérées sans que vous ayez à y penser, notre service de dépannage WordPress peut auditer votre installation dans les 24h.

À propos de l'auteur

Yohann LE DU

Expert WordPress & Sécurité web

Développeur senior depuis plus de 20 ans, spécialiste WordPress et sécurité web. Yohann accompagne les TPE, PME et associations dans la maintenance préventive et la sécurisation de leurs sites WordPress.

Votre site utilise Avada Builder ? Vérifiez sa version maintenant.

Une version non à jour expose wp-config.php et votre base de données. Notre service de maintenance WordPress applique les correctifs critiques dans les heures suivant leur publication.