Our Blog

Is AI Making Exploitation Faster?
Featured

Is AI Making Vulnerability Exploitation Faster? What the Evidence Shows | HackerStorm

 

 

Subscribe to get these articles directly to your inbox when published

 

 

 

PHP2Shell illustrates how quickly vulnerabilities can be targeted, but it does not prove AI was involved.

 

Bottom Line for Security Leaders: Public evidence does not show that AI has measurably accelerated vulnerability exploitation across the threat landscape. Individual cases show that AI-assisted vulnerability discovery, a zero-day exploit believed to be AI-developed, and AI agent-driven intrusions are operationally feasible. Exploitation timelines were already compressing before generative AI was widely available. Defenders should focus on exposure reduction, behaviour-based detection and patch velocity, controls that address compressed attack windows whether an attacker uses generative AI or conventional tooling.

 

As of 30th October 2026. This article covers vulnerability exploitation only. It does not assess phishing, social engineering or deepfakes. PHP2Shell reporting is still developing, so details of the incident may change after this date. The article’s central question, whether the evidence shows AI is speeding up exploitation, rests on broader data and does not depend on any single incident.

 

hackerstorm Dynamic Intelligence

Need live data on specific KEVs ?

Lookup scores, news, poc's, threat intel, vendor advisory status, and exploit vectors in real time.

 

On 21 October 2026, the PHP project released emergency fixes for two serious security vulnerabilities, collectively known as PHP2Shell. PHP is used to run parts of websites and web applications. On affected, unpatched systems, the flaws could allow an attacker to run their own code on a server without logging in. The vulnerabilities were rated 9.2 out of 10 under the CVSS v4.0 severity scale.

 

What made PHP2Shell particularly notable was the speed of events around it. A reported attack attempt preceded public disclosure; scanning and further attack attempts followed around the time fixes became available; and a researcher subsequently demonstrated successful exploitation against a honeypot (a decoy system set up to observe attackers). On 26 October, CISA added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalogue, a list of flaws it considers actively exploited. These events show why defenders cannot assume they have days or weeks to respond to a serious vulnerability.

 

But they do not answer a bigger question: is artificial intelligence making it easier for attackers to find vulnerabilities, develop working exploits and carry out intrusions faster? PHP2Shell is a useful case study in compressed attack timelines, but the available reporting does not establish that AI was involved in discovering or exploiting these particular flaws.

 

To answer the wider question, we need to look beyond one incident: at historical exploitation trends, documented cases of AI-assisted cyber activity, and evidence that could distinguish a genuine change in attacker capability from the automation and rapid exploitation that already existed before generative AI.

 

Key takeaways

 

■ Verdict: AI plausibly helps attackers at the margin, but the evidence does not show it has measurably sped up exploitation overall.

 

■ Exploitation was already fast before generative AI. Mandiant’s average time-to-exploit fell from 63 days (2018-2019) to 32 days (2021-2022).

 

■ PHP2Shell shows how quickly events can move: leak on 20 October, CISA KEV listing on 26 October. Public reporting does not show AI was involved.

 

■ AI use by attackers is documented: GTIG reported a criminal actor with a zero-day exploit believed to be AI-developed (May 2026), and OALABS documented an AI-agent campaign against at least 14 companies. These show capability, not prevalence.

 

■ Defenders should reduce exposure, patch high-risk internet-facing systems quickly and monitor behaviour. This works whether or not AI is involved.

 

PHP2Shell: What Happened and Why It Matters

 

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. CVE identifiers are the standard public reference numbers for disclosed vulnerabilities. Both are memory-safety flaws, meaning errors in how PHP handles memory, and both allow remote code execution (RCE): an unauthenticated attacker can run arbitrary code on PHP installations serving web requests on unpatched releases, according to watchTowr intelligence. The releases fixing these two PHP2Shell vulnerabilities are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These version numbers relate specifically to CVE-2026-109618 and CVE-2026-109619; administrators should also check subsequent PHP security advisories for any additional issues. Reported activity falls into three distinct tiers: scanning (searching the internet for vulnerable systems), exploitation attempts (trying to trigger the flaw), and demonstrated successful exploitation. The timeline below keeps them separate.

 

