CVE-2026-96648 in Data Tables Generator by Supsystic Plugin
Summary
by MITRE • 10/10/2026
The Data Tables Generator by Supsystic plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Table Cell 'data' Value via updateRows Action in all versions up to, and including, 1.15.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is only exploitable by Subscriber-level users when an administrator has added their role to the plugin's 'access_roles' setting, which is a documented and explicitly supported plugin feature that grants lower-privileged users access to the dtgs_nonce required to reach the vulnerable updateRows action handler.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The Data Tables Generator by Supsystic for WordPress contains a critical stored cross-site scripting vulnerability affecting all versions up to 1.15.1. This flaw stems from insufficient input sanitization and output escaping within the plugin's handling of table cell data values. Specifically, the updateRows action handler fails to properly validate or encode user-supplied content before storing it in the database and subsequently rendering it on web pages. When an authenticated attacker injects malicious JavaScript payloads into these fields, the scripts are persistently stored rather than executed immediately upon submission. This persistence distinguishes the flaw as a stored XSS attack, where the injected code becomes part of the page's HTML structure itself.
The operational impact of this vulnerability is significant because it allows for persistent compromise of user sessions and data integrity without requiring further interaction from the attacker after the initial injection. Any user who views a page containing the infected table cell will have their browser execute the malicious script in the context of the vulnerable WordPress site. This can lead to session hijacking, where attackers steal authentication cookies to impersonate legitimate users, or defacement of the website content. In more severe scenarios, if combined with other vulnerabilities such as cross-site request forgery weaknesses, it could facilitate privilege escalation or data exfiltration from connected databases.
Exploitation is restricted to authenticated users due to WordPress's default role-based access control mechanisms. However, the vulnerability specifically targets lower-privileged accounts when an administrator has explicitly configured the plugin's 'access_roles' setting to include subscriber-level permissions and above. This configuration grants these users the necessary dtgs_nonce token required to interact with the updateRows action handler. While this is a documented feature intended to allow collaborative editing or data entry by non-administrators, it inadvertently expands the attack surface for XSS attacks. An attacker compromising a low-privilege account can leverage this legitimate access path to inject persistent malicious scripts that affect all subsequent visitors viewing those specific table views.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The failure occurs in both the input validation phase and the output encoding phase, violating fundamental secure coding principles for web applications. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1059 Command and Control via Application Layer Protocol or more specifically T1189 Drive-by Client Side Scripting if used in a broader campaign context, though primarily it represents an injection flaw leading to client-side code execution.
Mitigation strategies should focus on immediate remediation of the input handling logic within the plugin's PHP backend. Developers must implement strict whitelisting for allowed HTML tags and attributes when processing table cell data, ensuring that script-related elements like script tags or event handlers are stripped out before database storage. Furthermore, output encoding must be enforced using functions such as htmlspecialchars with appropriate flags to ensure special characters are rendered safely in the browser context rather than interpreted as executable code. For administrators currently running vulnerable versions, it is recommended to either update to a patched version immediately if available from the vendor or restrict the 'access_roles' setting to exclude subscriber-level users until the patch is applied. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact even if injection occurs.