AI Is Accelerating Cybersecurity. But Who Is Moving Faster? Attackers or Defenders?

You open your laptop, ready to fix one small bug before lunch. Three security alerts have other plans. Update PHP. Check whether yesterday’s package was malicious. Rotate those cloud credentials. Your code has not changed. Your tests are green. Apparently, your afternoon has changed. Then someone drops the inevitable question into the team chat: “Is this because of AI?”

Sometimes, yes. Sometimes, AI helped find the problem. Sometimes, the connection is simply that the company being attacked sells AI tools. And sometimes, we are giving AI credit for a security failure we have been perfectly capable of producing for years.

AI is accelerating useful work for both attackers and defenders. Public evidence does not establish a universal winner. The practical concern is that faster technical work can leave teams less time to identify exposure or revoke a credential. My assessment is that the decisive gap is increasingly between the speed of technical capability and the speed of operational response.

That is my reading of the evidence, not a global scoreboard. Before declaring a winner, I want to know what actually happened and where AI entered the story.

Where AI fits into the story

When I read a security story, I try to work out which job AI was doing:

• AI as investigator: a researcher uses models to find, understand, or reproduce a weakness.
• AI as attacker assistance: an operator uses models for reconnaissance, tooling, analysis, or parts of an intrusion.
• AI tools as an exposed capability: malicious code attempts to invoke an agent already installed in a trusted environment.
• AI infrastructure as the target: attackers pursue platforms, credentials, or distribution channels supporting AI applications.
• No demonstrated AI involvement: a serious incident happens during the AI era, but its explanation does not require AI.

These categories can overlap. They are questions about mechanism, not labels that prove causation. An attack against an AI company does not establish that the attacker used AI. An AI-discovered bug does not establish that AI wrote the vulnerable code.

PHP2Shell: how AI helped uncover old vulnerabilities

Wiz’s 21 October research describes frontier models helping researchers turn longstanding PHP memory-safety weaknesses into working exploits. The team reports adapting exploits across applications in hours. That is evidence of AI-assisted research in this investigation; it is not a controlled estimate of how much faster all researchers or attackers have become.

The original PHP2Shell pair is CVE-2026-109618, involving out-of-memory corruption, and CVE-2026-109619, involving stale global state across requests. The weaknesses sit in the runtime beneath applications, the part of the stack your beautifully reviewed pull request does not fix. Researchers demonstrated remote code execution on representative deployments and also demonstrated process-memory disclosure. See the researchers’ technical summary.

Use the published severity, not the early rumor: PHP’s OOM advisory gives a critical CVSS v4.0 score of 9.2. It also explains that exploit reliability depends on the build, extensions, frontend behavior, and memory layout. A critical rating warrants urgent remediation; it does not mean every deployment is equally easy to compromise.

Similarly, PHP’s large share of website technology is not a count of exploitable or compromised websites. A claim that “70% of the internet was hacked” would confuse technology prevalence, vulnerable versions, reachable attack paths, and actual intrusion outcomes.

PHP2Shell’s disclosure and exploitation timeline

• 17 October: AWS says its MadPot honeypots recorded a PHP2Shell exploitation attempt.
• 20 October: PHP published an advance notice of the emergency security release.
• 21 October, 02:00–08:00 UTC: AWS reports additional attempts before the scheduled embargo lift.
• 21 October, 14:00 UTC: the coordinated disclosure and patch release occurred; AWS reports further proof-of-concept activity and attempts soon afterward.
• 23 October: PHP issued a separate informational advisory for CVE-2026-115560.

The telemetry and embargo timing come from Amazon Threat Intelligence’s report; PHP’s news archive records its advance notice and follow-up. AWS’s qualification matters: AWS says it was unclear whether the observed attempts would have succeeded against real-world systems. Honeypot attempts are evidence of targeting, not a confirmed victim count. AWS also says it does not know how the actor obtained exploit information before disclosure. This timeline does not prove AI generated those particular payloads.

