The Vulnerability Economy

The 14-Year-Old Vulnerability That Changed Cybersecurity

In October 2026, the discovery of two critical vulnerabilities in PHP, one of the most widely used programming languages for websites, demonstrated how profoundly AI is changing cybersecurity. The underlying weaknesses were particularly remarkable because some of the affected mechanisms dated back to 14 years earlier.

The discovery is significant because it demonstrates a change in the vulnerability research. According to Wiz Research’s technical analysis, frontier AI models substantially reduced the effort required to understand and exploit the affected code. The researchers reported that work which might previously have required a highly specialized team over several months could be accomplished by an experienced researcher with AI assistance in approximately a week.

The implications extend far beyond PHP. A weakness does not become dangerous solely because it exists; its practical significance also depends on whether someone can discover and exploit it.

AI is changing that second factor.

Does software that has operated successfully for years can suddenly become a realistic target without any modification to its underlying code? Is it because the system has not necessarily deteriorated, but the capabilities of potential attackers have improved?

That distinction explains why the increasing discovery of vulnerabilities cannot simply be dismissed as unnecessary alarm. Some newly identified weaknesses represent genuine changes in an organization’s exposure to attacks. Yet it also raises an important question: If AI can identify problems that have remained hidden for decades, how many additional weaknesses will emerge as these analytical capabilities continue improving, and how should we decide which findings deserve attention?

When Detecting More Problems Does Not Necessarily Mean More Danger

In software engineering, automated vulnerability detection is not a new development. Static analysis tools have been used for decades to examine source code without executing it, identifying programming patterns that may cause security or reliability problems.

Modern AI-assisted systems extend these capabilities by helping analyze complex relationships, interpret findings, construct test cases, and investigate behavior that traditional have been overlooking.

However, established research has demonstrated that automated detection introduces problems of its own.  Johnson, Song, Murphy-Hill, and Bowdidge published a study titled Why Don’t Software Developers Use Static Analysis Tools to Find Bugs? at the International Conference on Software Engineering. The researchers interviewed 20 developers to understand why automated analysis tools were not being used more extensively. Although participants generally recognized the benefits of automated bug detection, irrelevant warnings were among the important barriers to adoption.

An irrelevant warning occurs when a system identifies a problem that classifies a harmless condition as a defect. It means, a finding is technically accurate without being important. A scanner might correctly identify an outdated component, an inefficient function, or a missing configuration setting while providing little evidence that the observation represents a meaningful security threat.

Computer science addresses this through the concepts of precision and recall, widely used in information retrieval, machine learning, and classification systems. Precision describes how many reported findings are genuinely relevant, while recall describes how many of the genuinely relevant findings the system successfully identifies. A scanner designed to detect as many potential weaknesses as possible may achieve high recall at the expense of producing numerous irrelevant warnings. Such a system can be useful during comprehensive research, but it is not necessarily suitable for determining which problems require attention.

Consider a hypothetical security scanner that reports 200 potential problems in a large website. After technical verification, perhaps two turn out to be genuine security weaknesses. The scanner has not necessarily failed: it may have successfully identified all five important problems. Nevertheless, the organization must investigate the additional findings to establish their significance.

This distinction matters as AI makes increasingly sophisticated analysis available at lower cost and higher speed. A website may receive a report containing hundreds of detailed technical observations, creating the impression that it suffers from an extraordinary number of security problems. The report may contain lots of information, but its length does not establish the seriousness of the findings.

Interestingly, even the PHP Foundation encountered this problem during the period surrounding the PHP vulnerability. In its October 2026 statement, the organization reported that its security team had published vulnerability reports where more than 100 reports proved invalid, duplicated, or impossible to reproduce. AI-assisted research was producing genuine discoveries, but it was also generating massive irrelevant weaknesses.

The scientific lesson is that detection and importance are two different things. An analytical system can produce large quantities of information, but determining which findings matter requires context, validation, and judgment.

Which Vulnerabilities Actually Matter

One of the most relevant studies in this discussion was published by cybersecurity researchers Allodi and Massacci in their peer-reviewed paper, Comparing Vulnerability Severity and Exploits Using Case-Control Studies. Rather than assuming that technically severe vulnerabilities were necessarily the ones most likely to be exploited, the researchers examined whether established severity classifications corresponded to attacks observed in practice.

Their methodology is especially interesting because it was adapted from epidemiology, the scientific study of how diseases and their associated risk factors occur in populations. Allodi and Massacci applied this approach to cybersecurity by comparing vulnerabilities exploited in real-world attacks with vulnerabilities that had not been observed being exploited at all.

The study demonstrated something more specific: the technical severity of a weakness and the probability that attackers will exploit it are not the same measurement.

