CVE-2026-77753 in Temporary Login Without Password Plugin
Summary
by MITRE • 09/12/2026
The Temporary Login Without Password WordPress plugin before 1.9.9 does not prevent a temporary user from creating an Application Password, and does not revoke one when the temporary access expires or is disabled, allowing the recipient of a temporary login to retain working access to the site over REST and XML-RPC after the administrator believes it has been withdrawn. The retained access carries whatever role was granted, which for the Temporary Login Without Password WordPress plugin before 1.9.9's main use case is Administrator.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in versions of the Temporary Login Without Password plugin prior to release 1.9.9 represents a critical authentication bypass and session management failure within the WordPress ecosystem. This flaw specifically targets the lifecycle management of temporary administrative accounts, which are designed for short-term access by contractors or third-party developers. The core technical deficiency lies in the plugin's inability to properly handle Application Passwords associated with these transient user profiles. When an administrator grants a temporary login using this plugin, they often assign high-privilege roles such as Administrator to facilitate necessary tasks. However, the plugin fails to enforce restrictions on the creation of new Application Passwords for these users and, more critically, does not automatically revoke existing Application Passwords when the temporary access period expires or is manually disabled by an administrator.
From a technical perspective, this issue stems from a lack of synchronization between the temporary account's expiration status and the WordPress core mechanism that validates Application Passwords. In standard WordPress architecture, Application Passwords are stored as distinct entries in the usermeta table and validated independently during REST API and XML-RPC requests. The vulnerability arises because the plugin does not hook into or override these validation processes to check for active temporary access constraints. Consequently, even after an administrator believes they have revoked a contractor's access by disabling their account or allowing the time limit to pass, the underlying Application Password remains valid in the database. This allows any individual possessing that specific password string to authenticate successfully against the site's API endpoints without needing the user's main login credentials.
The operational impact of this vulnerability is severe due to the typical privilege level assigned to temporary users. Since the primary use case for Temporary Login Without Password involves granting Administrator-level access, an attacker or malicious insider who retains a valid Application Password effectively maintains full administrative control over the WordPress installation. This persistent access enables unauthorized modifications to site content, installation of malicious plugins, modification of theme files, and potential compromise of associated server infrastructure through remote code execution vulnerabilities that may exist in other installed components. Furthermore, because REST API and XML-RPC are often used by modern front-end applications and mobile clients, this backdoor remains functional even if the attacker cannot access the traditional wp-admin dashboard interface directly via standard login forms.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, as well as CWE-284, indicating improper access control where authentication mechanisms are bypassed or remain active beyond their intended scope. In terms of the MITRE ATT&CK framework for enterprise security, this behavior corresponds to T1078, Valid Accounts, specifically the sub-category of Persistence through valid account credentials that were not properly decommissioned. It also relates to T1528, Steal Application Access Token, if an attacker intercepts or retrieves these stored passwords from a compromised local environment before they are revoked. The persistence mechanism allows for long-term unauthorized access without triggering typical alerts associated with new login attempts from unknown IP addresses, as the authentication appears legitimate based on valid credentials.
Mitigation strategies must focus on immediate remediation and future prevention. Administrators running versions of Temporary Login Without Password prior to 1.9.9 should upgrade immediately to version 1.9.9 or later, where this logic has been corrected to ensure Application Passwords are revoked upon account expiration or disablement. For sites that cannot update immediately due to compatibility constraints with other plugins, manual intervention is required. Administrators must review the list of temporary users and manually delete any existing Application Passwords associated with those accounts through the WordPress user profile settings or directly via database queries if necessary. Additionally, implementing a policy that limits the duration of temporary administrative access and regularly auditing active API tokens can reduce the window of opportunity for exploitation. Security teams should also consider monitoring REST API logs for unusual activity from users whose primary login status is inactive but who continue to generate successful authentication events via Application Passwords.