Three WordPress security releases landed within four weeks this summer, and several of our clients have asked us the same questions: is this getting worse, and should we be worried about the platform our site is built on? The honest answer is that something has changed, but it’s not that WordPress is becoming less secure, nor has our confidence in it changed.
What actually changed
Vulnerabilities are being found faster than they used to be, and AI is most of the reason. The bad news is that adversaries are utilizing AI to find and exploit vulnerabilities in all sorts of software. AI is really good at holding an entire codebase in view at once and noticing two or more seemingly unrelated pieces that can be hooked together to gain access to software it otherwise couldn’t. This is exactly the kind of connection that used to take a human researcher months to stumble on, if ever.
The good news: AI is being used by software companies to find those vulnerabilities first. Microsoft shipped a record 570 security fixes in their July release, roughly triple its previous record, after deploying an AI-powered system built to find bugs in its own code before attackers do. The WordPress flaw patched in July was reported by pwn.ai, a tool built by third-party security firm Octagon Networks.
What has shifted is not how many holes exist in software, it’s how quickly they are found and how little time there is between a fix becoming available and an exploit being used in the wild (i.e. on publicly accessible sites). With the July WordPress release, exploitation of unpatched WordPress sites started the same evening the patch was shipped. That turnaround time used to be a window measured in weeks, not hours.
The risk hasn’t changed shape, it’s changed speed. Which means the thing that protects you is no longer “we update our site quarterly,” it’s how fast someone notices and acts.
Is WordPress a riskier choice now?
No. It’s as safe as it’s always been, and one of the reasons it gets attacked is because of how widely it’s used: WordPress runs approximately 43% of the public internet. If you drive the most common car on the road, more of them get stolen every year than any other model. That’s simply because there are more of them to steal, not because they’re easier to break into.
Every piece of software has vulnerabilities. Whether it’s software like Microsoft Windows, WordPress, your internet-connected fridge’s touchscreen, or the content management system that your competitor’s agency built in-house and stopped maintaining in 2020. The difference between platforms isn’t whether flaws exist; it’s how many people are looking, how quickly fixes ship, and how far back those fixes get applied. WordPress core has hundreds of engineers contributing and fixing code from around the world with a dedicated security team, and when the July fix went out, it was applied to every release going back to 4.7, which was released in 2016. That means a vulnerability vector existed for 10 years and was only discovered recently.
I’ve been building on this platform for almost two decades. The security response today is not comparable to what it was ten years ago, it’s better… in every way that matters.
No two incidents are the same
Let’s compare two of the recent incidents. Both were both called vulnerabilities, but there is more nuance.
The release in July was serious. It required no account on the website, no additional plugins, and no interaction from an admin user; an anonymous visitor could get in on a fresh install, since it exploited two bugs in tandem in the core of the software. WordPress shipped an emergency release. A working exploit was public within hours, a turnaround that hasn’t been seen in almost 10 years.
The fix in August needed two separate things to be true at once: someone with author-level access or higher was already logged into your site, and a specific image-processing configuration on the server that hosted the site had to exist. Researchers found it, reported it privately through the WordPress security team, and it was patched before anyone could use it. It was still worth updating immediately, but it was not the same urgency.
Questions we’re hearing
How will I know when the next one happens?
The primary source is wordpress.org/news/category/releases. Everything else, us included, is downstream from that page. If you are on one of our maintenance plans, you’ll hear from us first, but you are always welcome to bookmark the page if you want.
Who handles this at PL when something breaks?
Two tracks running at once. Remediation sits with our rotating on-call staff from the development team, led by our Development Director, Dev Managers, and DevSecOps. Communication sits with our project managers, led by our Projects Director, VP of Delivery, and Managing Director. The more critical the issue, the more resources are utilized to ensure faster remediation across our portfolio of sites. For an incident like July’s, that means every site we host gets patched, then checked again for anything that got in before the patch.
What do you do when a vulnerability happens?
Every vulnerability gets acted on as soon as we’re aware of it. We respond and the severity of the incident dictates the pace. Understand, patch, investigate, clean, and report.
- Understand the vulnerability and what it takes to secure a site against it.
- Patch, via software update or another mitigation (like a plugin) if a patch isn’t available yet.
- Look for evidence of active exploitation on the affected site.
- Clean up and report anything we find.
What does responsible maintenance look like, or what should I ask my web hosting provider?
If you take one thing from reading this article, take this list. It applies whether we are hosting your site or not.
- Offsite backups. Not on the same server. A backup that shares its fate with the thing it’s backing up isn’t a backup. Multiple days of backups is important, in case it takes a few days for the vulnerability to be found.
- Security as the default, in server configuration and in the baseline set of plugins a site ships with, not something added after an incident. In practice that means strong passwords, server access limited to the people who actually need it, security plugins running on the site itself, plugins chosen from sources with a track record of taking security seriously, and enough people to act quickly when risks surface.
- Uptime and activity monitoring, because unusual behaviour is usually the first visible sign someone got through.
- Planned, regular maintenance, where software gets updated and the site gets checked for quality and consistency at the same time. This is the single most important thing you can do to keep your site safe. Even in the case of the July vulnerability for WordPress which was a core issue, it still makes patching to the latest version faster and less risky if you’re up-to-date prior to an incident.
None of that is exotic. It’s unglamorous, it’s boring, and it’s exactly what holds the gates closed; when the time between disclosure and exploitation is four hours instead of four weeks.
If you’d rather not own that work internally, our managed hosting and ongoing support services are designed to take it off your plate. We manage the infrastructure, monitoring, backups, and ongoing maintenance needed to keep your website or application running smoothly. And because the people supporting your site often include the people who built it, we already understand how it fits together—so we can spend less time getting up to speed and more time solving the problem.
Image by Brian Penny from Pixabay