Further research reinforced the importance of this distinction. In 2020, Jacobs, Romanosky, Adjerid, and Baker published Improving Vulnerability Remediation Through Better Exploit Prediction in the Journal of Cybersecurity. Analyzing approximately 76,000 publicly disclosed vulnerabilities, the researchers found that only around 5% had been observed being exploited in the wild in their available datasets. This demonstrates the considerable difference between the number of disclosed vulnerabilities and the number observed in real attacks.

The Forum of Incident Response and Security Teams, FIRST explicitly warns that this probability is not a complete measure of organizational risk because it does not incorporate the consequences of an attack or the specific circumstances of an affected system.

A similar distinction is reflected in the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. Their 2026 risk-based directives emphasize prioritizing high-risk vulnerabilities rather than treating every weakness identically.

These methods provide an established scientific foundation for a principle that becomes increasingly important in the AI era: The number of vulnerabilities identified is not a reliable measure of how insecure a system actually is. Security decisions must consider the likelihood of exploitation, the consequences of an attack, the system’s exposure, and the protections already in place.

A Growing Business Model Around Security Warnings

The ability to identify potential security weaknesses is becoming an increasingly accessible commercial service. Established cybersecurity companies have long performed vulnerability assessments and penetration tests, but AI-assisted tools can reduce the time required to conduct preliminary investigations, classify findings, and prepare reports. For companies offering website maintenance or security remediation, this creates an opportunity to approach businesses with technical observations about their existing websites.

An unsolicited security letter examined for this article from one of my clients illustrates the mechanism. The sender informed our client owner that publicly available information suggested several missing security protections, including HTTP security headers. The letter referred to recent PHP vulnerabilities, emphasized the potential consequences of cyberattacks, and offered professional assistance. The warnings were sufficiently concerning that our client contacted us for clarification.

The warnings were not entirely unfounded. They identified several weaknesses involving HTTP security headers, the kind of issues commonly found on websites. These are legitimate security protections, which gave the letter technical credibility rather than making it an obvious attempt to sell unnecessary services. However, OWASP‘s own guidance also demonstrates that such findings require interpretation, because not every missing security header represents a meaningful vulnerability or even requires correction. That distinction was conveniently absent from the unsolicited letter. Instead of assessing the actual security risks, the company presented its findings and offered its services to fix them.

This is an important illustration of the difference between a checklist and a security assessment. A scanner may correctly identify a missing header, but that finding does not automatically establish a practical vulnerability, nor does adding every conceivable security header necessarily improve security. In fact, inappropriate configurations can even interfere with website functionality, including embedded services and third-party applications.

The broader economic problem of fixing vulnerabilities has been studied for years. Microsoft researcher Herley published So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. Herley examined why people frequently disregard cybersecurity recommendations and argued that ignoring certain advice can be economically rational when the time and effort required to follow it exceed the expected benefits.

Imagine a company that receives ten security assessments every month, each identifying a different collection of potential weaknesses. Even if every provider acts in good faith, the company must spend resources evaluating the findings, determining whether they are already addressed, and deciding whether additional work is justified.

This has effectively become a business model: Providers use AI-powered systems to automatically scan websites, generate security reports at minimal cost, and send unsolicited letters and emails to website owners to acquire new customers. The recipients, meanwhile, bear the considerably greater costs of verifying the findings and implementing any necessary corrections.

We are increasingly seeing this business model in action, with a growing number of AI-assisted security reports and recommendations reaching our clients. Almost every day, at least one client contacts us after receiving such a letter, asking for advice on how to address the alleged issues. These warnings are causing considerable alarm among our clients, as the companies sending them create a sense of urgency without establishing how serious the identified risks actually are.

A commercial provider benefits from discovering additional issues and offering corrective services, while the business receiving the warning must determine whether the expenditure produces a meaningful security benefit.

Security Fatigue and the Problem of Endless Warnings

In 2016, researchers Stanton, Theofanos, Spickard Prettyman, and Furman published a study titled Security Fatigue, associated with the U.S. National Institute of Standards and Technology. The study used semi-structured interviews with 40 participants to investigate how individuals perceived and managed online security requirements. More than half of those interviewed spontaneously described experiences consistent with security fatigue.

The researchers identified patterns including resignation, feelings of lost control, risk minimization, and avoidance of security-related decisions. Their findings provided evidence that excessive security demands can influence how individuals evaluate and respond to security advice.

The relevance to AI-generated vulnerability reporting is substantial. When website owners repeatedly receive warnings about different technical weaknesses, they may begin treating all security notifications as routine commercial solicitations. The consequence could be reduced attention to warnings that genuinely require urgent intervention.