Date (2026) Tier Event
11 and 24 August Disclosure Calif reported the first bug to PHP on 11 August, and Wiz Research reported the vulnerabilities on 24 August, according to Sansec's timeline.
17 October Exploitation attempt Amazon Threat Intelligence reported a pre-disclosure attempt against a honeypot, four days before public disclosure, per Tenable.
20 October Disclosure (leak) Details leaked ahead of the coordinated disclosure, and watchTowr publicly confirmed the flaws were real.
21 October Exploitation attempts and scanning Cloudflare reported attack traffic at 07:43 UTC, after the 20 October leak but before the official patch release at 14:00 UTC, per Sansec. watchTowr reported attempts against both CVEs at 14:19 UTC, per The Hacker News. Threat telemetry documented scanning activity the same day using the user agent “php2shell-scan/109618”, per VulnCheck analysis.
24 October Demonstrated exploitation (honeypot) Researcher Adel Karimi reported successful RCE against honeypots running PHP 8.4.26, consistent with CVE-2026-109618 only and in a favourable single-worker configuration, per The Register. This shows the exploit can work under favourable conditions. It is not a confirmed compromise of a production system.
26 October CISA KEV listing CISA added both CVEs to its KEV catalogue, as documented by Tenable. CISA set a remediation deadline of 29 October for Federal Civilian Executive Branch (FCEB) agencies under Binding Operational Directive (BOD) 26-04, which sets deadlines for US federal civilian agencies. CISA urged other organisations to prioritise the fixes, but the deadline did not bind them.

Related notes

Retracted attribution (23 and 25 October): Palo Alto Networks Unit 42 linked an intrusion at a European government agency to PHP2Shell on 23 October, then retracted the link on 25 October, stating it could not confirm initial access came through the PHP2Shell CVEs, per The Hacker News.

Separate PHP advisory (23 October): PHP disclosed a separate, narrowly scoped session flaw, CVE-2026-115560, per Tenable. It is not one of the two PHP2Shell CVEs, and the 21 October releases do not fix it. At the time of reporting, no exploitation had been reported, and PHP said the fix would ship in its next routine bugfix release, per SOCRadar. Check PHP’s security advisories for the current status.

 

The KEV listing confirms CISA considers both CVEs actively exploited. It does not establish how many production systems were compromised, and CISA has not disclosed affected organisations. For defenders, the sequence matters more than the bug class: attack attempts were reported before fixes were available, which left no safe interval between public knowledge of the flaws and the first attack traffic.

 

What PHP2Shell Proves, and What It Does Not

 

PHP2Shell demonstrates how quickly events can unfold. From the leak on 20 October to CISA's KEV listing on 26 October, scanning, exploitation attempts and a successful demonstration against a honeypot were reported within six days. A separate attack attempt had reportedly occurred on 17 October, before public disclosure. The sequence demonstrates the urgency of responding to serious vulnerabilities, but does not establish that AI was involved. Public reporting has not detailed confirmed compromises of specific production systems.

 

PHP2Shell does not, by itself, prove AI involvement. The sources cited here do not attribute the discovery of these two CVEs, or any confirmed exploitation of them, to AI tooling. Unit 42's retracted report described AI tooling used after initial access, in an intrusion it can no longer tie to PHP2Shell. Internet-wide scanning tools such as ZMap were presented at USENIX Security in 2013 (able to scan every public internet address in under 45 minutes), years before generative AI, so rapid scanning after disclosure is not new.

 

A common analytical error is treating every fast exploitation event as evidence of AI involvement. Speed alone tells you nothing about the tooling behind it.

 

PHP2Shell works as a case study because it forces the question in context. If AI is accelerating exploitation, cases like PHP2Shell are worth investigating, but establishing AI's role requires evidence about the tools and techniques used, not just the speed of events. The evidence for the broader claim lives elsewhere.

 

The Baseline: Exploitation Was Already Fast

 

Any claim about AI changing exploitation has to clear a high historical bar. The compression of time-to-exploit started long before large language models. The series below uses a single source and definition: Mandiant's time-to-exploit (TTE) metric, the average time taken to exploit a vulnerability before or after a patch is released (Mandiant 2023 TTE analysis, published October 2024).

 

■ 2018-2019: average time-to-exploit stood at 63 days.

 

■ 2020-2021: 44 days.

 

■ 2021-2022: 32 days.

 

■ 2023: 5 days after Mandiant removed 15 statistical outliers, 47 days with outliers included. Of 138 exploited vulnerabilities disclosed in 2023, 97 (70%) were first exploited as zero-days and 41 (30%) as n-days. A zero-day is exploited before a fix is available; an n-day is exploited after a fix has been released. Mandiant reported that 12% of the n-day vulnerabilities in its 2023 sample were exploited within one day, per the Mandiant 2023 TTE analysis.

 

