CVE-2026-18431: Critical Unauthenticated RCE in Avada WordPress Theme (Public PoC, KEV Listed)

TL;DR

CVE-2026-18431 is a critical (CVSS 9.8) unauthenticated arbitrary file write in the Avada WordPress theme (versions up to and including 7.16) when the Fusion Builder plugin (versions up to and including 3.16) is installed and active. Attackers can write attacker-controlled PHP files to the server and execute them, achieving remote code execution and full site compromise. A public proof-of-concept exists on GitHub, and CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog on 2026-08-26 — treat internet-facing WordPress sites running both components as an emergency patch item. If you cannot patch immediately, deactivate Fusion Builder or apply virtual patching at the edge.

What happened

On August 26, 2026, Wordfence publicly disclosed CVE-2026-18431, a chain of authorization and input validation weaknesses spanning the Avada theme and its companion Fusion Builder plugin. The vulnerability allows an unauthenticated attacker to write arbitrary files to the web server, which can be leveraged to plant and execute PHP code. The same day, CISA added the CVE to the KEV catalog, signaling confirmed exploitation in the wild. A public proof-of-concept repository appeared on GitHub, lowering the barrier to entry for opportunistic attackers.

Avada is one of the best-selling commercial WordPress themes, with over one million sales. Fusion Builder is its bundled page builder. The combination is common on business, agency, and marketing sites, which means the potential victim pool is large and includes organizations that may not have mature patch processes.

Technical details

The root cause is a multi-step exploitation chain — Wordfence describes it as a six-step attack — that abuses missing authorization checks and insufficient input validation across both components. Neither component alone is sufficient: the vulnerable path requires Avada (≤7.16) and Fusion Builder (≤3.16) to be installed and active, and it also depends on certain administrator-authored content being present on the site.

When those preconditions are met, an unauthenticated remote attacker can reach a code path that fails to verify the caller's identity and fails to validate the destination or contents of a file write operation. The result is an arbitrary file write primitive on the underlying server, constrained primarily by the web server user's filesystem permissions. Because the write target can be a location the web server executes, the attacker can plant PHP code and trigger it through a normal HTTP request, escalating the file write into remote code execution.

The weakness maps conceptually to CWE-862 (Missing Authorization) and CWE-434 (Unrestricted Upload of File with Dangerous Type), though the source advisory does not assign a specific CWE. The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-reachable, low complexity, no privileges required, no user interaction, with high confidentiality, integrity, and availability impact.

Attack prerequisites are: network reachability to the WordPress site, Avada ≤7.16, Fusion Builder ≤3.16, both active, and the presence of the administrator-authored content the exploit chain depends on. No authentication, no user interaction, and no special network position are required beyond HTTP access.

Exploitation in the wild

CISA added CVE-2026-18431 to the KEV catalog on 2026-08-26, which is a strong signal that the vulnerability has been exploited in real attacks. The public PoC on GitHub further increases the likelihood of mass scanning and opportunistic exploitation. Defenders should assume that automated scanners are already probing internet-facing WordPress sites for the vulnerable component combination.

While the EPSS score is currently low (0.00638, percentile 0.49174), EPSS is a probabilistic forecast and should not override KEV status or the critical CVSS rating. The KEV listing is the authoritative signal here: treat this as an emergency.

Exposure validation

Before you can remediate, you need to know where you are exposed. Use the following steps to validate exposure across your estate:

1. Inventory WordPress sites. Identify all internet-facing and internal WordPress installations. Include sites managed by marketing, agencies, and subsidiaries — they are often outside central patch oversight.
2. Fingerprint Avada and Fusion Builder. Check for the presence of /wp-content/themes/Avada/ and /wp-content/plugins/fusion-builder/ paths. Version strings in asset URLs (for example, ?ver=7.16) can help confirm installed versions.
3. Confirm version ranges. Avada ≤7.16 and Fusion Builder ≤3.16 are vulnerable. If either component is absent or inactive, the site is not exploitable via this chain.
4. Verify the admin-authored content precondition. The exploit chain requires certain administrator-authored content to be present. Not every matching site is exploitable, but this precondition is common on real sites — do not assume you are safe without checking.
5. Check for signs of compromise. Review web server logs for unauthenticated POST requests to Fusion Builder AJAX endpoints or REST routes, followed by GET requests to newly created PHP files. Inspect upload and cache directories for unexpected PHP files.
6. Prioritize internet-facing sites. Any site that matches the component and version criteria and is reachable from the internet should be treated as high priority for immediate patching or mitigation.

Indicators of compromise

• Unexpected PHP files in wp-content/uploads, wp-content/cache, wp-content/themes/Avada, or wp-content/plugins/fusion-builder directories, especially files with random names or recent modification times.
• POST requests to Avada or Fusion Builder AJAX endpoints (for example, admin-ajax.php with fusion-related actions) from unauthenticated sessions, particularly with unusual parameters or file-related payloads.
• HTTP responses with 200 status for requests to newly created PHP files that were not part of the original deployment.
• Web server logs showing sequential requests: a write attempt followed quickly by a GET to the same path.
• EDR or file integrity monitoring alerts on file creation in web root or upload directories by the web server user (www-data, apache, nginx).
• Outbound network connections from the WordPress host to unfamiliar IP addresses, especially on common C2 ports, or DNS queries to newly registered domains.
• New or modified WordPress administrator accounts, unexpected plugin or theme installations, and changes to .htaccess or wp-config.php.
• Search engine or security scanner alerts indicating injected spam, malicious redirects, or blacklisting of the site.

Detection guidance

