45% of Top-Site WordPress Installs Patched Within 12 Hours of the 7.1.4 Security Release

Ras Al Khaimah, United Arab Emirates, 29 October 2026.

WordPress released version 7.1.4 on 28 October 2026 at 17:13 UTC, a security release that fixes a remote code execution weakness in the core upgrade process along with a series of stored cross-site scripting flaws, and the project backported the fixes to every branch back to 4.7 the same day. About 12 hours later, our crawl of the 20,000 most popular domains found that 326 of the 729 WordPress homepages exposing a version number (44.7%) were already on one of the patched releases. The rest were not, and a fifth of the sample was two or more releases behind.

For SEO teams the gap matters because Google treats hacked content as spam and labels compromised sites in its results, and Google's own guidance names missed software updates as one of the main ways sites get compromised.

Key findings

• Of 12,248 top domains whose homepage loaded, 1,684 carried WordPress markup and 729 exposed a released version number we could match to WordPress.org's release list.
• Roughly 12 hours after release, 44.7% of those 729 sites ran a 28 October release: 7.1.4 itself or a backported branch release such as 7.0.8, 6.9.11 or 6.8.12.
• The most common unpatched version was 7.1.3, the 6 October release, on 211 homepages. That is the population automatic minor updates are designed to move next.
• Patch rates were not higher at the very top of the list: the band ranked 5,001 to 10,000 led at 53.3%, while the top 5,000 sat at 44.1%.

What 7.1.4 fixes

The WordPress.org announcement asks site owners to update immediately and lists the issues fixed. The most serious is a weakness in the upgrade process that can lead to remote code execution during the upgrade window. Most of the others are stored cross-site scripting (XSS) flaws in editing features such as blocks, the Interactivity API and the Customizer.

Area	Issue type listed by WordPress
Core upgrade process	Remote code execution during the upgrade window
Interactivity API	Multiple stored XSS issues and a stored denial of service
Blocks (Categories, Playlist, Image, comments pagination, crafted block markup)	Stored XSS
Customizer	Stored XSS in selective refresh; unpublished changesets discoverable by unauthenticated users
User logins and privacy data removal requests	Stored XSS
Notes	Readable by privileged users without edit access to the post
Bundled root certificates	Updated after the eMudhra revocation

The announcement says the fixes were backported to all branches still eligible for security fixes, currently through 4.7, while reminding owners that only the latest version is actively supported. The WordPress release archive lists 25 maintenance releases dated 28 October, from 7.1.4 down to 4.7.39, plus 7.2 Beta 3.

How far behind the rest are

Because each branch received its own patched release, "unpatched" is not the same as "running an old branch". A site on 6.8 is patched if it runs 6.8.12. We therefore grouped every homepage by the release date of the exact version it reports.

Two groups stand out. The 253 sites one release behind are mostly on 7.1.3 and are likely to move soon if automatic background updates are on: WordPress's update documentation says minor core updates, which include security releases, update automatically by default, and strongly discourages disabling them. The smaller tail is the concern. 54 homepages report versions released in 2024 or earlier, 15 of them more than 20 releases behind on their own branch, which suggests updates have been switched off or the site is no longer maintained.

A caveat applies to both groups: page caching can keep serving an older generator tag after the code underneath has been updated, so some "unpatched" sites may simply have stale caches. The reverse error is less likely, since a cached page cannot claim a version that was never installed.

Popularity did not predict patching

Tranco rank band	WordPress homepages with a version	On a 28 October release	Share patched
1 to 5,000	145	64	44.1%
5,001 to 10,000	195	104	53.3%
10,001 to 15,000	206	94	45.6%
15,001 to 20,000	183	64	35.0%

The bands are small, so the differences are indicative rather than conclusive. What the data does show is that the most popular sites did not patch faster than the next tier down. One possible explanation, which our crawl cannot test, is that larger sites run customised stacks with their own release processes.

Top sites look like the wider WordPress base

To check whether our sample was skewed, we compared its branch mix with the version statistics WordPress.org publishes from sites that check in for updates. The match on the current branch was close.

Top sites were slightly less likely than the overall install base to sit on 6.7 or older branches. Branch share says nothing about patch level, though, which is why the release-date view above is the more useful one for judging exposure.

