CVE-2024-6397 Exploit & Vulnerability Analysis

The Exploit

An unauthenticated attacker with knowledge of a target WordPress username can bypass authentication and log in as that user without ever knowing their password.

POST /wp-json/instawp-connect/v1/temporary-login HTTP/1.1
Host: target-site.com
Content-Type: application/json

{
  "i": "1",
  "e": "2025-12-31 23:59:59",
  "r": "999"
}

The attacker receives a response containing a temporary login token. Seconds later, they visit the site and append ?iwp-temp-login=<token> to any URL; WordPress logs them in as the user specified by parameter i (the user ID). No API key, no session cookie, no CSRF token was required to generate this token. The REST endpoint permission_callback evaluated to __return_true before any authentication function ran.

What the Patch Did

Before

'permission_callback' => '__return_true',

After

'permission_callback' => '__return_true',

Wait—the permission callback itself did not change in the diff. The real fix came in the second patch file: class-instawp-hooks.php added nonce verification to the API key generation flow. The hook that accepts the temporary login token now calls wp_verify_nonce( $instawp_nonce, 'instawp_connect_nonce' ) before invoking Helper::instawp_generate_api_key(). Additionally, the temporary login handler validates token expiration and attempt counts via instawp_is_user_login_expired() and instawp_is_user_attempt_expired() before silently logging the user in. The core vulnerability—that REST endpoints allow unauthenticated POST/DELETE to sensitive authentication endpoints—remained exploitable via CSRF (as the CVE note confirms), but the nonce addition restricted the initial API key generation handshake to same-origin requests.

Root Cause

CWE-306 (Missing Authentication) + CWE-352 (Cross-Site Request Forgery).

The REST API endpoints /temporary-login (POST) and /delete-temporary-login (DELETE) in class-instawp-rest-api.php set 'permission_callback' => '__return_true', meaning WordPress performs zero access control checks before invoking the handler. An attacker-controlled i parameter (user ID) reaches the temporary_login() method unvalidated: the function calls validate_api_request() internally, but this runs after WordPress has already granted access via the permissive callback. The temporary login token is then generated and returned directly to the attacker. Even though version 0.1.0.44 added the nonce check to the initial API key setup, an attacker who already possessed a valid API key (or who triggered setup from an attacker-controlled domain) could repeatedly call the REST endpoints to generate tokens for any user ID, crossing the authentication boundary without proof of identity.

Why It Works

The load-bearing line in the patch is wp_verify_nonce( $instawp_nonce, 'instawp_connect_nonce' ). This function checks that the request originated from a form or link generated by the same WordPress instance, preventing an attacker from issuing the sensitive API key generation call from an external site. However, this only protects the initial handshake. The reason the engineer also added instawp_is_user_login_expired() and instawp_is_user_attempt_expired() checks was defence-in-depth: even if someone steals a temporary token, it will auto-expire and will be rejected after N failed attempts. The problem is that the REST endpoints themselves—temporary-login and delete-temporary-login—were never gated with a proper capability check like current_user_can('manage_options'). They only call validate_api_request(), which apparently accepts any numeric user ID. If you removed the nonce from the setup flow but kept the REST endpoint permission_callback as __return_true, an attacker who already had an API key (or who intercepted one) could still generate tokens for any user indefinitely.

Hardening Checklist

• Implement explicit capability checks in REST permission callbacks: Replace 'permission_callback' => '__return_true' with a closure that calls current_user_can('manage_options') or validates an API key before the handler runs, not during it.
• Validate object ownership and boundaries: Before generating a temporary login token for user ID i, confirm via get_user_by('ID', $i) that the user exists and belongs to the authenticated request's context.
• Add nonce validation to state-changing operations: Call wp_verify_nonce() on all POST/DELETE/PUT endpoints that affect authentication state, not just on initial setup.
• Implement per-user rate limiting and cooldown: Use wp_cache_set() or update_user_meta() with a timestamp to enforce a minimum delay (e.g., 1 second) between consecutive token generation requests for the same user, limiting brute-force enumeration.
• Always sanitize and validate time parameters: Use strtotime() and then time() comparison to reject expiration dates in the past or more than N days in the future; do not store user-supplied epoch timestamps directly.

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-6397