Brief summary: Avada theme CVE-2026-115346, unauthenticated arbitrary file upload with possible RCE

Introduction

A file type validation gap in the Avada theme's Forms upload fields gave unauthenticated visitors a possible path from submitting a form attachment to executing code on WordPress sites running Avada 7.16.2 or earlier. ThemeFusion shipped the fix in Avada 7.16.4 on October 27, 2026, three days before the CVE was published. The version numbering leaves a gap at 7.16.3, and you should understand that gap before you mark a site as remediated.

Avada is a website builder theme for WordPress and WooCommerce, developed by ThemeFusion (the CVE record lists the vendor as unknown) and sold through ThemeForest since 2012. The ThemeForest listing records 1,074,584 sales, and the vendor describes Avada as the leading selling website builder on ThemeForest since launch, which is its own characterization. Sales are not a count of vulnerable sites, but that reach means Avada shows up across agency portfolios, client sites, and WooCommerce stores, so it belongs in any commercial WordPress theme inventory.

Technical information

Root cause

The vulnerable code is the convert_palette_images_to_truecolor() function. Judging by its name, it converts palette-based (indexed color) images to truecolor. According to the Wordfence advisory, the flaw is insufficient file type validation before uploaded files are processed. ThemeFusion's 7.16.4 security update places the issue in Avada Forms upload fields, and the Wordfence advisory title describes it as an unauthenticated arbitrary file upload via the Avada Form Upload Field.

The weakness is classified as CWE-434, Unrestricted Upload of File with Dangerous Type. In upload-to-RCE bugs of this kind, the dangerous step is code that writes or keeps attacker-supplied bytes on disk under an attacker-influenced name or extension, and that happens before anyone confirms the file is a real image of an allowed type. A file can look like an image at a glance (a polyglot, or a spoofed extension or MIME type) and still end up stored as something the web server will run.

The disclosure claims only that uploaded files may be executable, which makes remote code execution possible. Accepting an upload and executing it are separate steps. MITRE's general description of CWE-434 notes that execution depends on the receiving environment interpreting the uploaded file as code. That explains the risk mechanism, but it is not evidence of a specific Avada payload.

Severity and the CVSS vector

NVD displays the Wordfence CNA assessment. NIST has not provided its own score.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack vector: Network. The flaw is remotely reachable.
• Attack complexity: High. Exploitation depends on conditions beyond the attacker's control.
• Privileges required: None. No WordPress account is needed.
• User interaction: None. No victim action is required.
• Scope: Unchanged.
• Confidentiality, Integrity, Availability: High.

No authentication does not mean low complexity. The FIRST CVSS v3.1 specification defines High attack complexity in terms of conditions outside the attacker's control, and the Avada disclosures do not say which conditions produce that rating here. We should treat this as a potentially serious execution path without assuming every Avada installation is immediately exploitable or that every arbitrary upload yields code execution.

Attack flow

Based on the published descriptions, the documented path looks like this:

1. An unauthenticated attacker locates a site running Avada 7.16.2 or earlier with a published Avada Form that includes a file upload field.
2. The attacker submits a crafted file through that upload field.
3. Because file type validation is insufficient before processing in convert_palette_images_to_truecolor(), a potentially dangerous file is accepted into the image processing path.
4. If the web server can interpret the stored file as code, the attacker requests it directly, which can result in remote code execution.

The sources do not publish the request format, upload endpoint, payload, destination path, or precise execution trigger, and no verified proof of concept is available. The details above are the full extent of what the public record supports.

Patch information

Fixed version: Avada 7.16.4, released October 27, 2026. ThemeFusion's Version 7.16.4 Security Update contains one security entry:

SECURITY: Fixed a possible remote code execution vulnerability in Avada Forms upload fields.

The post thanks Wordfence, which coordinated the disclosure. The Wordfence record lists the issue as "Patched: Yes" with 7.16.4 as the patched version, and NVD lists the vendor post as the official reference for the fix.

The 7.16.3 gap

