On March 21st, 2026, we received a submission for an Arbitrary File Read and an SQL Injection vulnerability in Avada Builder, a WordPress plugin with an estimated 1,000,000 active installations. The arbitrary file read vulnerability can be used by authenticated attackers, with subscriber-level access and above, to read arbitrary files on the server, which may contain sensitive information. The SQL injection vulnerability can be used by unauthenticated attackers to extract sensitive data from the database, such as password hashes.
Props to Rafie Muhammad who discovered and responsibly reported these vulnerabilities through the Wordfence Bug Bounty Program. This researcher earned bounties of $3,386.00 and $1,067.00 for these discoveries. Our mission is to secure WordPress through defense in depth, which is why we are investing in quality vulnerability research and collaborating with researchers of this caliber through our Bug Bounty Program. We are committed to making the WordPress ecosystem more secure through the detection and prevention of vulnerabilities, which is a critical element to the multi-layered approach to security.
Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against any exploits targeting the Arbitrary File Read vulnerability on March 25, 2026. Sites using the free version of Wordfence received the same protection 30 days later on April 24, 2026.
Also, all Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those using the free version of our plugin, are protected against any exploits targeting the SQL Injection vulnerability by the Wordfence firewall’s built-in SQL Injection protection.
We provided full disclosure details to the Avada team instantly through our Wordfence Vulnerability Management Portal on March 24 and 25, 2026. The developer released the first patch on April 13, 2026, and the second patch on May 12, 2026.
We urge users to update their sites with the latest patched version of Avada Builder, version 3.15.3 at the time of this writing, as soon as possible.
Vulnerability Summary from Wordfence Intelligence
Technical Analysis #1:
Examining the code reveals that the plugin uses the fusion_get_svg_from_file() function to get svg content from local or remote files. This function is used by the fusion_section_separator shortcode. If the custom_svg parameter is specified, it attempts to load the SVG from the provided URL and use it in the separator HTML.
function fusion_get_svg_from_file( $url, $args = [] ) {
if ( ! $url ) {
return;
}
$svg = fusion_file_get_contents( $url );
function fusion_file_get_contents( $url ) {
$file_content = false;
// Init the filesystem.
$wp_filesystem = Fusion_Helper::init_filesystem();
// Get the contents of file.
$file_content = $wp_filesystem->get_contents( $url );
// file_exists won't work for URL (only for path).
if ( ! $file_content && ( function_exists( 'ini_get' ) && ini_get( 'allow_url_fopen' ) ) && file_exists( $url ) ) {
$file_content = file_get_contents( $url ); // phpcs:ignore WordPress.WP.AlternativeFunctions
}
// So we try alternative in case URL was passed.
if ( ! $file_content && false !== filter_var( $url, FILTER_VALIDATE_URL ) ) {
$response = wp_remote_get( $url );
if ( ! is_wp_error( $response ) && 200 === wp_remote_retrieve_response_code( $response ) ) {
$file_content = wp_remote_retrieve_body( $response );
}
}
return $file_content;
}
Unfortunately, this function does not include any file type or file source checks in the vulnerable version. This means that not only .svg files can be included, but .php files can as well.
Further examining the code reveals that the plugin uses the get_shortcode_render() function in the Fusion_Builder_Front class to render shortcodes for the builder.
public function get_shortcode_render() {
check_ajax_referer( 'fusion_load_nonce', 'fusion_load_nonce' );
$return_data = [];
FusionBuilder()->set_global_shortcode_parent( wp_unslash( $_POST['cid'] ) );// phpcs:ignore WordPress.Security.ValidatedSanitizedInput
if ( isset( $_POST['shortcodes'] ) ) {
$return_data['shortcodes'] = [];
$post_shortcodes = wp_unslash( $_POST['shortcodes'] ); // phpcs:ignore WordPress.Security.ValidatedSanitizedInput
if ( ! empty( $post_shortcodes ) ) {
foreach ( $post_shortcodes as $shortcode ) {
$shortcode = wp_unslash( $shortcode );
do_action( 'awb_before_ajax_shortcode_render', $shortcode );
$return_data['shortcodes'][ $shortcode ] = do_shortcode( $shortcode );
do_action( 'awb_after_ajax_shortcode_render', $shortcode );
}
}
}
$content = '';
if ( isset( $_POST['content'] ) ) {
$content = wp_unslash( $_POST['content'] ); // phpcs:ignore WordPress.Security.ValidatedSanitizedInput
}
do_action( 'awb_before_ajax_shortcode_render', $content );
$return_data['content'] = do_shortcode( $content );
do_action( 'awb_after_ajax_shortcode_render', $content );
echo wp_json_encode( $return_data );
wp_die();
}
Although this function is nonce protected, the nonce can be obtained by authenticated attackers in the vulnerable version of the plugin. Also, there is no capability check in this AJAX function. This made it possible for authenticated users, such as subscribers, to invoke this render shortcode AJAX action and execute arbitrary shortcodes.
This ultimately makes it possible for authenticated attackers with minimal access, like subscribers, to read any arbitrary file on the server, including the site’s wp-config.php file, which contains the database credentials as well as keys and salts for cryptographic security.
Wordfence Firewall
The following graphic demonstrates the steps to exploitation an attacker might take and at which point the Wordfence firewall would block an attacker from successfully exploiting the vulnerability.
Technical Analysis #2:
Insecure implementation of the plugin’s post card items query functionality allows for SQL injection. Examining the code reveals that the plugin uses the post_query() function in the FusionSC_PostCards class to query WordPress post card items to list them, where the order can be specified with the 'product_order' parameter.
$args['order'] = ( isset( $_GET['product_order'] ) ) ? sanitize_text_field( wp_unslash( $_GET['product_order'] ) ) : $defaults['order']; // phpcs:ignore WordPress.Security.NonceVerification.Recommended
Although the sanitize_text_field() function is used, it does not protect against SQL injection.
$query = "
SELECT opl.product_id, MAX(opl.date_created) AS last_purchased
FROM {$wpdb->prefix}wc_order_product_lookup AS opl
INNER JOIN {$wpdb->prefix}wc_orders AS o
ON opl.order_id = o.id
WHERE o.status IN ('wc-completed', 'wc-processing')
AND opl.product_id > 0
GROUP BY opl.product_id
ORDER BY last_purchased {$args['order']}
LIMIT %d
";
$product_rows = $wpdb->get_results( $wpdb->prepare( $query, $limit ), ARRAY_A );
The ORDER BY statement is added to the query without using the WordPress wpdb prepare() function. The prepare() function would parameterize and escape the SQL query for safe execution in WordPress, thereby providing protection against SQL injection attacks.
Since Union-Based SQL injection is not possible due to the structure of the query, an attacker would need to use a Time-Based blind approach to extract information from the database. This means that they would need to use SQL CASE statements along with the SLEEP() command while observing the response time of each request to steal information from the database. This is an intricate, yet frequently successful method to obtain information from a database when exploiting SQL Injection vulnerabilities.
We would like to draw attention once again to the fact that the vulnerability only critically affects users who previously used the WooCommerce plugin and then deactivated it.
Wordfence Firewall
The following graphic demonstrates the steps to exploitation an attacker might take and at which point the Wordfence firewall would block an attacker from successfully exploiting the vulnerability.
The Wordfence firewall rule detects the malicious SQL query and blocks the request.
Disclosure Timeline
March 21, 2026 – We received submissions for both an Arbitrary File Read vulnerability and an SQL Injection vulnerability in Avada Builder via the Wordfence Bug Bounty Program.
March 24, 2026 – We validated the Arbitrary File Read report and confirmed the proof-of-concept exploit.
March 24, 2026 – Full disclosure details were sent instantly to the vendor through our Wordfence Vulnerability Management Portal.
March 25, 2026 – Wordfence Premium, Care, and Response users received a firewall rule to provide protection against any exploits that may target the Arbitrary File Read vulnerability.
March 25, 2026 – We validated the SQL Injection report and confirmed the proof-of-concept exploit.
March 25, 2026 – Full disclosure details were sent instantly to the vendor through our Wordfence Vulnerability Management Portal.
March 25, 2026 – The vendor acknowledged the reports and began working on a fix.
April 13, 2026 – The partially patched version of the plugin, 3.15.2, was released.
April 24, 2026 – Wordfence Free users received the same protection.
May 12, 2026 – The fully patched version of the plugin, 3.15.3, was released.
Conclusion
In this blog post, we detailed an Arbitrary File Read vulnerability, and an SQL Injection vulnerability within the Avada Builder plugin affecting versions 3.15.2 and earlier. The Arbitrary File Read vulnerability allows authenticated threat actors with subscriber-level permissions or higher to read arbitrary files, which can contain sensitive information. The SQL Injection vulnerability allows unauthenticated threat actors to inject malicious SQL queries to steal sensitive information from the database. The vulnerabilities have been addressed in version 3.15.3 of the plugin.
We encourage WordPress users to verify that their sites are updated to the latest patched version of Avada Builder as soon as possible considering the critical nature of these vulnerabilities.
Wordfence users running Wordfence Premium, Wordfence Care, and Wordfence Response have been protected against the Arbitrary File Read vulnerability as of March 25, 2026. Users using the free version of Wordfence received the same protection 30 days later on April 24, 2026.
All Wordfence users, including those running Wordfence Premium, Wordfence Care, and Wordfence Response, as well as sites running the free version of Wordfence, are fully protected against the SQL Injection vulnerability.
If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as these vulnerabilities pose a significant risk.
The post 1,000,000 WordPress Sites Affected by Arbitrary File Read and SQL Injection Vulnerabilities in Avada Builder WordPress Plugin appeared first on Wordfence.