For me, the uncomfortable part is the head start. Our team may begin responding when the advisory arrives. An attacker may already be working. So “we patched this morning” answers one question. “Did anything happen before this morning?” deserves its own investigation.

A separate follow-up: CVE-2026-115560

PHP’s 23 October notice identifies CVE-2026-115560: an unusual session configuration can create another potential RCE path. It requires session upload progress to remain enabled and an application to configure php_binary or php_serialize, then switch to php at runtime before session_start(). PHP says applications that never change the handler at runtime can retain the feature.

At the 25 October source check, the notice recommended session.upload_progress.enabled=0 until the next regular bugfix release and said a full advisory would accompany that release. At that point, PHP had not given a complete affected-version range or identified an available fixed release for this follow-up.

For the original pair, PHP’s 21 October advisory names 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as fixed releases. Vendor backports may use other package versions. Updating application code alone does not update its PHP runtime; verify the deployed package and restart affected workers. The follow-up must be tracked separately rather than described as proof that the original fixes did nothing.

This is where I would ask the question nobody enjoys: did we update the running service, or just the Dockerfile?

A merged pull request is reassuring. A forgotten worker still running the old runtime is less interested in our reassurance. “Patched” needs to describe what is actually running.

What real AI-assisted intrusions tell us

Anthropic: the September 2025 espionage campaign

Anthropic’s report, published on 13 November 2025, describes suspicious activity detected in mid-September. It assesses that a Chinese state-sponsored group used Claude Code against roughly 30 targets, succeeding in a small number of cases.

Anthropic estimates AI performed 80–90% of the campaign’s work, with humans retaining critical decisions. That is the provider’s campaign-specific estimate, not an 80–90% intrusion success rate or a measurement of all cybercrime. The report also describes hallucinated credentials and erroneous claims about stolen information.

One correction deserves preservation: Anthropic amended its wording on 14 November to “thousands of requests, often multiple per second.” It did not substantiate thousands of requests per second. The report gives valuable operational visibility, but outsiders cannot independently reconstruct every victim outcome from the public account.

AWS: the January–February 2026 FortiGate campaign

AWS’s 20 February report describes a financially motivated actor using commercial generative AI services in a campaign affecting more than 600 FortiGate devices across over 55 countries between 11 January and 18 February 2026.

AWS says initial access relied on exposed management interfaces and weak credentials with single-factor authentication; it observed no exploitation of FortiGate vulnerabilities. Its investigation found staged tooling and operational material supporting the assessment of AI use. It also records failures against harder targets.

This case supports a narrower, more practical concern than omnipotent autonomous hacking: assistance can help an operator organize and repeat familiar techniques at scale. A count of six hundred devices does not establish six hundred independent victim organizations. The report also does not measure how many devices the actor would have compromised without AI.

These accounts establish that abuse has moved beyond hypothetical demonstrations. They do not establish how common AI-assisted intrusions are across the internet, nor a percentage increase attributable to AI. Providers observe different slices of activity, and successful investigations are not random samples.

Different incidents, different lessons

LiteLLM: an exposed key and a compromised release

LiteLLM’s 23 October canonical investigation supersedes parts of its initial account. Its sequence is instructive:

• 27 May 2026: a master key for its agent platform was committed publicly; removing the commit was not followed by revoking that key.
• 10 October: an attacker used the key to access the platform and obtain an organization owner’s GitHub CLI token.
• 21 October: the attacker manipulated the release process and published malicious LiteLLM 1.107.0 artifacts.
• 23 October: the company published the corrected chain, explicitly replacing earlier assumptions.

The initial theory about tokens coming from internal deployment logs should not be repeated as the established root cause. The canonical account instead identifies an exposed platform key and excessive GitHub authority. The artifact and response notice lists affected packages and containers; exposure depends on what was actually installed or executed, not simply whether a team uses LiteLLM.