The advisory lists affected versions as up to and including 7.16.2, but names 7.16.4, not 7.16.3, as the patched release. The 7.16.3 security update (October 20, 2026) fixed two other issues:

• a Contributor+ stored XSS in Avada Forms fields
• missing authorization in a legacy Global Options migration routine

It says nothing about upload field file validation or RCE. The only release that publicly claims this fix is 7.16.4, so sites on 7.16.3 should treat 7.16.4 as the minimum safe version. A version number above 7.16.2 does not, by itself, confirm that the security update is applied.

What the fix most likely changes (inferred)

ThemeFusion has not described the code change, so this part is inference and could not be checked against source code. Fixes for CWE-434 usually move validation ahead of any image processing. Typical changes include:

• checking the real file type and extension against an allowlist, for example with WordPress's wp_check_filetype_and_ext(), instead of trusting the client-supplied name or MIME type
• refusing to process or save a file that fails those checks
• making sure the stored filename cannot end in an executable extension such as .php or .phtml

The vendor wording, "possible remote code execution" in "upload fields", fits a fix where uploaded files are checked before the palette conversion code runs.

No public diff

Avada is a commercial theme sold through ThemeForest. There is no public repository, commit, or diff for this fix, so we cannot show a code snippet. The GitHub Advisory entry for this CVE still lists patched versions as "Unknown". Version 7.16.4 is the authoritative fix.

Applying the update

The vendor's update instructions are linked from the 7.16.4 post, along with the changelog and the Important Update Info page. The documented sequence is:

1. Back up first: database, website files, and configuration files.
2. Update the theme before the plugins. If you use a child theme, switch to the parent theme before updating, then switch back and confirm the child theme works.
3. Update required plugins afterward: Avada Core first, then Avada Builder, both to their latest versions.
4. Do not keep obsolete theme files. Avoid older copies in the themes directory and do not rename the Avada folder. For manual updates, delete the old folder rather than overwriting it, so removed files do not linger.
5. Clear caches: Avada, browser, plugin, and server caches.

If patching cannot happen immediately, IONIX recommends restricting access to pages that use Avada Forms file upload fields and reviewing web-accessible upload directories for unexpected executable files such as PHP files. These recommendations come from a secondary source and do not replace the patch.

Detection methods

Where detection stands

No CVE-specific detection content has been published. cvebase shows "No detection rules found" and no indexed exploits. CVETodo lists no Sigma, Suricata, YARA, or Nuclei rules as of October 30, 2026. isMalicious finds no Nuclei template, Exploit DB entry, PoC repository, or Metasploit module, and records 0 indicators tied to the CVE over seven days.

CISA's SSVC entry says there is no evidence of exploitation, and the CISA KEV catalog snapshot version 2026.10.30 (1,766 entries) has no entry for this CVE. TheHackerWire also reports no confirmed public exploit code and no known ransomware campaign. There are no published IoCs, IPs, or payload hashes, so detection rests on exposure inventory and hunting for signs of the bug class.

1. Find exposed sites by version

With no published payload, the installed Avada version is the most accurate exposure signal. Wordfence rates all versions up to and including 7.16.2 as affected and names 7.16.4 as patched. The WPScan entry is titled "Avada ... < 7.16.4", which puts 7.16.3 in a gray zone. Treat 7.16.3 sites as needing a check, not as automatically safe.

• WPScan: scans that identify the Avada theme and its version can flag the issue by its WPVDB ID.
• Wordfence Intelligence: the record can be queried through Wordfence's free vulnerability database API and webhook feed, so you can match an Avada version inventory automatically.

2. Narrow the attack surface

The vulnerable code is reached through Avada Forms file upload fields. Prioritize sites with at least one published Avada Form that includes a file upload field. A vulnerable version with no public upload form is a smaller risk than one where anonymous visitors can submit files. Given the High attack complexity rating, do not expect every attempt to succeed.

3. Hunt on the filesystem

The clearest evidence of exploitation is an executable file somewhere it should not be. IONIX advises checking web-accessible upload directories for unexpected executable files, such as PHP files, on any site that ran an affected version.

