Will Open-Source Software Survive the AI Vulnerability Flood?

Why the AI-driven vulnerability flood could hit open-source maintainers harder today—and leave surviving projects more secure tomorrow.

Recent reports about the php2shell flaws (CVE-2026-109618 and CVE-2026-109619), critical remote code execution vulnerabilities in PHP core reportedly discovered with AI assistance, have heightened concerns about the speed of vulnerability discovery and exploitation. At the same time, the curl project has announced changes to its vulnerability-reporting process starting 26 October, reserving private reporting for high- and critical-severity issues amid growing pressure from security submissions, including AI-generated reports.

We may be entering the largest vulnerability discovery wave in software history. AI is making it practical to examine billions of lines of legacy code more thoroughly and continuously, reassessing their security as they interact with new components and environments. One potential consequence is a sharp increase in reported vulnerabilities, and some projects are already experiencing the pressure.

But open source appears to be facing this wave earlier and more visibly than closed source. Does that mean proprietary software is more secure in the age of AI?

And can open-source projects survive the flood?

The more interesting question is what happens after it.

Key Takeaways

1. Software complexity makes vulnerability discovery a universal challenge. Vulnerabilities can emerge from interactions between components, dependencies, and changing environments—even when the underlying code has not changed. Continuous security reassessment, using evolving AI capabilities, is essential across both open- and closed-source software.
2. The AI-driven vulnerability flood will be a temporary peak, not permanent growth. AI-assisted analysis will progressively deplete the finite backlog of detectable historical vulnerabilities, while continuous security analysis in development and CI/CD will reduce its replenishment. Vulnerability discovery will continue, but at a lower rate once the initial backlog has been substantially examined.
3. Open-source projects may face the flood before they can adapt. Easier access to source code and broader independent scrutiny could accelerate vulnerability discovery, overwhelming individual maintainers and communities whose security-response capacity cannot scale quickly enough.
4. Open-source software could become more secure, but its ecosystem will face growing pressure to reorganize. AI-driven vulnerability discovery and growing security obligations could expose the longstanding fragility of critical dependencies maintained by small, underfunded communities. The resulting pressure may accelerate funding changes, consolidation, and project abandonment—potentially producing more secure surviving projects, but a less diverse ecosystem with new concentrations of systemic risk.
5. Closed source is not necessarily safer—it may simply face the flood later. Restricted access to code and binaries can delay independent discovery and reduce public visibility, potentially leaving historical vulnerabilities undiscovered and unfixed for longer. Internal vendor analysis can alter this trajectory.
6. More public vulnerabilities today could mean fewer exploitable vulnerabilities tomorrow. Broad AI-assisted scrutiny of open-source code may accelerate the discovery and elimination of historical vulnerabilities. Closed-source software may retain a larger hidden backlog for longer, while attackers can independently discover and exploit vulnerabilities regardless of public disclosure. Higher CVE counts may therefore reflect faster elimination of hidden risks, not inherently less secure software.
7. Enterprises must accelerate remediation from patch creation to production. AI compresses the discovery-to-exploitation window, making traditional patch deployment timelines increasingly dangerous. Automated testing, cloud-native rolling updates, user-space live patching, and high-availability clustering can reduce deployment delays without sacrificing service continuity.

The Hidden Backlog AI Can Now See

Every mature codebase carries an unknown number of undiscovered vulnerabilities. Some were introduced recently. Many have existed for years or decades.

Traditional security research was always constrained by human time and expertise, so the number of vulnerabilities reported was never a reliable measure of the number that existed.

A project with ten CVEs was not necessarily less secure than one with none; it may simply have been examined more carefully.

AI changes the economics of that examination. Analysis that once required sustained expert attention can increasingly be automated, repeated, and applied across large codebases.