What stays with me is the gap between “we removed that key” and “that key no longer works.” Those can feel like the same thing during a busy incident. They are not.

An agent platform holding an organization owner’s token deserves the same nervous attention as any other production control plane. The documented chain gives us plenty to fix without inventing an autonomous AI mastermind.

Nx: malicious packages targeting developer tools

The Nx S1ngularity postmortem dates malicious npm releases to 26 August 2025. A workflow injection enabled publishing-token theft; the packages ran a post-install script that searched for sensitive information, attempted to invoke local AI tools, and uploaded results through the GitHub CLI.

“Attempted to invoke” is the right level of claim. It does not prove every local agent complied or that AI was necessary for the exfiltration. The lesson I draw is about combined authority: dependencies, authenticated command-line tools, source code, and agents can coexist on one developer machine. Their access boundaries deserve to be reviewed together.

Railway and eMudhra: different failures, different responses

Railway’s 21 October disclosure describes possible access to customer environment variables, including some decrypted contents, and recommends credential rotation. It says the company believes the activity targeted AI inference providers. That is a stated targeting assessment; it does not demonstrate AI use by the attackers.

Google’s 20 October eMudhra disclosure describes CA private keys generated with insufficient randomness. It reports receiving the finding on 17 October and deploying Chrome blocking protections that evening. It does not establish AI involvement.

These incidents occurred close together. That proximity does not establish a shared actor, entry point, or cause. Keeping the explanations separate produces better responses: credential containment for one chain, trust-store and certificate remediation for another, runtime updates for PHP.

What cybersecurity benchmarks can tell us

A benchmark score can make an excellent headline. Before I let it ruin my morning, I want to read the small print.

What task did the agent get? What could it see? How many tries did it have?

Cybench contains 40 professional CTF tasks. Its leaderboard includes results on different subsets: for example, the displayed Claude Mythos Preview result is 100% on a 35-problem subset. That is not “AI can hack 100% of real organizations.” The site also documents an answer-leakage problem affecting older model evaluations. Dataset size, exclusions, and evaluation corrections belong beside the score.

CyberGym comprises 1,507 historical vulnerability instances across 188 projects. Its Level 1 leaderboard gives agents a vulnerability description and an unpatched codebase, then tests whether they can produce a working reproducer. The page explains that results are submitted by teams, runs vary, and an instance can count as solved if any allowed trial succeeds.

Reproducing a known flaw with source access is valuable. It differs from finding an unknown entry point in a hardened organization and sustaining an intrusion. Conversely, a failure on one benchmark does not prove a system is harmless in every operational setting.

Before putting two scores on the same chart, I would ask:

• Were the exact same tasks and exclusions used?
• Was the result one attempt or success across several attempts?
• What tools, hints, code, prior knowledge, and execution feedback were available?
• What were the time, token, and monetary budgets?
• Was success a crash, code execution, a patch, or an end-to-end objective?
• Was the result independently reproduced, and could the tasks have leaked?

A useful defender evaluation must go further: did the proposed patch preserve behavior, did detection generate manageable false positives, and did the team deploy safely? Comparing an offensive exploit score with a defensive marketing claim cannot establish which side is improving faster.

What CISA KEV numbers actually measure

The official CISA KEV data snapshot retrieved for this article reports 1,756 entries, catalog version 2026.10.23, released at 19:30:18.9209 UTC on 23 October 2026. That is a dated catalog total, not 1,756 vulnerabilities newly discovered this year or 1,756 intrusions.

KEV records CVE identifiers and dates added; it does not supply a field establishing that AI discovered or exploited each vulnerability. One CVE may affect many victims. Several CVEs may be used in one intrusion. Old vulnerabilities can enter the catalog much later.

Any yearly comparison should therefore count by dateAdded, preserve the snapshot, and compare equivalent periods. A partial 2026 total against all of 2025 would be a poor growth measure. Publication-to-KEV delay is also not time from discovery to first exploitation: it includes visibility and cataloging delays.

