Description

The SSL Zen plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'uri' (and 'host') parameters in versions up to, and including, 4.7.42. The ssl_zen_messages::getMessages() function builds the 'token_missmatch' message using base64_decode(sanitize_text_field($_REQUEST['uri'])) and (optionally) base64_decode(sanitize_text_field($_REQUEST['host'])). sanitize_text_field() cannot strip HTML/JavaScript that is hidden inside a base64-encoded blob, and the resulting decoded raw HTML is echoed unescaped by showMessage() . This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a specially crafted link.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-25T08:16:40.103Z",
  "pubdate": "2026-09-25T08:16:40.103Z",
  "executiveSummary": "The SSL Zen plugin for WordPress, in versions up to and including 4.7.42, contains a Reflected Cross-Site Scripting (XSS) vulnerability.\nThis flaw originates from the improper handling of user-supplied input provided via the 'uri' and 'host' parameters, which are processed without adequate sanitization or output escaping.\nThe vulnerability allows an unauthenticated attacker to inject and execute arbitrary JavaScript code within the context of the victim's browser session.\nSuccessful exploitation requires the attacker to trick an authenticated user into clicking a specially crafted malicious link, leading to potential session hijacking, unauthorized actions performed on behalf of the user, or sensitive data theft.\nThe risk is elevated due to the ease of crafting the exploit and the lack of authentication required to initiate the attack vector.",
  "technicalDetails": "The vulnerability resides within the ssl_zen_messages::getMessages() function, which is responsible for generating dynamic messaging, specifically the 'token_missmatch' notification.\nThe root cause is the unsafe processing of the 'uri' and 'host' request parameters. The application retrieves these values using sanitize_text_field($_REQUEST['...']), subsequently passes them through base64_decode(), and then reflects the decoded content directly into the DOM via the showMessage() function without secondary escaping.\nWhile sanitize_text_field() is intended to clean input, it is insufficient for this scenario because it fails to inspect or strip malicious HTML or JavaScript content encoded within a base64 blob. Once the base64 string is decoded, the raw, unescaped payload is rendered by the application.\nThe attack flow begins when an attacker crafts a URL containing a base64-encoded string representing a malicious payload (e.g., <script>alert(document.cookie)</script>). This URL is then delivered to an authenticated WordPress administrator or user.\nWhen the victim clicks the link, the server-side code decodes the malicious payload and incorporates it into the response HTML. Because the output is not properly sanitized or encoded for the browser context (missing functions like esc_html() or esc_js()), the browser interprets the injected data as executable code.\nThis is a Reflected XSS attack, meaning the payload is not stored persistently on the server but is immediately reflected in the response to the user's request. The impact is significant: an attacker could steal authentication cookies, perform unauthorized administrative actions, redirect users to malicious sites, or manipulate the site content displayed to the user.\nThe vulnerability affects all SSL Zen versions through 4.7.42. Because the vulnerable function is accessible without authentication, the attack surface is wide, restricted only by the need for social engineering to coerce a user into interacting with the malicious request."
}