CVE-2024-6328 Exploit & Vulnerability Analysis

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.

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

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

[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