Historically, discovering or disclosing a vulnerability did not necessarily make it immediately exploitable at scale. Some vulnerabilities may already have been exploited privately as zero-days for years before public discovery or disclosure. Developing a reliable exploit often required specialized expertise and considerable time. AI is eroding that barrier. It can accelerate exploit development, automate parts of the exploitation process, and make sophisticated attacks accessible to a much broader range of attackers. The interval between vulnerability discovery and widespread exploitation could shrink dramatically, potentially approaching zero for some classes of vulnerabilities.

The more intensively software is examined, the worse its reported security can initially appear—not because the code has changed, but because previously invisible defects are becoming visible.

A Temporary Peak, Not a Permanent Elevation

For relatively stable codebases, the result should be a temporary peak in vulnerability discovery rather than a permanently elevated discovery rate.

AI-assisted analysis first encounters the accumulated backlog. Discoveries accelerate. Mature projects that reported relatively few issues may suddenly generate substantial numbers.

As detectable legacy flaws are progressively discovered, the remaining backlog of undiscovered vulnerabilities should eventually shrink. Whether the software actually becomes safer depends on how quickly those discoveries are converted into effective fixes.

The prediction is that the initial discovery flood will be temporary, not that vulnerability discovery will eventually stop. Its timing, magnitude, and duration will differ across projects, languages, and ecosystems.

A similar possibility was raised by Cisco Talos in October 2026, which suggested that AI-driven vulnerability discovery could eventually exhaust much of the readily discoverable historical backlog, while AI-assisted security testing during development could help reduce future vulnerability accumulation.

Software continues to change. New features, dependencies, architectural shifts, and AI-generated code can introduce fresh vulnerabilities. Even unchanged legacy code may become exploitable when combined with new components or exposed in different environments. Vulnerabilities can also emerge from interactions between individually secure components, making security a property of the integrated system, not just its individual parts. This makes continuous reassessment necessary across both open- and closed-source software, not merely repeated analysis of newly written code.

Continuous reassessment must also evolve with AI itself. As AI analysis improves, it may identify vulnerability classes, attack paths, and complex interactions that earlier generations of tools could not detect—even in code that has not changed. A completed security scan therefore represents an assessment using the capabilities available at that time, not a permanent declaration that the software is secure.

The historical backlog accumulated over decades when comprehensive security analysis was expensive and largely dependent on human expertise. New software will increasingly be developed under very different conditions.

As AI-assisted vulnerability detection becomes integrated into CI/CD pipelines, newly written code can be examined continuously, allowing vulnerabilities to be discovered and corrected before they reach production or accumulate into another historical backlog.

For this reduction to be sustainable, AI-assisted vulnerability detection must eventually become a commodity: an affordable, routine part of software development rather than an expensive, separately commissioned security activity. Finding and fixing vulnerabilities while code is still being written is far cheaper than discovering them years after deployment, when remediation may require coordinated disclosure, backports, and production patching.

This security analysis must also remain distinct from AI-assisted code generation. Both can coexist in the same development workflow, but generating code and independently evaluating its security are different responsibilities. Vulnerability detection requires dedicated security-focused tools and AI systems trained or optimized for that purpose. Just as compilation does not replace testing, an AI system that produces code should not be relied upon as its sole security reviewer.

AI therefore creates two opposing pressures on vulnerability accumulation. AI-assisted coding can accelerate the introduction of new vulnerabilities as software production scales, potentially sustaining elevated discovery rates even after much of the historical backlog has been examined. Continuous, independent AI-assisted security analysis during development can counteract that effect by identifying and correcting vulnerabilities before they reach production. Without that second mechanism, the predicted decline in vulnerability discovery rates may never materialize.

Not every defect will be detected. But the most readily detectable vulnerabilities should increasingly be identified and eliminated during development rather than accumulating unnoticed for years.

This creates two complementary mechanisms: AI-driven discovery and remediation reduce the historical vulnerability backlog, while continuous AI-assisted security analysis limits its replenishment.

AI-assisted vulnerability detection should therefore become a continuous, standard part of CI/CD pipelines, rather than an occasional security assessment.