Why this is a search problem

Google's spam policies list hacked content, including injected code, injected pages and hidden injected links, as a policy violation, and note that hackers often use cloaking to hide their changes from site owners. When Google determines a site was hacked, the Security issues report in Search Console shows the finding, and affected pages can carry a warning label in search results or trigger a browser interstitial.

Google's guide to how sites get hacked by spammers puts missed security updates near the top of its list, saying attackers actively look for old software with known vulnerabilities, and it names WordPress security releases as one of the feeds to follow. Plugins and themes get the same warning. The release comes a week after the PHP project's emergency security releases, covered in Google's advice on serving a 503 while patching PHP.

What SEO teams should do

• Check the version on every WordPress property you look after. The patched releases are 7.1.4, 7.0.8, 6.9.11, 6.8.12 and the matching 28 October release on older branches. Anything else is exposed.
• Confirm automatic minor updates are on. Look for AUTOMATIC_UPDATER_DISABLED set to true or WP_AUTO_UPDATE_CORE set to false in wp-config.php, and for hosting dashboards that hold back core updates.
• Purge page caches after updating so that the live HTML matches the installed version, and so that your own audits do not report false positives.
• Consider removing the generator tag. It does not change your exposure, but it stops broadcasting an exact version to anyone scanning for vulnerable installs.
• Watch Search Console. Check the Security issues report and Manual actions, and scan the Pages report for unfamiliar URLs, which can point to injected pages. Link-shared and user-generated pages are a related risk: see our report on Google's new user-generated spam guidance.
• Do not stop at core. Google's hacking guide singles out outdated plugins and themes, which this release does not cover.

Methodology

We took the first 20,000 domains of the Tranco top sites list downloaded on 29 October 2026 and requested each homepage over HTTPS (falling back to the www host) between 05:23 and 05:36 UTC, following redirects, with a desktop Chrome user agent and a 15-second timeout. 12,248 homepages returned a status below 400; the rest failed, timed out or were blocked by our network path, so the sample covers sites we could reach rather than the full list.

We counted a site as WordPress when its homepage HTML referenced /wp-content/ or /wp-includes/ (1,684 sites). We read the version from the WordPress generator meta tag (518 sites) or, where that was absent, from the version parameter on core stylesheets or the core emoji script under /wp-includes/ (213 sites). We kept versions matching a release in the WordPress.org archive or the 7.2 pre-release (731 sites), then set aside the two pre-release sites, leaving 729. A site counted as patched if its version was one of the releases dated 28 October 2026 in that archive. Rank bands use the Tranco rank. Branch comparisons use the WordPress.org version statistics API read on the same morning. Sites that strip version information are not represented, and cached pages can under-report updates, as noted above. For a related crawl of top sites' configuration files, see our robots.txt study.

Conclusion

Half a day after WordPress shipped 7.1.4 and its backports, a little under half of the top-site WordPress installs we could identify were protected. If automatic minor updates work as designed, much of the remaining gap should close quickly, since most laggards are exactly one release behind. The tail of sites running versions from 2024 or earlier will not close by itself.

For anyone responsible for organic visibility, a compromised site is a search problem as much as a security one, with spam pages, warning labels and lost trust that take longer to clean up than an update takes to install.

Questions and answers

Which WordPress versions contain the 28 October security fixes?

WordPress 7.1.4 and the backported releases published the same day, including 7.0.8, 6.9.11 and 6.8.12, down to 4.7.39 on the oldest branch still receiving security fixes, according to the WordPress release archive.

How many top sites had updated?

In our crawl between 05:23 and 05:36 UTC on 29 October 2026, about 12 hours after the release announcement, 326 of 729 WordPress homepages in the Tranco top 20,000 that exposed a version (44.7%) reported a 28 October release.

Does WordPress install security releases automatically?

Yes by default. WordPress's update documentation says minor core updates, which include maintenance and security releases, are applied automatically unless a site disables them, and it strongly discourages disabling them.

Why does an outdated WordPress install matter for SEO?

Google's spam policies treat hacked content as a violation, and its Security issues report documentation says affected pages can show a warning label in search results or a browser interstitial. Google's hacking guide lists missed security updates as a common way sites are compromised.

###