For businesses receiving unsolicited security assessments, this creates an important distinction between demonstrating that a weakness exists and demonstrating that a proposed service will materially reduce risk. A meaningful recommendation should identify the mechanism through which the weakness could be exploited, explain the consequences, and provide a defensible assessment of the benefits of correction.

Otherwise, security advice can become a proposition that is commercially persuasive but difficult and expensive to evaluate.

When Hosting Problems Become Arguments About Website Development

Here is another problem: First you have to understand that AI-assisted development has made it easier to modernize existing software, but modifications to established systems carry risks. As described by Lehman’s Laws of Software Evolution and Hyrum’s Law, software accumulates complexity and hidden dependencies over time, sometimes relying on behaviors that developers may not even recognize.

This becomes particularly relevant when hosting providers update PHP versions, databases, caching systems, or server configurations. Even improvements intended to increase security and performance can disrupt applications that previously worked reliably.

Google’s 2025 DORA State of AI-Assisted Software Development Report  also identified a negative relationship between AI adoption and software stability.

One of my clients, who has a mid-size website, suddenly began experiencing down-times during on his website. Important website functions became inaccessible for several minutes at a time. The problems appeared from one week to the next, even though the website had previously been working without issues.

The client contacted the hosting provider, which investigated the server logs and determined that certain website components had stopped responding for several minutes at a time. The provider also identified numerous other issues involving plugins, theme components, and other parts of the website.

What caught my attention was the extraordinary level of detail in the technical report the client forwarded to me. It contained findings that would normally require a security expert weeks of investigation to compile. It was highly unlikely that the hosting provider had invested that amount of manual effort into a routine support ticket. My conclusion was that the report had been generated using an AI-powered scanning tool.

This would make perfect sense from an operational standpoint. Hosting providers handle large volumes of support requests, and AI tools now allow their technical departments to perform extensive automated scans and deliver detailed reports to clients without investing significant engineering resources into each individual ticket.

The findings were technically relevant, but they concerned different aspects of the website. However the he correspondence presented those additional deficiencies separately from the description of the outages and did not establish that they were responsible for the website becoming unresponsive.

This distinction is central to root cause analysis, an established method for investigating failures in engineering and computer systems. Identifying a defect during an investigation does not establish that the defect caused the incident. To demonstrate causation, investigators must establish a plausible mechanism supported by evidence, ideally including timing, reproduction, and analysis of relevant system behavior.

For example, if a website has generated PHP warnings for several years but only recently began experiencing timeouts, the warnings alone are insufficient to explain the change. Investigators would need to determine whether the warnings increased, whether they were associated with resource exhaustion, whether related code was modified, or whether environmental conditions of the hosting provider changed.

Google’s Site Reliability Engineering organization has developed extensive practices around precisely this problem. In its Postmortem Culture guidance, Google emphasizes evidence-based incident investigation and the importance of identifying contributing conditions rather than assigning blame prematurely. The methodology examines what happened, why the system behaved as it did, and what changes could prevent recurrence.

A useful investigation therefore requires more than a list of code imperfections. It may involve comparing server configurations before and after an incident, examining deployment histories, analyzing process resource consumption, tracing individual requests, and testing whether suspected defects can reproduce the observed failures.

This becomes particularly important when a hosting provider and an application developer share responsibility for the operational environment. The developer may control application code, plugins, and database queries, while the hosting provider controls server infrastructure, resource allocation, and important runtime configurations. A failure may arise in either environment or through an interaction between them.

AI-assisted diagnostic tools may help investigate these relationships, but they do not eliminate the requirement to establish causation. A highly detailed technical report is not automatically a root cause analysis, and identifying numerous defects does not prove that the responsible party has been identified.

The principle is straightforward but important: The purpose of an incident investigation is not to discover everything that could be improved. It is to determine why a specific failure occurred and what corrective action will prevent it from happening again.

When AI Finds Vulnerabilities Faster Than Humans Can Fix Them

The growing imbalance between vulnerability discovery and remediation is already creating problems for software maintainers. One of the clearest examples involves curl, the widely used open-source software project for transferring data between computers over networks.

In January 2026, curl’s lead developer Daniel Stenberg announced the termination of the project’s paid vulnerability bug-bounty program after a growing volume of low-quality security reports placed considerable pressure on the maintenance team. Automated and AI-assisted submissions had made it easier to produce plausible reports, but evaluating their accuracy continued to require specialized engineering expertise.

By October 2026, the problem had evolved. In his article Ignore the Slop, Stenberg explained that the he was increasingly receiving technically accurate reports identifying genuine defects.

This development is particularly significant because it removes an easy explanation for the growing workload: The increased number of reports are requiring a huge burden. If reports identify genuine weaknesses, the problem becomes more difficult: Someone must evaluate their security implications, design corrections, test the changes, and distribute updated software.

