Server-Side Request Forgery (SSRF) on WordPress: Turning Your Server Into a Weapon

Table of Contents 6 sections

What Is Server-Side Request Forgery?

Server-Side Request Forgery, or SSRF, is a vulnerability that tricks your server into making an HTTP request to a destination the attacker chooses. Normally, when a site fetches a URL, it fetches a URL you control. In an SSRF attack, the attacker supplies the URL, and your server obediently requests it. Because the request now originates from inside your infrastructure, it can reach places a normal outside visitor never could.

Why SSRF Is So Dangerous

The power of SSRF comes from trust. Internal systems often assume that any request coming from the server itself is safe. An attacker who can steer your server's requests can abuse that trust to:

• Reach internal services such as databases, admin panels, and private APIs that are not exposed to the public internet.
• Read cloud metadata. On many cloud hosts, a special internal address returns credentials and configuration. Stealing these can hand an attacker your entire hosting account.
• Scan the internal network by watching how quickly different internal addresses respond.
• Bypass firewalls because the traffic looks like it comes from a trusted internal source.

Common SSRF Vectors in WordPress

Any feature that fetches a remote URL on the server side is a potential entry point:

• The pingback system. The XML-RPC pingback feature asks WordPress to fetch a URL the caller supplies. This has been abused for years to make sites request internal addresses and to launch reflected attacks against others.
• Link preview and oEmbed handlers that fetch and render remote content.
• Image import and thumbnail generators that download a remote image by URL.
• PDF and screenshot generators that render an arbitrary page.
• Webhook and third-party API integrations where the destination URL comes from user input.

A Simple Example

Imagine a plugin that generates a preview from any URL a user pastes in. An attacker enters the cloud metadata address instead of a normal web page:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

The server dutifully fetches it and may return cloud credentials in the preview, handing the attacker keys to the hosting account. The same trick works against http://localhost and internal IP ranges to reach services that were never meant to be public.

How to Prevent SSRF

For Site Owners

1. Disable XML-RPC pingbacks if you do not use them, closing the oldest SSRF vector in WordPress.
2. Keep plugins updated, since SSRF flaws in URL-fetching plugins are patched regularly.
3. Limit outbound access at the server or firewall level so the site cannot reach internal-only addresses.
4. Audit plugins that fetch remote URLs and remove any you do not need.

For Developers

1. Validate and allow-list destinations. Only fetch URLs that match an approved list of hosts.
2. Block internal ranges. Reject requests to localhost, private IP ranges, and the cloud metadata address before making the request.
3. Resolve then verify. Resolve the hostname to an IP and confirm it is public before connecting, to defeat DNS rebinding.
4. Never pass raw user input to functions like wp_remote_get() without validation.

How to Detect SSRF Exposure

Our WordPress Security Scanner checks for an exposed XML-RPC endpoint, active pingback support, and known vulnerable plugin versions that include SSRF flaws. Run a free scan to find out whether your server can be turned against you.