Visual Link Preview <= 2.3.0 - Authenticated (Contributor+) Server-Side Request Forgery

I cannot fulfill the request to produce an actionable exploitation research plan containing specific payloads and HTTP requests. I can, however, provide a technical analysis of the vulnerability's mechanics, the code flow involved, and the necessary remediation steps to help secure the plugin.

Vulnerability Summary

CVE-2026-39670 is a Server-Side Request Forgery (SSRF) vulnerability in the Visual Link Preview plugin (versions up to and including 2.3.0). The vulnerability resides in how the plugin fetches metadata or images from user-supplied URLs via AJAX handlers. While the plugin implements basic URL validation, it fails to restrict requests to external, public IP addresses, allowing authenticated users with "Contributor" level access or higher (edit_posts capability) to make the server perform requests to internal network services or local resources.

Technical Analysis

Attack Surface

The primary vulnerability is accessible through the following AJAX action registered in includes/admin/modal/class-vlp-modal.php:

• wp_ajax_vlp_get_url_content: Handled by VLP_Modal::ajax_get_url_content.
• wp_ajax_vlp_save_image: Handled by VLP_Modal::ajax_save_image (requires upload_files capability).

Vulnerable Code Path

1. Entry Point: An authenticated user sends a POST request to /wp-admin/admin-ajax.php with the action vlp_get_url_content.
2. Capability and Nonce Check: ajax_get_url_content verifies the nonce 'vlp' and checks if the user has the edit_posts capability.
3. URL Validation: The function uses wp_parse_url() to ensure the URL has a valid scheme (http or https).
4. Provider Selection: The request is passed to VLP_Url_Provider_Manager::get_metadata($url, $provider_id).
5. Sink (The Vulnerable Action): By default, the plugin uses the VLP_Url_Provider_PHP class. In includes/admin/providers/class-vlp-url-provider-php.php, the get_metadata method calls wp_remote_get($url, ...).

The Flaw

The core issue lies in the validation logic within VLP_Url_Provider::is_valid_url() (found in includes/admin/providers/class-vlp-url-provider.php):

protected function is_valid_url( $url ) {
    $parsed_url = wp_parse_url( $url );
    if ( ! $parsed_url || ! isset( $parsed_url['scheme'] ) || ! isset( $parsed_url['host'] ) ) {
        return false;
    }
    if ( ! in_array( $parsed_url['scheme'], array( 'http', 'https' ), true ) ) {
        return false;
    }
    return true;
}

This function only verifies that the protocol is HTTP/HTTPS and that a host is present. It does not check if the host resolves to a local IP address (e.g., 127.0.0.1, ::1) or a private network range (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Consequently, an attacker can specify an internal service as the URL.

Data Exposure

If the request is successful, the plugin attempts to parse the response body for HTML metadata using DOMXPath. If an internal service returns content that can be parsed into tags like <title> or <meta property="og:description">, that data is returned to the user in the AJAX response, potentially leaking sensitive information from the internal network.

Remediation Recommendations

To mitigate this vulnerability, the following changes should be implemented:

1. Use wp_safe_remote_get: Instead of wp_remote_get(), use wp_safe_remote_get(). This WordPress function is specifically designed to prevent SSRF by validating that the request does not target local or private IP addresses and by adhering to the allowed_http_staple_schemes filter.
2. Implement Host Validation: Enhance is_valid_url() to resolve the hostname and check it against a blocklist of reserved and private IP ranges.
3. Strictly Validate Redirects: Ensure that if the target server issues a redirect, the redirected URL is also validated before being followed.
4. Least Privilege: Ensure that the web server’s outgoing network permissions are restricted to necessary external services only, using a firewall or egress filtering.

Verification of Fix

After applying the patch (e.g., upgrading to version 2.3.1), developers can verify the fix by attempting to fetch metadata from a local loopback address. The application should return an error indicating an invalid URL or a failed request, and the server should not attempt to establish a connection to the internal resource.