The series ends at 2023, the period covered by the Mandiant analysis used here. Newer time-to-exploit figures are not included.

 

Two caveats apply. The 2023 figure is outlier-adjusted, and Mandiant's analysis attributes part of the decline to the zero-day share of the sample. Even so, the decline from 63 to 32 days occurred across periods that predate broad availability of generative AI tools. Other vendors publish time-to-exploit series built on different datasets and definitions. Those series are not directly comparable to Mandiant's and are excluded here.

 

This baseline reframes the question. The useful inquiry asks whether AI adds measurable acceleration on top of an already compressed curve, and whether it changes who can operate at that speed.

 

What Researchers Have Actually Reported

 

Several key findings below come from security vendors (GTIG, watchTowr) that have a commercial interest in the topic. Their reporting is presented as their own assessment, and several of the AI claims rest on a single source.

 

Three categories of reporting deserve separation: documented AI use, measured aggregate shifts, and single incidents. A fourth distinction cuts across all three: AI-assisted discovery by security researchers, which ends in coordinated disclosure, is different from AI use by threat actors. Evidence of one does not demonstrate the other.

 

Documented AI use in exploitation

 

Google Threat Intelligence Group identified the first threat actor using a zero-day exploit believed to be developed with AI in May 2026. The criminal actor planned a mass exploitation event. Google's proactive discovery may have prevented deployment, per GTIG reporting.

 

 

“AI can review the underlying logic, context, and flow of code at scale to discover vulnerabilities. It can also be used to build working exploits which are a significant hurdle.”

John Hultquist, Chief Analyst, Google Threat Intelligence Group, in an email to Cybersecurity Dive

 

 

Ryan Dewhurst, watchTowr's Head of Threat Intelligence, framed the operational reality in a statement to The Hacker News: “AI is already accelerating vulnerability discovery, reducing the effort needed to identify, validate, and weaponize flaws.”

 

Measured aggregate shifts

 

GTIG analysed vulnerabilities disclosed from January 2025 to August 2026, per GTIG trend data. Two findings need separating. AI-assisted discovery: in a subset of disclosed CVEs that GTIG identified as likely AI-discovered, 58% rated Medium risk versus 28% for other CVEs, and 50% led to remote code execution versus 26%. GTIG built this subset with heuristics, because standardised metadata on AI involvement in discovery does not exist. The sample covers disclosed vulnerabilities and does not show threat actors using AI to find bugs. AI-stack vulnerabilities: GTIG separately tracked 2,076 cumulative AI-related CVE disclosures over the same window, more than 1,500 of them in 2026. The figure counts vulnerabilities affecting the AI/LLM operational stack, roughly half in orchestration frameworks. It does not count vulnerabilities discovered by AI. GTIG reports only a handful of the 2,076 confirmed as exploited in the wild.

 

GTIG also reported that in-the-wild exploitation rose from an average of 10.5 vulnerabilities per month in 2025 to 18 per month from January to August 2026. GTIG attributes that growth primarily to rapid weaponisation of previously disclosed, high-risk vulnerabilities rather than a major rise in zero-day exploitation. GTIG has confirmed in-the-wild exploitation of some AI-discovered vulnerabilities after disclosure, which it describes as an early indicator rather than an established trend. The exploitation increase coincides with wider AI adoption. The data does not establish that AI caused it, and disclosure volume may also have risen over the same period.

 

Single incidents, which prove capability rather than trend

 

Between February and June 2026, an attacker used copied installations of Claude Code and OpenAI's Codex to breach at least 14 companies. OALABS researchers documented the campaign from more than 1,000 recovered agent sessions, per OALABS research. The AI agents handled reconnaissance, exploit development, credential harvesting, and exfiltration. OALABS reported that in many cases the attacker supplied only “vague, low-skill prompts” and let the agent fill in the gaps. The logs did not confirm that the attacker monetised stolen data.

 

One operation demonstrates feasibility. It does not establish prevalence.

 

Where AI Touches the Attack Lifecycle

 

A precise assessment maps AI's influence stage by stage, and the confidence level differs at each stage.

 

