PhastPress EUVD-2026-101823

Exploitation requires reaching the PhastPress 'scripts service' endpoint, which builds its allowed-URL whitelist dynamically from the incoming HTTP 'Host' header; an attacker simply sets the Host header to match the URL they want fetched, so no authentication, user interaction, or non-default configuration is needed on any WordPress site running PhastPress ≤3.10. The practical limiting factors are: the PhastPress plugin must be installed and active (it is a specific optional performance plugin, not core WordPress), and the actual value of the SSRF depends on what internal or external destinations are network-reachable from the WordPress server (e.g., internal services or cloud metadata endpoints). Returned data is limited to what the fetched endpoint responds with.

Signals are moderately consistent and point to a genuine but not top-priority issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a low-complexity, remote, unauthenticated vulnerability, which the description corroborates: the whitelist is built from the attacker-supplied HTTP Host header, so no authentication or user interaction is needed. Impact is rated C:L/I:L/A:L, reflecting that SSRF here returns response content (enabling internal reconnaissance and reaching internal/cloud-metadata services) rather than direct code execution. No EPSS score, no KEV listing, and no public POC are present in the input, so exploitation is currently theoretical in the public record - exploitation status is 'no public exploit identified at time of analysis'. The practical risk driver is that SSRF returning response bodies is a well-understood, easily automatable class, and the trigger (spoofing a single header) is trivial; however, real-world impact depends heavily on what internal services are reachable from the WordPress host. Note the C:L rating may understate risk in cloud environments where SSRF can reach instance metadata endpoints - verify against deployment context. Overall: a real, easily triggered flaw worth patching promptly on exposed sites, but not an emergency absent evidence of active exploitation.

An unauthenticated attacker sends a request to the PhastPress scripts service endpoint while spoofing the HTTP Host header to match an arbitrary internal or external URL, causing that URL to pass the dynamically-built whitelist. The WordPress server then fetches the attacker-chosen destination (e.g., an internal admin panel or cloud metadata service) and returns the response content to the attacker. No public exploit code is identified at time of analysis, but the technique is trivial to reproduce given the low attack complexity (AC:L) and lack of authentication (PR:N).