CVE-2024-8672: Contributor-to-RCE in the Widget Options Plugin (100,000+ Sites, CVSS 9.9)

If your WordPress site accepts contributions from more than one person – guest authors, freelance writers, junior editors – a critical vulnerability in one of the web’s most popular widget plugins should have your full attention. Widget Options – The #1 WordPress Widget & Block Control Plugin, installed on more than 100,000 sites, contained a flaw that let a low-privileged user run arbitrary PHP code on the server. That is about as bad as it gets: it turns a contributor account into a foothold for complete site takeover.

The vulnerability is tracked as CVE-2024-8672 and carries a CVSS score of 9.9 out of 10 – critical. It was fixed in version 4.0.8. If you run Widget Options and haven’t updated in a while, this post explains what the flaw is, why it matters, and exactly how to check and fix your site.

CVE details at a glance

• CVE ID: CVE-2024-8672
• Plugin: Widget Options – The #1 WordPress Widget & Block Control Plugin (by MarketingFire)
• CVSS 3.1 score: 9.9 (Critical) – vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
• Vulnerability type: Remote Code Execution via Code Injection (CWE-94)
• Privilege required: Contributor-level access or above
• Affected versions: All versions up to and including 4.0.7
• Patched version: 4.0.8
• Active installations: 100,000+
• Disclosed by: Wordfence (published November 28, 2024)

How the vulnerability works

Widget Options gives site owners fine-grained control over where widgets and blocks appear. One of its most powerful features is display logic: a small field where you can write a conditional expression to decide whether a widget or block should be shown – for example, only display something on the front page, or only for logged-in visitors. This feature extends several popular page builders, including Elementor, Beaver Builder, and the native Gutenberg block editor.

The problem is in how that logic was evaluated. To turn your conditional expression into a true-or-false decision, the plugin passed the input directly to PHP’s eval() function. eval() takes a string and executes it as live PHP code. Used carelessly, it is one of the most dangerous functions in the language, because anything the attacker can put into that string, the server will run.

In this case the plugin applied no filtering and no capability checks to the display logic input before evaluating it. That means the expression was never restricted to a safe list of allowed operations, and the plugin never verified that the person supplying it had permission to run code. Instead of writing a harmless condition like is_front_page(), an attacker could supply a string that calls system functions, writes files, or opens a shell – and the server would obediently execute it.

What does an attacker need to pull this off? Just one thing: an account with Contributor privileges or higher. Contributor is a deliberately limited role – contributors can write drafts but normally cannot publish them, install plugins, or touch site settings. Because this flaw lets a contributor jump straight to running server-side code, it collapses the entire permission model that’s supposed to keep low-trust users boxed in.

Real-world impact

Remote code execution is the most severe class of web vulnerability because it removes the boundary between “user of the site” and “operator of the server.” Once an attacker can run PHP of their choosing, the practical consequences include:

• Full site takeover. The attacker can create a new administrator account, disable your existing admins, and lock you out entirely.
• Backdoors and web shells. They can write malicious PHP files into your uploads or theme directories, giving them a way back in even after you update the plugin.
• Data theft. Your wp-config.php holds database credentials; from there an attacker can dump customer records, order history, email addresses, and hashed passwords.
• Content and SEO abuse. Compromised sites are routinely used to inject spam links, serve malware to your visitors, or redirect traffic to scam pages – which can get your domain blacklisted by Google.
• Pivoting. On shared hosting, a foothold in one site can sometimes be used to attack neighboring sites on the same server.

Because the barrier to entry is a contributor account, the sites most at risk are exactly those that welcome outside contributors: news and magazine sites, community blogs, and membership platforms where the default role has been bumped up.

How to check if you’re affected

Determining your exposure takes about two minutes:

1. Log in to your WordPress dashboard and go to Plugins > Installed Plugins.
2. Look for Widget Options in the list. (Its full name may appear as “Widget Options – Advanced Conditional Visibility for Gutenberg Blocks & Classic Widgets.”)
3. Check the version number shown beneath the plugin name. If it reads 4.0.7 or lower, your site is vulnerable.
4. Also review who has accounts on your site under Users > All Users. Pay attention to how many people hold Contributor, Author, Editor, or Administrator roles, and check whether new registrations default to Contributor under Settings > General.

If you don’t use Widget Options at all but it’s still installed, that’s worth noting too – unused plugins are pure risk with no benefit.

How to fix it

The fix is straightforward: update Widget Options to version 4.0.8 or later.

1. Go to Dashboard > Updates or Plugins > Installed Plugins.
2. If an update is available for Widget Options, click Update Now.
3. Confirm the installed version now reads 4.0.8 or higher.
4. Consider enabling auto-updates for this plugin so you don’t fall behind again: on the Plugins screen, click Enable auto-updates next to Widget Options.

Beyond patching, a few hardening steps meaningfully reduce your exposure to this class of bug:

• Audit your user accounts. Remove stale contributor and author accounts, and make sure new registrations default to the lowest role (Subscriber) rather than Contributor.
• Practice least privilege. Only give people the role they genuinely need, and only for as long as they need it.
• Restrict PHP execution in uploads. Configure your server so that files in /wp-content/uploads/ cannot be run as PHP – this blunts many post-exploitation techniques.
• Run a firewall or security plugin. A web application firewall can detect and block attempts to abuse code-injection flaws, buying you time between a vulnerability’s disclosure and your update.
• Keep offsite backups. If the worst happens, a clean, recent backup is the difference between an afternoon of cleanup and a lost site.

One important footnote: the researchers who found this bug recommended that the vendor restrict the display-logic feature to an allowlist of safe functions and limit it to administrators only. The vendor did not adopt that approach, so while 4.0.8 is considered patched, some residual risk remains in how the feature is designed. If you don’t actually rely on display logic, the safest posture is to make sure only fully trusted administrators can edit widgets and blocks – and to keep the plugin updated as further hardening lands.

The takeaway

CVE-2024-8672 is a textbook example of why WordPress security is about more than strong passwords on your admin account. A single plugin feature that trusted user input a little too much handed low-privileged accounts the keys to the whole server. The lessons are the ones that never go out of date: update plugins promptly, give every user the least privilege they can get away with, be deliberate about who gets a contributor account, and assume that any input a plugin evaluates could be turned against you. Patch to 4.0.8, tidy up your user list, and this particular door is closed.