CVE-2026-11370: WP Meta SEO SSRF Vulnerability (4.5.18 and Earlier)

Technical summary

CVE-2026-11370 is a CWE-918 Server-Side Request Forgery in WP Meta SEO up to version 4.5.18. The vulnerability exists in AJAX endpoint handlers that process the 'new_link' parameter without proper URL validation or filtering. The parameter is passed to an HTTP client that executes requests with the web server's network context. Critically, the response status_code is returned in the JSON response, enabling attackers to enumerate internal services through HTTP status observation—a technique effective against internal APIs, database proxies, and cloud metadata services (e.g., 169.254.169.254 on AWS EC2 instances).

Business impact

Organizations running WP Meta SEO face elevated risk of data exfiltration and lateral movement. An attacker with contributor access—a permission level often granted to content editors and junior staff—can probe and potentially interact with internal services, cloud metadata stores, and databases without direct network access. In cloud-hosted environments, this is particularly severe because metadata services expose credentials, IAM roles, and security tokens. Additionally, SSRF can be chained with other vulnerabilities to pivot deeper into infrastructure or interact with internal APIs not exposed to the internet.

Affected systems

The vulnerability affects WordPress installations running the WP Meta SEO plugin in any version up to and including 4.5.18. Impact is limited to sites where contributors or editors (or higher-privileged users) may be untrusted or compromised. Self-hosted and managed WordPress hosting are both affected. The vendor_products field in the source data is empty, so refer to the official WP Meta SEO repository and security advisories for confirmed affected versions and patch availability.

Exploitability

Exploitation requires an authenticated account with at minimum contributor-level privileges in WordPress. No user interaction or special browser configuration is required—the attack is entirely server-side via AJAX. The vulnerability is easily exploitable by any authenticated user and requires no special tooling; curl, wget, or a script can trigger the vulnerable endpoint. The enumeration oracle (status code reflection) makes reconnaissance straightforward. However, the authentication requirement prevents unauthenticated mass exploitation, reducing opportunistic attack risk.

Remediation

Update the WP Meta SEO plugin to the patched version. Site administrators should check the WP Meta SEO project page and security advisories for the specific patch version that addresses CVE-2026-11370. As an interim measure, restrict contributor-level access to accounts that genuinely require it, and audit contributor and editor accounts for signs of compromise. Implement network segmentation to limit the reach of internal requests originating from the web server.

Patch guidance

Check the official WP Meta SEO repository (plugins.wordpress.org or the developer's security advisory) for patch version information addressing CVE-2026-11370. Apply the patch via the WordPress admin dashboard (Plugins > Installed Plugins > Update) once available. Test in a staging environment to verify compatibility with your theme and other plugins. After patching, review contributor and editor account access logs to detect any exploitation attempts prior to the update.

Detection guidance

Monitor AJAX requests to WP Meta SEO endpoints for unusual 'new_link' parameter values, especially those containing internal IP addresses, localhost, or cloud metadata service endpoints (e.g., 169.254.169.254). Search web server logs for POST requests to paths containing 'wp-admin/admin-ajax.php' with action parameters associated with WP Meta SEO. Log all responses returned by these endpoints and flag any that expose HTTP status codes indicating internal service availability. Consider Web Application Firewall rules to block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) in the 'new_link' parameter.

Why prioritize this

Although CVSS 6.4 (MEDIUM) reflects that exploitation requires authentication, the practical risk is elevated in environments with weak contributor access controls or high user churn. The reconnaissance capability and potential for cloud credential exposure make this a priority for cloud-hosted WordPress deployments and sites with numerous editors or contributors. Organizations should prioritize patching if they host sensitive workloads or run on cloud infrastructure.

Risk score, explained

CVSS 3.1 Base Score 6.4 reflects: Network Attack Vector (AV:N), Low Attack Complexity (AC:L), Low Privilege Requirements (PR:L), No User Interaction (UI:N), and Changed Scope (S:C) with Low Confidentiality and Low Integrity Impact. The score does not account for the effective reconnaissance oracle or cloud metadata exposure, which may elevate risk in specific environments. Environmental factors—such as reliance on cloud infrastructure or the presence of untrusted contributors—should inform local risk assessment.

Frequently asked questions