Skip to main content
CVE Vulnerability Database

CVE-2024-4404: Wpmet Elementskit SSRF Vulnerability

CVE-2024-4404 is a Server-Side Request Forgery flaw in Wpmet Elementskit PRO plugin for WordPress that allows authenticated attackers to make unauthorized web requests. This post covers technical details, affected versions, and mitigation.

Published:

CVE-2024-4404 Overview

CVE-2024-4404 is a Server-Side Request Forgery (SSRF) vulnerability in the ElementsKit PRO plugin for WordPress. The flaw affects all versions up to and including 3.6.2 and resides in the plugin's render_raw function. Authenticated attackers with contributor-level permissions or higher can abuse this function to issue arbitrary outbound web requests from the WordPress host. These requests can target internal services, cloud metadata endpoints, and other resources reachable from the server. The issue is classified under CWE-918: Server-Side Request Forgery.

Critical Impact

Authenticated low-privilege users can pivot through the WordPress server to query and modify internal services, exposing data on otherwise unreachable network segments.

Affected Products

  • Wpmet ElementsKit PRO for WordPress, all versions through 3.6.2
  • WordPress sites running ElementsKit PRO with contributor-or-higher user registration enabled
  • Hosting environments where the WordPress server can reach internal-only services or cloud metadata endpoints

Discovery Timeline

  • 2024-06-14 - CVE-2024-4404 published to NVD
  • 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2024-4404

Vulnerability Analysis

The ElementsKit PRO plugin exposes a render_raw function intended to render content from URLs supplied by authenticated users. The function does not validate or restrict the destination URL before issuing a server-side HTTP request. An authenticated attacker with contributor-level access supplies a URL pointing to an internal resource, and the WordPress server fetches it and returns the response body.

The attacker effectively turns the WordPress host into a proxy for internal reconnaissance and interaction. Targets include internal admin interfaces, databases exposed on localhost, container orchestration APIs, and cloud instance metadata services such as http://169.254.169.254/. On many cloud deployments, the metadata service returns temporary credentials usable for further lateral movement.

Root Cause

The root cause is missing input validation and allow-list filtering on the URL parameter consumed by render_raw. The function trusts contributor-supplied input and issues outbound requests without restricting schemes, hostnames, or IP ranges. There is no enforcement preventing requests to loopback addresses, RFC1918 ranges, or link-local addresses.

Attack Vector

Exploitation requires an authenticated account with the WordPress contributor role or higher. The attacker submits a crafted request invoking render_raw with a URL pointing to an internal target. The plugin performs the request server-side and returns the response, allowing the attacker to read internal HTTP responses. The bug enables both reconnaissance via GET requests and state-changing operations against internal services that accept unauthenticated requests from the local network.

No verified public exploit code is available. Refer to the Wordfence Vulnerability Report for additional technical context.

Detection Methods for CVE-2024-4404

Indicators of Compromise

  • Outbound HTTP requests from the WordPress PHP process to internal IP ranges, loopback addresses, or 169.254.169.254
  • Unexpected access entries in internal service logs sourced from the WordPress server's IP address
  • Web server logs showing requests to ElementsKit endpoints invoking render_raw with URL parameters referencing private addresses
  • New contributor-level accounts created shortly before SSRF activity

Detection Strategies

  • Inspect WordPress access logs for POST or GET requests to ElementsKit AJAX or REST endpoints containing URL parameters in their payloads
  • Correlate PHP-FPM or Apache outbound connections with destinations outside expected upstream services
  • Hunt for cloud metadata service access originating from WordPress workloads using egress flow logs or VPC traffic mirroring

Monitoring Recommendations

  • Alert on any HTTP request from web-tier hosts to 169.254.169.254, 127.0.0.1, or RFC1918 ranges not on an approved allow-list
  • Monitor creation and role changes for contributor and author accounts on WordPress installs running ElementsKit PRO
  • Forward web application and egress logs to a centralized data lake to enable cross-source correlation between authenticated user actions and outbound network behavior

How to Mitigate CVE-2024-4404

Immediate Actions Required

  • Upgrade ElementsKit PRO to a version later than 3.6.2 that contains the vendor fix; confirm the running version against the WPmet ElementsKit Roadmap
  • Audit all WordPress accounts with contributor role or higher and remove inactive or untrusted users
  • Disable open user registration on affected sites until patching is complete
  • Review egress logs for prior SSRF activity against internal endpoints and cloud metadata services

Patch Information

The vendor has addressed the issue in releases following 3.6.2. Site administrators should consult the Wordfence Vulnerability Report for the fixed version and the WPmet ElementsKit Roadmap for vendor release notes.

Workarounds

  • Deactivate the ElementsKit PRO plugin until an updated version is installed
  • Enforce IMDSv2 with hop-limit 1 on AWS instances hosting WordPress to block SSRF-based credential theft
  • Apply egress firewall rules from the WordPress host that deny traffic to 169.254.169.254, 127.0.0.0/8, and RFC1918 networks except for required backends
  • Place the site behind a web application firewall configured to block requests where ElementsKit parameters contain internal IP addresses or non-HTTP schemes
bash
# Example egress restriction using iptables on the WordPress host
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.