The end of the vulnerability grace period

Lessons from the PHP case on AI-assisted research and exploit velocity

Key takeaways 

• AI is shrinking the defensive window. Weaknesses once considered too complex to exploit can become practical attacks. A published fix can become a working exploit in hours rather than weeks.

• Preemptive cybersecurity shifts the goal. Continuous threat and exposure management (CTEM) helps organizations reduce reachability or exploitability before attacks succeed, rather than simply respond faster.

• Layered defenses buy time and contain damage. Rapid, scalable temporary protections and infrastructure that supports confident patching can help organizations keep pace while fixes are developed. Defense in depth limits the consequences when those measures fall short.

AI is changing what makes a vulnerability dangerous.

Research disclosed in October 2026 showed how AI could be used to discover exploitation pathways impacting longstanding weaknesses in PHP, a widely used programming language that powers websites and online applications. Attackers who successfully reconstruct those methods could execute malicious code on affected servers, potentially stealing data or disrupting operations. One weakness had been identified years earlier but wasn’t deemed critical without a viable path to exploit it. This changed in early August 2026, when AI was used to uncover attack pathways that had eluded earlier research. After details leaked ahead of the planned disclosure, emergency security fixes were accelerated before this exploitation pathway could be replicated in the wild. 

The good news: Emergency security fixes were successfully developed and deployed despite disclosure leaks and the noise of unvalidated exploitation pathways. The warning: Organizations can no longer assume that years-old unexploited vulnerabilities are safely hidden. Use of AI and other advanced tools can reveal attack paths previously deemed improbable, sharply reducing the time defenders have to respond.

The research, and the exploitation attempts observed before public disclosure, underscores how unpredictable the window between vulnerability discovery, disclosure, and exploitation has become. Organizations should be prepared to assess growing volumes of vulnerabilities, act on incomplete intelligence, and contain threats while maintaining critical operations, even before permanent fixes or reliable indicators of compromise are available. 

Faster patching is no longer enough. Security leaders need defensive capabilities that buy time, speed up decisions, limit the consequences of exploitation, and enable investigation if prevention fails.

These capabilities reflect a broader shift toward preemptive cybersecurity, which aims to deny, disrupt, or contain attacks before they succeed rather than rely primarily on detection and response. That shift calls for a sustained program, not a series of emergency responses. Continuous threat and exposure management (CTEM) provides that structure by identifying the assets most critical to the business, discovering and prioritizing exposures based on real-world exploitability, validating what attackers can reach, and mobilizing fixes or temporary protections.

On October 21, 2026, PHP maintainers released emergency fixes for two critical vulnerabilities, collectively known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), that could allow attackers to remotely take control of affected systems without a username or password.

The underlying weaknesses existed for years, but researchers had struggled to establish how attackers could exploit them. That changed in August 2026, when researchers using frontier AI capabilities analyzed complex interactions within PHP's software and identified viable attack paths that had eluded earlier research. Researchers working through OpenAI's Patch the Planet initiative, along with Wiz, which identified the flaws independently, demonstrated how longstanding weaknesses could be exploited to take control of affected systems, dramatically increasing the urgency of remediation.

The coordinated disclosure process didn’t go as planned. Details about the vulnerabilities became publicly available before the planned announcement, which sped up the release of security updates.

Amazon Threat Intelligence detected exploitation attempts on October 17, four days before the official disclosure and three days before details first leaked publicly. Amazon said it remained unclear how the attacker obtained the information, or whether this and subsequent attempts would have succeeded against real-world systems.

On October 26, the US Cybersecurity and Infrastructure Security Agency (CISA) added both vulnerabilities to its Known Exploited Vulnerabilities catalog, indicating it had reliable evidence of exploitation activity, although it did not disclose the evidence behind the listing.

The PHP case shows how accelerating vulnerability research is intensifying several interconnected pressures on cyber defense, challenging longstanding assumptions about exploitability, the time available to respond, and organizations’ capacity to assess and address emerging threats.

Changing exploitation, not just discovery

AI-assisted research can make previously understood and tolerated security weaknesses far more consequential, even when nothing about the underlying software has changed. Frontier AI can accelerate code analysis and exploit development.

