Avada Builder CVE-2026-4798

Exploitation requires the WordPress site to have previously used WooCommerce plugin followed by its deactivation while residual WooCommerce database tables (wp_posts with product post types, wp_postmeta with WooCommerce keys, or custom WooCommerce tables) remain in the database. The vulnerable code path in Avada Builder queries these orphaned tables without proper input sanitization. Standard WooCommerce plugin deactivation does not remove database schema, creating persistent attack surface even after plugin removal. Exploitation is NOT possible on: (1) fresh Avada installations without WooCommerce history, (2) sites where WooCommerce tables were manually purged post-deactivation, or (3) sites currently running active WooCommerce (likely protected by WooCommerce's own input validation). Exploitation IS possible against: sites that tested WooCommerce during development then switched to alternative e-commerce solutions, sites that migrated from WooCommerce to other platforms, or sites that deactivated WooCommerce due to performance concerns while retaining Avada theme. Attack surface limited by this specific deployment history but expanded by WooCommerce's 30%+ market share among WordPress e-commerce sites, making residual installations common.

CVSS 7.5 indicates High severity with maximum exploitability (AV:N/AC:L/PR:N/UI:N) but impact limited to confidentiality (C:H/I:N/A:N). Real-world risk is significantly constrained by exploitation conditions: requires prior WooCommerce installation followed by deactivation, a narrow deployment scenario. EPSS data not provided, but typical blind SQL injection vulnerabilities without public exploit code show moderate probability. Not present in CISA KEV, indicating no confirmed active exploitation. SSVC assessment: exploitation status unproven, technical impact limited to data exfiltration, automation feasible for targeted attacks against known Avada+former-WooCommerce sites. Priority depends on organizational use of Avada Builder and WooCommerce history. Time-based SQLi is slower than error-based techniques, reducing appeal for mass exploitation but viable for targeted reconnaissance. Wordfence disclosure suggests vendor notification occurred; defenders should verify patch release timeline. Risk higher for high-value WordPress sites (e-commerce, membership platforms) where historical WooCommerce usage is common and database contains customer PII, payment records, or credentials.

An unauthenticated remote attacker identifies a WordPress site running Avada Builder 3.15.1 or earlier through theme fingerprinting (common in WordPress reconnaissance). Attacker probes for historical WooCommerce usage by testing for residual database tables via error-based SQLi or publicly exposed wp-json API endpoints. Once confirmed, attacker crafts HTTP requests injecting time-based SQL payloads into the 'product_order' parameter (e.g., 'product_order=id' AND SLEEP(5)--). By measuring response times, attacker extracts database contents character-by-character, including WordPress user credentials (wp_users table with password hashes), customer personal information, order history, and potentially payment tokens if stored locally. Attacker escalates by cracking admin password hashes offline, then authenticates to install malicious plugins for persistent backdoor access or defacement.