• Search WordPress upload locations, including wherever form attachments are stored, for server-executable extensions. Image processing paths should only hold image files.
• Look closely at files whose extension and content do not match, such as something named like an image that contains script code. Since the flaw sits before an image conversion step, a file posing as an image is the most likely disguise.
• Compare file creation times against the exposure window, meaning everything before the site moved to a fixed release.

4. Review web logs

• Upload stage: unauthenticated POST requests submitting Avada Forms with file attachments, especially bursts, or requests from sources that never loaded the form page first.
• Execution stage: a later GET or POST straight to a file in an uploads directory that returns HTTP 200 with a response that is not an image. Requests for script files under uploads paths strongly suggest a successful upload being used.
• Correlation: tie the two stages together by source IP and timing. An upload followed shortly by a request to a new file under uploads is the pattern that indicates exploitation.

5. Treat generic controls as partial coverage

With no rule targeting this CVE, WAF and endpoint coverage depends on generic file upload and webshell rules. Use them as supporting signals, not as a replacement for the version and filesystem checks. Keep watching the aggregators above. If a Nuclei template, Sigma rule, or real IoCs appear, that is likely the first sign exploitation has started, and the detection approach should change accordingly.

Affected systems and versions

• Product: Avada, Website Builder For WordPress & WooCommerce theme, by ThemeFusion.
• Affected: all versions up to and including 7.16.2 (Wordfence CNA).
• Gray zone: 7.16.3 is not confirmed fixed. Its security bulletin covers other issues, and WPScan describes the affected range as below 7.16.4.
• Fixed: 7.16.4 and newer patched releases.
• Highest-risk configuration: an affected version with at least one published Avada Form containing a file upload field reachable by anonymous visitors.
• Related components to update alongside: Avada Core and Avada Builder, per the vendor's update procedure.

Vendor security history

Avada has had several unrelated security issues across different attack surfaces:

• CVE-2024-2344: SQL injection through the entry parameter in Avada through 7.11.6, requiring editor privileges or higher.
• CVE-2026-18431: a CVSS 9.8 Critical execution chain combining six weaknesses across Avada and Fusion Builder, requiring both products to be active and particular administrator-authored content. Per the Wordfence write-up, it was discovered July 30, 2026, disclosed to ThemeFusion August 5, acknowledged August 10, with a preliminary patch August 12. Avada 7.16.1 and Fusion Builder 3.16.1 shipped August 25, and the vendor's 7.16.1 bulletin corroborates that release as a remote code execution fix in the Fusion Patcher.
• 7.16.3 (October 20, 2026): fixed a Contributor+ stored XSS in Avada Forms fields and missing authorization in a legacy Global Options migration routine.
• CVE-2026-115346: the current unauthenticated upload issue, fixed in 7.16.4.

These are different vulnerability classes rather than one recurring exploit, and the August exploit details, prerequisites, and firewall protections do not transfer to this CVE. The record shows both real security failures and a documented patch response. With four security releases (7.16.1 through 7.16.4) in roughly two months, Avada operators should keep their update cycle short.

References

• NVD: CVE-2026-115346
• CVE Record: CVE-2026-115346
• Avada: Version 7.16.4 Security Update
• Wordfence Intelligence record (CVE source link)
• Wordfence Intelligence record
• Wordfence: Avada 7.16.2 and earlier, Unauthenticated Arbitrary File Upload via Avada Form Upload Field
• Avada: Version 7.16.3 Security Update
• IONIX threat center entry
• WPScan vulnerability entry
• cvebase entry
• CVETodo entry
• isMalicious entry
• TheHackerWire analysis
• Avada on ThemeForest
• Avada: About Us
• Avada: Important Update Info
• Avada: How To Update The Avada Website Builder
• Avada Changelog
• Avada: Version 7.16.1 Security Update
• Avada: Version 7.16 Security Update
• Wordfence: Complex 6 Step Critical RCE in Avada Theme
• NVD: CVE-2024-2344
• CISA Known Exploited Vulnerabilities feed
• FIRST CVSS v3.1 Specification
• MITRE CWE-434