Loading...
On March 11, 2026, WordPress pushed version 6.9.4 — the third patch in 48 hours — after acknowledging that previous security fixes were incomplete. If your business site runs on WordPress and you're not actively maintaining it, this is what falling behind looks like.
WordPress released three updates in two days in March 2026, culminating in version 6.9.4 after admitting earlier patches didn't fully resolve security issues. WordPress powers 43% of the web but depends entirely on manual maintenance. Sites that aren't actively updated, backed up, and monitored are sitting targets. Here's what happened, why it matters, and what to do about it.
WordPress released version 6.9.4 — the third update in a 48-hour window. The first two patches addressed security vulnerabilities that the WordPress security team flagged as needing immediate attention. The third patch came after the team acknowledged that not all fixes in the earlier releases were fully applied.
Read that again: WordPress shipped security fixes, then had to ship another fix because the first fixes did not completely work.
This is not unusual for WordPress. It is not a scandal. It is the normal operating reality of software that powers 43% of all websites on the internet. When vulnerabilities are discovered, patches ship fast — sometimes too fast for complete verification. The expectation is that site owners will update promptly and stay current.
The problem is that most small business WordPress sites are not maintained by anyone.
Every hour between a security patch being published and your site being updated is an hour of exposure. When WordPress announces a vulnerability and releases a fix, it simultaneously publishes details about what was broken. Attackers do not need to discover vulnerabilities on their own — they read the same changelogs security researchers do.
Automated scanning tools begin probing WordPress sites within hours of a patch announcement. They are looking for the sites that have not updated yet. Three patches in two days means the window was messy — site owners who updated on day one may not have had the complete fix. Site owners who waited were exposed to all of it.
WordPress automatic updates help — but they are not a complete solution. WordPress has a background auto-update feature for minor releases, but it depends on server configuration, hosting environment, and whether the site owner or their developer disabled it. Plugin conflicts, custom code, and older PHP versions can all prevent auto-updates from applying cleanly. And auto-updates do not cover major version upgrades, plugin updates, or theme updates — which are where the majority of WordPress vulnerabilities actually live.
The real exposure is not WordPress core — it is the ecosystem. According to WPScan's vulnerability database, the vast majority of WordPress security issues come from plugins and themes, not from WordPress itself. A site running the latest WordPress core but using three outdated plugins is not secure. It is secure in one layer and exposed in three others.
Most small business owners think their WordPress site is "fine" because it loads when they visit it. Here is what "fine" often looks like under the hood:
WordPress core is two or more versions behind. The site was built by an agency or freelancer, launched, and never updated. Every skipped update compounds the number of known vulnerabilities present.
Plugins have not been updated in months — or years. The contact form plugin, the SEO plugin, the caching plugin, the security plugin, the slider plugin that nobody uses anymore but is still installed. Each one is a potential entry point.
The PHP version is outdated. WordPress runs on PHP, and many hosting providers allow sites to run on older PHP versions indefinitely. Older PHP versions no longer receive security patches, which means the foundation your site runs on has its own set of unpatched vulnerabilities.
Backups are not running — or have never been tested. Many site owners assume their hosting provider handles backups. Some do. Many do not, or their backup retention window is too short to be useful after a compromise that goes undetected for weeks.
Nobody is checking the admin panel. If you do not log into your WordPress dashboard regularly, you will not see the update notifications, the security warnings, or the signs that something has already gone wrong.
This is not an edge case. This is the default state of the majority of small business WordPress sites.
A hacked WordPress site costs between $3,000 and $50,000 to clean up and recover. That range covers malware removal, data recovery, SEO damage repair (Google may have already flagged the site as unsafe), customer notification if personal data was exposed, and the business lost while the site was down.
A maintained WordPress site costs $50 to $300 per month. That covers core updates, plugin updates, security monitoring, backups, uptime checks, and someone who actually looks at the site regularly.
The math is not complicated. But the maintenance cost is easy to skip when the site appears to be working and nobody is checking what is happening underneath.
Most small business owners do not skip maintenance on purpose. They skip it because nobody told them it was necessary. The agency that built the site handed it over and moved on. The freelancer finished the project and is not answering emails. WordPress itself does not send invoices for maintenance — it just silently falls behind until something breaks.
WordPress is free to install. It is open source. It is flexible and powerful. It has the largest ecosystem of themes and plugins of any CMS. And it requires active, ongoing maintenance to remain secure.
That is the trade-off built into the WordPress model. You get freedom and flexibility in exchange for accepting responsibility for updates, security, compatibility testing, and performance monitoring. For businesses with dedicated IT teams or reliable maintenance partners, that trade-off works.
For a small business that built a WordPress site three years ago and has not touched it since — the trade-off has already gone sideways. The site is running on unpatched software, with unpatched plugins, on a potentially outdated server environment, with no backup strategy, and no one watching.
Three patches in two days is WordPress working as intended. The security team found problems and shipped fixes quickly. That is responsible behavior. But it only protects the sites that actually apply the updates. For the millions of WordPress sites where nobody is paying attention, the patches might as well not exist.
Log in to your WordPress dashboard this week. Check what version you are running. Check how many plugins have pending updates. Check your PHP version (Settings > Site Health). If you see a wall of orange and red notices, that is your answer.
Update everything — but carefully. Update WordPress core first, then plugins one at a time. If you have a staging environment, test there first. If you do not, take a manual backup before updating. Plugin conflicts during updates can break a site.
Remove any plugins you are not actively using. Deactivated plugins are still a risk — they can still be exploited if the files are on the server. Delete what you do not need.
Verify your backups. Not "do you have backups turned on" — have you actually downloaded and tested a backup restore? A backup you cannot restore is not a backup.
Check who has admin access. Old developer accounts, former employee logins, and the default "admin" username are common entry points. Remove what should not be there. Enable two-factor authentication on every remaining account.
Decide who is responsible for ongoing maintenance. This is the critical question. If the answer is "nobody," that is the vulnerability — not any specific plugin or patch.
WordPress is a legitimate platform that powers a massive portion of the web. The problem is never the tool — it is whether anyone is maintaining it. Three patches in two days is a healthy security response from the WordPress team. But it also highlights exactly how demanding the maintenance commitment is.
We build on modern frameworks that reduce the maintenance surface area — fewer plugins, no shared hosting dependencies, no PHP version roulette. But the principle applies regardless of what platform your site runs on: a website is infrastructure, not a one-time project. It needs someone watching it.
If your WordPress site has not been updated in months, or if you are not sure who is supposed to be maintaining it, that is worth a conversation — before the next patch cycle decides for you.
👉 Get a site health review or Book a strategy call with Sitora
If this article reflects the kind of problem you are solving, these are the most relevant next steps inside SitoraWeb.
Improve trust, search visibility, and lead quality with a custom website built around how buyers actually compare options.
Explore Website ServicesBuild secure portals, dashboards, internal tools, and customer-facing web apps that remove operational friction.
Explore Web App ServicesGet validation, workflow analysis, and a roadmap before you commit to the wrong build path.
Explore ConsultingThe rest of the blog covers search strategy, site architecture, analytics, automation, and common mistakes that slow down growth.