AI detection capabilities will continue improving, but their effectiveness need not grow exponentially forever. As techniques mature and become widely adopted, the most readily detectable vulnerabilities should become progressively less common in both legacy and newly developed code.

The expected outcome is therefore an initial discovery flood followed by a smaller, continuous flow of newly discovered vulnerabilities—not the disappearance of vulnerabilities altogether.

New vulnerability classes, major architectural changes, and uneven adoption could produce further discovery waves. But they do not necessarily imply that the enormous historical backlog can be recreated at the same rate.

A lasting reduction in the total vulnerability stock requires effective elimination to exceed the introduction of new vulnerabilities.

Discovery enables elimination; it does not itself reduce the total stock.

Three quantities must be kept distinct.

Discovery is the identification of a vulnerability. Disclosure is its public reporting. Elimination is its effective removal from the software.

CVE counts track a subset of publicly recorded vulnerabilities. They miss vulnerabilities found and fixed internally without public assignment of an identifier.

Residual vulnerability stock is also not the same as residual security risk. Severity, exploitability, exposure, and available mitigations matter. A hundred obscure issues in unreachable code may represent less practical risk than one remotely exploitable flaw in an exposed service.

Two Curves

One curve describes the rate at which vulnerabilities are discovered. Another describes the residual stock of vulnerabilities that remain.

These curves do not necessarily move together.

A surge in discoveries can coexist with a falling residual stock if vulnerabilities are eliminated faster than new ones are introduced. Conversely, a low discovery rate can coexist with a stable or growing vulnerability stock if scrutiny is limited or remediation lags. The discovery curve alone cannot establish whether software is becoming more secure.

Public CVE disclosures provide an imperfect observable indicator of the first curve, not a direct measurement of it.

In open source, the discovery curve is hypothesized to rise earlier and more sharply for three reasons:

• First, source code makes large-scale AI-assisted analysis easier, although AI can also analyze binaries.
• Second, open-source code is generally accessible to independent researchers and automated systems, while proprietary binaries, historical versions, and patches may be less readily available.
• Third, open-source discoveries and remediation are often more publicly visible, while proprietary vendors can handle some findings internally before public disclosure.

This could also produce a more visible peak in public disclosures, although the two trajectories need not be identical.

A further accelerator is independent scrutiny by downstream users. Open-source projects are not analyzed only by their maintainers or security researchers. Commercial manufacturers and integrators also have incentives to examine the components they depend on, reinforced by regulations such as the EU Cyber Resilience Act, which establishes security responsibilities across their software supply chains. AI makes such analysis increasingly affordable and repeatable. Even a small project could therefore face continuous scrutiny from many independent organizations, accelerating the discovery of historical vulnerabilities while helping detect new ones before another backlog accumulates. Projects that can keep pace may become substantially more secure. Those that cannot may struggle to survive.

The same visibility can accelerate independent investigation and remediation through upstream fixes, forks, and downstream patches without waiting for a single vendor.

Neither advantage is guaranteed.

Limited maintainer capacity can turn a discovery surge into a growing backlog of known but unfixed vulnerabilities. Well-resourced proprietary vendors may remediate internal findings faster.

Proprietary software could experience a lower, later, and less visible peak in public vulnerability statistics. But that does not necessarily imply a lower rate of actual discovery. Its source is generally available to fewer external researchers, while well-resourced vendors can conduct extensive internal AI-assisted analysis, discover vulnerabilities, and remediate them before public disclosure.

Furthermore, delaying discovery does not eliminate the underlying vulnerabilities. If the historical backlog is examined and remediated more slowly, vulnerabilities may remain undiscovered and unfixed for longer. A lower public disclosure rate, reflected in fewer CVEs, can therefore coexist with a larger hidden vulnerability backlog, although extensive internal security analysis by proprietary vendors can change that outcome.

