The WordPress security release published on 17 September 2026 closed 11 vulnerabilities at once, and at least three of them were reported by companies that use artificial intelligence to hunt for bugs. That detail is not a footnote: it is the most consequential shift the WordPress ecosystem has seen this year, and it directly changes how long WordPress patch management can safely wait before applying a fix.
At Amicatek we track every release cycle because maintenance is part of what we deliver. WordPress 7.1.1 differs from its predecessors both in pace and in where the findings came from. That is worth unpacking.
Update — 22 September 2026. Hours after this article first went out, WordPress shipped 7.1.2, an emergency fix for a critical flaw: unauthenticated remote code execution present in every version since 4.7. If your site is not on 7.1.2, update now. Details are in the next section; the rest of the article stands as published.
7.1.2 landed five days later and changed the urgency
On 22 September, five days after 7.1.1, the project shipped WordPress 7.1.2 to fix a single flaw rated critical: CVE-2026-87902, CVSS 9.2.
The problem sits in get_page_template(), in wp-includes/template.php. The function built candidate template filenames from the pagename query variable without validating the result, which allowed any readable PHP file outside the active theme directories to be included — a local file inclusion, with no authentication required.
An LFI on its own does not guarantee code execution: it needs a readable .php file on the server that does something useful when included. The vector most often cited is PEAR’s pearcmd.php, which becomes exploitable when PHP runs with register_argc_argv enabled — the default in the official PHP Docker images and in cPanel environments running PHP below 8.5. Under those conditions, the LFI becomes remote code execution.
The exposure window is the uncomfortable part: the flaw affects versions 4.7.0 through 7.1.1 — close to a decade of releases. Robert Ressl reported it through responsible disclosure, and the fix applies two measures: validate_file() on the previously unprotected pagename_decoded branch, plus a new containment check requiring every resolved template to stay inside the allowed theme directories.
One detail cuts against this article’s own thesis and deserves stating plainly: this flaw was not found by AI. A human researcher found it, in code that had been in core since 2016. It is a reminder that manual review still turns up the most severe findings — and that a decade of exposure belongs to no single discovery method.
What WordPress 7.1.1 actually fixed
WordPress 7.1.1 shipped as a maintenance and security release: 17 core bug fixes, 19 block editor fixes and 11 security vulnerabilities, with more than 90 contributors involved. Security backports were extended all the way to version 4.7, although only the current release receives active support.
Two of the fixes deserve particular attention from anyone running client sites.
The flaw that needs no login at all
The most severe is a stored XSS in the wpautop() function — CVE-2026-93485, CVSS 7.1 — reported by Rafie Muhammad. The attack requires no account. An ordinary-looking comment carrying the right payload slips past sanitization and executes when the page is rendered for any visitor.
The only real obstacle is moderation, and in a default configuration that obstacle is thin. A first-time commenter goes into the queue; once one of their comments has been approved, later ones can be published automatically. An attacker can therefore open with something harmless, wait for approval, and come back with the payload.
Click2Shell: when a chain of bugs becomes remote code execution
The second is more inventive. Paulos Yibelo, of pwn.ai, found a CSRF flaw in theme installation and preview that Patchstack named Click2Shell.
The chain starts with a specially crafted URL that silently installs a theme from the WordPress.org repository. The theme is then activated through the Customizer, and from there an inadequately protected AJAX handler can allow code execution on the server.
The root cause is a mismatch between layers. The backend sanitizes the theme slug one way, while the frontend JavaScript drops that same value straight into a jQuery selector string with no treatment at all, opening the door to selector injection.
Version 7.1.1 fixed it by restricting the lookup to legitimate .theme elements and applying $.escapeSelector(), so the value is read as literal text rather than as part of the selector’s structure.
Exploitation requires a logged-in administrator to open the crafted URL, either through targeted phishing or by way of an XSS already present on the site. Combined with the first flaw, in other words, this one stops being theoretical.
The remaining nine fixes cover path traversal in the REST templates controller, arbitrary post overwriting by contributor-level users, disclosure of private post titles, comment reparenting by any authenticated user, a capability bypass via XML-RPC, and network-wide plugin activation by site administrators on multisite. Most require authentication at some level — including low-privilege roles such as contributor.
Who found the flaws has changed, and that has consequences
This is where the story stops being purely technical and starts affecting operations.
Anthropic reported two of the 11 vulnerabilities fixed in 7.1.1 — the REST API path traversal and the contributor-level post overwrite. A third came from pwn.ai. According to The Repository, AI companies have appeared in the credits of every WordPress security release since July 2026; earlier releases credited OpenAI’s Sol Ultra and Aikido Security.
The volume explains the rest. The same reporting notes that security submissions to WordPress through HackerOne jumped from a historical average of 20 to 30 per month to 773 in August 2026 alone. This is not a passing spike of interest. It is the direct result of models that can read code at scale and propose plausible exploitation chains.
The project has already responded. On 28 August the security team announced the Core Security Initiative, organized around three tracks: a tighter, more automated release process with improved end-to-end testing; a concentrated effort to drive the backlog of open reports down to zero; and AI-assisted scanning to find vulnerabilities before they can be exploited. The bug bounty scope was also narrowed to cope with the volume.
What this changes in your WordPress patch management
Whether you run one WordPress site or several hundred, patching has stopped being an end-of-month chore. Four practical consequences:
The window between patch and exploitation has narrowed. The same class of tooling that finds a vulnerability can also read the changelog and the commit diff. Once a fix is public, so is the map to the problem. The comfortable two-week gap between release and deployment that many agencies still run on is now a bad bet.
Automatic core updates are no longer optional. Minor releases — 7.1 to 7.1.1 — have been applied automatically by default for years, yet plenty of installations have that switched off after an old scare with an incompatible plugin. The calculation has changed: staying unpatched now carries more risk than installing the fix.
Low-privilege accounts are attack surface. Several of the 7.1.1 flaws need nothing more than an authenticated user — contributor, author, in some cases any account at all. A site carrying 40 dormant logins from past interns and freelancers has 40 possible entry points. Auditing users is basic security hygiene, not paperwork.
Speed is only safe with a staging environment. Updating fast without staging swaps exposure risk for downtime risk. What works is the combination of a staging environment, an automated backup taken before the update, and a rollback path that has actually been tested rather than improvised mid-incident.
A 30-minute checklist
If you want to turn this into something done today:
- Check the installed version under Dashboard → Updates. If the site is not on 7.1.2, update immediately — the critical fix shipped on 22 September moved this item from “today” to “right now”.
- Enable automatic minor core updates. In
wp-config.php:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
- Review accounts under Users → All Users. Delete dormant logins and downgrade anyone who does not need editing rights.
- Tighten comment moderation. Under Settings → Discussion, require manual approval for every comment, not just the first one from each author.
- If the site does not rely on XML-RPC — most do not — disable it at the server or through a security plugin.
- Confirm the date of the last backup that was successfully restored. A backup that has never been tested is an assumption, not a guarantee.
- Repeat the exercise for plugins and themes: core is only part of the attack surface.
The other side: AI is also playing defense
It is easy to read this as bad news alone. It is not the whole story.
The three AI-assisted findings in 7.1.1 came through responsible disclosure and were fixed before any known exploitation. The Core Security Initiative has put AI-assisted scanning on the project’s side of the table as well.
The net result, so far, is a WordPress with fewer latent flaws than it had a year ago. What changed is the speed at which those flaws surface — and the discipline that demands from whoever keeps the sites running.
That shift is exactly what shapes our work. WordPress remains the right platform for most projects, but operating it in 2026 calls for a routine quite different from the one that worked in 2022.
Is your site on 7.1.2? If you cannot answer that with confidence, the uncertainty is the answer. Amicatek runs a WordPress site assessment covering installed version, user exposure, backup health and update strategy — and takes over ongoing maintenance for teams that would rather not learn this the hard way. We work with clients in Brazil and abroad.
Sources
- WordPress 7.1.2 Release — WordPress.org News
- WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE — Patchstack
- WordPress 7.1.1 Maintenance and Security Release — WordPress.org News
- WordPress 7.1.1 Maintenance and Security Release — Patchstack
- Click2Shell: The RCE WordPress 7.1.1 Just Patched — Patchstack
- WordPress 7.1.1 Ships 11 Security Fixes, Credits Anthropic and pwn.ai Again — The Repository
- The Core Security Initiative — Make WordPress Security