Lifecycle stage Evidence strength What the evidence shows What it does not show
Vulnerability discovery Strongest, and it comes from disclosed vulnerabilities GTIG's likely-AI-discovered sample shows AI-assisted discovery producing real bugs, including RCE-class flaws, that reached disclosure. It does not show threat actors using AI for discovery. Threat-actor interest is reported by GTIG for specific nation-state groups, without published measurement of results. AI discovering a novel vulnerability differs from AI helping an attacker exploit an already-published one, and conflating them inflates the threat picture.
Exploit development Moderate and growing GTIG's May 2026 finding and Hultquist's assessment indicate working exploits are achievable. Historically, exploit development demanded specialised expertise and significant time. GTIG assesses that AI lowers that barrier, per GTIG analysis. The size of that reduction has not been measured across a broad sample.
Target selection and reconnaissance One reported campaign The reported 14-company campaign shows agents handling reconnaissance. Automated scanning existed long before this, so the potential change is lower operator effort. One reported campaign does not establish how widely that reduction applies.
Operational execution and post-exploitation Thinnest The OALABS-documented campaign shows credential harvesting and exfiltration handled by agents. This remains a small number of documented cases. Claims of fully autonomous end-to-end operations remain speculative.

 

 

Who Benefits, by Actor Class

 

The impact distributes unevenly across the threat landscape.

 

Actor class What the evidence shows What it does not show
Nation-state groups GTIG reports that actors associated with China and North Korea have demonstrated significant interest in AI for vulnerability discovery. For teams that already employ elite exploit developers, AI would plausibly deliver marginal efficiency rather than new capability. Interest is not demonstrated adoption, and GTIG has not published measured results of that use. Attribution here comes from GTIG and should be treated as their assessment.
Established cybercriminals The May 2026 zero-day case involved a criminal actor planning mass exploitation. For this tier, AI may compress the window between disclosure and weaponisation. That would matter for n-day exploitation, which Flashpoint reports accounts for over 80% of the known exploited vulnerabilities it tracked over the past four years, per Flashpoint research. This is Flashpoint's dataset, not CISA's KEV catalogue. Aggregate measurement of AI-driven compression for this actor class is not yet available.
Initial access brokers Faster weaponisation of fresh CVEs would expand sellable inventory. Mandiant's M-Trends 2025 report, covering 2024 investigations, found exploitation to be the most common initial infection vector for the fifth consecutive year, at 33% of investigations. Brokers who adopt AI-assisted exploitation at scale would feed that pipeline. Published evidence of that adoption remains limited.
Low-skill attackers This is where the potential change looks most significant, and where the evidence base is narrowest. OALABS reported that the attacker behind the 14-company campaign often supplied only “vague, low-skill prompts”, which indicates that in at least one case, AI agents carried out operations that would otherwise have required more expertise. A single reported campaign does not show that sophisticated exploitation is now broadly accessible to low-skill attackers, or how reliably such operations succeed. One plausible reading, which is this article’s inference rather than a finding in the sources, is a lower barrier to entry without a higher capability ceiling. Confirming it requires repeated, independently verified cases.

 

What Defenders Should Change

 

The response follows from the evidence rather than from the hype. Prioritised by role:

 

Security teams

 

■ Scale response windows to risk. For internet-facing, unauthenticated RCE with public exploit code, credible leak information, or observed attack attempts, plan for exploitation before or within hours to days of official disclosure. PHP2Shell drew a reported pre-disclosure attempt, then attack traffic and scanning before the official patch release. For flaws with lower exposure or exploitability, standard patch cycles remain proportionate. For high-risk cases, build detection for exploitation of newly disclosed CVEs, including scanner user agents and anomalous request patterns, before patches deploy.

 

■ Shift weight towards behaviour-based monitoring. Post-compromise activity such as credential access, lateral movement and exfiltration can be observed regardless of how the initial exploit was built. Monitoring for it does not depend on knowing whether AI was involved.

 

■ Instrument internet-facing services first. Exploitation led initial infection vectors for the fifth consecutive year in Mandiant's M-Trends 2025 data. Internet-facing services are where the compressed timelines bite.

 

■ For PHP2Shell specifically: inventory PHP versions across hosting, containers and CMS stacks. Confirm systems run the fixed release for their branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35). Search web and proxy logs from 17 October onwards for the scanner user agent “php2shell-scan/109618”, and for other attack attempts against PHP endpoints.

 

Vulnerability managers

 

