CVE-2026-3712 in PhastPress Plugin
Summary
by MITRE • 10/15/2026
The PhastPress plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.10 This is due to the scripts service endpoint constructing its URL whitelist dynamically from the attacker-controlled HTTP 'Host' header. This makes it possible for unauthenticated attackers to spoof the header to match any target URL, bypassing the whitelist and forcing the server to make HTTP requests to arbitrary internal or external destinations and return the response content.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The PhastPress plugin for WordPress contains a critical Server-Side Request Forgery vulnerability affecting all versions up through 3.10. This flaw resides within the scripts service endpoint, which is designed to fetch and serve static assets such as JavaScript or CSS files from external sources to optimize page load times. The security failure stems directly from how the plugin constructs its URL whitelist for validation purposes. Instead of relying on a hardcoded list of trusted domains or using strict input sanitization that ignores user-controlled headers, the application dynamically builds this allowlist by parsing the HTTP Host header sent with the incoming request. This architectural decision introduces a severe trust boundary violation because the Host header is easily manipulated by any client making an HTTP request to the server.
An unauthenticated attacker can exploit this vulnerability by crafting a malicious HTTP request that includes a custom or spoofed Host header containing the domain of their choice, such as an internal corporate network address or a sensitive external service endpoint. When the PhastPress plugin processes this request, it reads the manipulated Host value and adds it to its whitelist dynamically before validating subsequent URLs against that list. Consequently, any URL specified in the request parameters is deemed valid because it matches the attacker-controlled host domain added during the validation phase. This logic flaw effectively bypasses all intended security restrictions, allowing the server-side application to initiate HTTP requests to arbitrary destinations without proper authorization checks or input filtering.
The operational impact of this vulnerability extends beyond simple data exfiltration from external sites. Because PHP-based WordPress plugins typically execute with the same privileges as the web server process, an attacker can leverage SSRF to probe internal network services that are not exposed to the public internet. This includes accessing local database interfaces like MySQL or PostgreSQL on localhost, querying metadata endpoints of cloud infrastructure providers such as AWS EC2 instance metadata service at 169.254.169.254, or interacting with internal API gateways and administrative panels that rely solely on network-level access controls for protection. The attacker can force the server to return response content from these internal resources, potentially exposing sensitive configuration data, authentication tokens, database credentials, or proprietary application logic. This capability significantly expands the attack surface of a compromised WordPress installation, facilitating further lateral movement within an organization's infrastructure.
From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to URLs specified by users without sufficient validation. The exploitation technique maps directly to the MITRE ATT&CK framework under T1046, specifically Network Service Discovery and potentially T1537 if used for data exfiltration through external endpoints. The root cause is a failure in input validation where user-controllable HTTP headers are treated as trusted configuration parameters rather than untrusted input data that requires rigorous sanitization or rejection of non-standard values.
Mitigation strategies must address both the immediate vulnerability and the underlying architectural weakness. For administrators using PhastPress versions up to 3.10, the most effective remediation is to update the plugin immediately if a patched version has been released by the vendor. If an update is not yet available, temporary mitigations include configuring the web server or reverse proxy to strip or normalize the Host header before it reaches the application layer, ensuring that only expected domain names are permitted in HTTP requests. Additionally, implementing strict egress filtering at the network perimeter can prevent the WordPress server from initiating connections to unauthorized internal subnets or sensitive external endpoints. Long-term resolution requires refactoring the URL validation logic to use a static whitelist of trusted domains rather than dynamically deriving trust from request headers, thereby eliminating the possibility of header-based bypasses and ensuring that all outbound requests are explicitly authorized by predefined configuration settings.