BugsQA’s 2026 security QA research found that software is now shipped, and searched for flaws, faster than the teams that own it follow up, with broken access control growing fastest. The US National Vulnerability Database published 75% more CVE records by 21 October 2026 than in all of 2025, and 46% of WordPress vulnerabilities went public with no patch. Our conclusion: any team that ships weekly needs access-control and security testing on every release, not once a year.
Two shifts drive this. AI coding tools let teams ship far more code: WordPress.org went from about 150 new plugin submissions a week in 2024 to about 700 in May 2026. AI research tools let researchers, and attackers, examine that code far faster: AI labs and AI tools found at least 11 of the 44 security issues WordPress Core fixed in 2026, after it fixed just 2 in all of 2025.
To measure the gap, BugsQA pulled seven public datasets (NVD, WordPress.org, Patchstack, Wordfence, GitHub, CISA and the published studies on AI-written code), counted every WordPress Core security issue from 2022 to 2026 by hand, classified who reported each one and compared the datasets against each other. We built our security QA testing service on what we found.
This report gives the six findings first, each with its charts, causes and caveats. After the data, it explains what QA security testing is, how it differs from a penetration test and how a QA team closes the gap, and it ends with every dataset in full, free to download.
Six findings from our 2026 security QA research
BugsQA’s research found six patterns that hold across every dataset we compared: disclosures surged, code output surged, AI took over much of the bug hunting, follow-up fell behind, broken access control grew everywhere, and attackers moved faster on the few vulnerabilities they use. Each finding below shows the data, explains why it happens, states the caveat and ends with what it means for a team that ships software.
Finding 1: disclosed vulnerabilities rose 75% in 2026
The NVD published 87,574 CVE records between 1 January and 21 October 2026, against 49,972 in all of 2025. BugsQA pulled these counts from the NVD API by publish date; without rejected records, 2026 so far stands at 85,344. Growth had already been steady (+32% in 2024, +23% in 2025), so 2026 is a break from the trend, not a continuation of it.
CVE records published in the NVD per year
- 202019,222
- 202121,950
- 202226,431
- 202330,949
- 202440,704
- 202549,972
- 2026 to 21 Oct87,574
The surge built through the year rather than arriving at once. The NVD published 5,143 records in January and 15,074 in September, almost three times as many, with the steepest climb from July onward.
CVE records published in the NVD per month, 2026
- 5,143Jan
- 4,808Feb
- 6,304Mar
- 5,885Apr
- 6,985May
- 8,001Jun
- 9,919Jul
- 12,719Aug
- 15,074Sep
- 12,736Oct 1-21
WordPress Core shows the same break at a smaller scale. It fixed 26, 14, 6 and 2 security issues in 2022 to 2025, then 44 by 22 October 2026, nearly as many in one year as in the previous four combined (48).
Unique security issues fixed in WordPress Core per year
- 202226
- 202314
- 20246
- 20252
- 2026 to 22 Oct44
The 2026 WordPress issues are more serious as well as more numerous. BugsQA classified each one by the access an attacker needs: 7 needed no login at all, against 2 in the previous four years, and 5 could lead to code running on the server.
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 open-source package registries broke the same way. BugsQA counted reviewed advisories in the GitHub Advisory Database: npm went from 631 in all of 2025 to 3,535 in 2026 so far, 5.6 times as many, and PyPI more than tripled.
Reviewed security advisories per ecosystem, 2025 vs 2026
- npm6313,535
- PyPI7432,451
- Composer (PHP)5791,477
- Maven (Java)7111,003
All of 20252026 to 22 October
Why it happens. The volume of code went up (Finding 2) and the cost of searching it went down (Finding 3) at the same time. Most of the jump is old code being examined more closely, not new code being written worse.
The caveat. A CVE record is a disclosure, not an attack. Different trackers also count differently: the NVD totals here include records later rejected, which is why some sources quote lower 2026 figures. The direction is the same in every source we checked.
What it means for you: the libraries, plugins and runtimes under your product now receive security fixes several times more often than in 2025. A dependency check that ran at project start goes stale within weeks, and every fix that lands is a change that needs a retest. Our release-by-release WordPress analysis shows what that cadence looks like for one platform.
Finding 2: teams ship up to five times more code than in 2024
WordPress.org received about 150 new plugin submissions a week in 2024 and a record of about 700 a week in May 2026, according to the WordPress.org Plugins Team. The team calls that 2.7 times 2025 and 5 times 2024, and writes that “AI has lowered the barriers” to building a plugin.
New plugins submitted to WordPress.org per week
- 2024 average~150
- Late 2025~330
- March 2026~500
- May 2026~700
The review side grew too, but slower. The Plugins Team reviewed 12,713 plugins in 2025 (+40.6%) and approved 5,415 (+66.2%), while submissions roughly doubled. Its first-review queue peaked at about 1,050 plugins in mid-April 2026 before new reviewers and AI-assisted checks brought it down.
App stores show the same curve. Developers released 557,000 new apps on the App Store in 2025, up 24% and the most since 2017 (Appfigures), then 80% more in Q1 2026 than a year earlier (TechCrunch).
New apps released on the App Store per year (thousands)
- 7312017
- 4742018
- 4912020
- 4342022
- 4242023
- 4482024
- 5572025
Inside codebases, AI now writes a large share of what ships. GitHub users pushed nearly 1 billion commits in its 2025 reporting year (+25%) and merged 518.7 million pull requests (+29%) (Octoverse 2025). Developers in Sonar’s survey say AI writes 42% of the code they commit and expect 65% by 2027.
Share of committed code written by AI, as reported by developers
Why it happens. AI coding tools turn an idea into working code in hours, so people who never shipped software now ship it, and teams that shipped monthly now ship weekly.
The caveat. Submissions are not approvals, and Appfigures and TechCrunch treat AI as the likely cause of the App Store jump rather than a proven one. The growth itself is measured; the cause is the most plausible explanation.
What it means for you: each release now carries more new code than a year ago, much of it written by a model and read closely by nobody. The plugins, packages and AI-built tools you depend on follow the same curve.
Finding 3: AI tools now find a growing share of vulnerabilities
AI labs and AI tools found at least 11 of the 44 WordPress Core vulnerabilities fixed in 2026, and their share rose within the year. BugsQA classified every reporter credit in the release notes: Anthropic found six, the autonomous pentesting product pwn.ai found three, Trail of Bits working with OpenAI found one, and a researcher using OpenAI’s GPT-5.6 found one.
WordPress Core security 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%)
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 real AI share is higher, because most researchers who use AI do not say so in public credits. Wordfence asks the researchers in its bug bounty directly: 16% said they used AI in the first week of tracking in late November 2025, and about 66% by April 2026 (Wordfence).
Share of Wordfence bug bounty reports made with AI help
The volume followed. Monthly submissions to the Wordfence program rose from 486 in October 2025 to 1,718 in March 2026, and the number of active researchers grew from 69 to 327 in nine months. Wordfence’s own autonomous AI researcher became its most productive finder, with 88 published vulnerabilities in 30 days.
Wordfence bug bounty submissions per month, July 2025 to June 2026
- 325Jul
- 438Aug
- 374Sep
- 486Oct
- 746Nov
- 759Dec
- 897Jan
- 1,078Feb
- 1,718Mar
- 1,288Apr
- 1,095May
- 1,066Jun
AI also collapsed the cost of a serious find. Searchlight Cyber researcher Adam Kues pointed GPT-5.6 at the WordPress source and built wp2shell, the first unauthenticated remote code execution chain in WordPress Core in about a decade, in roughly 10 hours of model time for about $25 (Infosecurity Magazine).
On 21 October 2026, Wiz disclosed two critical PHP flaws it found with Gemini 4 Argon and GPT-5.6 and wrote that “a single researcher completed in a week what previously would have taken a world-class team months of work” (see our PHP2Shell guide).
Why it happens. Frontier models read code, form hypotheses and test them faster than people, so a researcher with AI covers far more code per day. The same models are available to attackers.
The caveat. Not every AI report is useful. Patchstack narrowed its bug bounty on 1 June 2026 after a rise in low-impact and duplicate AI-generated reports, and Wordfence submissions fell 38% from the March peak by June. Valid findings grew, but much less than raw submissions.
What it means for you: someone with a $200 AI subscription can now audit your product’s code paths in an afternoon. Assume the bugs in your release will be found; the question is whether your team finds them first.
Finding 4: follow-up is the gap, not discovery
Discovery scaled with AI, but fixing, reviewing and retesting did not. Patchstack reports that 46% of WordPress vulnerabilities in 2025 had no patch from the developer when they went public, up from 33% in 2024 (Patchstack). The WordPress.org Plugins Team reports that 38.7% of the plugin authors it reviewed in 2025 never replied to the review at all.
The follow-up gap in three numbers
Inside software teams, code review became the bottleneck. Telemetry from more than 10,000 developers shows teams with high AI adoption merging 98% more pull requests, while the review time per pull request rose 91% and the size of each pull request rose 154% (Faros AI).
What changed for teams with high AI adoption
- Pull requests merged+98%
- Review time per pull request+91%
- Pull request size+154%
LinearB’s 2026 benchmarks, based on 8.1 million pull requests, show the queue in hours: pull requests written by AI agents wait 17.6 hours to be picked up for review, against 3.4 hours for code written without AI, and only 32.7% of AI pull requests merge within 30 days, against 84.4% of unassisted ones (LinearB).
Hours a pull request waits before review starts (75th percentile)
- Written by an AI agent17.6 h
- AI-assisted8.3 h
- Written without AI3.4 h
Developers know the risk and still skip the check. In Sonar’s survey, 96% said they do not fully trust that AI-generated code is correct, 38% said AI code takes more effort to review than a colleague’s, yet only 48% always check it before committing. QA capacity is not catching up either: the US Bureau of Labor Statistics projects QA analyst and tester jobs to grow 6% from 2025 to 2035, against 10% for the wider software developer group (BLS).
The platforms behind AI-built apps push the follow-up back to their customers. Researchers found 170 of 1,645 apps showcased on Lovable (10.3%) exposing their databases, and Lovable disputed the vulnerability record on the grounds that each customer owns their app’s data (researcher’s statement).
Why it happens. Writing code and finding bugs both got cheaper with AI; reading code, deciding what is safe and confirming a fix still take a person’s time, and the number of people doing it barely moved.
The caveat. Once a reviewer picks up an AI pull request, LinearB finds the review itself is not much slower. The delay is in the queue and in ownership, which is exactly where a dedicated tester helps.
What it means for you: 96% of developers distrust AI code, yet fewer than half check it. Distrust does not become testing unless someone owns the check, and on most teams nobody does.
Finding 5: broken access control grew in all six datasets we compared
Broken access control, where a user can see or change something their role should not allow, rose in every dataset BugsQA compared. Injection bugs such as SQL injection and cross-site scripting (XSS) stayed common but did not grow.
In WordPress Core, access-control and authorization fixes jumped from 5 across 2022 to 2025 to 11 in 2026 alone, while 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 WordPress plugin ecosystem crossed over in the same year. In Wordfence’s Q1 2026 report, Missing Authorization (CWE-862) became the most common vulnerability class with 753 cases, overtaking XSS with 736 (Wordfence Q1 2026).
Most common WordPress vulnerability classes, Q1 2026
- Missing Authorization (CWE-862)753
- Cross-site scripting (CWE-79)736
Four more sources point the same way:
| Dataset | What BugsQA found |
|---|---|
| GitHub Octoverse 2025 | Broken access control became the most common code-scanning alert, in 151,000+ repositories, up 172% |
| Patchstack 2025 | Broken access control was the most exploited WordPress vulnerability category |
| Tenzai test, December 2025 | Five AI coding agents built 15 apps with no SQL injection or XSS, but improper API authorization was one of the most common flaws, and all five introduced server-side request forgery (SecurityWeek) |
| AI-built app incidents | Lovable (database rules), Base44 (authentication bypass) and Moltbook (database open to read and write) all failed on access control |
Why it happens. Scanners and AI models catch rule-based bugs well, because a rule like “escape this output” applies everywhere. Access control has no universal rule: whether an Author may make a post sticky, or a customer may open another customer’s invoice, depends on the business. That knowledge lives in the product’s requirements, not in the code, so tools that only read code cannot see the mistake.
The caveat. XSS is still the single largest class in WordPress Core, and some of the growth reflects researchers and bounty programs paying more attention to authorization. The shift is in what grows, not in what disappears.
What it means for you: a scan that passes tells you little about who can do what in your product. A role-by-role permission test on every release is now the single highest-value security check.
Finding 6: few vulnerabilities get exploited, but the exploited ones get hit within hours
Exploitation grew far slower than disclosure. CISA added 245 vulnerabilities to its Known Exploited Vulnerabilities catalog in 2025 and 270 by 21 October 2026, about 10% more, while CVE records rose 75%.
2026 to date vs all of 2025: disclosed vs exploited
- CVE records published (NVD)+75%
- Known exploited added (CISA KEV)+10%
VulnCheck found that only 14 of 1,061 vulnerabilities discovered with AI help (1.3%) had been exploited in the wild, and that the share exploited on or before disclosure day fell from 28.93% in 2025 to 23.43% in the first half of 2026 (VulnCheck).
Exploitation is concentrated
Speed moved the other way. VulnCheck measured the median time from publication to known exploitation falling from 120 days in 2025 to 80 days in the first half of 2026. Patchstack measured a median of five hours to first exploitation for heavily targeted WordPress vulnerabilities, with about half of high-impact ones exploited within 24 hours.
Median days from publication to known exploitation
- 2025120 days
- First half of 202680 days
wp2shell shows it in practice. WordPress shipped the fix on 17 July 2026 and forced automatic updates, and within hours watchTowr’s honeypots had logged tens of thousands of attack attempts and more than 100 backdoor admin accounts.
Why it happens. Attackers pick the few vulnerabilities that give remote access to many sites, and AI helps them turn a published fix into a working exploit quickly. Everything else stays on paper.
The caveat. Exploitation data only covers what defenders see, so real figures are higher. Even so, every source agrees that most disclosed vulnerabilities are never used in an attack.
What it means for you: testing everything equally wastes effort. Test deepest where attackers go (login, roles, file upload, payments, public APIs) and retest those paths within a day of every security update.
What the findings mean for teams that ship software
Put together, the six findings mean that the cost of finding a flaw in your product fell sharply in 2026 while the cost of checking your own release did not. Each type of team feels it differently:
| Team | What changed in 2026 | What to test first |
|---|---|---|
| SaaS and web app teams | AI-assisted releases carry more unreviewed code each sprint | Access between accounts and roles, API authorization |
| WordPress site owners and agencies | Core, plugins and PHP ship security fixes every few weeks, often forced | Logins, roles, forms and checkout on the day each update lands |
| Founders building with Lovable, Bolt, Replit or Cursor | The platform secures itself, not your app | Database rules, exposed keys, ownership checks before launch |
| Mobile app teams | App volume rose fastest of all | Hardcoded keys, open backends, account access between users |
What is QA security testing?
QA security testing is security testing that QA engineers run on every release: written test cases for access control, authentication, secrets, input handling, dependencies and fixes, reported like any other bug. Teams also call it security QA, security QA testing or QA cyber security. It sits inside the normal release cycle, so a security issue is found, fixed and retested in the same sprint as the feature that introduced it.
What does a QA security test check?
A QA security test checks that the product refuses what it should refuse. In practice that covers seven areas, each written as repeatable test cases:
- Role and permission matrix: every role tried against every sensitive page, action and API endpoint, including other users’ records.
- Authentication flows: login, password reset, email confirmation, sessions and multi-factor prompts, including skipped and replayed steps.
- Secrets and configuration: no keys in client code or app bundles; database rules (Supabase row-level security, Firebase rules) tested from an anonymous session.
- Input handling: forms, uploads, URL parameters and rich text, with the payloads from the OWASP Web Security Testing Guide.
- Dependencies: every package exists, is the intended one and has no known vulnerability.
- Business logic: negative quantities, changed prices, skipped payment steps, reused coupons.
- Fix retest: every security fix and update retested on the release it ships in, with regression around it.
The checks map to OWASP ASVS Level 1 and 2, the standard most web and mobile products are measured against.
How is QA security testing different from penetration testing?
QA security testing and penetration testing answer different questions, and most products need both.
| QA security testing | Penetration testing | |
|---|---|---|
| Question | Does the product still refuse what it should? | How far can a determined attacker get? |
| Who runs it | QA engineers | Specialist security testers |
| When | Every release | Once or twice a year, and after major changes |
| Method | Repeatable test cases from requirements and OWASP ASVS | Goal-driven attack that chains weaknesses |
| Output | Bug reports and tests that stay in the regression suite | Attack narrative and risk-rated findings |
| Best at | Access control, logins, secrets, regressions | Deep chains, infrastructure, cloud and network issues |
When a regulation or contract names a pentest, such as PCI DSS requirement 11.4, a specialist firm should run it. QA security testing keeps the issues it found from coming back between pentests.
What is security testing for AI-generated code?
Security testing for AI-generated code applies the same checks to code an AI tool wrote, with extra weight on the areas the data shows AI gets wrong: authorization, configuration and dependencies. For apps assembled entirely by an AI builder, people call it vibe coding security. The difference from normal QA is not the method but the assumption: nobody on the team may have read the code, so the tests have to cover what a careful reviewer would have caught.
Why don’t scanners and AI code reviewers catch these bugs?
Scanners and AI code reviewers catch patterns that are wrong everywhere, such as unescaped output or a known vulnerable package version. They miss bugs that are only wrong for your business: a Contributor who can overwrite another author’s post, a customer who can open another customer’s invoice, a coupon that applies twice. Finding those needs someone who knows your roles and rules and tests the running product against them.
How a QA testing company can help you close the gap
A QA testing company closes the follow-up gap by owning the check that nobody on a busy product team owns: testing each release for security regressions before users see it. That is the part the data shows is missing, and it does not need a full security team.
What BugsQA does on each release
BugsQA adds a security pass to release testing for websites, web apps and mobile apps:
- Before the release: we run the role and permission matrix, authentication flows, secrets and database-rule checks and input tests on your staging build.
- When a fix lands: we retest it the same day and run regression on the features around it, so a security fix does not break a workflow or reopen another hole.
- When an upstream update lands: for WordPress, PHP, plugins and key packages, we retest your critical flows within a day of the security release.
- Every report: steps, severity, affected roles and video, inside your own bug tracker.
For AI-built products, our security testing for AI-built apps starts with database rules, exposed keys and ownership checks. For WordPress sites, our WordPress security testing adds plugin checks and post-update retests. API-heavy products get API testing for authorization on every endpoint.
When to bring in a QA team
Bring in a dedicated QA team when one of these is true:
- More than half of each release is written with AI tools and your senior developers review it in their spare time.
- You ship weekly or faster and test security once a year, or never.
- You run WordPress, PHP or plugins you did not write, and nobody retests after security updates.
- You built your product with an AI app builder and real users are about to sign up.
- A customer, investor or auditor has asked how you test security between pentests.
Why nearshore QA fits this work
Security follow-up depends on speed: a fix should be retested the day it ships. BugsQA works from Cali, Colombia, with 7 to 8 hours of overlap with US Eastern time, so a fix pushed at 2 p.m. is retested the same afternoon. Our plans and process are on how we work.
How we built this report
BugsQA verified every number in this report at its source between 20 and 22 October 2026, and labels its own calculations as such. You may reuse the data under CC BY 4.0, with a link to this page.
- NVD: CVE records by publish date from NVD API 2.0, summed in monthly windows, pulled 22 October 2026, including records later rejected.
- WordPress Core: every issue in WordPress.org security and maintenance releases 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 do not count again. “AI-credited” means the release notes name an AI lab, an AI tool or a researcher who disclosed using an AI model for that finding.
- GitHub advisories: reviewed advisories per ecosystem and publish year from the GitHub Advisory API, pulled 22 October 2026.
- CISA KEV: additions per year from the catalog’s dateAdded field, pulled 21 October 2026.
- Vendor reports: Patchstack, Wordfence, Faros AI, LinearB, Sonar, Endor Labs, GitGuardian and VulnCheck figures appear as published. These companies sell security or engineering products, so read their framing with that in mind.
Raw data: every dataset in this report
This section holds every dataset behind the findings, in full, with its source and a CSV download. BugsQA serves the files from this site; they contain only public data. Jump to a dataset:
- WordPress Core issues per year
- WordPress Core issues by type
- WordPress Core 2026 by access needed
- AI-credited WordPress fixes
- NVD CVEs per year
- NVD CVEs per month, 2026
- CISA known exploited per year
- Exploitation speed and share
- GitHub advisories by ecosystem
- WordPress ecosystem per year
- Wordfence per quarter
- Wordfence bug bounty per month
- WordPress.org plugin submissions
- New App Store apps per year
- PHP and WordPress versions in use
- Code review and verification
- AI-built app incidents
- AI dependencies and secrets
WordPress Core security issues per year, 2022 to 2026
| Year | Unique Core issues | Security releases | Needing no login | Credited to AI labs or tools |
|---|---|---|---|---|
| 2022 | 26 | 4 | 1 | 0 |
| 2023 | 14 | 4 | 1 | 0 |
| 2024 | 6 | 3 | 0 | 0 |
| 2025 | 2 | 1 | 0 | 0 |
| 2026 (to 22 Oct) | 44 | 8 | 7 | 11 |
Source: WordPress.org release notes, counted by BugsQA. Download the yearly summary (CSV) or the full issue list, one row per issue (CSV).
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 |
Source: BugsQA classification of WordPress.org release notes. Download (CSV).
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 |
Source: WordPress.org release notes, classified by BugsQA. Download (CSV).
AI-credited WordPress Core fixes, 2026
| Release window | Releases | Issues fixed | Credited to AI labs or tools | Share |
|---|---|---|---|---|
| March 2026 | 6.9.2 | 10 | 0 | 0% |
| July to August 2026 | 7.0.2, 7.0.3, 7.0.4 | 15 | 4 | 27% |
| September to October 2026 | 7.1.1, 7.1.2, 7.1.3 | 19 | 7 | 37% |
Credited: Anthropic (6), pwn.ai (3), Trail of Bits with OpenAI (1), Searchlight Cyber researcher using GPT-5.6 (1). Download (CSV).
NVD CVE records per year, 2020 to 2026
| Year | CVE records published | Change |
|---|---|---|
| 2020 | 19,222 | |
| 2021 | 21,950 | +14% |
| 2022 | 26,431 | +20% |
| 2023 | 30,949 | +17% |
| 2024 | 40,704 | +32% |
| 2025 | 49,972 | +23% |
| 2026 (to 21 Oct) | 87,574 | +75% vs all of 2025 |
Source: NVD API 2.0, pulled by BugsQA on 22 October 2026, including rejected records. Download (CSV).
NVD CVE records per month, 2026
| Month | Records | Month | Records |
|---|---|---|---|
| January | 5,143 | June | 8,001 |
| February | 4,808 | July | 9,919 |
| March | 6,304 | August | 12,719 |
| April | 5,885 | September | 15,074 |
| May | 6,985 | October (1 to 21) | 12,736 |
Source: NVD API 2.0, pulled by BugsQA. Download (CSV).
CISA known exploited vulnerabilities per year, 2021 to 2026
| Year | Added to the KEV catalog | Note |
|---|---|---|
| 2021 | 311 | Catalog launched with a backfill |
| 2022 | 555 | Includes older CVEs added retroactively |
| 2023 | 187 | |
| 2024 | 186 | |
| 2025 | 245 | |
| 2026 (to 21 Oct) | 270 |
Source: CISA KEV catalog feed, counted by BugsQA. Download (CSV).
Exploitation speed and share, 2025 vs 2026
| Measure | Earlier | 2026 |
|---|---|---|
| Share exploited on or before disclosure day | 28.93% (2025) | 23.43% (first half) |
| Median days from publication to known exploitation | 120 (2025) | 80 (first half) |
| Known exploited vulnerabilities as a share of CVEs | 2.7% (late 2023 peak) | 1.4% (first half) |
| AI-discovered vulnerabilities exploited in the wild | 14 of 1,061 (1.3%) | |
| Median time to first exploitation, heavily targeted WordPress vulnerabilities | 5 hours (2025) |
Sources: VulnCheck State of Exploitation 1H 2026; Patchstack 2026. Download (CSV).
GitHub reviewed advisories by ecosystem, 2020 to 2026
| Ecosystem | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026 (to 22 Oct) |
|---|---|---|---|---|---|---|---|
| npm | 934 | 597 | 670 | 400 | 436 | 631 | 3,535 |
| PyPI | 142 | 525 | 1,351 | 527 | 692 | 743 | 2,451 |
| Composer (PHP) | 116 | 376 | 2,269 | 714 | 995 | 579 | 1,477 |
| Maven (Java) | 151 | 394 | 3,005 | 951 | 566 | 711 | 1,003 |
Source: GitHub Advisory API, pulled by BugsQA. The 2022 Composer and Maven spikes reflect bulk imports. Download (CSV).
WordPress ecosystem vulnerabilities per year, 2020 to 2025
| Year | New vulnerabilities (plugins, themes, Core) | Change |
|---|---|---|
| 2020 | 582 | |
| 2021 | 1,382 | |
| 2022 | 4,528 | |
| 2023 | 5,948 | +24% |
| 2024 | 7,966 | +34% |
| 2025 | 11,334 | +42% |
In 2025, 91% were in plugins, 17% were high severity and 46% had no patch at disclosure. Source: Patchstack State of WordPress Security reports (2020 to 2022 as reported by WP Tavern). Download (CSV).
Wordfence vulnerabilities per quarter, Q3 2025 to Q2 2026
| Quarter | Vulnerabilities published | Change | High threat | Unpatched at quarter end |
|---|---|---|---|---|
| Q3 2025 | 1,857 | -32.4% | 137 | 950 |
| Q4 2025 | 2,213 | +19.2% | 131 | 905 |
| Q1 2026 | 2,738 | +23.7% | 158 | 747 |
| Q2 2026 | 2,073 | -24.3% | 182 | 149 |
Source: Wordfence quarterly WordPress threat intelligence reports. Download (CSV).
Wordfence bug bounty submissions per month, July 2025 to June 2026
| Month | Submissions | Active researchers | Bounties paid |
|---|---|---|---|
| Jul 2025 | 325 | 69 | $18,047 |
| Aug 2025 | 438 | 84 | $18,054 |
| Sep 2025 | 374 | 77 | $12,664 |
| Oct 2025 | 486 | 99 | $38,814 |
| Nov 2025 | 746 | 131 | $27,737 |
| Dec 2025 | 759 | 122 | $12,402 |
| Jan 2026 | 897 | 151 | $21,517 |
| Feb 2026 | 1,078 | 212 | $24,651 |
| Mar 2026 | 1,718 | 321 | $62,174 |
| Apr 2026 | 1,288 | 327 | $37,054 |
| May 2026 | 1,095 | 293 | $34,454 |
| Jun 2026 | 1,066 | 306 | $42,553 |
Source: Wordfence Bug Bounty Program monthly reports. Download (CSV).
WordPress.org plugin submissions and reviews, 2024 to 2026
| Period | Measure | Value |
|---|---|---|
| 2024 average | New plugin submissions per week | about 150 |
| Late 2025 | New plugin submissions per week | about 330 |
| March 2026 | New plugin submissions per week | about 500 |
| May 2026 | New plugin submissions per week | about 700 |
| 2025 | Plugins reviewed | 12,713 (+40.6%) |
| 2025 | Plugins approved | 5,415 (+66.2%) |
| 2025 | Reviewed plugins whose authors never replied | 38.7% |
| Mid-April 2026 | Plugins waiting in the review queue | about 1,050 |
Source: WordPress.org Plugins Team posts, January and June 2026. Download (CSV).
New App Store apps per year, 2017 to 2026
| Year | New apps released |
|---|---|
| 2017 | 731,000 |
| 2018 | 474,000 |
| 2020 | 491,000 |
| 2022 | 434,000 |
| 2023 | 424,000 |
| 2024 | 448,000 |
| 2025 | 557,000 |
| Q1 2026 | +80% vs Q1 2025 |
Source: Appfigures; Q1 2026 via TechCrunch. Download (CSV).
PHP and WordPress versions in use, October 2026
| PHP version | Share of WordPress sites | WordPress version | Share of sites |
|---|---|---|---|
| 8.3 | 26.7% | 7.1 | 63.0% |
| 8.2 | 23.7% | 7.0 | 7.6% |
| 7.4 | 15.9% | 6.9 | 6.8% |
| 8.1 | 10.5% | 6.8 | 5.3% |
| 8.4 | 9.5% | 6.7 and older | 17.2% |
| 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).
Code review and verification metrics, 2025 to 2026
| Measure | Value | Source |
|---|---|---|
| Developers using or planning to use AI tools | 84% (76% in 2024) | Stack Overflow Developer Survey 2025 |
| Professional developers using AI daily | 50.6% | Stack Overflow 2025 |
| Developers who distrust AI accuracy | 46% (33% trust) | Stack Overflow 2025 |
| Share of committed code written by AI | 42% (65% expected by 2027) | Sonar, January 2026 |
| Developers who always check AI code before committing | 48% | Sonar |
| Pull requests merged, high-AI teams | +98% | Faros AI, 2025 |
| Review time per pull request, high-AI teams | +91% | Faros AI |
| Pull request size, high-AI teams | +154% | Faros AI |
| Review pickup time, agent vs human pull requests | 17.6h vs 3.4h | LinearB, 2026 |
| Pull requests merged within 30 days, AI vs unassisted | 32.7% vs 84.4% | LinearB |
AI-built app security incidents, 2025 to 2026
| Date | Platform or app | Issue | Scale | Status |
|---|---|---|---|---|
| Mar to May 2025 | Lovable (CVE-2025-48757) | Missing or ineffective Supabase row-level security | 170 of 1,645 showcase apps, 303 endpoints | Found by researchers; Lovable disputes |
| Jul 2025 | Base44 (Wix) | Authentication bypass with a public app ID | Several enterprise apps | Found by Wiz, fixed in 24 hours |
| Jul 2025 | Replit agent | Agent deleted a production database during a code freeze | One project, data recovered | Agent misbehaviour |
| Aug 2025 | Nx npm packages | Malware used developers’ AI coding agents to hunt for secrets | Eight malicious versions | Exploited in the wild |
| Oct 2025 | Vibe-coded apps (Escape scan) | Scan of public apps built on AI builders | 2,000+ vulnerabilities, 400+ secrets, 175 PII exposures | Vendor scan |
| Feb 2026 | Moltbook | Supabase key in client code, row-level security off | About 1.5M API tokens, 35,000 emails | Found by Wiz, fixed in hours |
| Feb 2026 | Exam app hosted on Lovable | Inverted access check in authentication | 18,697 user records | Found by a researcher |
| Apr 2026 | Lovable | Missing ownership check on project chats and source | Not published | Found by a researcher; Lovable apologised |
Sources: researcher and vendor disclosures, Wiz, The Register (links in the CSV). Download (CSV).
AI coding dependencies and leaked secrets
| Measure | Value | Source |
|---|---|---|
| Dependency versions imported by AI agents with known vulnerabilities | 49% | Endor Labs 2025 |
| Dependency versions imported by AI agents that do not exist | 34% | Endor Labs |
| Dependency versions recommended by AI assistants that are safe | about 1 in 5 | Endor Labs |
| Unique hallucinated package names in 576,000 code samples | 205,474 | Spracklen et al., USENIX Security 2025 |
| Package hallucination rate, commercial vs open-source models | 5.2% vs 21.7% | Spracklen et al. |
| New secrets leaked on public GitHub in 2025 | 28.65 million (+34%) | GitGuardian 2026 |
| Secret leak rate, Claude Code-assisted commits vs baseline | 3.2% vs 1.5% | GitGuardian |
| Secrets found in MCP configuration files | 24,008 | GitGuardian |
Frequently asked questions
Who should do security testing, developers or QA?
Both, with different jobs. Developers should fix what scanners and code review flag before merging. QA engineers should test the running product every release against its roles, rules and data, because that is where access-control and business-logic bugs show up. In 2026 only 48% of developers always checked AI-written code before committing, so a separate QA check catches what slips through review.
Do AI app builders like Lovable handle security for you?
No. AI app builders secure their own platform, but they treat your app’s database rules, keys and permissions as your responsibility. Lovable disputed a 2025 vulnerability record on exactly that basis after researchers found 10.3% of 1,645 showcased apps exposing their databases. Test the app you ship, especially database rules and access to other users’ records, before launch.
Why did WordPress have so many vulnerabilities in 2026?
WordPress Core fixed 44 security issues in 2026, against 2 in 2025, mainly because far more researchers and AI tools started examining it. BugsQA found that at least 11 of the 44 were credited to AI labs or AI tools, and Wordfence reports that about two thirds of the reports it receives now involve AI. More bugs were found, not necessarily more bugs created.
What is the most common vulnerability in 2026?
Broken access control is the vulnerability class that grew fastest in 2026. It was the top WordPress class in Wordfence’s Q1 2026 report (Missing Authorization, 753 cases, ahead of XSS with 736), the most common GitHub code-scanning alert in 2025 and the fastest-growing type in WordPress Core. Cross-site scripting remains very common but stopped growing.
How often should you run security tests?
Run security test cases on every release that changes code users can reach, and retest within a day of any security update to a dependency, plugin, CMS or runtime such as PHP. A penetration test once or twice a year complements this. Heavily targeted WordPress vulnerabilities reached first exploitation in a median of five hours in 2025, so quarterly-only testing leaves long gaps.
Can I use the data in this report?
Yes. BugsQA publishes the data under CC BY 4.0: you may reuse, chart and republish it with a link to this page as the source. Every dataset is in the raw data section above as a table and a CSV download, and the original sources are named under each table.
Get a security QA pass on your next release
The data points one way: code ships faster, AI finds flaws faster, and teams follow up slower, with broken access control as the first casualty. Closing that gap does not need a new security department. It needs someone testing roles, logins, secrets, dependencies and fixes on every release.
BugsQA runs security QA testing for websites, web apps and mobile apps from a nearshore team in Colombia that works your hours. Send us your release schedule and the user roles your product has, and we will show you what a security test pass covers. Start with our security QA testing service or contact us.
- security
- ai
- wordpress
- data report
