Updating WordPress Won't Save Your Site. Hundreds of These Holes Have No Fix.

For ten years, every person who has ever touched Bob's website told him the same thing.

Keep it updated and you will be fine.

His web guy said it. His host says it in the welcome email. The little badge on his dashboard says it every month without using words. Update, and you are doing your part. It is decent advice and I have given it myself, in writing, more than once.

Here is the part nobody says out loud. It only works when there is something to update to.

At the end of the first quarter of 2026, Wordfence counted 747 known WordPress vulnerabilities still sitting there with no patch available. (Wordfence, 2026) Not late. Not ignored. Not shipped and unclicked. Nobody has written a fix.

There is no button for those. There is no badge. There is no screen anywhere in WordPress that will tell you if one of them is on your site right now.

TL;DR (the short answer)

No, updating WordPress does not cover you, because some holes have no update. At the end of the first quarter of 2026, Wordfence reported 747 known WordPress vulnerabilities that remained unpatched, meaning no fixed version exists. That number is falling, from 950 at the end of Q3 2025 and 905 at the end of Q4 2025, so the situation is improving. Wordfence's own advice when there is no patch is to remove the software. Nothing in the WordPress dashboard tells you whether one of your plugins is on that list.

3 Things to Remember

747 Holes. Nothing to Click. Nothing to Install.

Wordfence publishes a threat report every quarter, and one line in it does not get talked about enough.

At the end of Q1 2026, 747 vulnerabilities remained unpatched. (Wordfence, 2026)

Every other WordPress security story you have read is about a gap in time. A hole gets found, a fix gets written, and the danger lives in the days or months before you install it. I wrote a whole post about that gap, because it is real and it is most of the problem.

This is a different thing. For these 747, the gap never closes. There is no version to move to. The developer walked away, or shut down, or read the report and decided not to bother, or never saw it at all.

The dashboard cannot help you with this. It is built to compare what you have against what exists, and when nothing exists, it has nothing to say. So it says nothing, which looks exactly like being fine.

A Plugin Doesn't Announce That It Died.

Here is how a plugin ends up in that 747, and it is not dramatic.

Somebody built a useful thing in 2016. It did one job well. Thirty thousand people installed it, including whoever built your site. For a few years the developer shipped updates.

Then life happened. A job, a kid, a business that never made enough money. The updates got further apart, then stopped.

Nothing on your site changed the day that happened. The plugin still works. It still shows a green checkmark. It sits there doing its job, and the only difference is that there is now nobody on the other end.

Then somebody finds a hole in it. They report it properly. The report goes out into the world with a tracking number. And the email to the developer bounces, or lands in an inbox nobody opens anymore.

Now the hole is public, the code is on your site, and there is no fix coming. Ever.

The mistake: thinking a plugin that still works is a plugin that is still maintained.

The fix: check the last-updated date on every plugin you run. It is on the plugin's own page on WordPress.org.

The payoff: you find the dead ones before somebody else does.

I have said for years that the plugin pile holds you hostage because you cannot safely pull anything out of it. This is the other half of that. Some of what is in the pile is not just risky. It is abandoned.

Wordfence's Own Advice Is to Delete It.

This is the part I want you to sit with, because it comes from the security company, not from me.

In their own Q1 2026 report, writing about these unpatched vulnerabilities, Wordfence says the action to take is remedial action "like removing the software." (Wordfence, 2026)

That is a security firm telling site owners that for hundreds of known holes, the fix is not a patch. It is a shovel.

Think about what that means on a real site. Bob has fifteen plugins. Some of them are load-bearing. The form one, the booking one, the one his checkout runs through. "Remove the software" is an easy sentence to write and a hard afternoon to live through, because on a WordPress site you often cannot tell what else breaks when you pull one out.

That is the trap, and it is worth naming plainly. The recommended fix for these holes is the one action a stacked WordPress site makes most expensive.

The mistake: assuming there is always a safe middle option between "patch it" and "pull it."

The fix: find out today which of your plugins you could actually remove without breaking the site.

The payoff: when you do have to pull one, it is a decision instead of a crisis.

How to Check Your Own Fifteen.

