Avada Builder, the page-building plugin bundled with the popular Avada WordPress ecosystem, has patched two vulnerabilities that matter because they touch two high-value areas of a site: local files and the database. Wordfence reported that roughly one million sites may be using the plugin and described the issues as an authenticated arbitrary file read and an unauthenticated time-based SQL injection path [1].
The two bugs should not be read as the same risk. CVE-2026-4782 affects Avada Builder versions up to and including 3.15.2 and lets a logged-in Subscriber-level user or higher read arbitrary files through the fusion_get_svg_from_file function and a shortcode parameter. NVD says it was only partially patched in 3.15.2 and fully patched in 3.15.3 [2]. For site owners, the practical danger is not the file read by itself but what may sit in readable files: configuration data, paths, database credentials, debug logs, backups, or secrets left near the web root.
CVE-2026-4798 is different. It affects versions up to and including 3.15.1 through the product_order parameter and can be triggered without authentication, but NVD notes an important condition: it applies only where WooCommerce was previously used and later deactivated [3]. That condition is easy to miss in a patch notice. A store that tested WooCommerce months ago, disabled it, and kept Avada Builder active can still be in the audience for this bug, while a site with no such history may not have the same exposure.
What Site Owners Should Check
Update Avada Builder to 3.15.3 or later first, then verify the version from the WordPress admin area or the filesystem rather than assuming the theme updater completed. If the site allows public registration, membership accounts, customer accounts, LMS users, forum users, or any other Subscriber-level access, treat CVE-2026-4782 as more urgent because the attacker does not need admin privileges. Review recent requests that reference Avada/Fusion Builder shortcodes, SVG handling, or unusual file path strings, and check whether sensitive files such as wp-config.php, debug logs, exported backups, or old configuration copies may have been reachable.
For CVE-2026-4798, the first question is whether WooCommerce was ever installed and later disabled on the affected site. If yes, review web server and WAF logs for repeated delayed requests or suspicious sorting/order parameters tied to product views. Time-based SQL injection often leaves a different shape than normal browsing: repeated similar URLs, response-time spikes, and probing around a single parameter. If there are signs that database data may have been queried, rotate database credentials after patching, review WordPress admin users and application passwords, and check for new plugins or theme file changes that appeared after the suspicious traffic window.
This is also a good example of why WordPress cleanup should include both version state and feature history. A site can be “not running a shop anymore” while still carrying plugin paths, options, or database structures that keep an old attack surface alive. The same lesson appeared in recent WordPress incidents involving Burst Statistics admin takeover attempts and WooCommerce checkout skimmers: patching is the first move, but the useful work is confirming what the attacker could actually reach before the fix landed.
For teams that run more than one CMS, the same patch discipline applies outside WordPress as well: Drupal administrators should also review CVE-2026-9082 in Drupal core, where PostgreSQL-backed sites were exposed to SQL injection.
References
- Wordfence Intelligence: “1,000,000 WordPress Sites Affected by Arbitrary File Read and SQL Injection Vulnerabilities in Avada Builder WordPress Plugin,” May 12, 2026. Report
- NVD: CVE-2026-4782 record for Avada Builder arbitrary file read. CVE
- NVD: CVE-2026-4798 record for Avada Builder time-based SQL injection. CVE
