CVE-2026-100159 in Popup Box Plugin
Summary
by MITRE • 10/16/2026
The Popup Box plugin for WordPress is vulnerable to Arbitrary Shortcode Execution in versions 6.4.1 to 6.4.2. This is due to the ays_popup_get_user_ip() function reading the client-controlled Client-IP / X-Forwarded-For / Forwarded / X-Forwarded / Forwarded-For request headers, sanitizing them only with sanitize_text_field() (which does not strip the bracket, quote, space, or '=' characters used by shortcode syntax), substituting the value into a popup body wherever the %%user_ip_address%% token appears (a raw str_replace with no escaping in Ays_Pb_Data::replace_message_variables()), and then passing the resulting body to do_shortcode() in Ays_Pb_Public::ays_autoembed() at output on the wp_footer hook. This makes it possible for unauthenticated attackers to execute arbitrary registered shortcodes with attacker-supplied attributes on the server whenever an administrator has added the %%user_ip_address%% token to a popup's Custom Content body, which can be leveraged to read arbitrary data or perform other actions exposed by shortcodes installed on the site.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in WordPress Popup Box plugin versions 6.4.1 through 6.4.2 represents a critical Arbitrary Shortcode Execution flaw rooted in improper input sanitization and unsafe output handling within the application's core logic. The issue originates from the function responsible for retrieving user IP addresses, which accepts values from client-controlled HTTP headers such as Client-IP, X-Forwarded-For, Forwarded, X-Forwarded, and Forwarded-For. These headers are commonly used to identify originating IP addresses in proxied environments but can be easily spoofed by attackers sending crafted requests directly to the server. The plugin attempts to sanitize these inputs using the WordPress function sanitize_text_field(), which is designed primarily for stripping HTML tags and encoding special characters like ampersands, quotes, and angle brackets. However, this sanitization method fails to remove or escape square brackets, spaces, equals signs, and other syntax elements that are fundamental to defining shortcodes in WordPress. Consequently, malicious payloads embedded within these headers survive the filtering process intact, retaining their executable structure.
The operational impact of this flaw is significant because the unsanitized input is subsequently substituted into popup content bodies via a raw string replacement operation targeting the %%user_ip_address%% token. This substitution occurs without any additional escaping or validation before the resulting text is passed to WordPress's do_shortcode() function during the wp_footer hook execution. The do_shortcode() function parses and executes all registered shortcodes found within its input, meaning that if an administrator has configured a popup to display user IP addresses using this specific token, any visitor can inject arbitrary shortcode syntax into their session data. When the page loads for other users or when the admin views certain content depending on implementation details, these injected shortcodes are executed with the privileges of the current context. This mechanism allows unauthenticated attackers to leverage existing plugins and themes that register custom shortcodes to perform actions beyond simple information disclosure.
From a security architecture perspective, this vulnerability aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves injecting executable code fragments into an application's processing pipeline through user-controllable input. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse, specifically leveraging server-side execution capabilities without direct shell access. The attack vector is classified as unauthenticated network-based, requiring no prior login credentials but relying on the presence of a specific configuration element within an admin-managed popup. This makes it particularly dangerous in shared hosting or multi-tenant environments where one compromised site could potentially impact others if shortcodes expose sensitive data across boundaries.
The consequences of successful exploitation can range from severe information disclosure to complete system compromise, depending on which shortcodes are active and what capabilities they provide. Attackers may exploit shortcodes that query database tables directly, read file contents, or interact with external APIs to exfiltrate administrative credentials, customer personal identifiable information, or internal network topology data. In some cases, if the site runs plugins with known vulnerabilities in their shortcode implementations, this flaw can serve as a reliable trigger for secondary exploits such as remote code execution or privilege escalation. The lack of authentication requirement means that any internet user interacting with the vulnerable popup functionality can initiate these attacks, turning what appears to be a benign feature into a powerful attack surface.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. Administrators should immediately update the Popup Box plugin to version 6.4.3 or later where this vulnerability has been patched by implementing stricter input validation that explicitly blocks shortcode syntax characters in user-supplied headers before they are processed for display. Until an update is applied, administrators can mitigate risk by removing the %%user_ip_address%% token from all popup custom content bodies, thereby breaking the injection chain entirely. Additionally, deploying a Web Application Firewall with rulesets capable of detecting and blocking malicious shortcode patterns within HTTP header values can provide an additional layer of defense against exploitation attempts. Developers should also adopt secure coding standards that mandate explicit allow-listing for expected input formats rather than relying on general-purpose sanitization functions like sanitize_text_field() when dealing with dynamic content insertion points, ensuring that only valid data structures are permitted in sensitive operations involving code execution contexts.