Three conditions can heighten exposure: accessible technical material, a reachable attack surface, and a plausible path to significant impact. Organizations have little control over the first condition but can influence the other two by restricting access to vulnerable systems, removing the conditions an exploit depends on, and limiting what a compromised system can reach, reducing risk before a permanent fix is available.

PHP illustrates how these conditions can converge: publicly accessible source code, a widely deployed runtime, and complex memory management behavior. AI-assisted research changed the practical risk presented by existing software weaknesses.

Implications for organizations

Vulnerability prioritization can’t rely too heavily on historical assessments that a weakness is difficult to exploit or lacks a working proof of concept. Organizations should:

• Reassess longstanding weaknesses in critical and internet-facing components when technical complexity previously limited exploitability.
• Monitor upstream security research and maintainer disclosures for unresolved risks in foundational software dependencies.
• Enforce least privilege and review integrations and trusted connections to reduce potential risk.

When exploitation precedes disclosure

Coordinated disclosure is intended to give providers and customers time to prepare defenses before technical details become public. The PHP case shows how that window can disappear, which led Amazon to advise organizations to begin investigations from at least October 17, the date of the earliest attempt it observed, rather than from the disclosure date.

Premature circulation of technical information forced PHP maintainers to accelerate its release. Yet advance coordination also worked: providers deployed protections ahead of the official updates, helping reduce customer exposure. Attackers subsequently adapted techniques to evade those protections.

Temporary protections and advance coordination can buy organizations critical time but require continued monitoring and eventual remediation.

Implications for organizations

Public disclosure shouldn’t be treated as the start of exploitation risk. Organizations should:

• Establish threat-hunting lookback periods based on the earliest credible exploitation evidence, not just the CVE publication date.
• Prepare emergency vulnerability response procedures that can begin with incomplete but credible intelligence.
• Coordinate with vendors and infrastructure partners, including system integrators, managed service providers, and add-on vendors, on protections that can be staged before official disclosure.

When the patch becomes the roadmap

Exploitation risk doesn’t end when a fix is published. It can increase as attackers compare vulnerable and updated software to identify the underlying weakness and develop an exploit, a technique known as patch diffing.

Until now, turning a patch into a working exploit has required specialized technical expertise, with the time involved varying by vulnerability. AI is compressing that timeline by automating complex analysis and accelerating exploit development. Research published by Anthropic in June 2026 on “N-days” (vulnerabilities that have been publicly disclosed with a patch available, but not yet fixed) found that its Claude Mythos Preview model could autonomously build working exploits for 8 of 18 recently patched Firefox vulnerabilities. In one case, the exploit took under an hour from the patch and 18 days before the fixed version reached users. Anthropic found that less capable, publicly available models with safeguards turned off could also build exploits; and warned that the risk will grow as models become more capable, concluding that the time from patch to working exploit is now better measured in hours than in days.

Yet organizational remediation timelines remain measured in weeks. The Verizon 2026 Data Breach Investigations Report found a median of 43 days to fully remediate known critical exploited vulnerabilities. Recognizing the growing urgency, CISA issued Binding Operational Directive 26-04 in June 2026 requiring federal civilian agencies to remediate or mitigate certain high-risk vulnerabilities within three days, citing the potential for AI to further accelerate exploitation.

Implications for organizations

Remediation timelines built around 30-day service levels need to reflect how quickly a published fix can now be turned into a working exploit. Organizations should:

• Treat the publication of a fix, including source code changes in open-source projects, as the start of the exposure window rather than a milestone toward a 30-day deadline.

• Set remediation timelines by exposure and exploitability rather than severity scores alone, with the shortest timelines for internet-facing systems where exploitation could give an attacker control.

• For systems that can’t be patched on that timeline, prepare temporary protections that can be deployed within hours of a fix being published.

• Use AI-assisted tools defensively to assess quickly whether newly patched vulnerabilities are reachable and exploitable in their own environments.

Strains on validation and remediation capacity

AI-assisted research can increase vulnerability reports faster than organizations can validate findings and develop reliable fixes, straining specialized expertise and creating operational tradeoffs. The PHP Foundation reported publishing 15 vulnerabilities since July 1, 2026, while processing more than 100 additional reports that were invalid, duplicative, or not reproducible. It linked increased reporting volume to AI-assisted research.

