Shop & Support

LRob.fr

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

Written by

LRob

in

Advanced Custom Fields (ACF) powers more than 2 million WordPress sites. On 08/08/2025, a vulnerability referenced CVE-2025-54940 has been published. It concerns HTML injections possible in certain ACF applications until the version 6.4.2 included. Publisher WPEngine has delivered a patch 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 operation possible, not very complex, but high fees required and user interaction necessary; impact above all on integrity (content injection/modification), not on confidentiality or availability. Hence a “moderate” score - but not one to be ignored.

What vulnerability does

In practical terms, a user with access to custom fields can insert HTML code that will be displayed as is on the pages.
Result: degraded rendering, deceiving visitors via booby-trapped content (fake buttons, banners, links), and springboard to XSS depending on how your theme/blocks re-display these fields.

Visit administration, ACF indicates that the’unintentional import of malicious content (e.g. via JSON of groups of fields) could also pose a problem in certain use cases.

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

Why bother if the score is “only” 4.6?

  • Exhibition area huge (massively deployed plugin).
  • The “PR:H + UI:A”ACF" does not 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 close XSS can become a climbing lever (admin session theft, injection of third-party scripts, etc.) if the escape is lax.

Versions affected and patch

  • Vulnerable : ACF ≤ 6.4.2 (depending on the context of integration and exhaust).
  • Corrected : 6.4.3 (ACF and ACF PRO).

Plausible operating scenarios

  • Insertion of HTML trapped 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 secure (esc_html, esc_attr, wp_kses, etc.).
  • Import groups of fields (JSON) containing malicious values, then re-displayed in the admin or front-end.

What to do now (priorities)

  1. Update ACF to 6.4.3 everywhere (production, pre-production, clones).
  2. Developers: Check the exhaust ACF fields in the theme/blocks/shortcodes: never display what comes from a field “raw”.
  3. Check rights Who can create/edit fields, import JSON and publish rich content?
  4. Avoid unreliable imports Do not load groups of fields from external sources without an audit. A good reminder.
  5. Watch Active WAF, admin logs, alerts on changes to templates/sensitive pages.

Recommended hardening (bonus)

  • Deploy a Content-Security-Policy to limit the execution of unexpected scripts.
  • Centralise ACF outputs via helpers who systematically escape.
  • Replay critical pages with a XSS scanner and a crawl in search of unexpected HTML elements.
  • Activate a WAF (application firewall), such as active by default on LRob accommodation.

FAQ

“My site looks healthy, can I wait?”

Bad idea: the cost of an MEP is minimal compared with the risk of content being hijacked on key pages.

“My theme already escapes variables, am I covered?”

You reduce the risk, but update anyway you don't control 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 plan the update as quickly as possible.

Sources

Comments

Leave a Reply

More posts