The Cloud Security Alliance examined this development in its October 7, 2026, research note, When Discovery Outruns Remediation: Open-Source Disclosure Strain. The organization distinguished between excessive numbers of invalid submissions and a potentially more serious problem: valid discoveries outpacing the engineering resources available to address them.

The underlying resource imbalance is clear. Discovering a potential vulnerability is not the same as producing a safe correction. AI can assist with parts of that work, but the technical and operational consequences of software modifications still need to be evaluated. As vulnerability discovery becomes faster, the capacity to implement reliable corrections may become a more important limitation than the ability to identify additional problems.

Can Perfect Security Ever Be Achieved?

The idea of eliminating every vulnerability from a computer system conflicts with the way modern cybersecurity risk management is structured. Security standards generally assume that organizations face continuing risks, some of which cannot be eliminated completely.

The U.S. National Institute of Standards and Technology formalizes this approach in Special Publication 800-30, Guide for Conducting Risk Assessments. The framework emphasizes understanding threats, vulnerabilities, likelihood, impact, and uncertainty so that organizations can select appropriate responses. It does not require treating every conceivable weakness as an emergency.

The principle of defense in depth provides another example. Instead of assuming that every software component can be made completely secure, organizations implement multiple protective measures designed to limit the consequences of individual failures. An application may contain an undiscovered vulnerability, but network restrictions, access controls, monitoring, and appropriate permissions can reduce the likelihood or impact of exploitation.

AI produces more and more findings. The difficulty lies in deciding which improvements justify their costs and which changes introduce risks greater than the weaknesses they are intended to correct.

The Sisyphus Problem – When Security Becomes an Endless Task

There is an obvious similarity to the prospect of continuously examining software with increasingly sophisticated AI systems, correcting discovered weaknesses, and repeating the process when newer tools identify additional problems.

Software maintenance has always been a continuing process. New vulnerabilities are discovered, dependencies evolve, and operating environments change. The fact that maintenance never ends does not mean that the work is unnecessary. The question is whether the growing volume of AI-generated findings will result in proportionate improvements in security or merely increase the amount of work organizations are expected to perform.

There is also a potential feedback effect. An organization receives an automated report identifying weaknesses in its application and authorizes corrective work. The changes resolve the reported issues but alter the behavior of other components. Additional testing identifies compatibility problems, which require further modifications. A later assessment applies newer standards and identifies additional deficiencies. The application may become more secure during this process, but the organization also incurs continuing costs and faces repeated operational risks.

The Future of Cybersecurity May Depend on Knowing What Not to Fix

The most important consequence of AI-assisted vulnerability discovery may be a shift in the expertise that organizations require. When discovering potential weaknesses becomes comparatively inexpensive, the value of professional security work increasingly depends on validating findings, understanding their consequences, and selecting appropriate corrective measures.

For hosting providers, the same principle applies to diagnostic investigations. A comprehensive list of application deficiencies may be useful, but it does not replace a causal explanation of downtime. For developers, successful remediation requires understanding how a proposed correction interacts with existing software. For business owners, the critical question is not how many vulnerabilities a provider can identify, but which findings warrant investment and what measurable benefit the proposed work is expected to produce.

The distinction is also important for the commercial cybersecurity industry. AI-assisted scanning can support efficient and valuable security services, but the ability to generate detailed warnings should not be confused with the ability to assess risks accurately. A provider that identifies a single genuinely dangerous vulnerability and offers a reliable solution may deliver substantially greater value than one that produces dozens of technically accurate but operationally insignificant findings.

More Vulnerabilities Do Not Automatically Mean Less Security

AI has already demonstrated an extraordinary capacity to uncover serious weaknesses in mature software.

At the same time, decades of research in computer science, cybersecurity, software engineering, and security economics demonstrate that identifying technical weaknesses and improving actual security are different objectives. Automated tools can produce low-value findings. Severity scores do not reliably predict exploitation on their own. Excessive warnings can reduce attention to important threats, and software modifications can introduce new operational failures when their consequences are insufficiently understood.

The increasing accessibility of AI-assisted security analysis adds a commercial dimension to these established problems. Companies can identify potential weaknesses and approach prospective customers at lower cost, while the recipients must determine whether the findings justify corrective work.

The central question is therefore not whether AI will continue discovering vulnerabilities. The evidence strongly suggests that it will. The more important question is whether organizations will develop equally effective methods for evaluating those discoveries, distinguishing meaningful security risks from less consequential imperfections, and implementing corrections without unnecessarily compromising reliability.

The internet has never been free of vulnerabilities, and there is no scientific basis for expecting complex software systems to become ever flawless. Continuous improvement remains necessary, but continuous modification is not automatically synonymous with improvement.