The catalog helps teams prioritize known exploitation. It cannot, by itself, answer whether AI is causing more incidents or whether attackers are outperforming defenders.

Why more reports do not prove an AI effect

Put model releases on a timeline. Add vulnerability disclosures. Draw a line going up.

It might look convincing. I would still have questions.

A vulnerability has an introduction date, discovery date, private report date, patch date, and public disclosure date. An intrusion has an initial access date, detection date, and disclosure date. Using whichever dates are easiest to collect can manufacture an apparent relationship.

More disclosures might reflect better defensive discovery. More incident reports might reflect improved visibility. More exposed software or more organizations using agents could increase opportunities even if the risk per deployment stayed constant.

To estimate a causal AI effect, we would need comparable workflows or populations with and without assistance, consistent outcome definitions, exposure denominators, comparable observation periods, and attention to changes in reporting. For offensive and defensive comparisons, we would also need to account for cost, failures, human intervention, and access to tools.

The reports above provide mechanisms and concrete examples. They are not that experiment. The responsible conclusion is that capabilities and operational uses are advancing; the net effect on aggregate security remains insufficiently measured.

So, who is moving faster?

My working hypothesis is that AI creates the greatest advantage where skilled interpretation is the bottleneck and the surrounding workflow is ready to act on the result.

An attacker may benefit when a tool helps interpret an unfamiliar configuration or adapt a script. A defender may benefit when the same kind of help finds a reachable flaw, tests a fix, or turns logs into a useful investigation lead.

Imagine an AI tool finds a serious bug in an hour. Excellent.

Now the team spends three days working out who owns the service, whether it is still in production, and who remembers how to deploy it.

We have made the discovery faster. We have also found the actual bottleneck.

Attackers can pursue softer targets; defenders must decide which exposures matter and verify that containment worked. Defenders also have an opportunity to use context attackers lack: deployment inventories, intended behavior, access records, and the authority to remove an exposed service. Whether that advantage is usable depends on engineering practice.

What engineering teams can do now

1. Measure exposure closure. For an urgent advisory, record when affected running assets were identified, assigned, updated, restarted, and verified. Track the slowest exposed deployment as well as the median.
2. Test credential revocation. Know who can revoke each important key, which services depend on it, and how to verify old credentials no longer work. Removing a secret from source history is not revocation.
3. Reduce agent authority. Give development and analysis agents narrowly scoped identities, isolated workspaces, limited network access, and explicit boundaries around production changes. Review what a compromised dependency could reach in the same environment.
4. Treat package exposure as an incident question. Identify executed artifacts and their reachable credentials. A clean source tag is not sufficient evidence that a downloaded package or container was clean.
5. Pilot defensive AI against a bounded outcome. Choose a real task such as investigating an alert or proposing a patch. Measure analyst effort, verified correctness, missed findings, and deployment time against the existing workflow.
6. Keep evidence and interpretation separate. Preserve source revisions, snapshots, and unknowns. Update an incident explanation when the vendor corrects its postmortem.

These are recommendations drawn from the mechanisms above, not proof of a universal return on investment. A team should test them against its own systems and constraints.

The question I would carry into the next security review is concrete: if an attacker or an AI researcher found a useful weakness in our stack today, how long would it take us to identify the reachable assets, contain the exposure, and prove that we had done so?

That is the race I care about. And unlike the global scoreboard, it is one our team can actually measure.

Next in Part 2: the attacker’s workflow—where AI reduces effort, where human judgment still matters, and how to evaluate claims of autonomy. This four-part series will then turn to defensive operations and practical engineering controls.

Research note: This article distinguishes maintainer advisories, researcher demonstrations, provider investigations, and my analysis. Source checking was completed on 25 October 2026; the latest KEV snapshot retrieved was dated 23 October. Linked pages and operational guidance may change. No global incident-growth estimate or attacker-versus-defender performance ratio is inferred from these selected cases.