BugsQA’s count of every WordPress security release found that WordPress Core fixed 44 security vulnerabilities between January and 22 October 2026, after fixing 2 in all of 2025. Access-control flaws more than doubled against the previous four years combined, 7 issues needed no login, and AI labs or AI tools found at least 11. Our conclusion: every WordPress site now needs a same-day retest of logins, roles and key workflows after each security release, not just the update.
WordPress runs 39.6% of all websites, so its security cadence sets the workload for millions of site owners and agencies. In 2026 that cadence changed: eight security releases, six of them in the 82 days between 17 July and 6 October, two with forced automatic updates, and one critical flaw (wp2shell) under attack within hours of its fix.
To measure what changed, BugsQA read every WordPress.org security and maintenance release from 5.8.3 (January 2022) to 7.1.3 (October 2026), counted each issue once, and classified it by type, the access an attacker needs and who reported it. We use this list in our WordPress security testing work.
This post gives five findings first, then what to retest after each update, how plugins and PHP add to the risk, and how a QA team helps. It ends with the full list of all 44 WordPress vulnerabilities of 2026 and every dataset, free to download.
Five findings from our WordPress Core 2026 analysis
BugsQA’s analysis of the 2026 WordPress security releases found five shifts: more fixes than any recent year, more serious flaws, a jump in access-control bugs, a rising share found by AI, and a release cadence that leaves site owners days, not months, to react. Each finding shows the data, why it happens, the caveat and what it means for your site.
Finding 1: WordPress fixed 44 Core vulnerabilities in 2026, 22 times the 2025 count
WordPress Core fixed 44 unique security issues by 22 October 2026, against 2 in 2025, 6 in 2024, 14 in 2023 and 26 in 2022. One year now holds almost as many fixes as the previous four combined (48).
Unique security issues fixed in WordPress Core per year
- 202226
- 202314
- 20246
- 20252
- 2026 to 22 Oct44
The fixes arrived in large batches. Three releases carried 33 of the 44: 6.9.2 in March (10), 7.0.3 in August (12) and 7.1.1 in September (11).
New security issues fixed per WordPress release, 2026
- 106.9.2
- 27.0.2
- 127.0.3
- 17.0.4
- 117.1.1
- 17.1.2
- 77.1.3
Why it happens. Far more people and tools examined WordPress in 2026 (Finding 4). Most of the 44 issues sat in code that already existed; 2026 is when someone looked.
The caveat. A higher count means more was found and fixed, not that WordPress got less safe overnight. The WordPress Security Team fixed every issue and forced updates for the worst one.
What it means for you: WordPress maintenance is no longer a quarterly task. Each of these releases changes code your site runs, and each needs checking.
Finding 2: the 2026 vulnerabilities were more serious
Seven of the 44 issues could be triggered by a visitor with no account, against 2 in the previous four years combined, and five could lead to code running on the server. BugsQA classified each issue by the access an attacker needs:
Access an attacker needs for the 44 WordPress Core issues fixed in 2026
No login: 7 (16%)Any logged-in user: 10 (23%)Specific role or setup (Contributor+, Author+, admin, conditional): 11 (25%)Not stated in release notes: 16 (36%)
The worst was wp2shell (CVE-2026-63030, CVSS 9.8), a chain that let an anonymous visitor take over a default WordPress install with no plugins by combining a REST API batch-route confusion with a SQL injection (CVE-2026-60137). WordPress fixed it in 7.0.2 on 17 July 2026, backported it to 6.9.5 and 6.8.6 and forced automatic updates (Infosecurity Magazine). Attacks started within hours: watchTowr’s honeypots logged tens of thousands of attempts and more than 100 backdoor admin accounts.
Two months later, WordPress 7.1.2 fixed a second critical flaw: an unauthenticated path traversal in page-template resolution (CVE-2026-87902) that could run code on some server and theme setups. It shipped five days after 7.1.1 and its 11 fixes.
Why it happens. Severe bugs are what researchers and AI-assisted tools hunt for first, because they pay the most in bug bounties and on exploit markets.
The caveat. The release notes do not state the access needed for 16 of the 44 issues, so the true no-login count could be higher or lower.
What it means for you: a WordPress site with no plugins and no logged-in users was still exposed in 2026. Delaying a security update by a week is no longer a safe default.
Finding 3: access-control bugs more than doubled
Authorization and access-control flaws, where a user can do or see something their role should not allow, were the fastest-growing type of WordPress Core vulnerability in 2026. WordPress fixed 11 of them in 2026 alone, against 5 across 2022 to 2025. XSS-type fixes fell from 22 over those four years to 14 in 2026.
WordPress Core security fixes by type: four years vs one
- XSS and injection into pages2214
- Access control and authorization511
- Data exposure56
- Code execution, upload63
- SQL injection43
- SSRF and XXE03
2022 to 2025 combined2026 alone
The 2026 access-control fixes read like a role matrix gone wrong: Contributors overwriting any post, Authors making posts sticky, any logged-in user reparenting comments, a Site Administrator activating Network-only plugins, multisite users creating new sites. The plugin ecosystem shows the same shift: in Wordfence’s Q1 2026 report, Missing Authorization overtook XSS as the most common WordPress vulnerability class, 753 to 736 (Wordfence).
Server-side request forgery (SSRF) and XML external entity (XXE) flaws also appeared for the first time in our dataset, three in 2026 after none in 2022 to 2025. In an independent December 2025 test, all five AI coding agents tested introduced an SSRF flaw in the apps they built (SecurityWeek), so custom plugins deserve the same check.
Why it happens. XSS has a known fix pattern that scanners and reviewers check for. Whether a role may perform an action depends on what each WordPress role is meant to do, and no tool knows that by default.
The caveat. XSS remains the largest single class in 2026. The shift is in which type grows, not in XSS going away.
What it means for you: if your site gives people accounts (editors, authors, customers, members), test what each role can do after every update. A role-by-role permission matrix finds this class of bug; a version scanner does not.
Finding 4: AI labs and AI tools found a quarter of the 2026 fixes
At least 11 of the 44 WordPress Core vulnerabilities fixed in 2026 were credited to AI labs or AI tools: Anthropic (6), the autonomous pentesting product pwn.ai (3), Trail of Bits working with OpenAI (1) and a Searchlight Cyber researcher using OpenAI’s GPT-5.6 (1). None were credited to AI in 2022 to 2025.
Who found the 44 WordPress Core vulnerabilities fixed in 2026
AI labs and AI tools: 11 (25%)WordPress Security Team: 7 (16%)Other researchers and firms: 26 (59%)
The AI share rose within the year, from none of the 10 fixes in March to 7 of the 19 in September and October.
WordPress Core fixes credited to AI labs or AI tools, 2026
- March (6.9.2)0 of 10 (0%)
- July to Aug (7.0.x)4 of 15 (27%)
- Sept to Oct (7.1.x)7 of 19 (37%)
wp2shell shows what AI changed. Searchlight Cyber’s Adam Kues found the chain by pointing GPT-5.6 at a clean copy of the WordPress source for a little over 10 hours of model time, about $25 of compute. Wordfence, which asks its bug bounty researchers directly, says about 66% of the reports it received by April 2026 involved AI (Wordfence).
Why it happens. AI models read code and test ideas faster than people, so one researcher now covers what a team covered before. WordPress, as the largest open-source CMS, is one of the first places they look.
The caveat. WordPress credits do not ask whether a researcher used AI, so 11 is a floor. The real AI share is higher.
What it means for you: attackers have the same models. Assume any flaw in your WordPress stack, Core, plugin or theme, can now be found in an afternoon.
Finding 5: security releases now arrive every two weeks, and they change behavior
WordPress shipped six security releases in the 82 days between 17 July and 6 October 2026, roughly one every two weeks, and forced automatic updates for wp2shell. Each release fixed vulnerabilities by changing how WordPress behaves: when 7.1.3 stopped Authors from making posts sticky, any editorial workflow that relied on that permission broke.
| Release | Date | Days since previous security release | New issues fixed |
|---|---|---|---|
| 6.9.2 | 10 Mar 2026 | 10 | |
| 7.0.2 | 17 Jul 2026 | 129 | 2 |
| 7.0.3 | 6 Aug 2026 | 20 | 12 |
| 7.0.4 | 12 Aug 2026 | 6 | 1 |
| 7.1.1 | 17 Sep 2026 | 36 | 11 |
| 7.1.2 | 22 Sep 2026 | 5 | 1 |
| 7.1.3 | 6 Oct 2026 | 14 | 7 |
Most sites keep up, but not all. WordPress.org’s live statistics on 22 October 2026 showed 63.0% of sites on WordPress 7.1 and 37.0% on older branches (WordPress.org stats API). Older branches still receive security backports, so not every one of them is exposed, but sites that pin versions or block updates can sit weeks behind.
WordPress sites on the latest major branch, 22 October 2026
Why it happens. More findings (Findings 1 and 4) mean more fixes, and WordPress ships them quickly rather than waiting for a major release.
The caveat. Fast fixes are good news. The risk is not the cadence but sites that update without checking, or skip updates to avoid breakage.
What it means for you: budget for a short retest every two weeks, not a big audit once a year. The update fixes the hole; the retest makes sure it did not break your site.
What should you retest after a WordPress security release?
Retest the features a security release touched, and the roles and workflows that depend on them, on the day the update lands. Our post-update checklist for a WordPress site:
- Login and account flows: login, password reset, email confirmation and two-factor prompts (7.0.3 fixed a login-screen XSS and an email confirmation bypass).
- Role permissions: each role you use (Subscriber, Contributor, Author, Editor, Shop Manager, custom roles) tried against the actions they need and the ones they must not have.
- Editor and blocks: the blocks you use most (Post Content, Post Date, Latest Comments, embeds), Quick Edit and the template editor.
- Comments and moderation: pending comments, private and password-protected posts, comment feeds.
- Media and uploads: image uploads, PDF thumbnails and imports on your actual host.
- REST API and integrations: anything that writes to WordPress through the REST API or XML-RPC (apps, forms, sync plugins, headless front ends).
- Exports and imports: WXR export and any import tools (7.1.3 fixed a SQL injection there).
- Multisite: site creation, network-only plugins and user registration settings.
Should you test WordPress updates on staging first?
Yes, whenever you control the timing. Run the update on a staging copy, work through the checklist, then update production. When WordPress forces an update, as it did for wp2shell, run the same checklist on production right after it lands. This check is the step most teams skip.
What about WordPress plugins and PHP?
WordPress Core is the smallest part of WordPress risk. Patchstack counted 11,334 vulnerabilities across the WordPress ecosystem in 2025, up 42%, with 91% in plugins and 46% having no patch when they were made public (Patchstack). Plugin updates arrive far more often than Core releases, and the same retest applies to each one.
The layer underneath matters too. On 21 October 2026, PHP fixed two critical remote code execution flaws (CVE-2026-109618 and CVE-2026-109619) affecting PHP 5.4 through 8.5.11, which no WordPress update can fix. Our PHP2Shell guide for WordPress sites covers the fixed versions and what to test after upgrading PHP. The wider picture across CVEs, plugins and AI-built apps is in our 2026 QA security testing research.
How a QA team keeps WordPress sites safe after updates
A QA team keeps WordPress sites safe after updates by owning the retest that site owners and agencies rarely have time for. BugsQA tests WordPress sites and custom plugins on every security release:
- On staging, before production: the post-update checklist above, on your theme, plugins and host.
- Role by role: a permission matrix for every role you use, rerun after each update.
- Plugins: known vulnerabilities and abandoned plugins flagged, and the features they add tested.
- Same day: a nearshore team in Colombia working US hours, so a morning security release is retested that afternoon.
For a general pre-release check you can run yourself, use our free website QA checklist.
How we counted the 2026 WordPress vulnerabilities
BugsQA read every WordPress.org security and maintenance release from 5.8.3 (January 2022) to 7.1.3 (October 2026). We count each issue once: re-applied fixes (6.9.4) and branch backports (such as 6.9.5 and 7.0.7) do not count again. We grouped issues by type and by the access an attacker needs as stated in the release notes, and marked an issue as AI-credited when the notes name an AI lab, an AI tool or a researcher who disclosed using an AI model for that finding. You may reuse the data under CC BY 4.0 with a link to this page.
Raw data: the full list and every table
This section holds the full list of 2026 WordPress vulnerabilities and every table behind the findings, each with a CSV download. Jump to a dataset:
- All 44 vulnerabilities of 2026
- Security releases of 2026
- Issues per year, 2022 to 2026
- Issues by type
- 2026 issues by access needed
- WordPress and PHP versions in use
All 44 WordPress Core vulnerabilities of 2026
Every unique WordPress Core vulnerability fixed in 2026, in release order. “No login” means a visitor without an account can trigger it; “Contributor+” means any account with the Contributor role or higher. Issues marked (AI) were credited to an AI lab, an AI tool or a researcher who disclosed using an AI model.
| Release | Issue | Type | Access needed | Reported by |
|---|---|---|---|---|
| 6.9.2 | Blind SSRF | SSRF | Not stated | sibwtf and independent researchers |
| 6.9.2 | PoP-chain weakness in HTML API and Block Registry | Object injection | Conditional | Phat RiO |
| 6.9.2 | Regex DoS in numeric character references | Denial of service | Not stated | WordPress Security Team |
| 6.9.2 | Stored XSS in nav menus | XSS | Logged-in user | Phill Savage |
| 6.9.2 | AJAX query-attachments authorization bypass | Authorization | Logged-in user | Vitaly Simonovich |
| 6.9.2 | Stored XSS via data-wp-bind directive | XSS | Not stated | kaminuma |
| 6.9.2 | Admin-area XSS through client-side template override | XSS | Logged-in user | Asaf Mozes |
| 6.9.2 | PclZip path traversal | Path traversal | Not stated | Francesco Carlucci, kaminuma |
| 6.9.2 | Authorization bypass on the Notes feature | Authorization | Logged-in user | kaminuma |
| 6.9.2 | XXE in the external getID3 library | XXE | Not stated | Youssef Achtatal |
| 7.0.2 | Facilitated SQL injection (author__not_in) | SQL injection | Not stated | TF1T, dtro, haongo |
| 7.0.2 | REST API batch-route confusion leading to remote code execution (wp2shell) | Code execution | No login | Adam Kues, Searchlight Cyber (AI) |
| 7.0.3 | Pre-auth reflected XSS on the login screen, potential PHP code execution | XSS | No login | pwn.ai (AI) |
| 7.0.3 | Stored XSS in posts via the emoji settings element | XSS | Contributor+ | Asaf Mozes |
| 7.0.3 | Stored XSS in the Post Content block | XSS | Contributor+ | N05ec@LZU |
| 7.0.3 | Stored XSS in Quick Edit on sites with many users | XSS | Contributor+ | Naveen S, Ajmal Moochingal |
| 7.0.3 | Stored XSS in the Post Date block | XSS | Contributor+ | WordPress Security Team |
| 7.0.3 | Multisite privilege escalation: a user can create a new site | Authorization | Logged-in user | Aikido Security |
| 7.0.3 | Latest Comments block exposes comments on password-protected posts | Data exposure | Not stated | WordPress Security Team |
| 7.0.3 | Enumeration of post slugs | Data exposure | No login | HDWSec |
| 7.0.3 | Notes disclosed in comment feeds | Data exposure | Not stated | Elio Gubser |
| 7.0.3 | CSS injection through a safe-CSS filter bypass | CSS injection | Author+ | Anthropic (AI) |
| 7.0.3 | Email address confirmation flow bypass | Authentication | Not stated | Omar Hasan |
| 7.0.3 | SSRF in URL validation reaching link-local ranges | SSRF | Not stated | Andrew Mohawk and independent reporters |
| 7.0.4 | Code execution via malicious file upload on Imagick/Ghostscript sites | Code execution | Author+ | pwn.ai (AI) |
| 7.1.1 | Stored XSS in wpautop() via visitor comments (subject to approval) | XSS | No login | Rafie Muhammad, Awesome Motive |
| 7.1.1 | HTML API comment breakout in set_modifiable_text() | Injection | Not stated | WordPress Security Team |
| 7.1.1 | Stored XSS in themes supporting custom headers | XSS | Not stated | WordPress Security Team |
| 7.1.1 | Crafted URLs auto-install and preview an inactive WordPress.org theme | Authorization | Not stated | Paulos Yibelo, pwn.ai (AI) |
| 7.1.1 | Site Administrator can network-activate a Network-only plugin | Authorization | Administrator | Jesse McNeil |
| 7.1.1 | Path traversal in the WP REST Templates Controller | Path traversal | Logged-in user | Anthropic (AI) |
| 7.1.1 | XML-RPC publishes customize_changeset posts bypassing edit_css | Authorization | Logged-in user | WordPress Security Team |
| 7.1.1 | Arbitrary post overwrite | Authorization | Contributor+ | Anthropic (AI) |
| 7.1.1 | Missing read_post check leaks a private parent post’s title | Data exposure | Logged-in user | HDWSec |
| 7.1.1 | Draft and pending post slugs disclosed | Data exposure | Contributor+ | Jakub Herman |
| 7.1.1 | Any logged-in user can reparent comments, including notes | Authorization | Logged-in user | Justin Hart, Viridis Security |
| 7.1.2 | Path traversal in page-template resolution, conditional code execution | Path traversal | No login | Robert Ressl |
| 7.1.3 | Stored XSS on the Comments admin screen via pending comments | XSS | No login | Trail of Bits with OpenAI (AI) |
| 7.1.3 | Denial of service in WP_Http::make_absolute_url() | Denial of service | Not stated | Anthropic (AI) |
| 7.1.3 | Second-order SQL injection in WXR export | SQL injection | Logged-in user | Anthropic (AI) |
| 7.1.3 | Author role users can make posts sticky | Authorization | Author+ | Anthropic (AI) |
| 7.1.3 | Comments on private and unpublished posts disclosed | Data exposure | No login | Ananda Dhakal, Patchstack |
| 7.1.3 | XSS in Imgur embeds | XSS | Not stated | Zhengyu Liu, Jingcheng Yang, Gavin Zhong |
| 7.1.3 | Forgeable parameters in the {status}_{type} hook | Integrity | Not stated | WordPress Security Team |
Source: release posts on WordPress.org News. “Not stated” means the release notes do not say what access the issue needs. Download the full 2022 to 2026 list (CSV).
WordPress security releases of 2026
| Release | Date | New issues fixed | AI-credited | Note |
|---|---|---|---|---|
| 6.9.2 | 10 Mar 2026 | 10 | 0 | |
| 6.9.4 | 11 Mar 2026 | 0 | 0 | Re-applied three 6.9.2 fixes |
| 7.0.2 | 17 Jul 2026 | 2 | 1 | wp2shell; forced auto-update; backports 6.9.5 and 6.8.6 |
| 7.0.3 | 6 Aug 2026 | 12 | 2 | |
| 7.0.4 | 12 Aug 2026 | 1 | 1 | |
| 7.1.1 | 17 Sep 2026 | 11 | 3 | |
| 7.1.2 | 22 Sep 2026 | 1 | 0 | Critical, CVE-2026-87902 |
| 7.1.3 | 6 Oct 2026 | 7 | 4 |
WordPress Core issues per year, 2022 to 2026
| Year | Unique Core issues | Security releases | Needing no login | Credited to AI labs or tools |
|---|---|---|---|---|
| 2022 | 26 | 4 (5.8.3, 5.9.2, 6.0.2, 6.0.3) | 1 | 0 |
| 2023 | 14 | 4 (6.2.1, 6.2.2, 6.3.2, 6.4.2) | 1 | 0 |
| 2024 | 6 | 3 (6.4.3, 6.5.2, 6.5.5) | 0 | 0 |
| 2025 | 2 | 1 (6.8.3) | 0 | 0 |
| 2026 (to 22 Oct) | 44 | 8 | 7 | 11 |
WordPress Core issues by type, 2022 to 2026
| Type | 2022 | 2023 | 2024 | 2025 | 2026 |
|---|---|---|---|---|---|
| XSS and other injection into pages | 13 | 5 | 3 | 1 | 14 |
| Authorization, access control, request forgery | 2 | 2 | 0 | 1 | 11 |
| Data exposure | 3 | 2 | 0 | 0 | 6 |
| SQL injection | 4 | 0 | 0 | 0 | 3 |
| Code execution, object injection, file upload | 1 | 3 | 2 | 0 | 3 |
| SSRF and XXE | 0 | 0 | 0 | 0 | 3 |
| Path traversal | 0 | 1 | 1 | 0 | 2 |
| Denial of service | 0 | 1 | 0 | 0 | 2 |
| Other (prototype pollution, open redirect) | 3 | 0 | 0 | 0 | 0 |
WordPress Core 2026 issues by access needed
| Access an attacker needs | Issues in 2026 |
|---|---|
| No login | 7 |
| Any logged-in user | 10 |
| Contributor role or higher | 6 |
| Author role or higher | 3 |
| Administrator | 1 |
| Conditional on server or theme setup | 1 |
| Not stated in the release notes | 16 |
WordPress and PHP versions in use, October 2026
| WordPress version | Share of sites | PHP version | Share of WordPress sites |
|---|---|---|---|
| 7.1 | 63.0% | 8.3 | 26.7% |
| 7.0 | 7.6% | 8.2 | 23.7% |
| 6.9 | 6.8% | 7.4 | 15.9% |
| 6.8 | 5.3% | 8.1 | 10.5% |
| 6.7 and older | 17.2% | 8.4 | 9.5% |
| 8.5 | 4.2% | ||
| 8.0 | 3.8% | ||
| 7.3 and older | 5.7% |
Source: WordPress.org version statistics API, pulled by BugsQA on 22 October 2026. Download (CSV).
Frequently asked questions
What are the latest WordPress vulnerabilities?
The latest WordPress Core vulnerabilities, as of 22 October 2026, were fixed in WordPress 7.1.3 on 6 October 2026: a stored XSS on the Comments admin screen, a denial of service in WP_Http::make_absolute_url(), a second-order SQL injection in WXR export, Authors being able to make posts sticky, unauthenticated disclosure of comments on private posts, XSS in Imgur embeds and a hook parameter forgery. Updating to 7.1.3 or the latest backport for your branch fixes all seven.
Is WordPress a security risk in 2026?
WordPress is not unsafe by itself, but it is a large, heavily examined target with many moving parts, so it needs active maintenance. Core fixes arrive quickly and the WordPress Security Team forced updates for the worst 2026 issue, wp2shell. Most risk sits in plugins, outdated PHP and slow updates, which is why regular updates, a small plugin set and a retest after each security release matter more than the choice of platform.
Why were there so many WordPress vulnerabilities in 2026?
More WordPress vulnerabilities were found in 2026 mainly because far more people and AI tools started looking. BugsQA found that at least 11 of the 44 Core fixes were credited to AI labs or AI tools such as Anthropic and pwn.ai, and Wordfence reports that about two thirds of reports to its bug bounty now involve AI. Cheaper discovery surfaces older bugs faster; it does not mean new code is worse.
What was wp2shell?
wp2shell was a chain of two WordPress Core flaws, CVE-2026-63030 (CVSS 9.8) and CVE-2026-60137, that let an anonymous visitor take over a default WordPress install. Searchlight Cyber found it with help from OpenAI’s GPT-5.6 and disclosed it on 17 July 2026, when WordPress 7.0.2, 6.9.5 and 6.8.6 fixed it and automatic updates were forced. Attacks started within hours of the fix.
Do I need to do anything after a WordPress automatic security update?
Yes. Automatic updates install the fix but do not check that your site still works. Security fixes change behavior, such as tightening which roles can do what, so retest login, role permissions, the editor blocks you use, comments, uploads and any REST API integrations on the day the update lands, and check that plugins and PHP are current too.
Can I use this data?
Yes. BugsQA publishes the WordPress Core dataset under CC BY 4.0: you may reuse, chart and republish it with a link to this page. The full issue list and every table above are available as CSV downloads.
Keep your WordPress site tested after every release
The 2026 numbers point one way: more WordPress vulnerabilities, found faster, attacked within hours, with security fixes that change how roles and features behave. Updating is the first step. Checking that the update did not break your workflows, and that each role can only do what it should, keeps a site both safe and working.
BugsQA tests WordPress sites and custom plugins on every security release, with a role-by-role permission matrix and a regression pass on the features you depend on. Tell us which WordPress version, PHP version and plugins you run, and we will tell you what a release retest covers. See WordPress security testing or contact us.
- security
- wordpress
- data report
