Avada Builder flaws expose over 1 million WordPress sites to file read and SQL injection risks

Two vulnerabilities in the Avada Builder WordPress plugin exposed more than 1 million sites to file disclosure and database theft risks before they were patched.

The flaws are tracked as CVE-2026-4782 and CVE-2026-4798. One allows subscriber-level users to read sensitive server files, while the other allows unauthenticated attackers to run time-based SQL injection attacks under specific site conditions.

Wordfence says both issues were reported through its Bug Bounty Program by researcher Rafie Muhammad. The Avada team released a partial patch on April 13, 2026, and a full fix in Avada Builder 3.15.3 on May 12, 2026.

What happened with Avada Builder?

Avada Builder, also known by the plugin slug fusion-builder, is bundled with the Avada WordPress theme. It powers layout building, design elements, shortcodes, and page sections across a large number of WordPress sites.

That popularity makes any serious vulnerability in the plugin a high-priority issue. Wordfence estimates Avada Builder has around 1 million active installations, giving attackers a large target base if site owners delay updates.

The two May 12 flaws affect different parts of the plugin. CVE-2026-4782 affects shortcode handling, while CVE-2026-4798 affects a database query tied to product ordering.

CVE	Issue	Access needed	Affected versions	Severity
CVE-2026-4782	Arbitrary file read via custom_svg shortcode parameter	Subscriber-level account or higher	Avada Builder up to 3.15.2	6.5 Medium
CVE-2026-4798	Time-based SQL injection via product_order parameter	No authentication required	Avada Builder up to 3.15.1	7.5 High
Fix	Full patch released	Update required	Avada Builder 3.15.3 or later	Patched

File read flaw can expose wp-config.php

CVE-2026-4782 allows authenticated attackers with subscriber-level access or higher to read arbitrary files from the server.

The bug sits in how Avada Builder handles the custom_svg parameter inside the fusion_section_separator shortcode. Because the plugin did not properly validate the file source and file type, an attacker could abuse the shortcode to read files outside the intended path.

The most serious target is wp-config.php. This file usually stores WordPress database credentials, authentication keys, salts, and other sensitive configuration values.

Why subscriber-level access still matters

Some site owners may underestimate the file read bug because it requires a logged-in user account. That assumption can be dangerous.

Many WordPress sites allow public registration, customer accounts, membership accounts, forum users, or low-level subscriber profiles. Attackers may also obtain a low-privileged account through credential stuffing or phishing.

Once attackers read wp-config.php, they may gain enough information to access the database, reset admin access, or plan a wider compromise depending on the hosting setup.

• The flaw can expose server-side files.
• Subscriber-level access is enough to exploit it.
• wp-config.php is the highest-risk target.
• Database credentials and salts may be exposed.
• Sites with open registration face a higher practical risk.

SQL injection can expose database data

CVE-2026-4798 is a time-based SQL injection vulnerability in the product_order parameter. It affects Avada Builder versions up to and including 3.15.1.

The issue exists because user-supplied input was not safely prepared before being used in an SQL query. Attackers can use timing-based SQL injection techniques to extract database information slowly, even when the page does not print the stolen data directly.

Wordfence says the flaw can allow unauthenticated attackers to extract sensitive database data, including password hashes.

WooCommerce condition limits the SQL injection

The SQL injection flaw does not apply to every Avada Builder site in the same way. Exploitation requires a specific WooCommerce-related condition.

According to public reporting, the attack works when WooCommerce had been installed and activated on the site before, then later disabled, while the relevant database tables remained in place.

That condition limits the number of exploitable sites, but it does not remove the risk. Many WordPress stores test WooCommerce, migrate away from it, or disable it while leaving old tables behind.

