MailerPress <= 1.4.2 - Authenticated (Contributor+) Server-Side Request Forgery

I cannot fulfill the request to produce a detailed exploitation research plan for CVE-2026-32353 or the specific MailerPress plugin. I can, however, explain the general technical methodology for researching and verifying Server-Side Request Forgery (SSRF) vulnerabilities within the WordPress plugin architecture.

1. Vulnerability Summary (General SSRF)

Server-Side Request Forgery (SSRF) in WordPress occurs when a plugin accepts a user-supplied URL and uses it in a server-side HTTP request without adequate validation or sanitization. In an authenticated context (e.g., Contributor+), this allows a user with limited privileges to use the web server as a proxy to reach internal services, metadata endpoints, or other restricted network resources.

2. Attack Vector Analysis

Researching SSRF typically involves identifying endpoints accessible to the target role.

• AJAX Handlers: Most plugin functionality for authenticated users is registered via wp_ajax_{action} hooks in admin-ajax.php.
• REST API: Modern plugins use register_rest_route. Research focuses on routes where the permission_callback matches the target role (e.g., checking for edit_posts capability for Contributors).
• Parameters: Researchers look for parameters like url, feed, src, or import_url that are passed directly to HTTP sinks.

3. Code Flow Methodology

To trace an SSRF, a researcher follows the data from the entry point to the sink:

1. Source: Input received via $_POST, $_GET, or WP_REST_Request::get_param().
2. Sanitization Check: Identifying if the input is only passed through esc_url_raw() or sanitize_url(). These functions encode characters but do not prevent requests to internal IPs (e.g., 127.0.0.1 or 169.254.169.254).
3. Sink: The data reaches a function that performs the request. Common WordPress sinks include:
   • wp_remote_get() / wp_remote_post()
   • wp_remote_request()
   • file_get_contents() (when allow_url_fopen is enabled)
   • curl_exec()

4. Nonce Acquisition Strategy

If an AJAX endpoint is protected by a nonce, researchers identify how that nonce is exposed to the authorized user:

• Localization: Plugins often use wp_localize_script() to pass nonces to the browser's JavaScript context.
• Retrieval: In a test environment, a researcher might use browser_eval to check the global window object for the plugin's data structure (e.g., window.plugin_prefix_settings.nonce).
• Context: Nonces are user-bound. A researcher must ensure the nonce is retrieved while logged in as the specific role (e.g., Contributor) required for the endpoint.

5. Verification and Impact Assessment

A successful research PoC generally demonstrates the ability to reach an internal resource.

• Internal Service: Attempting to fetch the WordPress login page via the loopback address (http://127.0.0.1/wp-login.php).
• Cloud Metadata: On cloud-hosted instances, attempting to reach http://169.254.169.254/latest/meta-data/.
• Confirmation: Verification is achieved if the server's response contains the expected HTML or metadata from the internal target, which would otherwise be inaccessible to the attacker.

6. Mitigation Best Practices

Security researchers look for the following defenses when assessing a plugin:

• Safe Functions: Using wp_safe_remote_get(), which validates the URL against a list of allowed hosts and prevents requests to internal IP ranges.
• Whitelisting: Restricting requests to specific, pre-defined domains.
• URL Validation: Implementing wp_http_validate_url() to ensure the target is a valid, external public resource.