CVE-2026-6279: Avada Builder Unauthenticated RCE
Standard scheduled maintenance window.
CVE-2026-6279 is a critical Avada Builder vulnerability affecting versions 3.15.2 and earlier. The unauthenticated remote-code-execution flaw can be reached over the network without a WordPress account or user interaction. Upgrade to Avada Builder 3.15.3 or later immediately.
TL;DR - CVE-2026-6279 affects Avada Builder, also known as Fusion Builder, versions 3.15.2 and earlier. - Upgrade to version 3.15.3 or later. Disable the plugin if immediate patching is impossible. - No verified public PoC or confirmed in-the-wild exploitation was identified in the reviewed sources. - Affected sites should still be treated as high priority because exploitation requires no authentication.
Are You Affected?
CVE-2026-6279 affects ThemeFusion’s Avada Builder WordPress plugin, also known as Fusion Builder. The affected version range is 3.15.2 and earlier. The vulnerability was published on May 21, 2026, and the NVD record was last modified on July 23, 2026.
| Field | Details |
|---|---|
| CVE | CVE-2026-6279 |
| Product | ThemeFusion Avada Builder / Fusion Builder WordPress plugin |
| Affected versions | 3.15.2 and earlier |
| Fixed version | 3.15.3 or later |
| CVSS v3.1 | 9.8 Critical |
| Attack vector | Network |
| Attack complexity | Low |
| Privileges required | None |
| Authentication required | No |
| User interaction | None |
| Impact | High confidentiality, integrity, and availability |
| Patch available | Yes |
| CISA KEV | No |
Sites should be treated as affected if Avada Builder is installed and its version is 3.15.2 or lower. A site using the Avada theme may also have Avada Builder installed as a companion component. Verify the plugin version rather than relying only on the theme version.
For background on vulnerability terminology, see our practitioner’s definition of model extraction and glossary definition of an intrusion detection system.
The vulnerability can be reached through WordPress’s admin-ajax.php endpoint using the fusion_get_widget_markup action. The action is registered for unauthenticated users, and the relevant nonce can be exposed on public pages. The flaw therefore does not require a WordPress account or a visitor to click a malicious link.
The Fix, If You’re in a Hurry
Upgrade Avada Builder to version 3.15.3 or later. Prefer the latest version supplied through ThemeFusion or the normal WordPress update channel rather than stopping at the minimum fixed version. Version 3.15.2 is not a fix for this vulnerability.
From the WordPress administration interface, open Dashboard → Updates, locate Avada Builder or Fusion Builder, and install the available update. If WP-CLI is available, first identify the installed slug and version, then update the plugin using the command appropriate to the site’s repository configuration:
wp plugin list --format=table | grep -Ei 'fusion|avada'
wp plugin update fusion-builder
If the plugin is installed under a different directory or is distributed through a vendor-managed update channel, use the ThemeFusion-provided package or update mechanism. Confirm the resulting version:
wp plugin get fusion-builder --fields=name,status,version
If immediate patching is not possible, disable Avada Builder where operationally feasible:
wp plugin deactivate fusion-builder
Disabling the plugin may break page rendering or site functionality, so test the result and use maintenance controls if needed. As a temporary defensive measure, restrict or block unauthenticated requests to the fusion_get_widget_markup action at the web application firewall or reverse proxy. This is not equivalent to patching: request parsing and endpoint behavior can vary, and an application-layer control may be bypassed if it is incomplete.
Analyst’s Take: Patch first, then investigate exposure. The flaw combines network reachability, no required privileges, no authentication, and no user interaction, while the available evidence does not establish confirmed exploitation. A WAF rule or plugin deactivation can reduce immediate exposure, but neither replaces upgrading to 3.15.3 or later.
How This Vulnerability Works
The flaw is located in the wp_conditional_tags case handled by Fusion_Builder_Conditional_Render_Helper::get_value(). The vulnerable path accepts values from a Base64-decoded JSON object and passes attacker-controlled input to PHP’s call_user_func() without sufficient allowlist validation.
In PHP, call_user_func() invokes a callable supplied at runtime. If an application allows an attacker to influence that callable, the attacker may be able to select functions that perform sensitive operations. Here, insufficient validation creates a function-injection condition that can lead to arbitrary code execution in the WordPress process.
The endpoint is exposed through the fusion_get_widget_markup AJAX action. Avada registers the action for unauthenticated users through wp_ajax_nopriv_fusion_get_widget_markup. The endpoint uses a fusion_load_nonce, but the nonce is generated for user ID 0 and can be exposed in JavaScript output on public pages containing Avada elements such as [fusion_post_cards] or [fusion_table_of_contents].
Technical Notes
The relevant code areas identified in the available references include the widget-related AJAX handling and conditional-render helper:
Fusion_Builder_Conditional_Render_Helper::get_value()
wp_ajax_nopriv_fusion_get_widget_markup
fusion_get_widget_markup
wp_conditional_tags
The remediation in version 3.15.3 or later reportedly guards the previously unsafe call_user_func() path with input validation. Defenders should still validate the installed version directly and should not infer that an installation is protected merely because other Avada issues were fixed in version 3.15.2.
Severity, Explained
The vulnerability has a CVSS v3.1 score of 9.8, rated Critical. Its vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
The score is driven by an attack path that is remotely reachable over the network (AV:N), requires low attack complexity (AC:L), needs no privileges (PR:N), and requires no user interaction (UI:N). The vulnerable functionality can therefore be targeted directly against an exposed WordPress site rather than requiring an authenticated administrator or a victim to load a specially crafted document.
The impact metrics are all high. Successful exploitation may compromise confidentiality by exposing database or application data, integrity by modifying WordPress content or files, and availability by disrupting the site or host. The scope remains unchanged (S:U), meaning the scored impact is within the vulnerable WordPress security authority, although code execution on a server can still create broader operational consequences depending on deployment permissions.
A CVSS score describes technical severity, not observed exploitation. It does not prove that attackers are currently using the vulnerability, and it does not account for every environmental control. Internet exposure, filesystem permissions, backup quality, web-application-firewall coverage, and the privileges of the WordPress service account all affect practical risk.
Is It Being Exploited?
No confirmed in-the-wild exploitation was identified in the reviewed sources. No verified public proof-of-concept repository was identified either. The vulnerability is also not listed in the CISA Known Exploited Vulnerabilities catalog as of the information reviewed.
Those facts do not show that exploitation is impossible or that the risk is low. Absence from CISA KEV means CISA has not included this CVE in that catalog; it does not establish that no exploitation has occurred. Similarly, the absence of a verified public PoC does not prevent independent exploitation, private research, or opportunistic probing.
The practical assessment is therefore: unauthenticated exploitation is technically possible; public PoC status is not verified; confirmed active exploitation is not known from the reviewed sources; CISA KEV status is no. Because the vulnerability provides a direct path to arbitrary code execution with no authentication, organizations should remediate before exploitation evidence appears.
Detecting It in Your Environment
Begin by inventorying every WordPress installation that uses Avada Builder or Fusion Builder. Check active, inactive, staging, and forgotten sites, including instances managed outside the organization’s main hosting platform. Any installation at version 3.15.2 or earlier should be considered vulnerable until upgraded or removed.
Review web-server, reverse-proxy, WAF, and WordPress logs for requests to wp-admin/admin-ajax.php containing the fusion_get_widget_markup action. Requests with unusual parameters, repeated failures, unexpected Base64-like values, or activity from unfamiliar sources should receive priority review. A matching request is not by itself proof of exploitation, because legitimate Avada rendering can also use the action.
Technical Notes
A basic Apache or NGINX access-log search can identify the AJAX action:
zgrep -hE 'POST .*/wp-admin/admin-ajax\.php[^ ]*' /var/log/nginx/access.log* \
| grep -E 'fusion_get_widget_markup|fusion_load_nonce'
If parameters are logged in the request URI, search directly for the action:
grep -RniE 'fusion_get_widget_markup|fusion_load_nonce' /var/log/nginx /var/log/apache2 2>/dev/null
For environments using Elastic Common Schema, an initial Elasticsearch query could be adapted as follows:
url.original:*admin-ajax.php* AND
url.original:*fusion_get_widget_markup*
Investigate requests with unusually long Base64-looking parameter values, repeated requests across many sites, HTTP 200 responses followed by file changes, and activity that is followed by new administrative users or outbound connections.
Also inspect the host for post-exploitation indicators:
find wp-content -type f -name '*.php' -mtime -14 -ls
wp user list --role=administrator
wp cron event list
These commands provide triage signals, not proof of compromise. Compare changed files against known-good plugin and theme packages, inspect administrator-account creation timestamps, and correlate web requests with PHP-FPM, system, database, and outbound-network logs. If compromise is suspected, preserve logs and acquire a forensic copy before cleaning the host.
Recommended Response Plan
- Identify affected installations. Inventory active, inactive, staging, and forgotten WordPress sites.
- Confirm versions directly. Treat Avada Builder 3.15.2 and earlier as vulnerable.
- Upgrade immediately. Install version 3.15.3 or the latest available release.
- Disable if necessary. Deactivate the plugin temporarily if patching cannot happen immediately.
- Review exposure. Search web, WAF, PHP, and system logs for suspicious AJAX activity.
- Check for persistence. Inspect administrator accounts, modified files, scheduled tasks, and outbound connections.
- Document remediation. Record the previous and current plugin versions, update time, and investigation results.
For additional WordPress security context, review guidance on out-of-band patches.
References and Further Reading
The primary CVE record is available from the CVE Program:
The NVD and advisory records provide additional vulnerability metadata and affected-version information:
The following source references identify the relevant Avada Builder code paths and vendor update information:
- Avada changelog
- Fusion Builder AJAX and widget-related source
- Fusion Builder conditional-render helper
- Additional conditional-render helper reference
- Fusion widget shortcode reference
Administrators should record the installed plugin version, update to 3.15.3 or later, and retain evidence of the change. If the site was exposed while running an affected version, review logs and filesystem changes even after patching; upgrading closes the vulnerability but does not remove persistence that may already have been installed.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.