Introduction
The Firebase OTP verification flow in a WordPress authentication plugin never checks whose phone number was actually verified. Any attacker with a Firebase account and a target's phone number can authenticate as that user, including a site administrator, without ever needing their credentials. The flaw, tracked as CVE-2026-3655 and scored at CVSS 9.8, affects the "OTP Login With Phone Number, OTP Verification" plugin for WordPress in versions 1.8.50 through 1.8.60.
The OTP Login With Phone Number plugin provides phone number based login and registration for WordPress and WooCommerce sites, supporting SMS gateways including Firebase (as a free tier option), Twilio, Msg91, and WhatsApp. It has about 900 active installations and over 130,000 total downloads. The install base is modest, but the plugin serves a specific niche: operators who want phone based authentication without paying per message SMS costs. The Firebase integration is its main draw.
Technical Information
Root Cause: Session to Identity Decoupling
The vulnerability lives in the lwp_ajax_register AJAX handler within the ajax-handlers.php file. The Firebase OTP verification flow in this handler has two logically distinct steps that the plugin never binds together:
Step 1: Firebase Session Validation. The function idehweb_lwp_activate_through_firebase() (at line 649 of ajax-handlers.php) calls Firebase to validate that an OTP session is legitimate. Firebase returns a phoneNumber value representing the phone number that was actually verified through the OTP challenge.
Step 2: User Lookup by Request Parameter. Separately, at line 659, the handler reads the phoneNumber value supplied in the HTTP request body and uses it to look up a WordPress user account via the user meta table. This request supplied phone number determines which account the server authenticates the caller as.
The defect is that the phoneNumber returned by Firebase (the number actually verified via OTP) is never compared against the phoneNumber submitted in the HTTP request (the number identifying the target user account). The authentication logic treats these as independent, uncorrelated values. Under CWE-287 (Improper Authentication), this is a textbook case where authentication proceeds despite a missing identity verification step.
This is not a subtle timing issue or a race condition. It is a straightforward architectural omission. The code validates that a Firebase session exists and is legitimate, but never validates whose phone number that session belongs to before granting access to the account named in the request parameter.
Attack Flow
An unauthenticated attacker can exploit this through the following sequence:
-
Obtain a valid Firebase OTP session. The attacker starts a legitimate Firebase OTP verification for their own phone number. They receive the OTP via SMS, enter it, and generate a valid Firebase session token. This is a normal, legitimate use of Firebase.
-
Identify a target victim's phone number. The attacker finds the phone number of a target WordPress user (particularly an administrator) stored in the WordPress user meta table. Phone numbers may turn up through profile pages, data leaks, social engineering, or other reconnaissance.
-
Submit a crafted request to
lwp_ajax_register. The attacker sends an AJAX POST request towp-admin/admin-ajax.phpwithaction=lwp_ajax_register, including their valid Firebase session token alongside the victim's phone number as thephoneNumberparameter. -
Authentication bypass completes. The server calls
idehweb_lwp_activate_through_firebase(), which validates the Firebase session (legitimate, because the attacker did verify their own phone). The server then looks up the WordPress user tied to the victim's phone number from the request body. Since these two values are never cross checked, the server authenticates the attacker as the victim and issues a WordPress session for the victim's account.
The lwp_ajax_register handler is an AJAX endpoint open to unauthenticated users, so no prior WordPress session or any form of authentication is needed to start the attack. Beyond a Firebase account and the ability to craft HTTP requests, no special tools are required.
The Fix
The patch applied in changeset 3479314 modifies ajax-handlers.php to bind the Firebase verified phone number to the request supplied phone number. In the patched version, the phoneNumber returned by Firebase is compared against the phoneNumber parameter in the request, and authentication only proceeds if they match. This closes the decoupling that allowed the bypass.
CVSS Vector Breakdown
The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reflects the most dangerous combination of attributes:
| Component | Value | Meaning |
|---|---|---|
| Attack Vector | Network | Exploitable remotely over the internet |
| Attack Complexity | Low | No special conditions or preparation needed |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No victim action required |
| Confidentiality Impact | High | Full access to victim account data |
| Integrity Impact | High | Full control over victim account and site content |
| Availability Impact | High | Attacker can lock out legitimate users or modify site |
Affected Systems and Versions
The vulnerability affects the OTP Login With Phone Number, OTP Verification plugin for WordPress in versions 1.8.50 through 1.8.60 (inclusive).
A site is vulnerable if:
- It runs any version of the plugin from 1.8.50 to 1.8.60
- The Firebase OTP verification flow is enabled as an authentication method
- At least one user account (particularly an administrator) has a phone number stored in WordPress user meta
The vulnerability was patched in version 1.8.61. The current latest version is 1.8.62. The plugin requires WordPress 4.0 or higher and has been tested up to WordPress 6.8.5.
Vendor Security History
The security track record of this plugin is a real concern for anyone evaluating its use. The Wordfence Intelligence database records 14 vulnerabilities in this plugin since February 2022. The most severe entries are below:
| CVE | CVSS | Type | Affected Versions | Date | Researcher |
|---|---|---|---|---|---|
| CVE-2026-3655 | 9.8 | Authentication Bypass (Firebase OTP) | 1.8.50 to 1.8.60 | May 28, 2026 | lucky_buddy |
| CVE-2025-8342 | 8.1 | Authentication Bypass (WooCommerce OTP) | Up to 1.8.47 | Aug 14, 2025 | Arkadiusz Hydzik |
| CVE-2024-6482 | 8.8 | Privilege Escalation | Up to 1.7.49 | Sep 14, 2024 | Thanh Nam Tran |
| CVE-2024-5150 | 9.8 | Authentication Bypass (Empty Value) | Up to 1.7.26 | May 28, 2024 | Istvan Marton |
| CVE-2024-6125 | 8.1 | Insecure Password Reset | Up to 1.7.34 | Jun 18, 2024 | Istvan Marton |
| CVE-2024-32507 | 8.8 | Unauthorized Password Change | Up to 1.7.16 | Apr 15, 2024 | Emili Castells |
| CVE-2022-0593 | 6.5 | Remote Plugin Deletion | Up to 1.3.6 | Feb 16, 2022 | Michal Lipinski |
Three of the 14 vulnerabilities are authentication bypass flaws classified under CWE-287, and the plugin has had at least one critical or high severity vulnerability every year since 2022. The pattern is instructive. CVE-2024-5150 was a missing empty value check, CVE-2025-8342 involved OTP generation not bound to user identity, and CVE-2026-3655 involves a Firebase session not bound to the request phone number. All three share the same underlying architectural problem: the plugin's authentication logic processes the verified credential and the claimed identity as independent, uncorrelated values.
The developer has been responsive in issuing patches for each reported flaw. But the recurrence of the same vulnerability class across different code paths over two years suggests that each patch addresses the specific reported instance without a wider security review of adjacent authentication flows. Sites that patched CVE-2024-5150 but stayed on versions 1.8.50 through 1.8.60 were fully exposed again, which shows the risk of relying on plugins with repeated authentication logic failures.
Broader Threat Context
No confirmed active exploitation of CVE-2026-3655 has been documented as of May 29, 2026, but the broader landscape for WordPress authentication bypass vulnerabilities is active. Proofpoint reports that 12 distinct 2026 CVEs are being actively exploited in network facing attacks. The Digits WordPress plugin, a comparable phone based OTP authentication plugin, had its authentication bypass exploited in the wild, with FortiGuard publishing an IPS signature to detect attacks. Threat actors have also exploited authentication bypasses in the Service Finder WordPress theme. Given the low attack complexity and unauthenticated access vector, expect rapid weaponization of CVE-2026-3655.
References
- NVD Entry for CVE-2026-3655
- Wordfence Threat Intel Advisory: Unauthenticated Authentication Bypass via Firebase OTP Verification
- Wordfence Vulnerability History for OTP Login With Phone Number
- Vulnerable Code: ajax-handlers.php line 649 (tag 1.8.60)
- Vulnerable Code: ajax-handlers.php line 659 (tag 1.8.60)
- Vulnerable Code: ajax-handlers.php line 1167 (tag 1.8.60)
- Patch Changeset 3479314
- Patched Code: ajax-handlers.php trunk (line 649)
- WordPress Plugin Repository: OTP Login With Phone Number
- Proofpoint: 2026 Vulnerability Exploitation in the Wild
- FortiGuard IPS Signature: WordPress.Plugin.Digits.OTP.Security.Bypass
- Cyfirma Research: CVE-2026-1492 WordPress User Registration Auth Bypass



