Description

The Divi theme for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 4.27.6. This is due to the `et_pb_set_video_oembed_thumbnail_resolution()` function using `wp_remote_get()` instead of `wp_safe_remote_get()` to fetch a remote image URL, which does not restrict requests to private or reserved IP ranges. This makes it possible for authenticated attackers, with Contributor-level access and above, to make web requests to arbitrary locations originating from the web application server. The response body is not returned to the attacker (blind SSRF), but two oracles exist: a status oracle (the returned URL string differs depending on whether the target responded with HTTP 200) and a timing oracle (response time varies by target reachability).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-05T07:17:11.930Z",
  "pubdate": "2026-09-05T07:17:11.930Z",
  "executiveSummary": "The Divi theme for WordPress, in versions up to and including 4.27.6, contains a Server-Side Request Forgery (SSRF) vulnerability due to improper input validation in remote resource retrieval.\nThe vulnerability allows authenticated users with Contributor-level access or higher to force the WordPress server to initiate outbound HTTP requests to arbitrary network destinations, including internal infrastructure and private IP ranges.\nWhile the vulnerability is categorized as a blind SSRF, the availability of status and timing oracles permits attackers to perform network reconnaissance and potentially interact with services residing behind the firewall that are otherwise unreachable from the public internet.\nThis flaw presents significant risk by enabling unauthorized access to internal services, metadata APIs, or local network resources that trust the web application server's IP address.\nExploitation requires active authentication with at least Contributor privileges, making it a targeted internal threat within multi-user WordPress environments.",
  "technicalDetails": "The root cause of this vulnerability lies in the use of the `wp_remote_get()` function within the `et_pb_set_video_oembed_thumbnail_resolution()` function in the Divi theme. Unlike `wp_safe_remote_get()`, which includes built-in safeguards to block requests to private, reserved, or loopback IP ranges, `wp_remote_get()` performs no such validation on the provided target URL.\nIn the vulnerable implementation, the theme component accepts user-supplied URL parameters that are subsequently passed to the underlying networking function to fetch video thumbnail data. Because the input is not sanitized or restricted against internal network destinations, an attacker can manipulate the request to point toward sensitive internal endpoints.\nThe attack flow begins when an authenticated attacker (Contributor level or higher) triggers the specific functionality associated with video oEmbed thumbnail processing. By intercepting or crafting a request that provides a malicious URL, the attacker instructs the server to perform an HTTP GET request to a target of their choosing. The server processes this request, and while it does not return the raw response body to the attacker, it creates two distinct side-channel oracles.\nThe first, a status oracle, relies on the divergence of return values based on whether the target endpoint returns a successful HTTP 200 response code. The second, a timing oracle, leverages the latency inherent in the server's network stack when attempting to reach internal versus external or non-existent network endpoints.\nThrough these oracles, an attacker can systematically scan the local area network, probe for open ports on the hosting server, or interact with cloud-based metadata services (such as those provided by AWS, GCP, or Azure). This effectively bypasses network segmentation and firewall boundaries that would typically prevent direct external access to internal assets. The absence of strict allow-listing for the request destination allows for arbitrary SSRF, which can be leveraged to confirm the existence of internal services or to exploit vulnerabilities in internal APIs that lack strong authentication."
}