Detection should focus on the file write primitive and the subsequent execution of the written file. Because the vulnerability is unauthenticated, any POST request to a Fusion Builder AJAX action from a session without a valid WordPress authentication cookie is suspicious. Correlate web server logs with file system events: a write to a web-accessible directory followed by an HTTP GET to the same path within a short window is a high-fidelity indicator.

Enable file integrity monitoring on WordPress directories, with alerts on new PHP files in upload and cache directories. Restrict PHP execution in those directories via web server configuration — this is a defense-in-depth control that also breaks the final step of the exploit chain. Monitor for outbound connections from the web server process to unfamiliar destinations, which may indicate command-and-control or data exfiltration.

If you have a WAF, ensure virtual patching rules are in place for known exploit patterns targeting Avada and Fusion Builder. Review WAF logs for blocked attempts, as they can reveal scanning activity and attempted exploitation.

Remediation

• Patch immediately. Update Avada to a version later than 7.16 and Fusion Builder to a version later than 3.16 as soon as vendor patches are available. Check ThemeFusion's official channels and the Avada changelog for the fixed release.
• If patching is not possible, deactivate Fusion Builder. The vulnerability requires both components to be active. Temporarily deactivating Fusion Builder breaks the exploit chain, though it may impact site functionality.
• Apply virtual patching. Place the site behind a WAF with rules targeting the known exploit patterns, and enable rate limiting on AJAX endpoints.
• Restrict file write permissions. Limit the web server user's write access to the minimum required directories, and disable PHP execution in upload and cache directories via web server configuration.
• Enforce least privilege. Use strong authentication for WordPress administrators, remove unused plugins and themes, and audit user accounts for unauthorized additions.
• Monitor and scan. Run a full malware scan on any site that may have been exposed, and monitor for the indicators listed above.
• If compromise is suspected, isolate and rebuild. Preserve logs, rotate all secrets stored on the server (database credentials, API keys, salts), and rebuild from a known-good backup.

Business impact

Successful exploitation yields remote code execution in the context of the web server user, which in most WordPress deployments means full control of the site. Confidentiality impact is high: an attacker can read wp-config.php, database credentials, API keys, customer data, and any other files readable by the web user. Integrity impact is high: the attacker can modify theme and plugin files, inject malicious JavaScript into every page, alter content, and persist backdoors. Availability impact is high: the attacker can deface, delete, or ransom the site, or use it as a staging point for further attacks.

Downstream abuse scenarios include SEO spam injection, credential harvesting through injected scripts, redirecting visitors to malware, using the compromised host as a botnet node or proxy, and pivoting into adjacent internal systems if the WordPress host has network reachability to them. For defenders, the business exposure includes regulatory notification obligations if personal data is accessed, brand and reputational damage from defacement or malicious redirects, and the operational cost of full incident response and site rebuild.

Because the vulnerability is in a widely deployed commercial theme and its companion builder, the potential victim pool is large and includes small businesses, agencies, and enterprise marketing sites that may not have mature patch processes. The KEV listing and public PoC raise the urgency further.

Timeline

• 2026-08-26: Wordfence publicly discloses CVE-2026-18431. CISA adds the CVE to the KEV catalog. Public PoC repository appears on GitHub.
• 2026-08-26 to present: Active exploitation and scanning expected to continue. Defenders should assume compromise attempts are ongoing.

References

• CISA Known Exploited Vulnerabilities Catalog
• Wordfence Threat Intelligence Advisory for CVE-2026-18431
• Wordfence Blog: Complex 6-Step Critical RCE in Avada Theme
• GitHub Advisory GHSA-hm9x-g2wh-6xw7
• Public proof-of-concept repository on GitHub
• Avada Changelog
• BleepingComputer: Critical Avada WordPress Theme Flaw Enables Zero-Click RCE
• SOCRadar Analysis

FAQ

Is CVE-2026-18431 in CISA KEV? Yes. CISA added CVE-2026-18431 to the Known Exploited Vulnerabilities catalog on 2026-08-26, indicating confirmed exploitation in the wild.

Is there a public PoC? Yes. A public proof-of-concept repository exists on GitHub (https://github.com/HORKimhab/CVE-2026-18431). This lowers the skill barrier for attackers and increases the likelihood of mass scanning.

What versions are affected? Avada theme versions up to and including 7.16, when Fusion Builder plugin versions up to and including 3.16 are installed and active.

What is the CVSS score? CVSS v3.1 base score is 9.8 (Critical) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Do I need authentication to exploit this? No. The vulnerability is unauthenticated. However, exploitation requires both Avada and Fusion Builder to be installed and active, and certain administrator-authored content to be present.

What is the impact of exploitation? Remote code execution and complete site compromise. Attackers can read sensitive data, modify content, deploy backdoors, and potentially pivot to the underlying server infrastructure.

How do I fix it? Update Avada to a version later than 7.16 and Fusion Builder to a version later than 3.16 as soon as patches are available. If you cannot patch immediately, deactivate Fusion Builder or apply virtual patching at the edge.

What if I cannot patch right away? Deactivate Fusion Builder if business requirements allow — the vulnerability requires both components to be active. Additionally, restrict file write permissions, disable PHP execution in upload directories, and deploy WAF rules targeting the exploit patterns.

How can I tell if I have been compromised? Look for unexpected PHP files in upload or cache directories, unauthenticated POST requests to Fusion Builder AJAX endpoints, and outbound connections to unfamiliar IPs. See the Indicators of Compromise section for a full list.

Is EPSS score relevant here? EPSS is currently low (0.00638, percentile 0.49174), but it is a probabilistic forecast and should not override KEV status or the critical CVSS rating. The KEV listing is the authoritative signal.

What is the recommended priority? Treat internet-facing WordPress sites running both Avada and Fusion Builder as an emergency patch item. Given the KEV listing and public PoC, remediation should be prioritized above most other work.