Day zero: seven incidents, ten days, and what AI changes

Between 12 and 22 October 2026, seven security stories hit software and platforms that a lot of people run. PHP had two critical flaws with a leaked fix. GitLab shipped a second maximum-severity patch in ten days. Node.js fixed ten bugs in one release, and an LLM gateway called LiteLLM published a poisoned version of itself. Railway and OpenCode lost customers' stored keys. QUIC, the protocol under HTTP/3, kept collecting bugs.

The easy story is that AI is behind all of it. I read the primary sources for every item to see how much of that holds up. For PHP2Shell it holds up. For most of the rest, I found no source that shows it.

The research behind this is dated 23 October 2026. Several of these stories are two days old, so treat anything marked Claimed as open.

The short version

I do not read this as one wave. At least four different kinds of event landed in the same ten days: a memory-corruption bug in a language runtime, bugs in a regex engine and a decoder, a hijacked release pipeline, and two stolen-secret breaches. No source I read ties them to one actor. Railway says its breach is separate from PHP2Shell¹.

Two things do hold across the set. Attackers now turn a patch into a working exploit faster than most teams roll the patch out. And the three credential breaches all took keys: AI-provider keys, cloud roles and CI tokens that someone stored in a place that got breached.

The grid scores the same seven rows. The three credential breaches sit high on "exploited" and "secrets" and at or near zero on "AI-found". PHP2Shell is the only row that is high on both exposure and AI-found.

PHP2Shell: the one AI found

PHP's two CVEs came out on 21 October. CVE-2026-109618 is memory corruption triggered by running out of memory during a crafted multipart/form-data request². CVE-2026-109619 is stale state left over between requests, which the next request on the same worker then reuses³. On Apache mod_php, PHP says an unauthenticated request can trigger the attack before any application code runs⁴. PHP scores it CVSS v4.0 9.2, and it runs on roughly 69% of sites whose server language is known⁵.

This is the one case where AI discovery is documented. Calif⁶ started auditing PHP on 30 July and reported an RCE on 11 August. OpenAI reported the same root cause the same day, independently⁷. Wiz found its first bug on 19 August with its Atlas research agent plus Gemini 4 Argon and GPT-5.6 Sol⁸. Two AI-assisted teams landing on the same bug in the same fortnight suggests it was findable by anyone with the same tools.

The disclosure then fell apart. The CVE IDs leaked on 20 October with the wrong score. A proof-of-concept video went out that evening, and Chainguard published patched images about six hours before the coordinated release, so anyone could diff them⁷. Amazon's honeypot had already seen an exploit attempt on 17 October, four days early. Amazon says it is unclear whether any attempt worked, and does not tie the attempts to AI⁹.

The bug had also been seen before. A core developer noticed the first signs of the memory problem in 2024, during a security audit. Competing fixes stalled over compatibility and resourcing, and the PHP Foundation now calls the delay "a structural failure"⁷. After release, open issues on the fix itself include hard-exit crashes on large allocations and a claim that state resets too late on the upload-progress path. Maintainers had not responded when I checked².

The half defenders underrate is the memory disclosure. Wiz describes a bug that leaks heap memory, including other users' passwords and tokens, back through an oversized session cookie⁸. JPCERT/CC warns that attacks may leave no trace in logs¹⁰. If a host was exposed, I would treat every secret that passed through it as read, not only the ones stored on disk.

Governments agreed on the instruction and split on the facts. CISA said it had not observed exploitation¹¹, NCSC New Zealand said it was aware of reports of active exploitation¹², and several European governments took sites offline as a precaution¹³. The UK's NCSC advised considering taking affected systems offline¹⁴, and Australia's ACSC said it was not aware of successful active exploitation at home¹⁵. The statements can all be true. "Not observed" means a confirmed compromise. "Aware of reports" counts honeypot attempts.

Node.js and GitLab: old bug classes, fast diffs

Node.js

The 21 October release fixed ten CVEs across 26.12.1, 24.22.1 and 22.23.4, four of them rated High. There are no CVSS scores and no workaround¹⁶. The worst is CVE-2026-111497, an out-of-bounds write in the Brotli decoder bundled inside Node that nodejs.org says permits remote code execution. Because the decoder ships inside Node, updating your operating system's Brotli package does nothing. It is reachable through fetch(), through Express 5 request-body decoding and through node:zlib. Node 20 and 25 are end of life and get no fix.

