WordPress security in 2026: who is on call for your website?

Your WordPress site is running software with a timer on it, and nobody at your company is watching the clock.

Last year the security firm Patchstack logged 11,334 security flaws across the WordPress world, up 42% in a single year. That is about thirty a day, every day. Roughly 91% of them were in plugins, the third-party add-ons you installed for booking forms, galleries, popups, and payments. Nobody force-updates those for you.

46% had no fix available on the day they became public. For nearly half, there was nothing to install even if you had been watching. The only moves were to disable the add-on, block the traffic, or sit exposed, and all three need somebody who knows which is which.

Ninety minutes from announcement to attack

On July 17, 2026, a critical flaw scoring 9.8 out of 10 was disclosed in WordPress. It allowed remote code execution, meaning an attacker could run their own code on your server without ever logging in. The first attacks reached Patchstack’s sensors about ninety minutes later. Over the following days it blocked more than 65,000 attempts from over 1,500 separate addresses. Four days after disclosure the flaw was added to the federal catalog of vulnerabilities known to be under active attack.

That is the gap between a flaw becoming public and attacks reaching sites that run it. When one of your thirty-a-day lands on a plugin you use, the question is who applies the fix inside that window.

Why July was the lucky kind of flaw

That July flaw happened to be in WordPress core, and core is the one piece of your site that repairs itself. The researchers reported it privately, the repaired release shipped the same day, and WordPress force-enabled automatic updates to push it out. Most owners were covered before they knew anything had happened.

That is the exception, not the pattern. Six of last year’s 11,334 flaws were in core. The other 11,328 were in the parts of your site that nobody patches for you. There is no central team responsible for the booking plugin a developer built in 2019 and stopped touching in 2022. When that one goes public, no release gets force-pushed to you, no automatic update arrives overnight, and the ninety-minute clock runs exactly the same.

At thirty disclosures a day, something in your plugin list is likely affected right now. Most owners find out when the site starts redirecting elsewhere or the card processor calls.

The real question is a staffing question

Most small-business WordPress sites carry more add-ons than the owner can name from memory. Each one is software your business now depends on, written by someone you have never met, on a schedule you do not control.

So the useful question is not whether WordPress is secure. It is this:

When an urgent fix lands on a Saturday, who applies it within a day?

For most Houston businesses under thirty people, the honest answer is a name, and that name belongs to someone with another full-time job. That is not negligence. A five-person company cannot staff a security rotation for a website, and it does not have to keep owning one.

What a managed platform actually changes

On a managed platform, the vendor patches the software underneath. Webflow and Shopify work this way, and it is why our website work is built on those platforms. There is no add-on stack for an owner to inventory, and no late-night decision about whether an update breaks your checkout.

This does not make a site unhackable. What it removes is the ownership of patching: fewer moving parts that belong to you, and a vendor whose paid staff handles the rest. For most small businesses that trade is worth making.

There are businesses this does not suit, and we have written about when staying on WordPress is the right call. It comes down to whether you employ someone whose actual job includes patching your site on a Saturday. Almost no company under thirty people does. If you want the platforms compared side by side, that is its own article.

Three things to check this week

First, confirm your site is running WordPress 7.0.2, 6.9.5, or 6.8.6. Versions older than 6.8 escaped this one only because they predate the code that broke, which means they are old enough to be carrying problems of their own.

Second, open your plugins list and count. Then, next to each one, write the name of the person who would apply an urgent fix to it within 24 hours.

Third, count the blanks. Each one is a piece of your website nobody is responsible for patching.

If the blanks outnumber the names, the problem is not your software. It is a job nobody was hired to do that has been assigned to you by default. Send us your plugin list and we will show you what moving to a platform that patches itself would take, and what it would cost you to keep doing this yourself.

Frequently asked questions

Is WordPress safe to use in 2026?

That depends entirely on who maintains it. Of the 11,334 security flaws found across the WordPress world in 2025, 91% were in plugins, and 46% had no fix available the day they became public. WordPress core repairs itself automatically. The add-ons that make up most of your site do not, and attacks begin within about ninety minutes of a flaw going public.

How fast do attackers exploit a WordPress vulnerability?

Faster than any small business can staff for. The first attacks on the July 2026 flaw reached the security firm Patchstack about ninety minutes after the fix shipped, and it blocked more than 65,000 attempts from over 1,500 addresses in the days that followed. The gap between a public announcement and mass attack is now measured in minutes.

Do I still need a maintenance plan for a WordPress website?

Yes, and it needs a name attached to it. The question worth answering is who applies an urgent add-on fix within a day, including on a weekend. If the honest answer is nobody, the site does not have a maintenance plan. It has a hope.

Is a managed platform more secure than self-hosted WordPress?

It removes work rather than removing risk. On a managed platform like Webflow or Shopify the vendor patches the software underneath, so there is no add-on stack for an owner to track. A self-hosted site can be run just as safely, but somebody has to actually do it.