WPS Limit Login is edited by WP Serveur, WordPress french host. Criticity level for this update is low.
Protection ByPass #1
File : /classes/plugins.php
Lines : 427
[pastacode lang=”php” manual=”if%20(%20isset(%20%24request%5B’query’%5D%20)%20%26%26%20strpos(%20%24request%5B’query’%5D%2C%20’action%3Dconfirmaction’%20)%20!%3D%3D%20false%20)%20%7B%0A%0A%C2%A0%20%C2%A0%20%40require_once%20ABSPATH%20.%20’wp-login.php’%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
Issue : If the URL contains “action=confirmaction” it’s enough to acces the login page.
Demo : https://example.com/wp-login.php?SECUPRESSaction=confirmaction
Protection ByPass #2
File : /classes/plugins.php
Lines : 477-480
[pastacode lang=”php” manual=”if%20(%20is_admin()%20%26%26%20!%20is_user_logged_in()%20%26%26%20!%20defined(%20’DOING_AJAX’%20)%20%26%26%20%24pagenow%20!%3D%3D%20’admin-post.php’%20%26%26%20(%20isset(%20%24_GET%20)%20%26%26%20empty(%20%24_GET%5B’adminhash’%5D%20)%20%26%26%20%24request%5B’path’%5D%20!%3D%3D%20’%2Fwp-admin%2Foptions.php’%20)%20)%20%7B%0A%0Awp_safe_redirect(%20%24this-%3Enew_redirect_url()%20)%3B%0A%0Adie()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
Issue : Reading the code, you can see that if the param “adminhash” is present in the l’URL, you’ll have the right to access the login page.
Demo : https://exemple.com/wp-admin/?adminhash=1
Protection ByPass #3
File : /classes/plugin.php
Lines : 653-656
[pastacode lang=”php” manual=”if%20(%20!%20empty(%20%24_GET%20)%20%26%26%20isset(%20%24_GET%5B’action’%5D%20)%20%26%26%20’rp’%20%3D%3D%3D%20%24_GET%5B’action’%5D%20%26%26%20isset(%20%24_GET%5B’key’%5D%20)%20%26%26%20isset(%20%24_GET%5B’login’%5D%20)%20)%20%7B%0A%0Awp_redirect(%20%24this-%3Enew_login_url()%20)%3B%0A%0Aexit()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
Issue : This code is active if your have WooCommerce activated (+60% of WP e-commerce).
Demo : https://example.com?action=rp&key&login
Protection ByPass #4
File : /classes/plugin.php
Lines : 563
if ( strpos( $url, 'wp-login.php' ) !== false ) {
Issue : Still we check the presence os a string in the URL (referer) to give the right to access to the login page.
Demo : You have to modify the header “Referer” and just add “wp-login.php”. Now send an empty POST request on”https://example.com/wp-login.php?action=postpass“.
The WordPress core will do this:
[pastacode lang=”php” manual=”if%20(%20!%20array_key_exists(%20’post_password’%2C%20%24_POST%20)%20)%20%7B%0A%0Awp_safe_redirect(%20wp_get_referer()%20)%3B%0A%0Aexit()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
So, our referer will be read, then pass through our hook and since “wp-login.php” is present, we will be redirected on the login page.
Default Parameter Usage
File : /classes/plugin.php
Issue : If a default value is used, we know that the default is “login”, so if I can’t access to your login page, I’ll try “/login” first. Also, /login is already a shortcut in WordPress, so it’s not really changed, bots already know that one.
Full Path Disclosure
File : /classes/plugin.php
Lines : 498
&& ( $result = wpmu_activate_signup( $referer['key'] ) )
Issue : If we trigger the hook “wps_hide_login_signup_enable” with the correct URL we will get a Fatal Error because the function wpmu_activate_signup() is not declared yet, there is a lack of file inclusion. The displayed error discloses the path information.
These vulnerabilities has been patched in v1.5.3
