WordPress 7.1.3 was released on October 6 with seven security fixes. Three of the seven vulnerabilities were reported by Anthropic, while a fourth was reported by security firm Trail of Bits in collaboration with OpenAI.
That means more than half of the issues fixed in this WordPress security release were credited to AI labs or researchers working with them. It is also the third security release for WordPress 7.1 in just three weeks.
That does not mean WordPress has suddenly become less secure. It means vulnerabilities are being found, reported and fixed much faster than they used to be.
The part that has not necessarily sped up is the last step: getting those fixes installed on every WordPress site.
What happens during the gap between a vulnerability being patched and that patch reaching your site depends heavily on where the site is hosted.
What WordPress 7.1.3 fixed
The official WordPress 7.1.3 release notes list seven security fixes:
- A stored cross-site scripting vulnerability on the Comments screen in the WordPress admin area, triggered by a pending comment. Reported by Trail of Bits in collaboration with OpenAI.
- A SQL injection vulnerability in the WordPress export tool. Reported by Anthropic.
- A denial-of-service vulnerability in the code WordPress uses to make outgoing web requests. Reported by Anthropic.
- A permissions issue that allowed Author accounts to pin posts to the top of a site. Reported by Anthropic.
- An issue that allowed visitors who were not logged in to read comments on private and unpublished posts. Reported by Patchstack.
- A cross-site scripting vulnerability involving Imgur embeds. Reported independently by three researchers.
- A flaw in the way WordPress generates certain internal hook names. Reported by the WordPress security team.
WordPress has not reported active exploitation of any of these vulnerabilities, and several require either a logged-in account or some action by an administrator. In other words, 7.1.3 is an important security update, but not an emergency.
The previous release was more urgent.
WordPress 7.1.2, released September 22, fixed a vulnerability that could be exploited without logging in. Patchstack observed attackers attempting to exploit it within hours of the fix becoming public.
Why WordPress security releases are coming faster
For much of the past decade, the WordPress security team received roughly 20 to 30 vulnerability reports per month through its bug bounty program.
In July, that number jumped to about 450, according to a WordPress maintainer quoted by The Repository. The program’s public statistics now show roughly 2,000 reports over the past 90 days and more than $90,000 in bounty payments during that period. By comparison, the program had paid just over $200,000 in total since 2017.
WordPress attributes much of the increase to AI models that can analyze source code and identify potential vulnerabilities at scale.
A large number of those submissions are duplicates or low-quality reports. But enough are legitimate that WordPress announced a Core Security Initiative in August to accelerate the security release process and work through the growing backlog.
For site owners, the result is more frequent security updates.
Since WordPress 7.1 was released in August, there have already been three security releases:
- WordPress 7.1.1 on September 17, with 11 security fixes.
- WordPress 7.1.2 on September 22.
- WordPress 7.1.3 on October 6.
The same AI-assisted tools that help defenders find vulnerabilities are also available to attackers.
We wrote in May about how quickly a published security fix can now be turned into a working exploit. A security update that reaches your site a month late offers much less protection than it would have a few years ago.
WordPress updates automatically – until it doesn’t
WordPress has supported automatic installation of minor security releases since 2013.
That leads many site owners to assume security updates are always being installed automatically.
In practice, they are not.
After WordPress 7.1.3 was released, we checked the WordPress version of every WordPress site running across our shared hosting servers. One week after the release:
- About four in five sites running WordPress 7.1 had updated to 7.1.3.
- About one in six were still running WordPress 7.1 exactly, meaning they had missed all three subsequent security releases, including one that had already been actively exploited.
- Nearly one-third of all WordPress sites were still running a version older than 7.1.
Only about one in ten of the sites that were behind had automatic updates intentionally disabled.
The rest were configured to update themselves, but had failed to do so.
There are many reasons this happens. WP-Cron may have stopped running because the site receives very little traffic or because a developer disabled it for performance reasons. Someone may have added a setting to wp-config.php years ago to prevent an update from breaking a theme or plugin. An earlier update may have failed partway through and never retried. File permissions may have changed during a migration.
Even something as simple as a .git directory inside a WordPress installation can cause WordPress to disable automatic updates.
Our support team encounters and fixes situations like these regularly. Any hosting provider managing a large WordPress population is likely to see something similar.
That raises a more important question:
What protects a WordPress site during the days or weeks before it successfully installs a security update?
What protects a WordPress site that has not updated yet
On our servers, the answer is not just WordPress itself.
Every site we host, on every hosting plan, sits behind several security layers that continue protecting it even if WordPress is temporarily out of date.
A web application firewall with rules updated hourly. Every request to every hosted website passes through a web application firewall. Its rules are refreshed hourly with protections for newly disclosed WordPress core, plugin and theme vulnerabilities.
When a vulnerability such as the one fixed in WordPress 7.1.2 becomes public, a rule capable of blocking the exploit pattern can often reach our servers within hours. That is before many WordPress sites have installed the update, and potentially long before a site with a broken automatic updater ever would.
The malicious request is blocked at the server before it reaches WordPress.
Automatic attacker blocking. If an IP address repeatedly triggers security rules, it can be blocked from the server entirely. That prevents automated scanners from working through a long list of known WordPress exploits against every site they can find.
Real-time malware scanning. Files written into hosted sites are scanned as they arrive. Known malicious files can be quarantined automatically. If an attacker does manage to get past another security layer, this provides another opportunity to stop the payload before it can be used.
PHP execution monitoring. A separate security layer monitors PHP code as it executes and can terminate scripts exhibiting malicious behaviour, including code that has been modified or obfuscated enough to avoid a conventional signature scan.
Together, these protections mean that a site running one or two security releases behind is not automatically exposed to every exploit currently circulating.
That is very different from running the same outdated site on a server with no comparable protection.
Not every host provides the same protection
This is worth paying attention to because it is not something most people investigate when choosing a web host.
Some shared hosting environments do not use a web application firewall at all. Others offer one only as a paid add-on. Some rely on generic firewall rules that are updated infrequently and have little awareness of newly disclosed WordPress vulnerabilities.
Malware scanning also varies dramatically. On some platforms it may happen only periodically, meaning malicious files can remain active for hours or days before being detected.
On a server without compensating security controls, a WordPress site that misses a security update may be exposed from the moment an exploit becomes public until the update is finally installed.
For a site whose automatic updater is permanently broken, that exposure can effectively be permanent.
A useful question to ask any hosting provider is:
If my WordPress site misses a security update, what does your infrastructure do to protect it in the meantime?
“Keeping WordPress updated is your responsibility” may technically be true, but it also means the host is leaving the entire problem to the site owner.
You should still update WordPress
Server-level protection is a safety net, not a replacement for installing security updates.
Updating WordPress closes the vulnerability itself. A firewall blocks known ways of exploiting it.
You want both.
Log in to WordPress and go to Dashboard → Updates. The page will show the version you are currently running. If you are not running WordPress 7.1.3 or the equivalent security release for your branch, install the update.
Also check whether WordPress reports that automatic updates are enabled and functioning. If updates are disabled or being managed elsewhere, make sure you know why.
Then go to Tools → Site Health.
WordPress will flag problems with background updates and scheduled events. Repeatedly delayed scheduled events are often a sign that WP-Cron is not running properly, which can also interfere with automatic updates.
If your site is still running an older WordPress branch such as 6.9 or 7.0, security fixes have been backported to those versions as well. Your site should have received the corresponding security release.
WordPress describes those backports as a courtesy, however. Only the current major release receives full support, so older installations should still plan to move to WordPress 7.1.
The bigger change
AI has made finding WordPress vulnerabilities much cheaper and faster.
That is helping the WordPress security team discover and fix bugs sooner, but it is also shortening the time attackers need to understand a published vulnerability and start exploiting sites that have not yet been patched.
The result is likely to be more security releases, arriving more frequently.
At the same time, a meaningful percentage of WordPress sites will continue to miss automatic updates for reasons their owners do not even know about.
That makes the hosting environment more important than it used to be.
A missed security update should not immediately turn a website into an easy target. The server should provide another layer of defence while the underlying software catches up.
That is how we approach WordPress security on CanSpace.
Whatever host you use, make sure they can say the same.
