WordPress 6.7.2: Critical RCE Patch You Must Apply Now

Remote code execution means an attacker can run their own code on your web server without needing a username or a password. No login credentials, no weak password to guess, no employee to trick into clicking a link. Once they find a vulnerable site, they can plant malware, create hidden admin accounts, redirect your visitors to fraudulent pages, or exfiltrate your customer data — and the site continues to look entirely normal to you whilst all of that happens in the background.

WordPress 6.7.2 patches a confirmed critical-severity vulnerability of exactly this type. A critical rating means the attack is feasible at scale, requires little technical sophistication, and a successful exploit results in full server compromise. Scheduling this for your next maintenance window treats a structural fire as a draughty window.

The Gap That Leaves Business Sites Exposed

The most common situation I see is a site where nobody was ever clearly assigned responsibility for keeping WordPress updated. The developer who built the site handed it over and moved on. The marketing agency manages content but considers software updates outside their scope. The business owner assumes someone else is handling it.

That gap is a measurable liability. If an attacker gains access through an unpatched vulnerability and customer data is exposed, the question your legal team and the ICO will ask is straightforward: who was responsible for maintaining the software, and what did they do when a critical patch was released? “We weren’t sure who handled that” is not a defensible answer under UK GDPR. The accountability question matters independent of any specific vulnerability. This one just makes it urgent.

Checking Whether Your Site Has Been Updated

Log in to your WordPress admin dashboard and look at the version number displayed at the bottom of any admin screen. If you are running WordPress 6.7.2, the patch is in place. Any earlier version means your site is unpatched and exposed.

You can also go to Dashboard > Updates in the left-hand menu. WordPress will display your current version and flag whether an update is available. If 6.7.2 appears as an available update and has not been applied, apply it now before reading the rest of this post.

WordPress does run automatic background updates for minor security releases, and in many configurations a patch like this would be applied without any manual action. But automatic updates depend on several conditions being met: your hosting environment must allow the update process to write files, there must be no plugin or theme conflict blocking the update, and no developer must have disabled automatic updates in your site’s configuration. Any of those conditions failing means the update did not run — and you would have no way of knowing unless you checked. Automatic updates are a useful default, not a guarantee, and treating them as one is how sites remain unpatched for months.

If you have a staging environment or a managed hosting arrangement with update controls, check there too. Sites cloned for testing purposes sometimes run older WordPress versions and are forgotten, and because they share server resources, a compromise there can reach your live site.

Your hosting account is worth checking as well. Some businesses run multiple WordPress installations under a single account: perhaps a main site, a subdomain for a client portal, or an old site that was never decommissioned. Every one of those installations needs to be updated independently. A single unpatched installation in that account can give an attacker a foothold that extends to everything else hosted alongside it.

If You Cannot Answer the Accountability Question

After you have confirmed the update status, ask yourself one question: who is responsible for ensuring WordPress is updated when the next vulnerability is disclosed? If that question does not have a name attached to it, and a process behind that name, you have a gap that will reopen with the next patch cycle.

This is the part of the conversation that most technical suppliers avoid, because it requires someone to own a commitment. I work with business owners who want a clear answer: someone is watching, someone will act, and someone can be held to account. A retained support arrangement provides exactly that — a defined responsibility for keeping your site patched, monitored, and recoverable if something does go wrong, rather than a vague promise of availability.

The cost of a support arrangement is fixed and predictable. The cost of a compromised site is reputational damage if customers are redirected to malware, regulatory exposure if personal data is accessed, and the operational disruption of taking a site offline to clean and restore it. None of those costs are hypothetical. They follow from the same class of vulnerability that 6.7.2 patches.

If you have confirmed your site is already running 6.7.2, the immediate risk is addressed. The structural question remains.

---

If you have checked your dashboard and found your site is still running an earlier version of WordPress, contact me at The WordPress Guy today. I can apply the 6.7.2 patch, audit your remaining installations, and confirm whether automatic updates are functioning correctly on your hosting environment. Every day an unpatched site is live is a day it is discoverable by automated scanning tools that probe for exactly this class of vulnerability. The window between a patch release and active exploitation is short, and it is already open.