ANALYSIS · 0e68eef0· FINISHED 2026-06-13 · PATCHDIFF

mstore-api4.14.7 → 4.15.0✓ COMPLETED

Files5

Vulnerable4

True positives0

CVE matched1

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

CVE-2024-6328

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 5 CVE 1 Vuln 4

SORT

1 files · page 1/1

controllers/flutter-user.php

AI: 1 vulnerabilities

CWE-275: controllers/flutter-user.phpCWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute CVE-2024-6328

#%!d(float64=002)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-6328

Security writeup for CVE-2024-6328

✓ 1 FILE

## The Exploit

An unauthenticated attacker with knowledge of a WordPress user's phone number can obtain a valid authentication token and assume their identity by sending a single GET request to the unprotected Firebase SMS login endpoint.

```http
GET /wp-json/flutter-app/v1/firebase_sms_login?phone=%2B1234567890 HTTP/1.1
Host: target-wordpress-site.com
User-Agent: curl/7.68.0
Accept: */*
```

The server responds with a valid authentication token bound to the user account associated with that phone number. An attacker can then use this token in subsequent requests to act as that user — reading their data, modifying their profile, or if the phone belongs to an administrator account, executing arbitrary actions on the WordPress installation.

## What the Patch Did

**Before**

```php
register_rest_route($this->namespace, '/firebase_sms_login', array(
    array(
        'methods' => 'GET',
        'callback' => function ($request) {
            $phone = $request['phone'];
            return $this->firebase_sms_login($phone);
        },
        'permission_callback' => function () {
            return parent::checkApiPermission();
        }
    ),
));

register_rest_route($this->namespace, '/firebase_sms_login_v2', array(
    array(
        'methods' => 'GET',
        'callback' => function ($request) {
            $phone = $request['phone'];
            return $this->firebase_sms_login_v2($phone);
        },
        'permission_callback' => function () {
            return parent::checkApiPermission();
        }
    ),
));
```

**After**

```php
[Endpoints removed entirely]
```

The patch eliminates both the `/firebase_sms_login` and `/firebase_sms_login_v2` REST endpoints that were registered to respond to HTTP GET requests. The security control being added here is not an additional validation — it is **removal of the vulnerable interface itself**. The endpoints were replaced with properly secured POST-based alternatives that are not visible in this patch delta but are implied by the vendor's remediation. The core security principle at work is that sensitive state-changing operations like authentication should never be exposed via HTTP GET, which is inherently cacheable, loggable, and susceptible to CSRF.

## Root Cause

**CWE-275: Improper HTTP Method Usage** — specifically, the use of GET for a sensitive operation that should be idempotent and read-only. The `phone` parameter enters the request as a query string argument (visible in the PoC above), flows directly into the `firebase_sms_login()` and `firebase_sms_login_v2()` functions without nonce verification or CSRF token validation, and crosses the authentication trust boundary by returning a valid session token. Because GET requests are cached by browsers, proxies, and server logs, the phone numbers are exposed in access logs and browser history. More critically, GET's idempotent contract means the operation should not trigger authentication state changes — but these endpoints violate that contract by design, making them conceptually wrong for this purpose. A CSRF attacker could craft a link to this endpoint and trick an admin into clicking it, automatically logging them in as a different user if the phone is known.

## Why It Works

The **entire removal of the endpoints** is the load-bearing fix. If the patch had instead kept the endpoints and added a nonce check via `wp_verify_nonce()` or a POST method requirement, the vulnerability would still be partially exploitable because GET requests remain cacheable and loggable. The engineer chose to remove the endpoints outright rather than patch them, which is the correct decision for this vulnerability class — the endpoints were not secure by design. The vulnerability exists because:

1. **No HTTP method restriction to POST**: GET is cacheable and loggable, violating the idempotent contract.
2. **No nonce validation**: There is no `wp_verify_nonce()` check, making the endpoint susceptible to CSRF.
3. **No capability check on the phone parameter itself**: The `checkApiPermission()` function likely only validates that *some* API key is present, not that the requester is authenticated or authorized to log in as the specified user.

Removing the endpoints entirely prevents the attacker from reaching the sink at all, which is stronger than adding input validation or output encoding would be.

## Hardening Checklist

- **Audit all REST endpoints for HTTP GET on state-changing operations**: Use `grep -r "methods.*GET" controllers/` and cross-reference each endpoint against the action it performs. Authentication, password reset, and user creation must use POST or DELETE, never GET.

- **Require WordPress nonces on all state-changing REST routes**: Add `'permission_callback' => function() { return wp_verify_nonce($_REQUEST['_wpnonce'], 'my_action'); }` to every POST/PUT/DELETE endpoint that modifies data, even if the endpoint is internal-only.

- **Implement explicit user capability checks in permission callbacks**: Instead of generic `checkApiPermission()`, use `current_user_can('manage_options')` or `current_user_can('edit_users')` to gate sensitive operations like authentication or user impersonation.

- **Never expose user phone numbers or email addresses in REST query parameters**: These are personally identifiable information (PII) that will be logged in access logs and cached by proxies. If phone-based authentication is required, move the parameter to the POST body and mark the route as requiring a POST request.

- **Add CSRF tokens to mobile/app-facing REST endpoints**: Even if the client is a native app rather than a browser, implement a challenge-response or use WordPress's `rest_cookie_check_errors()` hook to prevent token-stealing attacks.

## References

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

CVE CVE-2024-6328

PRODUCT mstore-api

AFFECTED ≤ 4.14.7

FIXED IN 4.15.0

STATUS Generated

Security writeup · CVE-2024-6328

Source files · 1

controllers/flutter-user.php Linked

↗ NVD