Widget Options eval() bypass gives Contributors server-side RCE

TL;DR - Widget Options passes Display Logic expressions directly into eval(). The blocklist meant to prevent abuse can be bypassed using array_map with string concatenation. Authorization on the extended_widget_opts_block attribute is also unenforced. Net result: any Contributor-or-higher account gets arbitrary PHP execution on the server. Versions <= 4.2.2 are affected. 4.2.0 was a partial fix that didn't hold.

What happened

Widget Options - Advanced Conditional Visibility for Gutenberg Blocks & Classic Widgets is a WordPress plugin that adds conditional display rules to blocks and widgets. CVE-2026-2052 is authenticated remote code execution via that Display Logic feature.

Two problems compound each other. First, the plugin feeds user-supplied Display Logic expressions into eval(). Second, the blocklist intended to restrict what those expressions can do is insufficient - it can be bypassed using array_map combined with string concatenation. On top of that, authorization is not enforced on the extended_widget_opts_block attribute, so any Contributor-or-higher account can reach the vulnerable path.

Version 4.2.0 attempted a fix but only partially addressed the issue. That's a predictable failure mode. Once eval() is in the execution path, filtering the input is brittle. The only real fix is to remove the eval() call entirely.

Who is impacted

• WordPress sites running Widget Options - Advanced Conditional Visibility for Gutenberg Blocks & Classic Widgets at versions <= 4.2.2.
• Sites running Widget Options - Extended at versions <= 5.3.2, also listed as affected in the CVE record.
• Highest risk: multi-author deployments where non-admin roles (Contributor, Author, Editor) can create or edit content that influences block or widget rendering and triggers Display Logic evaluation.

What to do now

• Apply the latest patched release. The CVE record confirms all versions <= 4.2.2 are vulnerable and that 4.2.0 was only a partial fix - verify you are on a release that fully resolves the issue.
• Inventory every WordPress instance for widget-options and Widget Options - Extended, including staging environments and sites that skip routine plugin updates.
• Treat this as a privilege-bound RCE exposure:
  • Audit who holds Contributor-or-higher roles and revoke any grants that aren't actively needed.
  • Review recent content, widget, and block changes where Display Logic rules are configured.
  • If you suspect the vulnerability has been exploited, rotate all credentials and secrets reachable by the WordPress runtime - database credentials, SMTP passwords, third-party API keys - under your standard incident response process.