Here is an odd kind of good news. Security teams are fixing vulnerabilities faster than ever, and their vulnerability backlog keeps growing anyway. AI tools have made finding bugs far cheaper than fixing them.
A HackerOne report published on 7 October found average resolution time fell from 135 days to 62 days, yet validated, unresolved issues grew 131% over two years. For CTOs and security leaders, discovery is no longer the constraint. Triage and fix capacity is, and the answer is to rank work by real exposure and put AI on the remediation side as well.
How big is the vulnerability backlog problem?
The HackerOne figures are blunt. Average resolution time improved 54%, and the backlog still grew. Of 111 security leaders surveyed at companies with more than $100 million in revenue, nearly 70% said validated findings enter their systems faster than their teams can fix them, and 75% now formally track what HackerOne calls exposure debt. HackerOne CEO Kara Sprague put it simply: discovery is no longer the constraint.
On the finding side, 85% of 408 researchers surveyed said they are building their AI skills, and nearly three quarters reported a meaningful rise in valid findings. Researchers on the platform earned a record $89 million between July 2025 and June 2026.
Your team got faster. The people finding bugs got much faster.
Is AI really finding serious bugs?
Yes, including in code nearly everyone runs. On 21 October Wiz published PHP2Shell, four bugs in PHP itself tracked as CVE-2026-109618 and CVE-2026-109619, with severity up to CVSS 9.2. Wiz said it used AI models through discovery, exploit development and patch validation, and it showed unauthenticated remote code execution against WordPress, Drupal and Joomla in testing. Every PHP release from the last decade is affected by at least one of the bugs. PHP shipped patches the same day.
Anthropic's numbers show the scale problem from the other end. In an 8 October post launching an opt-in scanner for critical open-source projects, the company said its models had surfaced more than 29,000 candidate vulnerabilities over six months, and about 6,000 had been manually triaged. Anthropic said it is limited by human capacity to validate what the models find. In an early sample of 97 high and critical findings, 85 met the disclosure bar and only one was a false positive. Projects that opt in get model-generated reports sent straight to their maintainers, without human review first.
So the findings are mostly real. There are just a lot of them.
GitHub is pushing the same way inside the pull request. Since July, code scanning can show AI security detections on pull requests, in public preview for GitHub Code Security customers. Those findings are informational and do not block merges, which is sensible, but they still land in somebody's queue.
Where should leaders spend triage capacity?
If you cannot fix everything, and you cannot, the job becomes deciding what waits. A few rules hold up:
Rank by exposure, not severity score. A 9.2 in a library called only from an internal batch job is less urgent than a 7.5 on your login page. Reachability, internet exposure and data sensitivity matter more than the CVSS number.
Give known exploitation a fast lane. HackerOne noted that AI helps attackers too, turning a disclosed flaw into a working exploit in hours where it once took months.
Patch platforms, not apps, where you can. PHP2Shell is the example. One runtime upgrade in your base images fixes every app built on them. Teams with a standard base image and an automatic rebuild will clear it in a day. Teams without one will open a ticket per service.
Ask for a reproducer. AI-sourced reports that arrive with a working proof are quick to confirm. Maintainers at OpenSSL and PostgreSQL told The New Stack that such reports were close to ready to act on. Reports without one go to the back of the line.
Use AI to fix as well as find. Sprague's advice was to apply AI to remediation and formalise vulnerability operations. Candidate patches, backports and test generation are reasonable jobs for an agent, with a person reviewing the result.
Who owns the backlog?
This is a management question more than a tooling one. If security finds and engineering fixes, and engineering is judged only on features, the backlog grows no matter how good the scanner is. Sprague said organisations spend far more effort on new features than on paying down security debt. Most engineering leaders would admit the same in private.
Put a number on it. Reserve a fixed share of each team's capacity for security fixes, track backlog age by exposure tier and review it with the same seriousness as uptime. If the oldest critical item on an internet-facing system is older than a sprint, that is a leadership problem, not a scanner problem.
HackerOne said it is not yet clear whether breaches have risen alongside discovered bugs. Waiting to find out is not a plan.
