On this page (7 sections)
A critical vulnerability, CVE-2026-120534, has been published for the Advanced Custom Fields: Extended PRO plugin for WordPress. According to the NVD record, all versions up to and including 0.9.2.6 are affected, and unauthenticated attackers could call arbitrary WordPress functions with controlled arguments under certain conditions.
If you run WordPress sites that use this plugin, especially ones with front-end forms, you should check your version and configuration now. At the time of writing, only one independent publisher covers this story, and the sources we reviewed do not state a fixed version or any exploitation in the wild.
What happened
The NVD entry, published on 2026-11-03, describes a flaw in the plugin's render_field method. Form configuration parameters are not validated well enough before they are merged into field settings and passed to PHP's call_user_func_array. That lets an unauthenticated visitor influence which WordPress function gets called and with what arguments.
The description calls this "limited" code injection. The attacker does not get to run arbitrary PHP code directly. They can call WordPress functions of their choosing, which can still be serious depending on which functions are reachable. The sources do not say which functions are practical to abuse, and we will not speculate.
Technical details in plain terms
The core weakness is untrusted input reaching a dynamic function call. When code takes a function name and arguments from data a visitor can influence, and then invokes them, the safe approach is to check them against a strict allow-list first. The record says that validation step is insufficient here.
The record also says the flaw is not exploitable on every install. It names two separate conditions, which it calls Method 1 and Method 2:
| Path | What must be true |
|---|---|
| Method 1 | An administrator has enabled the non-default 'shortcode_preview' setting for the target form. |
| Method 2 | The server environment lacks OpenSSL functions, so the plugin's acf_decrypt falls back to unverified base64 decoding. |
In other words, a default configuration on a server with working OpenSSL support does not meet either condition as described. That reduces the realistic exposure, but it does not remove the need to verify. Do not assume your setup is safe without checking.
Who is realistically exposed
- Sites running Advanced Custom Fields: Extended PRO at version 0.9.2.6 or earlier.
- Sites where an administrator turned on 'shortcode_preview' for a form (Method 1).
- Sites hosted on PHP builds without OpenSSL functions, which is unusual on modern hosting but possible on stripped-down or custom environments (Method 2).
- Agencies managing many client sites, where the plugin may have been installed and forgotten.
How to check your exposure
Start by finding out whether the plugin is installed and which version it is. This WP-CLI command lists installed plugins with their status and version; run it from your WordPress root and look for an ACF Extended entry at 0.9.2.6 or lower.
wp plugin list --fields=name,status,versionNext, check whether the server has OpenSSL support in PHP. This command prints the PHP modules loaded by the command-line binary and filters for openssl. An empty result suggests it is missing, but note that the web server may use a different PHP build than the CLI, so confirm with your host if in doubt.
php -m | grep -i opensslFinally, review your forms in the WordPress admin and note any that have the 'shortcode_preview' setting enabled. The exact location of the setting is not described in the sources we reviewed, so consult the plugin documentation if you cannot find it.
What to do now
The sources do not name a patched release, so the most reliable source is the vendor's changelog. The Wordfence vulnerability entry is also referenced by the CVE record and may carry updated version details.
0 of 7 done
If you manage many sites, a WordPress security checklist can help you standardize plugin review, and the guide on checking whether a plugin is vulnerable explains how to follow advisories over time.
Detection and monitoring afterwards
Because the flaw involves unauthenticated requests, look for odd traffic to form pages, unexpected new administrator accounts, changed plugin or theme files and unfamiliar scheduled tasks. This command lists WordPress administrator accounts so you can spot unknown ones; run it from the WordPress root.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredA website firewall can add a layer of filtering in front of a site, though it is not a substitute for updating; see what a WAF is. Regular outside-in checks with Webforta Scan can also help you notice unexpected changes on sites you have verified. If you suspect a compromise, follow the steps in website hacked: what to do.
What we do and do not know
- Confirmed by the NVD record: affected versions (up to and including 0.9.2.6), the weakness description, the two conditions and the 9.8 CVSS score.
- Not confirmed in the sources reviewed: a fixed version number, whether the vendor has shipped a patch, and any exploitation in the wild.
- Coverage so far is thin: one independent publisher, plus the NVD record itself.
We will treat this as developing. Re-check the vendor changelog and the Wordfence entry before concluding that you are safe or fully patched.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.