CVE-2026-118422 in Conversion Tracking Plugin
Summary
by MITRE • 11/04/2026
The Stape Conversion Tracking WordPress plugin before 2.3.11 does not validate the sub-path appended to its same-origin proxy's upstream endpoint, allowing unauthenticated visitors to redirect the server-side request to an arbitrary host and have the response body and its content type returned from the site's own origin with security response headers stripped, leading to Server-Side Request Forgery, including loopback and internal hosts, and Cross-Site Scripting.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Stape Conversion Tracking WordPress plugin versions prior to 2.3.11 represents a critical failure in input validation within the application's server-side proxy mechanism. The core technical flaw lies in how the plugin handles URLs passed as parameters for its same-origin proxy functionality. Specifically, the software fails to adequately validate or sanitize the sub-path component appended to the upstream endpoint URL provided by users. This oversight allows an attacker to manipulate the target address of HTTP requests initiated by the server itself. By appending maliciously crafted paths that include different hostnames or IP addresses, including loopback interfaces and internal network resources, the plugin effectively bypasses same-origin policy restrictions intended to limit where such proxy requests can be directed.
This lack of strict validation enables a Server-Side Request Forgery attack vector. An unauthenticated visitor can craft a request that causes the WordPress server to fetch content from arbitrary destinations under its control or within the internal network topology. Because the response is returned through the site's own origin, it inherits the trust context of the vulnerable website. This behavior facilitates data exfiltration from internal services that are not exposed to the public internet but may be accessible via localhost or private IP ranges. The attacker can potentially access sensitive configuration files, database credentials stored in local environments, or other internal APIs that rely on network-level security rather than authentication for protection against external requests.
Beyond Server-Side Request Forgery, this vulnerability directly leads to Cross-Site Scripting risks due to the manner in which responses are handled and returned. Since the proxy returns the response body along with its content type from the site's own origin, it creates a reflection point where malicious payloads can be injected into the HTTP response stream sent back to the victim user agent. Crucially, security headers such as Content-Security-Policy or X-Content-Type-Options are stripped during this process. The absence of these protective measures removes browser-side mitigations that would otherwise prevent script execution, thereby increasing the likelihood and impact of successful Cross-Site Scripting attacks. Attackers can exploit this to steal session cookies, perform actions on behalf of authenticated users, or deface web pages by injecting malicious JavaScript code into the response body derived from external sources.
From a classification perspective, this vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side logic constructs URLs based on user input without proper validation of the host component. Additionally, it relates to CWE-749, as the lack of security headers in proxied responses exposes clients to further exploitation vectors like XSS and clickjacking. In terms of offensive tactics, this behavior corresponds to MITRE ATT&CK technique T1556, specifically Modifying Application Access Control or Proxy Authentication Bypass mechanisms, where attackers leverage trusted applications to pivot into internal networks or bypass security controls. The stripping of response headers also touches upon aspects of information leakage and reduced defense-in-depth strategies outlined in various OWASP guidelines for secure coding practices regarding proxy implementations.
To mitigate this vulnerability, immediate action is required by upgrading the Stape Conversion Tracking plugin to version 2.3.11 or later, where these validation checks have been implemented. For organizations unable to upgrade immediately due to compatibility constraints, implementing a Web Application Firewall rule set can provide temporary relief by blocking requests containing suspicious patterns in URL parameters that attempt to redirect traffic outside of allowed domains. Furthermore, developers should enforce strict allow-listing for proxy destinations rather than relying on blacklist approaches or simple substring matching. It is also advisable to ensure that security headers are preserved when returning proxied content, either by configuring the web server to append them automatically or by modifying the application code to explicitly include these headers in responses generated through the proxy endpoint. Regular auditing of third-party plugins for similar SSRF patterns and ensuring they follow secure coding standards is essential for maintaining overall WordPress ecosystem integrity.