AI can help evaluate and prioritize findings, but remediation still requires human judgment, particularly when changes could disrupt critical applications.

Implications for organizations

Faster discovery has limited benefit if businesses can’t absorb the remediation workload. Organizations should:

• Build capacity for concurrent high-severity vulnerability responses rather than assuming critical patches will arrive sequentially.

• Establish clear escalation routes when remediation is delayed by compatibility, operational, or ownership disputes.

• Use AI-assisted tools to accelerate triage, duplicate detection, technical analysis, and exposure assessment, while retaining human review for consequential decisions.

• Review and apply vendor-published patches for enterprise applications within defined timelines, and document risk decisions for any that are deferred.

• After patching, confirm security configurations haven’t drifted from approved, hardened baselines and run regression tests on critical business processes and security controls.

More intelligence isn’t always better

As vulnerability research accelerates, available intelligence can outpace the ability to verify its accuracy. Before official disclosure, technical claims circulated widely. One researcher’s claimed exploit attracted approximately 2.6 million views before a significant flaw was identified. VulnCheck found hundreds of purported exploit demonstrations on GitHub, only a small proportion of which represented legitimate techniques.

Yet dismissing questionable research carried risks of its own. By October 22, VulnCheck confirmed a working exploit that overcame technical limitations previously thought to constrain attackers.

For business leaders, this creates a difficult balance: acting on unverified intelligence can divert resources and disrupt operations, while waiting for definitive confirmation can leave organizations exposed.

Implications for organizations

Security teams shouldn’t treat every public claim as technically verified or dismiss every unverified one. Organizations should:

• Distinguish confirmed vulnerabilities and demonstrated exploitability from unverified proof-of-concept claims.

• Separate observed exploitation attempts from confirmed compromise, and communicate remaining uncertainties.

• Prioritize authoritative advisories, validated research, and observed activity, while communicating confidence and unresolved questions.

That precision helps avoid both overreacting to flawed intelligence and underreacting to critical threats.

Organizations are faced with addressing critical vulnerabilities while maintaining essential operations. Preemptive security, put into practice through CTEM, organizes that work around complementary capabilities: knowing where exposure lies, buying time by breaking reachability or exploitability, making permanent fixes safe to deploy quickly, limiting the consequences of exploitation, investigating when prevention fails, and speeding up decisions.

Know where exposure lies. CTEM depends on an accurate, current view of every instance of a vulnerable component, including those embedded in vendor appliances and managed services, and of the paths that connect it to critical systems. Vulnerability prioritization should reflect what attackers can reach and exploit, and should be validated rather than assumed. 

In the PHP case, security researchers reported that some network and server management appliances shipped PHP without standard memory protections, making them among the easiest systems to exploit and often the hardest to patch. A complete view of PHP exposure therefore had to include container images, managed hosting services, and appliances, as well as web servers, with priority given to internet-facing systems and widely used standard builds, where exploitation was most feasible.

Buy back time by breaking reachability or exploitability. Production patches may be delayed when critical services require coordinated testing. Temporary protections, including web application firewall rules, configuration changes, and workload isolation, can reduce your exposure while remediation proceeds by removing a condition an attack depends on.

• Some protections break reachability, most immediately through web application firewall and other edge security rules. These include managed rules that providers can deploy across their customers before official fixes are released, as well as by restricting servers to approved traffic, removing management interfaces from the internet, and isolating workloads.

• Others break exploitability, such as configuration changes, request size limits, and restrictions on what a compromised process can run. Protections that are tested in advance and can be deployed centrally, through edge services, configuration management, and policy tools, are far more useful than changes made server by server, since their value depends on how quickly and widely they can be applied.

PHP advisories describe mitigations that interrupt particular attack paths but may create availability tradeoffs or leave other variants exposed. Temporary controls need testing and cannot substitute for vendor fixes.

Make patching safe enough to be fast. Many patch delays reflect a lack of confidence rather than a lack of urgency, as teams hesitate to change production systems they can’t easily test or roll back. Investment in resilient infrastructure, such as standardized, image-based deployments, automated regression testing, staged rollouts, and reliable rollback, addresses that hesitation directly. It allows an organization to apply fixes and emergency mitigations in hours or days rather than weeks, with less risk to operations.

