October 2026 in Security: Attackers Went for the Keys, and AI Outpaced Our Patching

October 2026 made two shifts hard to ignore.

The first is about where attacks start. Several of the month's costliest incidents did not begin with a bug in the victim's own application. They began wherever credentials pile up: a package release pipeline (LiteLLM), a deployment platform's environment variables (Railway), an MSP backup app with standing access to Microsoft 365 tenants (ConnectWise) and, by Binance's initial account, one engineer's laptop that preceded a theft of about $6.3 billion.

The second is about speed. AI is finding bugs faster than ever. Researchers at Anthropic (using Claude) and on OpenAI's Codex Security team reported several of the 353 security fixes in Chrome 156, and OpenAI Codex Security reported the Node.js Brotli flaw. Six days after Node.js shipped its fix, CISA listed that Brotli flaw as exploited. PHP2Shell was attacked before its patch existed. Meanwhile, Reuters documented one operator who used AI agents to break into the websites of more than 100 companies, at an estimated $50 per successful intrusion.

Together they lead to my position: your blast radius is now set by where your secrets live and how fast your fleet absorbs a patch, not by how carefully you write your own code. Neither problem needs exotic tools. Both need habits most teams haven't built yet.

October at a glance

Date (2026)	Event	The lesson
29 Oct	Binance loses about $6.3 billion; first traced to an engineer's laptop	People who can sign high-value actions are tier-0
27 Oct	CISA lists the Node2Shell Brotli flaw (CVE-2026-111497) as exploited	Six days from patch to confirmed exploitation
21 Oct	LiteLLM 1.107.0 poisoned on PyPI and Docker with a stealer that runs at every Python start	Installing a package can leak every secret on the host
21 Oct	Railway says customer environment variables may have been decrypted	A PaaS is a secrets store whether you planned it or not
21 Oct	PHP2Shell emergency patches after attacks were seen before release	Some bugs are exploited before a fix exists
20–29 Oct	Chrome 156 with 353 security fixes, then two further stable updates	Patch volume is the new problem; fixes apply on relaunch
19 Oct	Reuters: AI agents breached the websites of 100+ companies	Probing your forgotten systems now costs almost nothing
15 Oct	Stolen ConnectWise Cloud Backup credential used against at least 162 Microsoft 365 tenants	One vendor key can open many customers
13 Oct	Windows Shell Mark-of-the-Web bypass exploited as a zero-day	Malicious downloads lose their warning prompts

Investigations into Binance, LiteLLM, Railway and ConnectWise are still open, so details may change. Each link goes to the page that row's claims come from.

Patch and check now

