What happened?
On 14 November 2024, the US National Vulnerability Database published CVE-2024-10924, giving federal weight to what WordPress site owners had been scrambling over for the prior week: a critical authentication bypass in Really Simple Security, the security plugin running on more than four million sites. The flaw, discovered by Wordfence researcher István Márton and disclosed on 6 November with patch 9.1.2 shipping the same day, lived in the plugin’s own two-factor authentication module – the component installed precisely to stop attackers from logging in as someone else. For versions 9.0.0 through 9.1.1.1, an unauthenticated attacker could manipulate the two-factor onboarding REST endpoint and, on sites where 2FA setup was incomplete, take over any account including administrators. When this post publishes on 30 November 2024, the patch campaign is weeks deep, the CVE record is public cannon, and the incident has become the year’s clearest demonstration that in the WordPress ecosystem the extras bolted on for security can carry more auth-bypass risk than the core they protect.
Quick Answer: CVE-2024-10924 is a CVSS 9.8 authentication bypass in the Really Simple Security plugin for WordPress (Free, Pro, and Pro Multisite), affecting versions 9.0.0 to 9.1.1.1 and exposing over four million sites at disclosure. The bug sat in the plugin’s two-factor authentication REST API: its onboarding-skip endpoint did not correctly validate the user it was acting on, so on configurations where 2FA was enabled but not yet fully configured for a user, an unauthenticated attacker could supply that user’s ID and complete the flow as them – including administrators. Wordfence’s István Márton discovered and disclosed the flaw on 6 November 2024 with an immediate patch (9.1.2), and the NVD published the record on 14 November 2024. Early exploitation evidence followed the public proof-of-concept pattern within days, and by month’s end the guidance was universal: sites still on 9.1.1.1 or earlier should treat admin password rotation, session revocation, and log review as mandatory follow-ups to the update, not optional extras.
The anatomy of the bypass
The technical anatomy matters because it explains the blast radius. Really Simple Security, formerly Really Simple SSL, began as an HTTPS-redirection helper and grew into a full hardening suite – login protection, two-factor authentication, vulnerability scanning. The 2FA feature exposed REST routes under the plugin’s own namespace, and one of them, the skip-onboarding endpoint, had a decision path for users who had 2FA enabled globally but had not finished enrolling. On that path the code failed to properly authenticate the requesting user before trusting a user identifier in the request. The result inverted the plugin’s purpose: sites that had done the responsible thing – switched on two-factor org-wide – were the vulnerable population, while sites that never enabled 2FA in this plugin were largely untouched. A security feature defined the attack surface; an incomplete setup defined the victims.
The paper trail
| Date | Event |
|---|---|
| 2024-11-06 | Wordfence’s István Márton discloses the authentication bypass; Really Simple Security 9.1.2 ships for all three editions the same day |
| 2024-11-06→14 | Advisories, media coverage, and mass-update campaigns roll out across the four-million-install base |
| 2024-11-14 | NVD publishes CVE-2024-10924 (CVSS 9.8), formalizing the record and the affected-version range 9.0.0–9.1.1.1 |
| 2024-11 mid→late | Exploit techniques matching the public write-ups circulate; hosters and WAF vendors push virtual-patch signatures for the rogue REST calls |
| 2024-11-20→26 | Major-vendor briefings (Kaspersky, SonicWall, university ISCs) land; unpatched long-tail sites are the residual risk pool |
| 2024-11-30 | This post publishes: patched-and-verified is the only safe state, and follow-up hygiene – password rotation and session audits – is the closing step |
Why the bypass cut so deep
Authentication bypass is the aristocracy of web vulnerabilities: no social engineering, no payload hosting, no zero-day broker – just a crafted request and instant administrative session. In WordPress terms an admin account is close to code execution, because administrators install plugins, and plugins run PHP. An attacker who bypasses auth on a vulnerable site could upload a malicious plugin or theme and own the box, its database, and its SEO. That chainability is why CVSS 9.8 was assigned despite the conditional trigger (incomplete 2FA enrollment), and why the incident response reflex for vulnerable sites went beyond patching: credential rotation, session-token invalidation, integrity checks on recently added plugins and users, and log review for hits on the telltale REST route in the access logs. The four-million-install figure is the quiet scandal – a single plugin decision by a single vendor became, overnight, one of the largest remediation obligations in the ecosystem’s history.
Ecosystem context: auth-bypass season
CVE-2024-10924 did not arrive alone. Autumn 2024 delivered a cluster of authentication failures across widely deployed WordPress plugins – the OAuth Single Sign-On plugin flaw (CVE-2024-10111, insufficient verification of the user returned by a social-login token, letting unauthenticated attackers log in as arbitrary users) chief among them, alongside the continuing aftershocks of file-upload and privilege-escalation bugs from earlier in the year. The pattern behind the pattern is structural: WordPress core’s own auth machinery – cookies, nonces, pluggable functions, application passwords for REST API and XML-RPC contexts – has been hardened by two decades of scrutiny, while the plugin layer re-implements authentication decisions (2FA flows, SSO token handling, onboarding skips) with a fraction of the review hours. Attackers noticed the differential years ago; 2024 made it undeniable. The ecosystem’s response vocabulary – virtual patching, canary auditing of plugin auth code, staged 2FA rollouts with enrollment enforced before enablement – all concedes the same point: the trust boundary is no longer at core login, it is at every plugin REST route that answers “who is asking?”
- Patch same-day, verify same-week: 9.1.2 shipped with disclosure; staying on 9.1.1.1 past mid-November meant open exposure to trivially scripted attacks.
- Security plugins carry real risk: the flaw lived in the 2FA module of a hardening suite – evaluate new security-plugin versions with the same skepticism as any other privilege-adjacent code.
- Partial 2FA rollout is a vulnerable state: the trigger was incomplete enrollment; enabling 2FA without enforcing completion left sites both inconvenienced and exploitable.
- Post-patch IR is part of patching: password rotation, session revocation, and log review for the rogue REST endpoint are standard follow-ups for any auth-bypass exposure, not paranoia.
FAQ
How did the attack actually work?
The plugin’s two-factor subsystem exposed a REST route used to skip the 2FA onboarding wizard. In the vulnerable versions, one code path – reached when two-factor was enabled globally but the target user had not completed enrollment – failed to properly validate that the requesting party was that user. An unauthenticated attacker could send a crafted request referencing an arbitrary user ID and, on affected configurations, the endpoint would complete the flow and grant an authenticated session for the chosen account. Attackers naturally aimed at user ID 1, the default first administrator. The request was a single unauthenticated POST to a predictable route, which is why post-patch guidance always includes searching access logs for the plugin’s REST namespace during the exposure window.
Was WordPress core itself affected?
No – this was a plugin vulnerability, not a core flaw, despite circulation headlines that blurred the line. WordPress core’s authentication functions and its application-password system (the 24-character tokens scoped to REST API and XML-RPC contexts since version 5.6) were not part of the bug. That distinction is the post’s real lesson: core auth has absorbed twenty years of adversarial review, but the ecosystem’s effective auth surface includes every plugin that makes its own identity decisions. A site is only as authenticatable as its least-reviewed REST route, and in November 2024 that route belonged to a security plugin on four million sites.
What should a site owner who missed the window do now?
Treat the site as potentially compromised, in order of urgency. Update to 9.1.2 or later immediately; then rotate all passwords, starting with administrators; invalidate existing sessions and application passwords so any stolen tokens die; audit users, plugins, and themes added or modified during the exposure window; and review access logs for POST hits on the plugin’s two-factor REST endpoints from unfamiliar IPs. If log coverage is incomplete, the conservative read is that exposure is unknown – and for e-commerce or membership sites that usually justifies a deeper forensic pass rather than an assumption of clean.
Legacy: trust is a moving target
CVE-2024-10924 closed the month as the definitive case study in ecosystem risk amplification: one vendor’s onboarding wizard, four million sites, and a week of global remediation fueled by a single well-written advisory. Its durable lesson cuts in two directions. For site owners: patch velocity is a security control, and authentication is the asset to protect with the most paranoia – the follow-up checklist (rotate, revoke, review) is now muscle memory for any auth-bypass disclosure. For the ecosystem: the mass-update machinery built out of past crises worked, moving the installed base to safety faster than any previous mega-plugin flaw, even as the long tail of unmaintained sites remained the permanent reservoir. And for everyone who installs a hardening suite and considers the job done, November 2024’s answer is permanent: security code is code, code has bugs, and the safest site is the one whose owner verifies – plugin by plugin, route by route – what is actually answering the question of identity.
