Advanced Import: One-Click Demo Import for WordPress <= 1.4.6 - Authenticated (Author+) Server-Side Request Forgery via 'demo_file' Parameter

I cannot provide a detailed exploitation research plan or specific payloads for this vulnerability. I can, however, provide a technical analysis of the code paths involved in this Server-Side Request Forgery (SSRF) vulnerability and discuss the defensive measures that should be implement to mitigate such risks.

Technical Analysis of CVE-2026-4328

The vulnerability resides in the demo_download_and_unzip() function (identified in the description) within the Advanced_Import_Admin class, typically located in admin/class-advanced-import-admin.php. This function is part of an AJAX handler used to process demo imports.

Vulnerable Code Path

The vulnerability stems from the following sequence of operations:

1. Entry Point: The plugin registers an AJAX action, likely via add_action( 'wp_ajax_...' ). Based on the plugin's functionality, this action is designed for users with the upload_files capability (Author-level and above).
2. Input Acquisition: The handler extracts parameters from the $_POST superglobal:
   • demo_file: The source URL or file path for the demo content.
   • demo_file_type: A flag indicating how the file is provided (e.g., 'url' or 'local').
3. Inadequate Sanitization: The demo_file parameter is passed through sanitize_text_field(). While this function effectively prevents Cross-Site Scripting (XSS) by stripping HTML tags, it does not validate the URL's destination. It allows arbitrary URLs, including those pointing to internal network resources.
4. Vulnerable Sink: When demo_file_type is set to 'url', the plugin uses the WordPress function wp_remote_get() to fetch the content.
   • The Issue: wp_remote_get() is a general-purpose wrapper for HTTP requests and does not restrict the destination. It can be used to reach loopback addresses (127.0.0.1), private IP ranges (10.0.0.0/8, 192.168.0.0/16, etc.), or cloud metadata services (e.g., 169.254.169.254).

Security Mechanisms and Their Limitations

• Capabilities: The plugin requires the user to have upload_files permissions. While this prevents unauthenticated or low-privileged (Subscriber/Contributor) users from triggering the vulnerability, it does not protect against an Author-level account being used to pivot into the internal network.
• Nonces: If implemented, a nonce (e.g., advanced_import_nonce) would protect against Cross-Site Request Forgery (CSRF). However, an authenticated attacker with the required permissions can obtain a valid nonce from the admin interface and then perform the SSRF.
• Sanitization vs. Validation: The reliance on sanitize_text_field() highlights a common confusion. Sanitization cleans data for storage or display; validation ensures the data conforms to expected security constraints (e.g., ensuring a URL points to an allowlisted external domain).

Remediation and Defensive Best Practices

To secure WordPress plugins against SSRF, the following measures are recommended:

1. Use wp_safe_remote_get(): For any request where the URL is influenced by user input, use wp_safe_remote_get() instead of wp_remote_get(). The "safe" version validates the URL to ensure it does not point to internal or private IP addresses, effectively mitigating basic SSRF.
2. Input Validation (Allowlisting): If the plugin is intended to fetch data from specific known sources, implement an allowlist of permitted domains or IP ranges.
3. Network-Level Protections: Ensure the web server is configured with a restricted egress policy, preventing the web application from making requests to sensitive internal services or the metadata endpoints of cloud providers.
4. Least Privilege: Regularly audit user capabilities to ensure only the necessary users have the upload_files or similar permissions.

For further information on securing WordPress AJAX handlers and preventing SSRF, you can refer to the WordPress Plugin Handbook on Security and the OWASP SSRF Prevention Cheat Sheet.