Node.js: upgrade to 22.23.4, 24.22.1 or 26.12.1 and rebuild every image that bundles it. End-of-life lines such as 20.x get no fix. Express 5 apps that can't upgrade yet can set body-parser's inflate: false, but that closes only the request-body path; fetch() clients stay exposed.
PHP: upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The published configuration mitigations do not fully prevent exploitation.
LiteLLM: if 1.107.0 ever ran on a host, treat every secret that host could read as stolen. Look for cook.pth, cook.py, sitecustomize.py, /tmp/.pc_once_*, /tmp/remote_code_loader.lock and traffic to litellm[.]dev. The most recent safe version is 1.106.2.
Railway: replace every sensitive credential that was in place before 21 October and remove public network access to databases, per its 23 October update.
ConnectWise: disable (don't delete) its apps, check every app for credentials added since 13 October, and review service principal sign-in logs, not just the default user sign-in view.
Windows and Chrome: install the October updates, then actually restart.

Shift one: attackers go where the keys are

Look at what each attacker wanted. The LiteLLM stealer collected cloud credentials, LLM provider API keys, SSH keys and browser credentials. Railway believes its attackers were after AI inference providers. The ConnectWise attackers did not need to phish anyone: they signed in as a trusted backup app, and in one tenant a ConnectWise app granted itself global administrator and added credentials to two other apps, set to stay valid until 2028. At Binance, according to CNBC citing TRM Labs, the attackers prepared for at least 36 hours and obtained transaction signatures in advance.

None of that required a flaw in the victims' own code. It required a credential that lived too long, reached too far, or sat on a machine nobody treated as critical.

Shift two: AI is patching faster than we deploy

October's patch volume was enormous. Microsoft fixed 1,411 flaws in one Patch Tuesday, by BleepingComputer's count. Chrome shipped 353 security fixes in one release and 52 more a week later. Node.js fixed 10 CVEs in a day. Some of these bugs came from AI-assisted research, as above. PHP2Shell was credited to researchers at Calif, OpenAI and Wiz, though reports don't say whether AI tools were involved.

That is good news. Bugs that might have sat for years are being found and fixed. The cost is that every fix is also a public pointer to vulnerable code, and the window to act on it is shrinking. The Reuters campaign shows how cheap automated exploitation has become: an estimated $5,000 in tokens, more than 1,200 sites attempted, and a typical successful intrusion taking about 23 hours. I see no reason patch diffing will stay manual when exploitation already isn't. Discovery is scaling with AI. For many organizations, deployment is still a monthly change window and a reminder to restart the browser.

What to change

1. Make credentials expire on their own

A leak only hurts for as long as the leaked key works.

Developers: use OIDC federation from CI to your cloud instead of stored keys. Scope each token to one service and one environment, and give every token an expiry date. Put spending caps and usage alerts on LLM API keys, so a stolen key shows up as a spike rather than an invoice.
IT leaders: keep a secrets inventory per platform (PaaS, CI, registries, LLM gateways), with an owner and a rotation runbook for each secret. Railway's request to replace every sensitive credential in place before 21 October is a checklist if you have that inventory. Without it, it's an archaeology project.

2. Assume an install can run code

LiteLLM showed that a package can run code without ever being imported: a .pth file executes at every Python start.

Pin dependencies by hash and container images by digest. The poisoned LiteLLM image was also served under the latest, main-latest and main-stable tags.
Add a release cooldown of a few days (pnpm's minimumReleaseAge, Renovate's equivalent, Dependabot's cooldown). LiteLLM's longest exposure window was under three hours.
Run LLM gateways and agent platforms in their own containers, holding only the keys they need, and keep them and their dashboards off the public internet.
Protect GitHub, PyPI, npm, your cloud console and your PaaS with passkeys or hardware security keys.

3. Patch at the speed of exploitation

Treat patching as a throughput problem, not a calendar event.

Set a 72-hour SLA for anything known to be exploited, backed by a pre-approved emergency change path. If you can't patch in time, isolate the system or take it offline, as the UK NCSC advised for PHP2Shell.
Make updates automatic by default: OS security updates, Renovate or Dependabot for runtime and base-image versions, and browsers with a relaunch deadline enforced through Chrome's RelaunchNotification and RelaunchNotificationPeriod policies.
Rebuild containers continuously. An image built on a Node.js release from before 21 October is still vulnerable to Node2Shell, however current your package.json is.
Know your embedded libraries. Brotli sits inside Node.js and other HTTP stacks, and Microsoft shipped an emergency .NET update for the same flaw. An SBOM that lists only direct dependencies misses that layer.
Switch off code paths you don't use. If your API never needs compressed request bodies, turn decompression off.

4. Treat third-party apps as privileged identities

ConnectWise warned that disabling its apps does not undo changes attackers had already made. Cleaning up your own tenant is your job.

Inventory every OAuth app and service principal in Microsoft 365, Google Workspace and GitHub, ranked by permission. Remove dormant integrations.
Alert when an existing app gains a new credential or grants itself a role.
Write vendor contracts that assume the vendor will be breached: per-tenant credentials, breach notification within 24 hours, and a kill switch you control.

5. Protect the people who can sign

Anyone whose laptop can approve a high-value action (a withdrawal, a package release, an IAM change) is a tier-0 asset.

Give them dedicated privileged-access workstations, separate from email and browsing.
Require multi-party approval with out-of-band verification. When signatures can be gathered in advance, as in the Binance case, approval controls must check what was signed and when, not just that a valid signature exists.
Prepare them for targeted lures. CISA's TraderTraitor advisory describes the group sending fake job offers to developers and DevOps staff to get them to install trojanized apps.

6. Find your forgotten surface, and your own bugs, first

The systems hit in the Reuters case included a public control panel, a standalone support site and a vendor-run website. Run continuous external discovery that covers vendor-run sites and admin panels. Then point the same kind of AI tooling at your own code. The tools finding bugs in Chrome and Node.js can review your services too.

How to recognize the next one early

If you weren't the victim, the first warning this month usually came from outside: a vendor's blog or status page, a CISA KEV entry, a researcher's post. Route the CISA KEV catalog, your national CERT, the security pages of every platform that holds your secrets, and malicious-package feeds matched against your SBOM into your ticket queue. Then map each attack pattern to a signal you already collect:

Pattern	Early signal	Where to look
Poisoned package	New `.pth` or `sitecustomize.py`; Python processes calling unfamiliar domains; `/tmp` lock files	EDR process trees, DNS logs, CI runner egress
Leaked platform secrets	API keys used from new networks; sudden LLM spend; unfamiliar cloud identity calls	Cloud audit logs, provider usage dashboards
Vendor app abuse	Service principal sign-ins seconds apart; new app credentials; apps self-granting roles	Entra service principal sign-ins and audit log
Pre-patch web RCE	Worker crashes, fatal errors before app code, web server spawning shells	PHP-FPM and web server logs, EDR on web hosts
AI-agent probing	Hours-long, methodical, high-variety requests against panels and APIs from one source	WAF and CDN logs, bot-management alerts

When it happens to you: the first day

Scope. Find every host, CI runner, image cache and tenant that touched the bad version, platform or app.
Contain. Isolate affected hosts. Disable compromised vendor apps rather than deleting them, so the evidence survives.
Rotate from a clean machine, broadest access first: cloud and organization admins, then CI, then per-service tokens.
Hunt for persistence. LiteLLM's backdoor checked in hourly, and in the ConnectWise case new app credentials were set to last until 2028. Check app credentials and role grants, mailbox rules, SSH keys, cron jobs and interpreter startup files.
Rebuild from verified, pinned artifacts, and purge the bad versions from internal mirrors.

Where this is heading

AI will keep raising the volume of fixes, and attackers will keep closing the gap between a fix and its exploitation. The organizations that come through this well won't be the ones with the most tools. They'll be the ones that can quickly answer two questions: which credentials would an attacker get from this machine, and how many days does our fleet take to absorb a patch? Measure both this week, then work on making both numbers smaller.