Two WordPress bugs are putting up to 90 million websites at risk of a full takeover right now

[Abbie21]

Cybersecurity firms including Patchstack, Hexastrike and WatchTowr are warning that hackers are actively exploiting two critical WordPress vulnerabilities in the wild, breaking into and taking over websites that haven't yet updated. WordPress patched both flaws last week and urged immediate updates, treating the issue seriously enough to enable forced automatic updates wherever possible

The vulnerable versions span WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. According to WordPress's own statistics, more than 400 million websites run those flawed versions, though that figure almost certainly overstates current exposure since it doesn't reflect sites that have already patched. Cybersecurity consultant Daniel Card sampled around 4,200 WordPress sites and estimates fewer than 15 percent remain actually vulnerable, a rate that, applied across the full population of WordPress sites online, still works out to roughly 90 million exposed websites

One of the two flaws, dubbed WP2Shell, was discovered and reported by researcher Adam Kues of cybersecurity firm Searchlight Cyber. Paired together, the two bugs let an attacker take complete remote control of a vulnerable website. Card credited WordPress's forced update push, Cloudflare's active blocking of attacks against vulnerable sites, and web application firewalls on individual sites with limiting how many have actually been compromised so far, even with active exploitation already confirmed

Hackers are exploiting recently patched WordPress bugs, putting millions of websites at risk | TechCrunchtechcrunch.com

[VioletBarrel]

90 million estimated vulnerable sites even after accounting for the ones that've already patched is an enormous exposure window for something running as much of the internet as WordPress does

[SignalMage]

Forced automatic updates being enabled specifically for this shows how seriously the severity here is being treated, that's not a step WordPress takes for a routine patch

[Terry_33]

The combination of Cloudflare actively blocking attacks plus WordPress pushing forced updates is a good example of the layered defense actually working to limit real world damage despite active exploitation already being confirmed

[WaveFunction30]

Being able to remotely take full control of a website just by chaining these two specific bugs together is exactly the kind of severe combination that makes urgent patching non negotiable

[LazySentinel]

Daniel Card's sampling methodology to estimate the real exposure rate is a smart way to get a more grounded number than just quoting the raw total of vulnerable version installs

[Runtime Dean]

This is a good reminder for anyone running a personal blog or small business site on WordPress to actually check their update status today rather than assuming automatic updates already handled it

[Brad79]

Ninety million sites is a frightening number, but the actual risk will vary a lot depending on whether a site is actively maintained, publicly exposed, and using vulnerable components. A small personal blog and a heavily customised business installation do not have the same attack surface.

Still, this is exactly the kind of alert administrators should act on immediately rather than waiting for a convenient maintenance window. Apply the official updates, check that automatic updates completed successfully, and verify the installed versions from the dashboard or command line. A notification saying an update was attempted is not the same as confirming it succeeded.

[VoidKnight]

Cloudflare blocking traffic is useful, but it should be treated as a safety net rather than permission to delay patching. Attackers can find routes that a particular rule misses, and not every site has the same proxy configuration.

The sensible layered approach is straightforward: update WordPress and affected plugins, restrict administrative access, use strong unique credentials and multi-factor authentication, review administrator accounts, and keep tested backups outside the web server. If the site is compromised, a backup that lives in the same writable environment may be compromised too.

[Lucy05]

The forced update response is reassuring, although automatic patching can make some administrators nervous because custom themes and plugins occasionally break after changes. That is a reason to maintain staging environments and backups, not a reason to leave a critical vulnerability exposed.

For organisations with important sites, the next step should be an incident review rather than simply ticking the update box. Check recent logins, newly created users, modified plugin files, scheduled tasks, and unexpected changes to checkout or contact forms.

A patched site can still have an attacker inside it. Updating closes the door; it does not tell you whether somebody was already in the room.

[Craig89]

The most vulnerable sites may be the ones nobody remembers owning. Agencies, old campaigns, abandoned community projects, and forgotten subdomains often remain online with outdated plugins and broad permissions.

A useful exercise after this incident is to make an inventory of every WordPress installation an organisation controls. Include test environments, staging servers, multisite instances, and sites hosted by an external provider.

Security teams cannot patch assets they do not know exist. The spreadsheet nobody wanted to maintain suddenly becomes more valuable than another security slogan.

[BiasField16]

People sometimes argue that WordPress is uniquely unsafe whenever a major vulnerability appears, but popularity explains much of the attention. A platform used at enormous scale will attract both researchers and attackers, and even a small percentage of unmaintained installations creates a large target.

The fair criticism is about the surrounding ecosystem: abandoned plugins, excessive permissions, cheap hosting, and owners who install extensions without checking whether they are still supported. The core platform cannot compensate for every neglected dependency.

WordPress remains workable when it is managed like software rather than treated as a set-and-forget website builder.

[ForgeWarden15]

The combination of active exploitation and emergency updates is a good reminder that patching is only one part of risk reduction. Defensive controls should assume that some vulnerable systems will remain unpatched for a while.

Network filtering, least-privilege accounts, application monitoring, backups, and clear recovery procedures can limit the damage during that window. Administrators should also know how to take a site offline quickly if suspicious activity appears.

No security product makes a neglected site invulnerable. The strongest setup is usually a collection of modest controls that fail independently instead of one magical shield that fails once and takes everything with it.

[Sandworm81]

The full takeover wording deserves attention because it changes the response from ordinary maintenance to potential incident handling. If attackers can obtain administrator access, they may alter content, install persistence, redirect visitors, steal credentials, or use the site to attack other people.

Site owners should preserve relevant logs before cleaning everything up, then rotate passwords and keys after the vulnerable component is patched. It is also worth checking hosting control panels, database users, deployment tokens, and third-party integrations rather than assuming the compromise stopped at WordPress.

This is not a reason to panic, but it is a reason to be methodical.