ACF: CVE-2025-54940: why 6.4.3 is still a must-have update (even if the CVSS score is moderate)

Author:

Robin Labadie (LRob)

CEO, System Administrator - LRob | WordPress Expert

08/08/2025

Security

Advanced Custom Fields (ACF) powers more than 2 million WordPress sites. On 08/08/2025, a vulnerability referenced CVE-2025-54940 was published. It concerns HTML injections possible in certain uses of ACF up to and including version 6.4.2. The WPEngine editor has delivered a correction in 6.4.3.

Details of the CVSS flaw

CVE: CVE-2025-54940
Base score: 4.6
Published on: 08/08/2025

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N → Base 4.6
CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:N/I:L/A:N → Base 3.4

Translation: remote exploitation possible, not very complex, but high rights required and user interaction necessary; impact mainly on integrity (content injection/modification), not on confidentiality or availability. Hence a "moderate" score - but not one to be ignored.

What vulnerability does

Concretely, a user with access to custom fields can insert HTML code that will be displayed as is on pages.
Result: degraded rendering, trickery of visitors via trapped content (fake buttons, banners, links), and trempline to XSS depending on how your theme/blocks redisplay these fields.

On the administration side, ACF points out that unintentional import of malicious content (e.g. via JSON of field groups) could also pose a problem in certain use cases.

Finally, we can assume that in certain ACF contexts, simple content editing by a user (not necessarily admin) could be enough to exploit the flaw.

Why bother if the score is "only" 4.6?

Exposure area huge (massively deployed plugin).
The "PR:H + UI:A" combination won't protect you if you have several powerful administrators/editors, if you import third-party JSON, or if automations process ACF content.
The impact may seem "visual", but a proximity XSS can become an escalation lever (admin session theft, third-party script injection, etc.) if the escape is lax.

Versions affected and patch

Vulnerable: ACF ≤ 6.4.2 (depending on integration context and escapement).
Correction: 6.4.3 (ACF and ACF PRO).

Plausible operating scenarios

Insertion of trapped HTML in an ACF field displayed "raw" by the theme → dummy buttons, pop-ups, redirects.
Internal phishing: content resembling legitimate components (CTAs, forms) to trick users.
Chain to XSS if the output is not secured (esc_html, esc_attr, wp_ksesetc.).
Import groups of fields (JSON) containing malicious values, then re-posted in admin or front-end.

What to do now (priorities)

Update ACF to 6.4.3 everywhere (prod, preprod, clones).
Developers: check the escaping of ACF fields in theme/blocs/shortcodes: never display "raw" what comes from a field.
Check rights: who can create/edit fields, import JSON, publish rich content?
Avoid unreliable imports: don't load groups of fields from external sources without auditing. A good reminder.
Monitor: active WAF, admin logs, alerts on template/sensitive page modifications.

Recommended hardening (bonus)

Deploy a Content-Security-Policy to limit the execution of unexpected scripts.
Centralize ACF output via helpers who systematically escape.
Replay critical pages with an XSS scanner and crawl for unexpected HTML elements.
Activate a WAF (application firewall), as default on LRob hosting.

FAQ

"My site looks healthy, can I wait?"

Bad idea: the cost of an MEP is minimal compared to the risk of content detour on key pages.

"My theme already escapes variables, am I covered?"

You reduce the risk, but update anyway you don't master all the entry points (imports, third-party blocks/shortcodes).

"I can't patch today".

Activate a WAF, freeze non-essential accounts, deactivates temporarily the "rich" displays likely to be injected, then schedule the update as soon as possible.