■ Prioritise on combined signals, not on any single metric. Weigh evidence of active exploitation (KEV listing, vendor and honeypot telemetry), exposure (internet-facing, unauthenticated reachability), exploitability (public exploit code, attack complexity), and business impact of the affected asset. Raw CVSS severity scores alone do not capture these factors. PHP2Shell scored high on all four: a reported pre-disclosure attempt, broad internet exposure, remote code execution without login (pre-authentication RCE), and a KEV listing five days after the 21 October patch release.

 

■ Prioritise carefully as AI-assisted discovery adds to the pipeline. In GTIG’s likely-AI-discovered sample, a higher share of CVEs were rated Medium risk (58% versus 28% for other CVEs) and a higher share led to remote code execution (50% versus 26%). Separately, the 2,076 AI-related CVEs GTIG tracked from January 2025 to August 2026 mark the AI/LLM stack itself as a growing patching surface for organisations running those systems. Reducing exposure shrinks what has to be triaged; strict prioritisation handles what remains.

 

■ Define emergency patch timelines for high-risk, internet-facing systems. The three-day FCEB deadline for PHP2Shell (26 October to 29 October) was a federal requirement under BOD 26-04 and bound only those agencies. For other organisations, it is a reference point for critical, actively exploited pre-authentication RCE, not a universal standard. Set internal targets according to exposure, exploitability, and business impact.

 

Executives

 

■ Fund exposure reduction before AI-specific defences. The attacks documented here exploit ordinary unpatched software. Attack surface reduction, asset inventory and patch velocity address AI-assisted and conventional exploitation alike. Three questions to put to security leadership:

 

◦ What is our time-to-patch for internet-facing systems, and how has it changed?

 

◦ Do we have a current inventory of PHP and other web runtimes, including hosting, containers and CMS platforms?

 

◦ Who owns emergency patching, and is there a defined process for out-of-cycle fixes?

 

One caution on PHP2Shell specifically: current reporting documents reported exploitation attempts and scanning activity, a demonstrated exploit against a honeypot, and a CISA KEV listing. Public reporting has not detailed confirmed compromises of specific production organisations, and one attributed intrusion claim was retracted. No published evidence supports framing it as a sustained APT campaign. Defenders should patch and monitor without inventing an adversary narrative the data does not contain.

 

Evidence That Would Strengthen or Weaken the Argument

 

The claim that AI is changing exploitation remains partially supported. These indicators would help establish whether AI is changing exploitation patterns over the next 12 to 24 months.

 

Evidence that would support it:

 

■ Sustained decline in median time-to-exploit beyond the pre-AI trend line, measured across the full KEV population rather than headline cases.

 

■ Repeated, independently verified campaigns where AI agents handle multiple lifecycle stages, moving the 14-company incident from anomaly to category.

 

■ Growth in the share of CVEs attributed to AI-assisted discovery, paired with a rising share of those CVEs reaching active exploitation.

 

■ Exploit broker and access broker pricing shifts consistent with cheaper, faster weaponisation.

 

Evidence that would challenge it:

 

■ Time-to-exploit metrics plateauing at levels explained by pre-2023 automation trends.

 

■ AI-discovered CVEs skewing towards low-severity, hard-to-weaponise bug classes even as their volume grows.

 

■ Documented AI-assisted operations failing at the execution stage, indicating the hard parts of intrusion still require human skill.

 

The disciplined position, as of this article’s date, separates three things.

 

Observed: AI-assisted discovery that ends in public disclosure produces a higher share of RCE flaws, according to GTIG’s heuristic sample. GTIG has documented one threat actor with a zero-day exploit believed to be AI-developed. In one reported campaign, AI agents ran large portions of an intrusion from low-skill prompts.

 

Plausible: AI lowers the effort needed for exploit development and reconnaissance, with the largest relative effect on less skilled operators.

 

Unresolved: whether AI has measurably accelerated exploitation across the threat landscape. GTIG reported that in-the-wild exploitation rose from an average of 10.5 vulnerabilities per month in 2025 to 18 per month from January to August 2026, but that coincides with AI adoption and a possible rise in disclosures. GTIG attributes it mainly to faster n-day weaponisation without isolating AI as the cause, and time-to-exploit was already falling before generative AI.

 

PHP2Shell shows how the question arises: inside compressed timelines where AI-assisted and conventionally automated attacks look the same in a defender’s logs. Defences should work either way. Teams that prioritise by exploitation, exposure, exploitability and impact, monitor behaviour and track the indicators above will be well positioned whatever the evidence ultimately shows.

 

 

What you should do next

 

Further reading to ensure you understand other related intelligence for learning and improving.

 

 

