CVE-2021-24917

What it actually does

CVE-2021-24917 is an authorization bypass in the WPS Hide Login WordPress plugin before version 1.9.1. The plugin is intended to obscure the WordPress login URL, but unauthenticated attackers can disclose the hidden login page by sending a request to /wp-admin/options.php with a random Referer header. The issue primarily affects confidentiality by revealing the protected login endpoint; it does not by itself grant authentication, code execution, or administrative access, but it removes an access-hiding control that many sites rely on to reduce automated login attacks.

Why it matters to the business

Organizations using affected versions of WPS Hide Login may lose the protective value of their custom WordPress login URL. Once the hidden login page is exposed, attackers can run credential stuffing, brute-force attempts, phishing validation, and other authentication attacks against the real login endpoint. The high EPSS score and weaponized exploit status indicate broad automated exploitation is plausible, so internet-facing WordPress sites using this plugin should treat remediation as urgent even though the vulnerability is not currently listed in CISA KEV and is not specifically associated with ransomware campaigns.

How an attack unfolds

An attacker first identifies a WordPress site using WPS Hide Login or broadly scans WordPress sites for exposure. They then send an unauthenticated HTTP request to /wp-admin/options.php while supplying a crafted or random Referer header. In vulnerable plugin versions, the response or redirect behavior discloses the secret login slug configured by the site. The attacker can then browse directly to that login URL and proceed with follow-on activity such as password spraying, credential stuffing, brute-force attacks, testing stolen credentials, or attempting to exploit other WordPress authentication and plugin weaknesses. Successful exploitation of this CVE alone reveals sensitive configuration information; compromise requires a subsequent authentication bypass, valid credentials, weak passwords, or another vulnerability.

How to fix it

Upgrade WPS Hide Login to version 1.9.1 or later. If the plugin cannot be upgraded immediately, disable it temporarily and protect WordPress authentication through compensating controls such as multifactor authentication, strong password policy enforcement, rate limiting, CAPTCHA, web application firewall rules, IP allowlisting for administrative access, and blocking unauthenticated access to sensitive wp-admin paths where operationally feasible. Because the vulnerability exposes a previously secret URL, change the hidden login slug after patching and review authentication logs for unusual activity against both the old and newly disclosed login locations. Ensure WordPress core, themes, and other plugins are also current, since disclosure of the login endpoint often precedes broader WordPress compromise attempts.

How to confirm the fix worked

Confirm the installed WPS Hide Login version is 1.9.1 or later from the WordPress administrative plugin inventory, filesystem plugin metadata, or command-line tooling such as WP-CLI. From an unauthenticated session, request /wp-admin/options.php with a random Referer header and verify the response does not disclose or redirect to the custom login URL. Also verify that /wp-login.php and /wp-admin/ behave according to the intended post-upgrade configuration. Review web server and WordPress authentication logs after remediation to confirm there is no ongoing high-volume access to the disclosed login path, /wp-admin/options.php probing, or abnormal login failure patterns.

Typical attack path

1. Scan for WordPress sites, especially those where /wp-login.php is unavailable or redirected in a way consistent with WPS Hide Login.
2. Send an unauthenticated request to /wp-admin/options.php with an arbitrary or random Referer header.
3. Observe the HTTP response, redirects, headers, or body content for disclosure of the custom login URL.
4. Access the disclosed hidden login page directly.
5. Perform follow-on attacks such as credential stuffing, password spraying, brute forcing, or testing known compromised credentials against the exposed login form.
6. If credentials are obtained, authenticate to WordPress and attempt privilege escalation, plugin/theme modification, web shell upload, spam injection, or persistence.

How to detect it

Investigate web server access logs, CDN/WAF logs, reverse proxy logs, and WordPress authentication/security plugin logs. Look for unauthenticated requests to /wp-admin/options.php, especially requests with unexpected, random, external, or malformed Referer headers. Correlate those requests with later access to the custom hidden login slug from the same source IPs, user agents, ASNs, or time windows. Follow-on exploitation often appears as increased POST requests to the hidden login endpoint, repeated HTTP 200/302 responses around login attempts, many failed authentications, attempts across multiple usernames, or successful administrator logins from unfamiliar IP addresses. Also check for post-login compromise indicators such as plugin/theme editor use, new administrator accounts, unexpected plugin installation, modified theme PHP files, suspicious uploads, or outbound connections from the web server. No single indicator proves exploitation, but /wp-admin/options.php probing followed by login activity against the hidden slug is strongly suspicious for this issue.

• /wp-admin/options.php
• Referer:
• wp-login.php
• POST /wp-login.php
• GET /wp-admin/options.php
• /wp-content/plugins/wps-hide-login/
• WPS Hide Login
• wps-hide-login
• POST /wp-admin/admin-ajax.php
• /wp-admin/plugin-editor.php
• /wp-admin/theme-editor.php
• /wp-content/uploads/
• Failed password
• authentication failed
• Invalid username
• Too many failed login attempts

What your security team should do

• Immediately inventory WordPress sites using WPS Hide Login and identify any installations running versions before 1.9.1.
• Upgrade affected installations to WPS Hide Login 1.9.1 or later, then rotate/change the hidden login slug because the prior value may already be exposed.
• Enable or enforce multifactor authentication for WordPress administrator and privileged accounts.
• Apply rate limiting, CAPTCHA, lockout controls, or WAF rules to WordPress login endpoints to reduce credential stuffing and brute-force risk.
• Search web access logs for unauthenticated requests to /wp-admin/options.php with unusual Referer headers and for subsequent requests to nonstandard login slugs.
• Review WordPress authentication logs for spikes in failed logins, password spraying across many usernames, or successful logins from unfamiliar IP addresses after probing activity.
• Keep WordPress core, plugins, and themes patched to reduce the likelihood that exposed login access leads to full site compromise.
• Monitor threat intelligence and exploit telemetry because the vulnerability has weaponized exploitation and a high EPSS likelihood despite not being in CISA KEV.