A hidden vulnerability backlog is not necessarily a safer one. Public disclosure can increase immediate exploitation risk by enabling parallel attacks, but it also creates an opportunity for remediation. Once a vulnerability is effectively eliminated, that particular exposure ends. By contrast, vulnerabilities that remain undiscovered or unremediated can persist for years, while attackers may independently discover and exploit them without any public disclosure. If broader AI-assisted scrutiny allows open-source projects to discover and eliminate their historical vulnerabilities earlier, they may accept greater short-term exposure in exchange for fewer long-term attack opportunities.

AI can still analyze binaries, compare patched and unpatched versions, and probe running systems. Closed source is not immune. The practical difference is often whether an attacker has access to the binary itself or only remote interaction with a running system.

Once sufficient technical information is available, unpatched deployments face similar exposure to AI-assisted exploitation regardless of the original licensing model. Proprietary vendors can still retain advantages in controlling the distribution of fixes and aspects of disclosure coordination.

Closed source also rarely means pure closed source. Most commercial products depend on substantial amounts of open-source code, and many proprietary vendors participate in upstream projects.

Those vendors cannot fully control the vulnerability discovery and disclosure timelines of their dependencies.

Short-Term Pain

AI-driven vulnerability discovery creates four immediate pressures—and a critical challenge:

1. Misleading public metrics: A surge in reported vulnerabilities can make software appear less secure even while its residual vulnerability stock is declining.
2. Compressed response windows: Exploitation can outpace patch development and deployment.
3. Production deployment bottlenecks: Traditional testing, change management, and downtime requirements delay security updates.
4. Regulatory and disclosure pressure: Vulnerability-handling obligations and coordinated disclosure add operational complexity.

The critical challenge is having no time to adapt. Open-source communities, individual maintainers, and enterprise teams must adapt to security-response timelines far shorter than those they are accustomed to, while already facing an accelerating vulnerability flood. Many lack the automation, resources, or capacity to make that transition quickly enough.

AI can shorten the time from discovery to exploitation. It can also shorten the time required to develop a fix.

The production deployment lag, however, largely predates AI.

Enterprise testing, validation, and change-management processes still take time. The danger is that attackers may increasingly exploit vulnerabilities faster than organizations can deploy remediation.

Even when fixes are available, delays in processing security advisories and identifying affected downstream dependencies can postpone remediation before production deployment even begins (When Discovery Outruns Notification).

As AI compresses the interval between discovery and exploitation, potentially to near zero, traditional response timelines become increasingly untenable. Maintainers may need to investigate, develop, validate, and release fixes within hours rather than days or weeks. Enterprises face the same pressure to test and deploy those fixes into production with minimal delay. For the most critical, readily exploitable vulnerabilities, security response may need to approach real-time operations rather than periodic patch management.

The response must be to aggressively compress the traditional patch workflow from development to production. Automated QA, regression testing, and deployment validation can shorten the time needed to release fixes safely. Once fixes are available, technologies that minimize service disruption can accelerate their deployment into production: cloud-native workloads designed for rolling restarts without service interruption, user-space live patching beyond the Linux kernel, and high-availability clustering for traditional applications. The objective is not merely to produce patches faster, but to deploy them into production before attackers can exploit the vulnerabilities they address.

Coordinated disclosure remains useful, but it cannot guarantee secrecy. Leaks, independent discoveries, public patch analysis, and active exploitation can all shorten the preparation window.

Open-source communities can respond through parallel investigation, but actual response speed depends on available expertise, coordination, and maintainer capacity.

When this discovery surge coincides with growing regulatory requirements, weaker projects, communities, and smaller companies may face genuine viability risks.

The EU Cyber Resilience Act introduces security and vulnerability-handling obligations for covered products with digital elements, including requirements relating to vulnerability management, security updates, and reporting of certain actively exploited vulnerabilities and severe incidents.

These obligations do not apply uniformly. Non-commercial open-source development is treated differently from commercial products, while qualifying open-source software stewards have a distinct framework.

Commercial vendors incorporating open-source components may nevertheless face obligations that increase expectations placed on upstream projects.

Meanwhile, the cost of triaging genuine vulnerabilities alongside noisy, low-quality, or AI-generated reports can overwhelm limited maintainer capacity.