More Security Intelligence

 

Stay informed with our weekly analysis of CISA Known Exploited Vulnerabilities (KEVs), including exploitation context, risk indicators and remediation priorities

 

 

 

hackerstorm Dynamic Intelligence

Need live data on specific KEVs ?

Lookup scores, news, poc's, threat intel, vendor advisory status, and exploit vectors in real time.

 


About This Report

 

Reading Time: Approximately 15 minutes

 

Attribution Note

This analysis is based on publicly available reporting and security research summaries. Some technical details may change as additional information becomes available.

 

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

 

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

  • Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
  • Source Transparency: Original research sources and citations are provided in the References section below
  • No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
  • Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections


Learn More: About Hackerstorm.com | FAQs

 

Glossary

 

■ CVE: the standard public reference number for a disclosed vulnerability.

 

■ CVSS: a severity scale that rates vulnerabilities out of 10.

 

■ KEV: CISA’s Known Exploited Vulnerabilities catalogue, a list of flaws it considers actively exploited.

 

■ RCE: remote code execution, a flaw that lets an attacker run their own code on a system remotely.

 

■ Zero-day: a vulnerability exploited before a fix is available.

 

■ N-day: a vulnerability exploited after a fix has been released.

 

■ Honeypot: a decoy system set up to observe attackers.

 

■ BOD: Binding Operational Directive, which sets deadlines for US federal civilian agencies.

 

■ FCEB: Federal Civilian Executive Branch agencies, the US federal civilian agencies bound by BOD deadlines.

 

Sources

 

■ Sansec, PHP2Shell research and disclosure timeline: https://sansec.io/research/php2shell

 

■ watchTowr, PHP2Shell intelligence: https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/

 

■ Tenable, PHP2Shell FAQ: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

 

■ SOCRadar, PHP2Shell affected versions, fixes and CVE-2026-115560 advisory: https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/

 

■ The Hacker News, PHP emergency patches and exploitation attempts: https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html

 

■ VulnCheck, PHP2Shell analysis: https://www.vulncheck.com/blog/php2shell-vulnerabilities

 

■ The Register, CISA KEV listing and honeypot exploitation: https://www.theregister.com/cyber-crime/2026/10/27/cisa-confirms-php2shell-under-attack-as-researchers-clock-successful-exploits/5305681

 

■ The Hacker News, Unit 42 retraction: https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html

 

■ Mandiant, 2023 time-to-exploit analysis: https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023

 

■ GTIG, AI-developed zero-day exploit and initial access: https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

 

■ Cybersecurity Dive, John Hultquist statement: https://www.cybersecuritydive.com/news/ai-working-zero-day-exploit-GTIG/819848/

 

■ The Hacker News, Ryan Dewhurst statement: https://thehackernews.com/2026/05/hackers-used-ai-to-develop-first-known.html

 

■ GTIG, vulnerability discovery and exploitation trends in the AI era: https://cloud.google.com/blog/topics/threat-intelligence/vulnerability-discovery-and-exploitation-trends-in-the-ai-era

 

■ GTIG, defending enterprise AI vulnerabilities: https://cloud.google.com/blog/topics/threat-intelligence/defending-enterprise-ai-vulnerabilities

 

■ OALABS, captured logs of the Claude and Codex 14-company campaign: https://research.openanalysis.net/claude/codex/hacking/ai%20hacking/llm/redteam/policy%20violation/2026/06/16/compromised-claude-hacking.html

 

■ Flashpoint, n-day vulnerability trends: https://flashpoint.io/blog/n-day-vulnerability-trends-turn-key-exploitation/

 

■ Mandiant, M-Trends 2025 full report (PDF): https://services.google.com/fh/files/misc/m-trends-2025-en.pdf

 

■ Mandiant, M-Trends 2025 executive edition (PDF): https://services.google.com/fh/files/misc/m-trends-2025-executive-edition-en.pdf

 

■ Google Cloud, M-Trends 2025 blog post: https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025

 

■ USENIX Security 2013, ZMap: Fast Internet-Wide Scanning and Its Security Applications (Durumeric et al.): https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_durumeric.pdf

 

 

 

 

By using this site, you agree to our Terms & Conditions.

COOKIE / PRIVACY POLICY: This website uses essential cookies required for basic site functionality. We also use analytics cookies to understand how the website is used. We do not use cookies for marketing or personalization, and we do not sell or share any personal data with third parties.

Terms & Privacy Policy