Last week WordPress shipped an emergency security release, 7.0.3, and marked every earlier 7.0 version insecure. The headline fix was a reflected XSS on the login screen that could chain to PHP code execution. In plain terms: the vulnerable page is public on every WordPress site in the world, no login required, and the worst case is full site takeover. It still needs a victim to click a crafted link, so it wasn’t a worm eating the internet. But it was the real thing, not scanner noise.

I manage WordPress for 23 small-business sites. Within two hours of the release I had audited all of them. What that afternoon turned up is more useful than the patch itself, so I’m writing it down.

Only 3 of 23 sites said anything

Every one of the 23 sites was on the vulnerable version. That’s not a scandal, the release was two hours old. What mattered: only three of them told me. Those three run a security scanner that checks core versions and emails alerts. The other twenty were just as exposed and completely silent.

The silence wasn’t good news. It just meant nobody was watching.

If you own a small-business site, this is the question worth asking your web person: “If WordPress shipped an emergency patch this morning, how would you know?” A lot of honest answers are “I’d find out when I logged in next.” For me the honest answer was “3 of my 23 sites would email me,” which wasn’t good enough, so I built a fleet-wide version check that same afternoon. It’s about sixty lines of Python. The point isn’t the tool, it’s that the gap was invisible until a real event exposed it.

“The host patches it for me” is true, with an asterisk

Most of these sites run on a managed WordPress host, and managed hosts do push emergency core releases across their platform. That rollout is free, it’s tested at a scale I can’t match, and for most of the fleet the right move was to let it happen. Within about 20 hours it was landing on its own.

But “the host will handle it” only covers the sites the host can reach, and that’s the part that bites people. In my 23:

  • One site was mid-migration, still on its old host for a few more days. The managed rollout would never touch it, and it happened to be the one site with a bot actively hammering its login screen, the exact surface this bug lives on. That one got patched by hand, first, with a backup taken before.
  • Two sites live on other hosts entirely, one on GoDaddy, one on a budget European host, because that’s where those clients keep them. Both were outside the rollout. Both were also the hardest to verify, and one of them showed an update screen with no update button at all, a bug I still can’t fully explain.

So the fleet split into two groups: nineteen sites where the right move was patience, and four where patience was the wrong answer. I patched the four by hand that afternoon, backup first, verified after, and let the platform carry the rest. Two days later all 23 were confirmed on 7.0.3.

The one that fixed itself

The stubborn site on the budget host, the one with the buttonless update screen, patched itself overnight two days later. WordPress’s own background updater got there before I did. I’d spent a chunk of Friday ruling out theories on that site, and the boring built-in mechanism quietly won.

There’s a lesson in that too: WordPress auto-updates are better than their reputation. They’re not a strategy on their own, because “probably, eventually” isn’t a patch policy when the vulnerable page is your login screen. But they’re a real safety net, and turning them off without a replacement plan is how sites end up on insecure versions for months.

What I’d tell a business owner

  • Vulnerability alerts only cover what’s monitored. No alert doesn’t mean no problem. Ask how your site’s core version is watched, not just its plugins.
  • Know which of your sites your host’s safety net actually covers. The stragglers are always the odd ones out: the site mid-migration, the one on the old host nobody moved, the one a vendor set up years ago.
  • Emergency patching is a triage decision, not a fire drill. Patch the exposed ones now, verify the rest landed. Doing all of it by hand is risk; doing none of it is worse.
  • Verify, don’t assume. “The update ran” and “the site is on 7.0.3” are different claims. The second one is checkable in seconds.

The patch took minutes per site. Knowing which sites needed it, which could wait, and which were quietly outside the safety net, that was the actual work. It usually is.

WordPress 7.0.3 release notes: wordpress.org/news. If you’re on 7.0.2 or earlier, update today.

Aaron