nodejs.org credits "OpenAI Codex Security" as the reporter. Imperva and two other outlets name a different person, who nodejs.org lists as the fixer, and I trust the advisory¹⁶. No source says how Codex Security found the bug. "Reported by an AI security product" is documented. "Found by an LLM" is a reasonable inference.

Imperva published a PoC the next day that ran code on stock Node 24.22.0 on Linux arm64, though not on every attempt¹⁷. Aikido says the first public PoC needed a deliberately weakened build¹⁸. I read that as a lab result on one platform, not a reliable remote exploit.

Node's ecosystem had a separate problem all quarter. Since August, npm worm campaigns that began with the compromise of a single popular maintainer have reached more than 400 packages. They steal AI-tool credentials and plant Claude Code and editor hooks so the malware survives a cleanup¹⁹.

GitLab

GitLab's 21 October patch fixed CVE-2026-110264, an integer overflow in the Onigmo regular-expression compiler. It is unauthenticated, CVSS 10.0, affects Community and Enterprise editions from 7.0, and has no workaround²⁰. GitLab.com is already patched.

The trap is the version number. Servers patched on the 12 October build fixed a sibling bug, CVE-2026-97229, and are still vulnerable to this one. "We patched last week" is not an answer²¹. One HackerOne researcher reported all four regex-engine RCEs in about a month. No source says whether that researcher used AI.

GitLab is also the cleanest example of speed without any documented AI. CVE-2026-85706 went into CISA's Known Exploited Vulnerabilities catalog one day after its 10 September patch²². Rapid7 published a working PoC for 97229 four days after the 12 October release²³. That speed came from public advisories and patch diffs.

QUIC: a steady drip, not a storm

QUIC has a real stream of bugs and no link I could find to PHP2Shell or to AI.

FoxIO's "Header Accordions" research, published on 20 October, found QPACK memory exhaustion in 7 of 10 HTTP/3 stacks. It is denial of service only, a public PoC exists, and nobody reported exploitation²⁴. quic-go, quiche and lsquic are fixed. Bun, h3 and aioquic were unpatched at disclosure. ngtcp2, Google's quiche and IIS are not affected.

The more serious bugs are in Microsoft's MsQuic: CVE-2026-62815 (use-after-free, 11 August) and CVE-2026-105016 (heap overflow, 13 October), both unauthenticated, both CVSS 9.8²⁵²⁶. nginx has fixed four HTTP/3 CVEs this year²⁷. curl's QUIC denial of service, CVE-2026-11352, came from a handle belonging to an AI security lab, though curl does not say AI was used²⁸. For nginx and for HAProxy's HTTP/3 request smuggling bug, the stopgap is to turn HTTP/3 off, after you check that TCP fallback carries your real traffic. This is the least verified section here. I did not read NVD or any CISA advisory for these items.

LiteLLM, Railway and OpenCode: the keys

LiteLLM

On 21 October, litellm==1.107.0 appeared on PyPI and in the latest and main-stable Docker tags. It was built from a lookalike repository, Berri-AI/litellm, one hyphen from the real one, using stolen GitHub CLI tokens from three engineers²⁹. The release pipeline then published it with valid provenance, so signature checks passed.

The payload runs on any Python start, even if you never import litellm. It steals cloud, SSH, browser and AI-tool credentials, and the provider keys stored in a proxy database. Wiz watched stolen AWS role credentials get tested about 4.5 hours later, with Bedrock model listing³⁰. The PyPI package was live for about an hour and forty minutes. The safe version is 1.106.2.

LiteLLM says the tokens may have leaked into logs of an internet-exposed internal deployment, and that Claude Code can embed a user's GitHub CLI token in response bodies that end up in logs²⁹. That is LiteLLM's own theory and the entry point is unconfirmed. This is also the second poisoning this year. In March, 1.82.7 and 1.82.8 went out through a compromised Trivy scanner in CI³¹. Datadog says no link between the two has been established³².

Separately, a pre-auth SQL injection, CVE-2026-42208, was exploited about 36 hours after it was listed, and the attacker went straight for the tables holding virtual keys and provider credentials³³. A gateway that stores every provider key is an obvious target.

Railway

On 21 October, Railway detected anomalous activity on the systems that store customer environment variables. It says a third party may have accessed encrypted variables and, for some customers, obtained decrypted values³⁴. It paused builds, invalidated OAuth sessions and every API token, rotated bucket credentials and paused signups. It tells every customer to rotate all secrets without waiting to learn whether they were affected.

