Description

The Table Field Add-on for ACF and SCF plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Table Cell Content in all versions up to, and including, 1.3.35 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-10-10T06:16:43.187Z",
  "pubdate": "2026-10-10T06:16:43.187Z",
  "executiveSummary": "The Table Field Add-on for ACF and SCF plugin for WordPress is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability.\nThis security flaw stems from inadequate input sanitization and output escaping mechanisms within the plugin's handling of table cell content.\nAuthenticated attackers possessing at least Contributor-level privileges can inject malicious JavaScript payloads into table fields.\nThese stored payloads are rendered directly in the browser of any user—including administrators—who views the compromised page, leading to unauthorized script execution.\nThe potential impact includes session hijacking, unauthorized administrative actions, redirection to malicious domains, or defacement of the affected WordPress site.\nThe vulnerability affects all versions up to and including 1.3.35, requiring immediate attention to prevent exploitation by authenticated users with elevated permissions.",
  "technicalDetails": "The vulnerability is identified as Stored Cross-Site Scripting (XSS), originating from the failure of the Table Field Add-on for ACF and SCF to properly sanitize user-supplied data before saving it to the WordPress database, and its subsequent failure to perform secure output escaping when rendering that data.\nThe flaw specifically resides in the plugin's processing of data input for individual table cells. Because the plugin does not implement server-side validation or sanitization routines, such as using WordPress's `sanitize_text_field()` or `wp_kses()` functions, it treats arbitrary HTML and JavaScript tags as valid input.\nThe attack flow begins with an authenticated attacker, such as a user with a Contributor role, accessing the post or page editor where the Table Field Add-on is utilized. By inserting a crafted payload, such as '<script>alert(document.cookie)</script>', into the content fields of a table, the attacker bypasses any expected input constraints.\nOnce the data is saved, the malicious payload is stored persistently in the database associated with that specific post or page object. When a victim—regardless of their privilege level—navigates to the rendered page, the application retrieves the malicious string from the database and inserts it directly into the HTML Document Object Model (DOM) without escaping special characters.\nAs a result, the victim's browser interprets the injected string as executable code. Because this occurs within the context of the site's authenticated session, the script executes with the victim's permissions. This permits the attacker to perform actions on behalf of the victim, such as modifying site settings, creating new administrator accounts, or exfiltrating sensitive session tokens (e.g., session cookies).\nGiven that WordPress contributors typically have access to create and edit content, the attack surface is limited to users who have already been granted at least a Contributor role within the WordPress installation. There is no requirement for network exposure beyond the standard web access provided by the WordPress front-end or back-end environment. The persistence of the payload ensures that the XSS condition is met every time the injected content is loaded by a user, making it a critical threat to user security within the WordPress environment."
}