Even projects that successfully improve their security may struggle with the financial and operational costs of the transition.

Can All Open-Source Projects Survive?

Not necessarily.

Open-source projects and maintainers will face five growing pressures:

1. Discovery overload: An unprecedented volume of vulnerability findings.
2. Response workflows: Triage, prioritization, coordinated disclosure, and remediation.
3. Continuous AI reassessment: Repeatedly scanning existing and new code as detection capabilities evolve.
4. Deployment readiness: Helping downstream users deploy security fixes rapidly, including through compatibility with rolling updates, live patching, or high-availability environments where applicable.
5. Supply-chain resilience: Continuously assessing the security and sustainability of critical third-party dependencies, particularly those maintained by small, underfunded communities.

Together, these pressures increase the cost and complexity of maintaining open-source software, potentially beyond what smaller communities can sustain.

The discovery flood will not affect every project equally. A well-funded project with dedicated security engineers, automated testing, and established vulnerability-response processes is in a very different position from a small community maintaining millions of lines of legacy code.

Many widely used open-source dependencies are maintained by small, underfunded communities, sometimes by a single volunteer. This is not a new problem: critical software infrastructure often depends on projects with very limited maintenance resources, creating systemic dependencies whose importance far exceeds the capacity of the communities supporting them. The imbalance between commercial dependence on these components and financial support for their maintenance has been discussed for years.

AI-assisted vulnerability discovery, combined with downstream compliance pressures from regulations such as the EU Cyber Resilience Act (CRA), could amplify this existing weakness. External researchers may soon be able to identify dozens of plausible vulnerabilities in days, while each report still requires validation, prioritization, remediation, and testing. Discovery capacity can scale dramatically without a corresponding increase in maintainer resources.

Automation can help. AI-assisted initial triage, duplicate detection, reproducibility checks, and severity assessment can reduce the burden of processing vulnerability reports. Maintainers can prioritize issues according to exploitability, exposure, and practical impact rather than treating every reported finding as equally urgent.

Integrating AI-assisted vulnerability detection into CI/CD pipelines can also prevent newly introduced vulnerabilities from accumulating into another historical backlog. But this addresses the future flow of vulnerabilities, not the immediate cost of investigating and remediating decades of existing defects.

Continuous security reassessment also introduces a recurring cost. As AI detection capabilities evolve, projects will need to re-examine existing code, not just newly introduced changes. Running increasingly sophisticated analysis, validating findings, and maintaining the necessary infrastructure will require resources that smaller communities may struggle to sustain.

The pressure extends beyond discovering and fixing vulnerabilities. Projects may also need to make security updates easier for their users to deploy, reducing the operational friction that leaves known vulnerabilities unpatched in production. Depending on the software, this may require supporting rolling updates, user-space live patching, or integration with high-availability clustering. These capabilities can reduce service disruption, but developing, testing, and maintaining them adds another cost that not every project can absorb.

And automation has limits. A project may receive more genuine findings than its maintainers can investigate, validate, fix, and release—even after substantially improving its processes.

Some projects will adapt. Others may need additional commercial support, foundation funding, shared security infrastructure, or new maintainers. Some may not survive the transition.

The ability to discover vulnerabilities is scaling faster than the capacity of every open-source community to remediate them.

Improving the security of open-source software does not guarantee the survival of the projects maintaining it.

The risk is systemic, not merely local to individual projects. A vulnerability in a widely reused, poorly maintained component can affect thousands of downstream products. The 2024 XZ Utils backdoor demonstrated how weaknesses in the maintenance and trust structure of a small upstream project could threaten major downstream projects, including Linux distributions, even though the incident involved a supply-chain compromise rather than an AI-driven vulnerability-discovery flood.

Even if the upstream project disappears, its software may remain embedded in production systems without security maintenance. AI-assisted discovery could expose these shared weaknesses at scale, turning the limited remediation capacity of a small upstream community into a security bottleneck for entire software supply chains. Greater reliance on fewer surviving projects could further concentrate systemic risk.