Risk question	Why it matters
Does the site run Avada Builder?	The vulnerabilities affect the fusion-builder plugin.
Is the version older than 3.15.3?	Older versions may remain exposed.
Does the site allow user registration?	That increases the practical risk of the file read flaw.
Was WooCommerce installed and later disabled?	That condition may make the SQL injection exploitable.
Are old WooCommerce tables still present?	Leftover tables may keep the attack path available.

Patch timeline

Wordfence says it received the vulnerability submissions on March 21, 2026. The arbitrary file read report was validated on March 24, and the SQL injection report was validated on March 25.

The Avada team received the full details through the Wordfence Vulnerability Management Portal on March 24 and March 25. The vendor acknowledged the reports and began work on a fix.

Avada Builder 3.15.2 arrived on April 13 as a partial patch. Wordfence says Avada Builder 3.15.3, released on May 12, fully addressed the two vulnerabilities.

1. March 21, 2026: Wordfence received both vulnerability submissions.
2. March 24, 2026: Wordfence validated the file read flaw and sent details to the vendor.
3. March 25, 2026: Wordfence validated the SQL injection flaw and sent details to the vendor.
4. April 13, 2026: Avada Builder 3.15.2 was released as a partial patch.
5. May 12, 2026: Avada Builder 3.15.3 was released as the full patch.

A newer Avada RCE advisory adds urgency

Since the May 12 disclosure, Wordfence has also listed another Avada Builder vulnerability: CVE-2026-6279. That separate issue affects Avada Builder versions up to and including 3.15.2 and is rated 9.8 Critical.

The newer flaw involves unauthenticated remote code execution through PHP function injection in the render_logics shortcode attribute via a widget AJAX handler.

Wordfence lists Avada Builder 3.15.3 as the patched version for that newer issue as well. This means site owners should not stop at 3.15.2, even if they believe they already applied the earlier partial fix.

What site owners should do now

WordPress administrators should update Avada Builder to version 3.15.3 or later immediately. Sites using the Avada theme should confirm the bundled builder plugin version, not only the theme version.

After updating, administrators should review user accounts, especially low-level accounts that no longer need access. They should also check whether WooCommerce was previously installed and whether old order lookup tables remain in the database.

If a vulnerable version ran on a site with public registration or untrusted subscriber accounts, administrators should treat wp-config.php exposure as possible and review database access logs, admin accounts, and authentication secrets.

• Update Avada Builder to 3.15.3 or later.
• Confirm that the active plugin version changed after updating.
• Remove unused subscriber, customer, and test accounts.
• Check whether public registration is enabled.
• Review whether WooCommerce was installed and later disabled.
• Check database logs for suspicious timing-based requests.
• Rotate database credentials if wp-config.php exposure cannot be ruled out.
• Review administrator accounts for unexpected changes.

How to reduce WordPress plugin risk

Widely used plugins can still contain serious bugs. Popularity does not remove the need for updates, monitoring, and access control.

Site owners should keep premium themes and bundled plugins updated through official vendor channels. They should also maintain current backups before applying major updates, especially on e-commerce sites.

Security teams should track plugin versions across all managed WordPress installations. This is especially important for agencies, hosting providers, and businesses that operate many sites with the same theme stack.

• Use a plugin inventory across all WordPress sites.
• Enable automatic update alerts where possible.
• Limit user registration to sites that actually need it.
• Give users the lowest role needed for their task.
• Remove inactive accounts and old test users.
• Use a web application firewall for virtual patching.
• Back up sites before plugin and theme updates.
• Monitor vendor advisories for bundled plugins.

Why this matters for WordPress security

The Avada Builder case shows how plugin vulnerabilities can quickly become a large-scale WordPress security problem. One flaw can affect a small site, an online store, an agency-managed website, and a corporate marketing site at the same time.

The file read flaw can expose configuration secrets. The SQL injection flaw can expose database content. The separate newer RCE advisory increases the pressure to update quickly.

For site owners, the safest response is direct: update Avada Builder, verify the version, reduce unnecessary accounts, and review the site for signs of suspicious access.

FAQ