ANALYSIS · cb1ee827· FINISHED 2026-06-13 · PATCHDIFF

instawp-connect0.1.0.44 → 0.1.0.45✓ COMPLETED

Files25

Vulnerable9

True positives0

CVE matched3

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-6397

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 25 CVE 3 Vuln 9

SORT

3 files · page 1/1

includes/apis/class-instawp-rest-api.php

AI: 2 vulnerabilities

CWE-306: Missing Authentication for Critical FunctionCWE-20: Improper Input Validation CVE-2024-6397

#%!d(float64=004)

includes/class-instawp-hooks.php

AI: 1 vulnerabilities

CWE-352: Cross-Site Request Forgery (CSRF) CVE-2024-6397

#%!d(float64=009)

includes/functions.php

AI: 1 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled KeyCWE-770: Allocation of Resources Without Limits or Throttling CVE-2024-6397

#%!d(float64=011)

1–3 of 3

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-6397

Security writeup for CVE-2024-6397

✓ 3 FILES

## 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.

```http
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**
```php
'permission_callback' => '__return_true',
```

**After**
```php
'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

CVE CVE-2024-6397

PRODUCT instawp-connect

AFFECTED ≤ 0.1.0.44

FIXED IN 0.1.0.45

STATUS Generated

Security writeup · CVE-2024-6397

Source files · 3

includes/apis/class-instawp-rest-api.php Linked

includes/class-instawp-hooks.php Linked

includes/functions.php Linked

↗ NVD