Railway believes this is part of a series of attacks on platform companies aimed at AI inference providers. That is its own belief and nobody has verified it. A researcher claims about $371,000 in wallet funds was drained from keys stored there. I could not confirm that. The attacker, the entry point and the count of affected accounts are unknown, and a postmortem is promised¹.

OpenCode

OpenCode says a legacy system it was decommissioning was breached between 16 and 18 October, and that provider keys saved in workspaces for 1.4% of Console users may have leaked. Users reported charges from hundreds of dollars up to about $1,700³⁵. "Distillation attack" is OpenCode's own label, with no evidence published. No attacker is named.

The co-founder says defenders "need agents going 24/7" and that frontier models used in the investigation started refusing until a defender tier became available³⁵. Both are vendor statements. No forensic evidence shows the attackers used AI. Separately, the OpenCode agent had a CVSS 9.8 remote-code bug on Windows through a malicious MCP server, patched on 28 September with no CVE and no advisory, which a scanner that keys on CVEs would miss³⁶.

Railway and OpenCode have not said how the attackers got in. OpenCode's own account, a system being decommissioned that still held customers' keys, reads to me as decommissioning debt.

The clock

Most of the activity bunched into 21 October. PHP2Shell is the long lane, because exploitation attempts started four days before the fix.

The sharper question is how long the gap is between a patch and a working exploit. The numbers below do not all measure the same thing, so read the colours. The fastest is a lab measurement with a model most attackers cannot use. The in-the-wild numbers run from hours to days.

What AI changes, and what it does not

The best-evidenced change is on n-days, the bugs that already have a public patch. Anthropic reports that its Mythos Preview model turned Firefox patches into a first working exploit in under an hour, 18 days before the fix shipped to users. On Windows it built eight full privilege-escalation chains for about $2,000 each, before most devices had patched³⁷. That is vendor-run, on small samples, with a model attackers cannot use. It is the best measurement I found.

Evidence that AI-found bugs get exploited more is weak. VulnCheck counted 14 confirmed exploited out of 1,061 AI-attributed bugs, 1.3%³⁸. The same analysis found only 126 published CVEs against the 23,019 issues Anthropic's Glasswing program reported³⁹. Most AI-found bugs are not patched or published yet.

Attackers do use models. Google's threat group reports one probable AI-built criminal zero-day, a two-factor bypass, attributed from code artefacts and not from logs⁴⁰. Anthropic documents agentic intrusions, including credential theft across about 200 downstream organisations in 34 hours⁴¹. Both vendors say nothing in those cases was technically new, and each sees only its own platform.

The cost lands on maintainers. The PHP Foundation has published 15 CVEs since 1 July and worked through more than 100 reports that were invalid, duplicates or not reproducible⁷. It does not say how many were written by AI. Anthropic itself calls maintainers "a major bottleneck"³⁹.

My reading: attackers can win by diffing patches faster than you roll them out, with or without a model. GitLab shows it with no model in the story. The odd detail in PHP2Shell is that AI-assisted defenders found the bug about two months before disclosure. The embargo failed anyway, and probing started before release. Finding the bug early did not buy time. The embargo leaked three ways.

Open models, chips and the pause question

How close are open models?

Three independent estimates put the best open-weight model on cyber tasks between 3 and 7 months behind the closed frontier. NIST's CAISI says about 4 months⁴². The UK's AI Security Institute says 4 to 5 months on narrow tasks and about 7 on a long multi-step range⁴³. Epoch AI says 6 to 7⁴⁴. They measure different things, so I did not average them.

The strongest open cyber model any of them tested is Zhipu's GLM-5.3. On short exploit tasks it gets close. On long ones it falls far behind.

On one Anthropic benchmark, GLM-5.3 built 50 working exploits in 410 attempts, against 56 for Anthropic's Mythos Preview and none for the previous open model⁴⁵. Anthropic makes the closed model in that comparison, so read it next to CAISI's wider gaps.

Safeguards are thin on open weights. Anthropic stripped GLM-5.3's refusals for about $4,400 of GPU time and estimates an experienced team could do it for about $1,200⁴⁵. That is a self-published test, and CAISI did not reproduce the bypass numbers.

The chip claim