You cannot look up the 747 as a list and match it against your site. That is the honest answer and I am not going to pretend otherwise.

What you can do is find the plugins most likely to be in it, and it takes about fifteen minutes.

• Pull your plugin list. Dashboard, then Plugins. Write down every name and version.
• Open each one's page on WordPress.org. Put the plugin's short name on the end of wordpress.org/plugins/. Two things matter on that page. The last updated date, and whether there is a red closure bar at the top.
• Flag anything over a year old. A plugin that has not shipped anything in a year is not necessarily vulnerable. It is the profile that ends up in the 747.
• A red closure bar means stop. That plugin was pulled from the directory. It does not disappear from your site on its own. If you have it, you still have it, running, today.
• Ask what breaks. For each flagged plugin, find out what on your site depends on it before you touch anything.

That list will not be perfect. It will find the worst of it, which is the part that matters.

You are a plain-talking website helper. Here is every plugin on my WordPress site: [PASTE YOUR PLUGIN LIST].

For each one, check its page on WordPress.org and show me a simple table.
1) The plugin name and its page address on WordPress.org.
2) The date it was last updated.
3) Whether that page shows a red closure notice, and if it does, the date and the reason word for word.
4) How many sites run it.
5) A plain-English guess at what my site uses it for.

Then give me three short lists.
A) Plugins with no update in over a year.
B) Plugins that have been closed or removed from the directory.
C) For each plugin in A and B, what is likely to break on my site if I remove it, and what a replacement would be.

Rules: short sentences, 5th grade words. If you cannot confirm something, say you cannot confirm it instead of guessing.

The Number Is Going the Right Way, and That Deserves Saying.

I am not going to run a scary number past you and skip the context.

747 is the lowest of the last three quarters. It was 950 at the end of Q3 2025 and 905 at the end of Q4 2025. (Wordfence, 2026)

That is a real drop, and it happened while the total number of reported vulnerabilities went up. More holes are being found and more of them are getting fixed. The people doing that work are winning ground.

Plenty of the 747 are also in plugins almost nobody runs, and plenty are low severity. The odds that one specific abandoned plugin is on one specific small business site are not high.

You Can't Abandon Code That Isn't There.

The reason my builds do not have this problem is boring. There is nothing on the site written by somebody who could walk away from it.

A WordPress site is a stack of businesses. Fifteen plugins is fifteen companies that can fold, get sold, or quietly stop caring, and your site keeps running their code either way. You did not sign anything with any of them.

The sites I build are already built. The pages are finished files sitting on a fast network. The features are part of the build, so there is no third party to go quiet on you.

That is not me being clever. It is fewer moving parts, and none of them belong to a stranger. That is the whole idea behind the 100K Website, and it is why I say the old machine is done for real business sites.

And keeping it current is my job, not yours. You go run your business.

Where Staying Updated Genuinely Is Enough.

Let me give the other side its full due, because most weeks it is right.

Updating is still the single highest-value thing a WordPress owner does. The overwhelming majority of WordPress sites that get hacked were running something with a patch available that nobody installed. If you do nothing else, do that.

And the reporting system around WordPress works. Researchers find these holes, they get tracking numbers, security firms publish them, and the unpatched count has fallen for three quarters running. That is a lot of people doing unglamorous work well.

Now the turn. All of that good work still lands on one person's shoulders, and for these 747 it lands there with nothing in its hands. Bob has no idea whether one of his fifteen plugins is on that list. There is no screen that will tell him. And the recommended fix, pulling the software off the site, is the exact thing his site is built to make impossible.

You should not have to audit fifteen strangers' software between jobs.

Keeping a website current is a real job. It is just not your job, and it should not be the thing standing between your business and a hole nobody is going to fix.

Let me show you what a site with nothing on it to abandon actually feels like, built on your own market.

Take a Test Drive →

You get a real look at your own market. No obligation, and nothing to cancel.

Want the whole playbook first? Plan your attack. Balls Out Marketing.

FAQ

This is post 5 in a run on WordPress security. Post 4 covered the fix that shipped in March and was still being attacked in June. That one was about a patch nobody installed. This one is about the holes where there is no patch to install.