Login No Captcha reCAPTCHA <= 1.8.0 - Unauthenticated Stored Cross-Site Scripting via PHP_SELF

This research plan outlines the steps required to demonstrate the Unauthenticated Stored Cross-Site Scripting (XSS) vulnerability in the Login No Captcha reCAPTCHA plugin (CVE-2026-2374).

1. Vulnerability Summary

The Login No Captcha reCAPTCHA plugin (up to version 1.8.0) is vulnerable to Stored XSS because it trusts the $_SERVER['PHP_SELF'] value during authentication attempts on non-standard login pages (like xmlrpc.php). The LoginNocaptcha::authenticate() function retrieves the current script's name using basename($_SERVER['PHP_SELF']) and stores it into the login_nocaptcha_error WordPress option when it identifies a login attempt that bypasses the standard wp-login.php flow. This stored value is later rendered in the admin dashboard via the admin_notices hook without any output escaping, allowing an unauthenticated attacker to inject malicious scripts into the administrator's view.

2. Attack Vector Analysis

• Vulnerable Endpoint: /xmlrpc.php/ (or any path that triggers the authenticate filter).
• Vulnerable Parameter: The URL path component of PHP_SELF.
• Authentication: None (Unauthenticated).
• Preconditions:
  1. The plugin must be configured with a valid-length (40 characters) Site Key and Secret Key to activate the authenticate filter.
  2. An administrator must visit the dashboard (/wp-admin/) to trigger the payload.
  3. The payload must be triggered within the time window before the notice is cleared (the description suggests a 30-second window, likely due to the plugin's transient handling of error notices).

3. Code Flow

1. Initialization: LoginNocaptcha::init() (in login-nocaptcha.php) checks if login_nocaptcha_key and login_nocaptcha_secret are set using valid_key_secret().
2. Hook Registration: If keys are valid, it registers the authenticate filter: add_filter('authenticate', array('LoginNocaptcha', 'authenticate'), 30, 3).
3. Source (Input): An attacker requests /xmlrpc.php/<img src=x onerror=alert(1)>. WordPress populates $_SERVER['PHP_SELF'] with the path including the payload.
4. Processing: The authenticate() function is called during the XML-RPC authentication attempt. It checks the current script: basename($_SERVER['PHP_SELF']).
5. Storage: The function identifies the script is not wp-login.php and calls update_option('login_nocaptcha_error', ...) containing the malicious basename.
6. Sink (Output): When an admin loads any admin page, LoginNocaptcha::admin_notices() is called. It retrieves the login_nocaptcha_error option and echoes it directly to the page without using esc_html() or wp_kses().

4. Nonce Acquisition Strategy

This vulnerability is unauthenticated and occurs during the authentication process itself (the authenticate filter). Therefore, no WordPress nonce is required to inject the payload.

5. Exploitation Strategy

The goal is to store an XSS payload in the login_nocaptcha_error option by making a failed login attempt via XML-RPC.

Step 1: Configure the Plugin
The plugin only hooks the vulnerable filter if it believes it is correctly configured.

# Set dummy keys of 40 characters (required by valid_key_secret check)
wp option update login_nocaptcha_key "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
wp option update login_nocaptcha_secret "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"

Step 2: Inject the Payload
Send an XML-RPC request to a URL path containing the XSS payload. We use a standard XML-RPC system call to trigger the authentication flow.

• URL: /xmlrpc.php/foo<img src=x onerror=alert(document.domain)>
• Method: POST
• Body: A standard wp.getUsersBlogs XML-RPC call with dummy credentials.

Step 3: Trigger the XSS
Log in as an administrator and navigate to the dashboard.

6. Test Data Setup

1. Plugin Status: Ensure login-recaptcha is installed and active.
2. Admin User: A standard administrator account (e.g., admin / password).
3. Keys: Keys must be 40 chars long as per LoginNocaptcha::valid_key_secret.

7. Expected Results

• The POST request to /xmlrpc.php/... will return an XML response (likely an authentication failure).
• The WordPress option login_nocaptcha_error will now contain the string foo<img src=x onerror=alert(document.domain)>.
• When the admin navigates to /wp-admin/, an alert box displaying the document domain will appear.

8. Verification Steps

After sending the injection request, verify the database state using WP-CLI:

wp option get login_nocaptcha_error

Expected Output: The string should contain your HTML payload unencoded.

To verify the XSS via browser:

1. Use browser_navigate to /wp-admin/.
2. Observe the execution of the JavaScript payload.

9. Alternative Approaches

If /xmlrpc.php/ does not correctly populate PHP_SELF due to server configuration (e.g., Nginx without proper path info support), try:

• Query String Injection: Some environments might include the query string in PHP_SELF if not properly handled, though basename() usually mitigates this.
• Direct Path: If the site uses a custom login page provided by another plugin that triggers authenticate(), use that path.
• Different Payload: If <img ...> is blocked by a WAF, try <details open ontoggle=...> or <svg onload=...> to avoid the script or img tags.

Payload for http_request (Step 2):

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value><string>attacker</string></value></param>
    <param><value><string>password</string></value></param>
  </params>
</methodCall>

Request URL: http://localhost:8080/xmlrpc.php/x%3Cimg%20src=x%20onerror=alert(1)%3E