CVE-2026-4006 in Draft List Plugin
Summary
by MITRE • 03/19/2026
The Simple Draft List plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'display_name' post meta (Custom Field) in all versions up to and including 2.6.2. This is due to insufficient input sanitization and output escaping on the author display name when no author URL is present. The plugin accesses `$draft_data->display_name` which, because `display_name` is not a native WP_Post property, triggers WP_Post::__get() and resolves to `get_post_meta($post_id, 'display_name', true)`. When the `user_url` meta field is empty, the `$author` value is assigned to `$author_link` on line 383 without any escaping (unlike line 378 which uses `esc_html()` for the `{{author}}` tag, and line 381 which uses `esc_html()` when a URL is present). This unescaped value is then inserted into the shortcode output via `str_replace()`. 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 a page containing the `[drafts]` shortcode with the `{{author+link}}` template tag.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/19/2026
The vulnerability identified in CVE-2026-4006 affects the Simple Draft List plugin for WordPress, specifically targeting versions up to and including 2.6.2. This represents a critical stored cross-site scripting vulnerability that exploits insufficient input sanitization and output escaping mechanisms within the plugin's handling of post meta data. The flaw exists in how the plugin processes the 'display_name' custom field when generating draft lists, creating an attack vector that can be exploited by authenticated users with contributor-level access or higher. The vulnerability stems from the plugin's improper handling of user-supplied data within the context of WordPress's post meta system, where the display_name field is not a native WordPress post property but rather a custom meta field that triggers the WP_Post::__get() magic method.
The technical implementation of this vulnerability involves the plugin's reliance on `$draft_data->display_name` which, due to the non-native nature of this field, invokes WordPress's get_post_meta() function through the WP_Post::__get() method. When the user_url meta field is empty, the plugin assigns the unescaped `$author` value directly to `$author_link` on line 383 without proper sanitization, creating a direct path for malicious script injection. This contrasts sharply with the proper escaping mechanisms used elsewhere in the code where `esc_html()` is correctly implemented on line 378 for the `{{author}}` tag and on line 381 when a URL is present. The inconsistency in escaping practices creates a predictable exploitation pattern where the unfiltered display_name value is then inserted into the shortcode output using str_replace() without any sanitization, making it possible for attackers to inject malicious JavaScript code that will execute whenever pages containing the `[drafts]` shortcode with the `{{author+link}}` template tag are accessed by other users.
The operational impact of this vulnerability extends beyond simple script execution, as it enables authenticated attackers to potentially compromise user sessions, steal sensitive information, or manipulate content within the WordPress environment. The fact that contributors and above can exploit this vulnerability means that even users with limited permissions can create persistent attack vectors that persist across multiple user sessions. This stored XSS vulnerability can be particularly dangerous in environments where multiple users access the same WordPress installation, as the malicious scripts will execute automatically whenever affected pages are loaded. The attack requires no special privileges beyond contributor-level access, making it accessible to a broad range of potential attackers who may have legitimate reasons to access the WordPress backend but could abuse this capability for malicious purposes. The vulnerability aligns with CWE-79 (Cross-site Scripting) and maps to ATT&CK technique T1566.001 (Phishing via Social Engineering) and T1547.001 (Registry Run Keys/Startup Folder) as attackers could potentially use this vulnerability to establish persistent access through malicious scripts that execute in users' browsers.
Mitigation strategies should focus on immediate plugin updates to versions that address this vulnerability, as well as implementing additional security measures such as input validation for custom fields and consistent output escaping across all template tags. Administrators should also consider implementing content security policies to limit the execution of inline scripts and regularly audit custom fields for potentially malicious content. The vulnerability demonstrates the importance of consistent security practices within WordPress plugins, particularly around input sanitization and output escaping, and highlights the need for comprehensive security testing of custom fields and meta data handling. Organizations should also implement monitoring for suspicious activity related to draft creation and author field modifications, as these activities could indicate attempted exploitation of this vulnerability. Regular security audits of WordPress installations, including third-party plugins, should be conducted to identify similar vulnerabilities that could potentially allow for privilege escalation or persistent attack vectors.