Six Million WordPress Sites Are Exposed to Two Flaws: The Patch Is Out, So Why the Wait?

Two distinct security vulnerabilities are currently affecting more than six million WordPress websites, and while patches are available, the window for exploitation is narrowing. The report from TechRadar doesn’t mince words on the severity, but the real story here isn’t just the existence of the flaws—it’s the operational reality that most of those six million sites won’t be updated within a meaningful timeframe.

What the Flaws Actually Are

TechRadar’s reporting confirms that two separate security issues are at play, both of which have been addressed in available patches. The scale is the headline number: over six million installations are potentially exposed. That figure alone puts this in the upper echelon of WordPress security incidents, not because the flaws are necessarily the most technically sophisticated ever found, but because the attack surface is so massive.

WordPress powers a significant portion of the web, and a vulnerability in its core—as opposed to a third-party plugin—means every site running an unpatched version is a potential target. The report does not specify whether these are remote code execution flaws, SQL injection points, or something else entirely, but the urgency implied by the patch availability suggests they are not trivial. For developers and site owners, the lack of granular technical detail in the initial report is less important than the immediate action item: update core, now.

The Patch Paradox: Availability vs. Adoption

Here is where the analysis gets uncomfortable. A patch being available is only half the battle. The WordPress ecosystem has a chronic adoption problem. While automatic minor core updates have been a feature for years, major versions and some security releases still require a manual trigger or a hosting configuration that supports auto-updates. The six million affected sites are not a static number; they are a countdown clock that resets only when site administrators take action.

For marketers and business owners who don’t manage their own infrastructure, this is a reminder that your CMS is not a “set it and forget it” tool. The responsibility often falls on a developer or agency, and if that relationship has lapsed, your site is sitting in the exposed pool. The practical takeaway is to verify your WordPress version right now and confirm that your hosting environment is configured to apply security patches automatically. If you are running a version that is even one minor release behind, you are likely in the affected cohort.

Why This Matters Beyond the Immediate Fix

This incident underscores a structural weakness in the WordPress model: the reliance on a decentralized update ecosystem. Unlike a SaaS platform where the vendor patches the server and all users are instantly protected, WordPress puts the onus on the site owner. This is the trade-off for the flexibility and control that WordPress offers, but it is a trade-off that carries real risk.

Consider the typical lifecycle of a vulnerability disclosure:

• Researchers find a flaw and privately report it to the WordPress core team.
• A patch is developed and released, often with a coordinated public disclosure.
• Attackers immediately reverse-engineer the patch to identify the vulnerability and begin scanning for unpatched targets.
• The window between patch release and mass exploitation is often measured in hours, not days.

This timeline means that the sites most at risk are not the ones run by diligent developers who update within the hour. The highest risk is for the long tail of the web: the small business blog, the local nonprofit, the portfolio site that was built three years ago and hasn’t been touched since. For those operators, this news is not a suggestion—it is a mandatory maintenance call.

What to Watch Next

The immediate action is clear, but the follow-up questions are where the real vigilance is required. First, monitor WordPress’s official security release channels for the specific version numbers that contain the fixes. If your site is on a managed WordPress host, check their status page or announcements—many reputable hosts will apply critical patches automatically, but you should not assume that is the case without verification.

Second, watch for signs of compromise even after you patch. If your site was exposed for any length of time, there is a possibility that an attacker already gained a foothold. A patch prevents future exploitation, but it does not clean up a site that has already been breached. Look for unfamiliar admin users, unexpected file changes, or suspicious outbound traffic. If you lack the technical capacity to perform this audit, this is the moment to engage a professional.

Finally, treat this as a catalyst for reviewing your broader security posture. If you are running outdated plugins, using default admin credentials, or have no backup strategy, you are not addressing the root cause of your risk. This patch closes the current hole, but the next disclosure is already in the pipeline somewhere. The sites that weather these storms are the ones that treat security as a continuous process, not a reactive event.