Three approaches put this into practice. 1) Platform as a service (PaaS) and other managed platforms shift responsibility for patching runtimes such as PHP to the provider; during the PHP incident, some hosting providers applied fixes before the public release. But an organization still needs to know which applications rely on those services and confirm that providers have acted. 2) Containerization allows teams to rebuild images on a fixed base image and redeploy rather than modify servers in place, provided they maintain an inventory of the images in use. 3) Infrastructure as code (IaC) defines servers, network rules, and security settings in version-controlled templates, so that a fix or temporary protection can be applied consistently across environments, reviewed before release, and reversed if it disrupts operations.

Because these approaches standardize environments, they also concentrate risk. Analysis of the PHP vulnerabilities found reliable exploitation most feasible against widely used, identical builds such as official container images, where an attacker could prepare an exploit once and reuse it. The same uniformity lets you patch at scale, provided you can rebuild and redeploy quickly and preserve forensic evidence before replacing affected systems.

Limit the consequences of exploitation. Defense in depth is particularly important in cases such as PHP, where the attack could succeed before any application code ran. That left application-level controls such as authentication ineffective and put the burden of limiting damage on the layers around the affected system. Remote code execution doesn’t automatically imply enterprise-wide compromise. The impact depends on the privileges, credentials, and network access available to the affected component. Restrict service accounts, isolate workloads, and reduce unnecessary access. Because access may drift over time, verify after every patch, upgrade, or design change that application roles and permissions still reflect least privilege to limit exposure to threats.

Enterprise applications such as enterprise resource planning (ERP), HR systems, and supply chain platforms show why. Their cores generally aren’t built on PHP, but surrounding portals and integration tools often are. A compromised server can expose the credentials, trusted connections, service accounts, and AI agents connected to these applications, giving attackers a trusted path into payments, payroll, and supply chain data. Limit these accounts’ access, rotate credentials regularly, and ensure security is addressed within each application at each security layer. Deploy automated technologies to continuously monitor application security access to reduce threats to your core enterprise systems.

Detect and investigate beyond known signatures. Investigations should correlate suspicious requests with runtime behavior, endpoint telemetry, unexpected process execution, and anomalous connections. Retrospective review should include the period before public disclosure. It should also extend into enterprise business applications, where security events, user activity, and change monitoring can reveal unauthorized changes to security configurations, users, roles, and integration credentials, or high-risk transactions such as altered supplier bank details.

Speed up decision-making. Delays often stem from uncertainty about affected assets, ownership, approval authority, or the acceptable impact of emergency changes. A CTEM program allows organizations to establish pre-authorized response options, clear business tradeoffs, and named owners for internet-facing systems in advance, turning credible intelligence into protective action without avoidable delay.

The PHP case shows how AI-accelerated research, disrupted disclosure, pre-disclosure exploitation attempts, and rapidly changing intelligence can converge. Security and business leaders should be able to answer these questions:

• How quickly can we identify every instance of a vulnerable runtime across our environment, including test, development, and disaster recovery copies?

• Can we reduce exposure and contain affected systems before a permanent fix is deployed, while keeping the business running?

• How quickly can we deploy temporary protections across every affected system once a fix is published, and do our remediation timelines still assume we have weeks?

• Can we patch, test, and roll back our most critical internet-facing systems within days without disrupting operations?

• Do we retain the logs, telemetry, and other evidence needed to investigate an intrusion after the fact, including exploitation that began before a vulnerability was publicly announced?

• How do we distinguish validated exploitation techniques from viral but unreliable research?

• Can our engineering, vulnerability management, and incident response teams handle several concurrent critical vulnerabilities?

• Do we know which credentials, service accounts, integrations, and AI agents connect internet-facing systems to our core enterprise applications, and would we detect their misuse?

Organizations need the capacity to assess intelligence, identify exposure, and implement protections quickly, as an established part of a proactive CTEM program rather than an emergency response, while retaining the ability to withstand and investigate exploitation. As new workloads, integrations, and AI capabilities come online, organizations should also keep reassessing security controls at every layer, from infrastructure to applications.