CVE-2024-10924: Critical Authentication Bypass in Really Simple Security (4 Million+ Sites)

In November 2024, the WordPress community ran into an uncomfortable irony: one of the most widely installed security plugins on the planet contained a flaw that let attackers log in as any user — including an administrator — without ever knowing a password. The plugin is Really Simple Security (formerly Really Simple SSL), active on more than four million websites. The vulnerability, tracked as CVE-2024-10924, earned a near-maximum severity score of 9.8 and was considered dangerous enough that WordPress.org took the rare step of force-updating sites across the network.

There is an extra twist that makes this case worth studying. The bug only became exploitable when you turned on the plugin’s two-factor authentication feature — so the site owners who took an additional step to harden their logins were precisely the ones left exposed. Here is what happened and what to do about it.

CVE Details at a Glance

How the Vulnerability Works

To support its two-factor login flow, Really Simple Security registers a set of REST API endpoints under its own namespace (for example, /wp-json/reallysimplessl/v1/two_fa/). When a request arrives at one of these endpoints, the plugin needs to figure out which user account the request belongs to. It does this through a helper function named check_login_and_get_user.

That function is supposed to do two things: confirm that the login attempt is legitimate, and then return the matching user. The problem is in how it handled failure. When the verification step did not pass, the error was not properly enforced — the code carried on instead of stopping, and still handed back a valid user object based on the user_id value supplied in the request. A check that fails silently is, in practice, no check at all.

The result is that an attacker only needs to send a single crafted request, name the user they want to become, and supply a made-up authentication token. Because administrators are almost always user ID 1, the path to full control is short:

POST /wp-json/reallysimplessl/v1/two_fa/skip_onboarding
Content-Type: application/json

{
  "user_id": 1,
  "login_nonce": "231231231",
  "redirect_to": "/wp-admin/"
}

No password. No valid nonce. No existing access of any kind — the plugin treats the request as a successfully authenticated login and issues a session for that user. Because the attack needs no authentication and is trivial to automate, its attack complexity was rated low, which is much of why the final CVSS score landed at 9.8.

Real-World Impact

An authentication bypass that lands you in an administrator account is about as bad as WordPress vulnerabilities get. Logging in as an admin is not a limited foothold; it is the keys to the entire site. From there an attacker can do essentially anything:

• Install malicious plugins or themes and plant persistent backdoors that survive a password change.
• Create new administrator accounts to keep access even after the original flaw is patched.
• Inject spam, deface pages, or silently redirect visitors to scam and malware sites.
• Read and export sensitive data — user records, and on WooCommerce stores, customer orders and personal information.
• Use the compromised site as a launch point for sending spam or attacking other targets.

Because exploitation is unauthenticated and easy to script, this is the kind of flaw that gets weaponized into mass, automated scanning within days of disclosure. With four million installations, the incentive for attackers to hunt for unpatched sites was enormous. And the requirement that two-factor authentication be enabled is a genuinely cruel detail: the more security-conscious administrators — the ones who bothered to turn on 2FA — were the exposed population, while sites that never enabled it were untouched.

How to Check If You Are Affected

Confirming your exposure takes about a minute. In your WordPress dashboard, go to Plugins > Installed Plugins and look for “Really Simple Security” or, on older installs, “Really Simple SSL.” Note the version number shown beneath the plugin name.

• If the version is anywhere from 9.0.0 through 9.1.1.1, the vulnerable code is present.
• If the version is 9.1.2 or higher, you are running the patched build.
• If you are below 9.0.0, the two-factor REST endpoints that carry this flaw were not present, but you are far behind on updates and should upgrade regardless.

One important caveat: WordPress.org pushed a forced security update for this release, so many sites were patched automatically. Do not assume that happened on yours. Forced and automatic updates can fail quietly because of restrictive file permissions, disabled auto-updates, or a customized setup. Verify the installed version reads 9.1.2 or later rather than trusting that it must have updated itself.

How to Fix It

The fix is straightforward and should not wait: update Really Simple Security to version 9.1.2 or later. Take a quick backup first, then update from Plugins > Installed Plugins (or through your host’s update tools), and confirm the version afterward. That single action closes the vulnerability.

A few additional steps strengthen your position:

• Can’t update this very moment? As a short-term stopgap only, disabling the plugin’s two-factor authentication setting removes the condition the exploit depends on. This is a temporary measure — patching is the real fix, so do not rely on it.
• Check for signs of compromise. Review your administrator accounts for any user you do not recognize, look for recently modified core or plugin files, and run a malware scan. Pay attention to unexpected new plugins or themes.
• If anything looks off, rotate credentials. Change administrator passwords, force a logout of all active sessions, and review any API keys or integration tokens.
• Turn on automatic plugin updates. For a flaw like this, the gap between disclosure and patching is the entire window of risk. Automatic updates shrink it.

The Takeaway

It is tempting to read this story as a reason to distrust security plugins, but that is the wrong lesson. Security plugins are software, and all software has bugs; a single mishandled error in one helper function was enough to undo an otherwise solid login system. The right response is defense in depth. Keep every plugin, theme, and the WordPress core current, ideally with automatic updates enabled. Run only the plugins you genuinely need, since every one is part of your attack surface. Monitor for the things an attacker would do after a breach — new administrator accounts, unexpected file changes, unfamiliar logins — so you find out quickly if something slips through. And consider a security layer that can virtual-patch known vulnerabilities, buying you protection in the hours and days before you apply an update.

The sites that weathered CVE-2024-10924 best were not the ones that guessed right about which plugin to trust. They were the ones that had updates, monitoring, and a firewall already in place before anyone had heard of the bug. That is WordPress security hygiene in a sentence: assume something will eventually break, and build the layers that catch it when it does.