The vulnerability exists in Secure Custom Fields WordPress plugin versions prior to 6.9.8, where a field definition is persisted without sanitization and later rendered as part of an HTML attribute name. An attacker who can configure fields can embed JavaScript that executes in the browsers of any user viewing a page that displays the affected field. In a multisite environment, a site administrator who does not possess the unfiltered_html capability can leverage this to inject scripts into other users’ sessions, potentially leading to session hijacking, defacement, or data exfiltration.

WordPress sites running the Secure Custom Fields plugin version 6.9.7 or earlier are affected. The problem manifests for any configuration that allows admins or non‑admins with field‑definition capability to add custom fields. The issue is relevant to both single‑site and multisite WordPress installations, but the impact is amplified on multisite networks where a site admin can affect other sites through injected scripts.

No CVSS score is provided and the EPSS score is unavailable, making precise risk quantification difficult. However, the vulnerability offers a stored XSS vector that can be triggered by users with field‑definition rights, including site administrators in a multisite scenario. Exploitation requires only the ability to create or edit a field definition, a privilege that many administrators possess. Because the script runs in the visitor’s browser, it can facilitate credential theft, cookie theft, or the execution of arbitrary JavaScript. In the absence of EPSS data, the likelihood of exploitation can be considered moderate to high, especially on actively managed sites.