You will see "trained on their own chips" said about Chinese labs. I could not verify it. For GLM-5, training on Huawei Ascend traces back to the company, relayed by secondary outlets, while the technical report documents adapting inference to domestic chips⁴⁵. DeepSeek's V4 report is silent on training hardware, and a US official's smuggling allegation is unproven⁴⁶. Bloomberg, through anonymous sources, reports Kimi K3 trained on a 20,000-chip Nvidia cluster rented through Alibaba⁴⁷.

Epoch puts Huawei's 2026 compute under 4% of Nvidia's⁴⁸, and estimates a median of 660,000 H100-equivalents were smuggled into China through 2025. My summary is that Chinese labs run a mix. Nvidia hardware, legal or grey-market or rented, does the biggest training runs, and domestic chips take on more inference and some training. A pure-domestic frontier run is possible but unproven.

Would pacing the frontier help?

I do not think it would help much. Weak incentives are only one of the reasons.

• Coordination does not exist. China called slowdown calls fearmongering, and the US administration said it would oppose any scheme to control AI⁴⁹. Verification is unsolved, and Lawfare notes that the harder the US pushes to suppress Chinese AI, the less reason China has to accept pacing⁵⁰.
• Open weights cannot be recalled. GLM-5.3 has been out since late August. A pause on future training does not undo it.
• The bottleneck is not discovery. Patch deployment, maintainer triage and the unpatched long tail decide outcomes, and a training pause touches none of them.
• Defenders benefit too. AI-assisted researchers found PHP2Shell before attackers shipped anything.

Two points cut the other way. A slowdown plausibly delays the next capability jump by about the 4 to 7 month lag, if Chinese labs are partly compute-bound, and the chip data says they are. And the pause is not one thing: stopping training, restricting access and stopping open-weight releases are different policies, and only the last matters much for cyber. The "Pacing the Frontier" letter asked for tools to pace development internationally, not a unilateral stop⁵¹. Nobody has measured the effect of any slowdown or export control on cyber outcomes, so all of this is capability data plus argument.

How the attacks line up

MITRE publishes no ATT&CK mapping for these events, so the grouping below is mine. Exploiting a public application is the common way in for the software bugs, and stored credentials are where nearly everything else ends up.

Provider keys feed one outcome all the credential breaches share, which is inference billing abuse. Cloud roles feed cloud enumeration. CI and Git tokens feed more poisoned packages, which is how a worm spreads.

What to do

Here is what I would do.

The first hour for any critical disclosure

1. Name one incident lead and one person keeping the timeline.
2. Check whether you run it. If your inventory cannot answer, that is your first finding.
3. Check the runtime inside the running container or host, not the package list. Distros backport fixes under old version numbers.
4. Check the fixed-version table for your branch. A recent patch is not enough, as GitLab showed.
5. Decide to patch, isolate or take it offline. If you cannot patch today, take it offline or put it behind a blocking WAF and write down who accepted the risk.
6. Start the hunt at the earliest exploitation date any source reports, not at disclosure. For PHP2Shell that was 17 October.
7. Snapshot disk and memory on any suspect host before you restart it.

If a vendor says your secrets may be exposed

1. Rotate at the upstream provider first, then update the platform, then redeploy. Confirm the old key now fails.
2. Go to the provider's dashboard directly. Phishing follows every breach.
3. Review usage from the earliest possible exposure date for unfamiliar models, regions and spend.
4. Set spend caps and alerts, and use one key per tool so one leak does not cost you everything.
5. Move wallet keys and anything irreplaceable out of environment variables.
6. Do not read "no email" as "not affected".

If a package or image you use was compromised

1. Do not run Python or pip on a host that may have run the bad version.
2. Treat the host as burned and rebuild from a clean image.
3. Rotate everything the host could read, including cloud roles, SSH keys, registry tokens and the keys in any proxy database.
4. Check cloud audit logs for calls from outside your network.
5. Remove persistence hooks before you rotate. Some npm worms plant editor and agent hooks that steal the new tokens.

Standing controls

• Pin containers and CI images by digest, not by latest, and pin lockfiles with integrity hashes.
• Wait a few days before adopting a brand-new package version.
• Fail a release build when its source repository owner is not the expected one.
• Keep one provider key per tool, each with a spend cap.
• Keep LLM gateways and local agent servers off the open internet.
• Run a WAF in block mode in front of every internet-facing PHP, Node and GitLab instance.
• Keep 30 days or more of web, runtime and process logs, and alert on a web server spawning a shell.
• Retire end-of-life runtimes at the edge. Cisco Talos expects about half of vulnerable PHP systems never to be patched⁵².