AI-driven vulnerability discovery may act as an evolutionary pressure on open source. Projects capable of adapting can emerge stronger and more secure, while those unable to keep pace risk disappearing. The result may be more secure surviving projects, but also a less diverse ecosystem with greater concentration of systemic risk.

Long-Term Gain

The discovery flood could leave four lasting consequences:

1. More secure software: Effective remediation reduces historical vulnerabilities, while continuous AI reassessment limits the accumulation of new ones.
2. Higher security standards: Continuous AI analysis and faster, less disruptive remediation become normal expectations for software maintenance.
3. A lower vulnerability discovery rate: Once the historical backlog is substantially examined, vulnerability discovery will stabilize at a lower, continuous rate.
4. A less diverse ecosystem: Rising maintenance costs may favor well-funded projects while threatening smaller communities.

The predicted discovery peak creates an opportunity for surviving projects to eliminate a substantial portion of their detectable legacy vulnerabilities. Whether that opportunity translates into improved security depends on sufficient remediation capacity.

The security benefit extends beyond publicly disclosed vulnerabilities. Undiscovered or privately discovered vulnerabilities may already be exploitable, including by attackers who never disclose them. Eliminating the historical backlog therefore reduces potential attack opportunities, not merely future CVE counts. The value of earlier discovery and remediation is that vulnerabilities can be removed before attackers exploit them—or before additional attackers independently discover them.

And if AI-assisted security analysis becomes a normal part of development pipelines, those projects may be less likely to accumulate comparable backlogs again.

This transition will also raise the baseline expectations for software maintenance. Continuous AI-assisted security reassessment, automated vulnerability triage, and faster remediation will increasingly become standard practices rather than optional investments. Users will also expect security updates that can be deployed with minimal service disruption. Meeting these expectations will require sustained engineering investment, even after the initial vulnerability flood subsides.

The most heavily scrutinized codebases may no longer be those with the largest remaining vulnerability stock. They may be those in which the greatest proportion of detectable historical defects has already been eliminated.

Raw CVE counts would then become an increasingly misleading comparative metric.

Comparing ecosystems by the number of vulnerabilities they report in a given year risks rewarding opacity and penalizing transparency.

But the benefits may not be distributed equally.

The projects that survive may increasingly be those backed by commercial vendors, large foundations, or organizations capable of sustaining continuous security operations.

Open-source software could emerge more secure from the transition, while the ecosystem maintaining it becomes less diverse.

These predictions are testable and falsifiable, but they concern different outcomes.

• The temporary discovery peak would be challenged if vulnerability discovery rates remain persistently elevated in mature, extensively analyzed codebases, or if continuous AI-assisted analysis fails to prevent newly introduced vulnerabilities from accumulating into another substantial backlog.
• The open-versus-closed-source trajectory would be challenged if proprietary ecosystems demonstrate equally early and extensive vulnerability discovery through internal AI-assisted analysis, rather than experiencing a delayed discovery wave.
• The long-term security improvement depends on effective remediation. It would be undermined if discovered vulnerabilities remain unfixed or if elimination fails to outpace the introduction of new vulnerabilities.

A decline in reported CVEs alone would not prove depletion. It could reflect reduced research activity, changes in disclosure practices, or declining analysis coverage.

The operational consequences of compressed timelines—continuous visibility, faster production remediation, and reduced exposure—are examined in my earlier article, Post-AI Security: The End of Slow, Static and Periodic Defense.

A dramatic increase in reported vulnerabilities does not necessarily mean software is becoming less secure. It may mean that decades of accumulated defects are finally being found.

Unlike the past, however, future software development could increasingly detect those defects before they become another generation of accumulated security debt.

Whether this discovery wave leaves open source weaker or stronger depends on which projects and companies can convert the findings into fixes before the peak exhausts them.

**The software reporting the most vulnerabilities today may be the software whose hidden vulnerabilities are disappearing fastest—provided it survives long enough for the cleanup to matter.
**