CVE-2026-93368 in Rename wp-login.php to anything you want Plugin
Summary
by MITRE • 09/23/2026
The Rename wp-login.php to anything you want plugin for WordPress is vulnerable to time-based SQL Injection via 'log' (Username) Parameter in all versions up to, and including, 2.0.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. WordPress core applies wp_unslash() to the 'log' POST value before dispatching the wp_login_failed action, stripping magic-quotes backslash escaping and allowing a raw single quote to reach the plugin's handler unimpeded.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in versions of the Rename wp-login.php to anything you want plugin up through 2.0.1 represents a critical security flaw rooted in improper input validation and database query construction. This specific instance of time-based SQL injection targets the log parameter, which corresponds to the username field during the authentication process. The root cause lies in insufficient escaping mechanisms applied to user-supplied data before it is incorporated into dynamic SQL queries. Because the plugin fails to adequately sanitize or prepare this input, an unauthenticated attacker can inject malicious SQL code that alters the intended logic of the database operation. This flaw allows for the extraction of sensitive information from the underlying WordPress database, potentially exposing credentials, configuration details, and other proprietary data stored within the system.
The operational mechanics of this exploit are facilitated by a specific interaction between WordPress core functionality and the plugin's handling of login attempts. When a user submits a username via the POST request to wp-login.php, the WordPress core applies the wp_unslash function to strip magic-quotes backslash escaping from the log parameter. While this is intended for standardizing input across different server configurations, it inadvertently allows raw single quotes to pass through unimpeded when they reach the plugin's handler. Since the plugin does not implement sufficient preparation on the existing SQL query using prepared statements or proper escape functions like wpdb::prepare(), these injected characters can break out of their expected string context. This enables attackers to append additional SQL queries, leveraging time-based techniques to infer database contents based on response delays caused by conditional logic execution within the injected payload.
From a classification perspective, this vulnerability aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The specific exploitation method falls under ATT&CK technique T1059.004, specifically PowerShell or command-line interface execution if the injection leads to further system compromise, but more directly relates to data exfiltration via database manipulation. The time-based nature of the attack means that even without immediate visible output in the response body, attackers can systematically extract data by observing variations in server response times. This makes detection through standard logging mechanisms potentially difficult unless specialized intrusion detection systems are monitoring for anomalous query patterns or latency spikes associated with boolean and blind SQL injection attempts.
The impact of this vulnerability is severe due to its unauthenticated nature. Attackers do not need valid credentials to initiate the exploit, making it accessible to a broad range of threat actors scanning for vulnerable WordPress installations. Successful exploitation can lead to full database compromise, including the retrieval of administrator passwords stored in plaintext or hashed formats depending on the site's configuration. Furthermore, if the underlying MySQL user has elevated privileges, an attacker might potentially execute administrative commands on the database server itself, leading to complete system takeover. This underscores the critical importance of securing all entry points that interact with the database layer, especially those exposed during public-facing authentication processes like login pages.
To mitigate this risk, immediate action is required by updating the Rename wp-login.php plugin to a version where this vulnerability has been patched. Developers should ensure that all user-supplied inputs are strictly validated and sanitized before use in SQL queries. The implementation of parameterized queries or prepared statements using WordPress's $wpdb class methods such as prepare() is essential to prevent injection attacks regardless of input content. Additionally, applying the principle of least privilege to database accounts used by web applications can limit the damage if an injection does occur. Regular security audits and penetration testing should be conducted to identify similar weaknesses in custom plugins or themes that may lack robust input handling practices.