Description

The Posts Table with Search & Sort plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'date_format' parameter in all versions up to, and including, 1.4.14 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. The payload bypasses wp_kses_post at save time because it contains no literal angle bracket characters; the malicious HTML tags are only reconstructed at render time, making this exploitable by Contributors who would ordinarily lack the unfiltered_html capability.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-11-06T09:17:00.310Z",
  "pubdate": "2026-11-06T09:17:00.310Z",
  "executiveSummary": "The Posts Table with Search & Sort WordPress plugin is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability residing within the 'date_format' parameter.\nThis vulnerability affects all versions up to and including 1.4.14.\nThe flaw allows authenticated users with Contributor-level privileges or higher to inject arbitrary malicious scripts into the application.\nThe impact is significant, as executed scripts run within the context of the victim's session, potentially leading to unauthorized actions, session hijacking, or sensitive data exfiltration.\nThe primary risk stems from the plugin's failure to properly sanitize input or encode output, effectively bypassing standard WordPress security filters such as wp_kses_post during the data submission phase.\nExploitation requires the attacker to possess at least Contributor-level access to the WordPress site, after which the malicious payload persists until manually removed by an administrator.\nThe vulnerability is particularly dangerous because the malicious markup is reconstructed at render time, rendering server-side static analysis checks insufficient to detect the underlying threat during initial input processing.",
  "technicalDetails": "The root cause of this Stored XSS vulnerability is improper handling of user-supplied data within the 'date_format' parameter during the plugin's configuration save process. The plugin fails to apply adequate sanitization or output encoding, allowing malicious payloads to be persisted in the WordPress database.\nThe vulnerability utilizes a clever bypass of the wp_kses_post function. Because the injection does not utilize literal angle brackets (< or >) in the raw input provided by the attacker, the server-side filtering mechanism deems the content safe for storage. The malicious HTML tags are subsequently reconstructed when the plugin retrieves the stored value and renders it in the administrative or public-facing views of the WordPress site.\nThe attack flow begins when an authenticated user (Contributor or higher) updates the plugin's 'date_format' setting. The attacker crafts a payload that circumvents initial filtering but results in valid script tags once the application processes the data for display. Once saved, this payload becomes part of the plugin's stored configuration.\nWhen any user—including administrators—views a page where the vulnerable plugin generates the output using the poisoned 'date_format' string, the browser parses the reconstructed script tags. This triggers the execution of the attacker's JavaScript in the context of the victim's browser session.\nThis vulnerability is critical because it elevates the privileges of a Contributor, who typically lacks the 'unfiltered_html' capability in WordPress. By exploiting the logic gap between input sanitization and output rendering, the attacker successfully bypasses the core security model of the WordPress Content Management System.\nPost-exploitation impact includes the potential for persistent session hijacking, as the script can access document cookies, perform unauthorized API requests on behalf of the victim, or redirect users to malicious domains. Since the script is stored globally within the plugin settings, it affects all users who load the specific page where the component is rendered, facilitating widespread impact across the affected WordPress instance."
}