Black October 2026: what leaked, and what to rotate now

What "Black October" refers to

In the third week of October 2026, critical vulnerabilities and breaches landed faster than most teams could read the advisories. After the php2shell disclosure, some infosec experts started calling the period "Black October", as 404 Media reported on 22 October. Viral lists on social media count anywhere from 10 to more than 40 incidents.

Part of the alarm is about AI. The php2shell flaws were found with the help of AI models by researchers at Wiz, Calif and OpenAI, 404 Media reports, and Chainguard's CEO said his company rediscovered them by asking a frontier model to look for bad vulnerabilities in PHP.

The viral lists mix confirmed facts with claims nobody has checked. This article covers the incidents we could verify against the vendor's own advisory or an official statement, as of 22 October 2026. One example of how the lists drift: it is widely repeated that governments took their websites offline. What CISA actually advised was to take PHP systems offline if they cannot be updated, and 404 Media reports that sites such as Archive.org and several Wikimedia services went offline temporarily to update.

The incidents at a glance

Black October timeline

All times are UTC and come from the vendors' own statements unless a source is named.

• 14 and 15 October. An attacker reads the secrets of every service on Zeabur's shared cluster and the platform database.
• 16 October. An intruder reaches a legacy system at OpenCode. State Bank of India receives alerts about customer data on the dark web.
• 17 October. Amazon's honeypots record a php2shell exploit attempt, four days before disclosure. At 18:05 the eMudhra key compromise is reported to Google; Chrome blocks the keys at 19:45. Zeabur announces that it will shut down.
• 20 October. Around 15:00 the php2shell CVE numbers leak. PHP announces an emergency release. Around 20:00 an exploit video is published by accident.
• 21 October. 03:02 Cloudflare's WAF rules go live. 07:41 Chainguard publishes patched images. 11:33 Railway pauses builds in all regions. 11:39 the poisoned LiteLLM 1.107.0 appears on PyPI. 14:00 PHP releases the fixes. The same day: GitLab 19.5.1, the Node.js security release, CISA's PHP alert and State Bank of India's regulatory filing. 19:36 the first crypto theft that an investigator links to Railway. 22:10 Railway publishes its security notice.
• 22 October. 404 Media reports the name "Black October". Railway invalidates all API tokens and restores builds for Pro and Enterprise workspaces; Hobby, Free and Trial are still waiting at 16:14.
• 27 October. Chrome's removal of the emSign ECC Root CA - G3 is expected to reach all devices.

The flaws: PHP, GitLab, Node.js and eMudhra

php2shell

CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution in PHP installations that serve web requests. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA tells organizations that cannot update right away, or that still run PHP 8.1 or older, to take PHP systems offline until they are patched. Our php2shell guide covers versions, settings and detection in detail.

Three facts shape the risk for anyone who ran PHP that week:

• The embargo broke early. The PHP Foundation's postmortem describes the CVE numbers leaking around 15:00 UTC on 20 October, an exploit video published by accident that evening, and Chainguard publishing images with the fix at 07:41 UTC on 21 October, more than six hours before the coordinated release. The Foundation found no working public exploit by release time.
• Someone tried earlier. Amazon says its MadPot honeypots recorded a php2shell exploit attempt on 17 October, four days before disclosure, from an address on a commercial anonymization network. Amazon says it does not know how the actor got the details.
• Volume exploded. Cloudflare CEO Matthew Prince wrote that Cloudflare saw thousands of attempts in the 10 hours before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions by early 22 October.

Attempts are not breaches. CISA had observed no exploitation when it published its alert. But a php2shell attack that reads worker memory can return another visitor's session token or the server's API keys and look like an ordinary request in the logs, so a server that was reachable before the update should be handled as if its secrets are known.

GitLab CVE-2026-110264

GitLab fixed an integer overflow in its regular expression compiler that, under certain conditions, lets an unauthenticated user run code on a self-managed GitLab server. It is rated CVSS 10.0 and reaches back to GitLab 7.0. The fixed releases are 19.5.1, 19.4.3 and 19.3.6, with backports 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab.com and GitLab Dedicated are already patched.

Teams that installed the critical patch of 12 October (19.4.2, 19.3.5, 19.2.8) are still exposed to this flaw and must update again. A GitLab server holds source code, CI/CD variables, deploy keys and runner tokens, which makes it one of the most valuable servers a company runs.

Node.js

The Node.js security release of 21 October fixes 10 vulnerabilities: four high, three medium and three low. The most serious, CVE-2026-111497, is an out-of-bounds write in the Brotli decoder that permits remote code execution. Two high-severity bugs let TLS hostname checks be bypassed. The same release updates the bundled CA certificates for the eMudhra compromise. Update to 22.23.4, 24.22.1 or 26.12.1; end-of-life lines stay vulnerable.

eMudhra

On 17 October, Google received a report that the private keys of eight eMudhra subordinate certificate authorities had been generated with insufficient randomness. Anyone holding those keys could issue HTTPS certificates that clients trust. TheNextWeb, citing Ars Technica, reports that one of the keys was the number 4.

Chrome blocked the intermediates the same evening. Google says no certificates chaining to the six TLS intermediates were logged to Certificate Transparency before the block, so browsers that enforce it were protected. The open risk sits elsewhere: command-line tools, language runtimes, containers, VPN clients and CI jobs that carry their own trust store keep trusting these keys until they are updated. Chrome is also removing emSign ECC Root CA - G3 from its root store, a change expected to reach all devices on 27 October, so sites with a certificate chaining to that root need a new one from another CA.

The breaches: where stored secrets left

LiteLLM 1.107.0

LiteLLM, a widely used gateway for AI model APIs, shipped a malicious version 1.107.0 on 21 October: on PyPI from 11:39 to 13:23 UTC, and on Docker Hub as v1.107.0, latest, main-latest and main-stable from 11:46 to 14:20 UTC. The package contained a credential stealer, a form of infostealer, and a backdoor that fetched and ran new code every hour. Because it hooked into Python start-up, any Python process in that environment ran it.

The way in matters for everyone who runs AI tooling. LiteLLM's investigation found GitHub CLI tokens in the logs of an internal, internet-reachable deployment, because a coding assistant can embed a user's GitHub token in a response body and those bodies were logged. With the tokens, the attacker disabled branch protection and published the release from a lookalike repository. LiteLLM's advice: pin 1.106.2, rebuild from scratch, and if 1.107.0 ever ran on a host with internet access, assume the theft succeeded and rotate every credential that host could reach.

Railway

On 21 October Railway disclosed that an unauthorized party may have accessed encrypted customer environment variables and, for some of them, obtained the decrypted contents. Railway paused all deployments, believes the incident is part of a series of attacks on platform companies, and has asked upstream providers to revoke keys. It says the impact may be limited to a subset of users, who will be contacted by email, and recommends that every customer rotate all environment variables, API keys and private registry credentials and review service logs.

Railway has since regenerated the credentials of every storage bucket, invalidated the GitHub tokens it held and, according to its status page, invalidated all API tokens. Its follow-up guide tells customers to redeploy services that use buckets, reconnect GitHub, and revoke GitHub registry tokens on GitHub itself, because removing them from Railway does not stop them working. On 22 October builds were back for Pro and Enterprise workspaces, while Hobby, Free and Trial were still waiting.

Some of the damage is already visible on public blockchains. Blockchain investigator Taylor Monahan links about $371,000 in suspected thefts, more than 500 transactions from over 200 addresses on at least 19 networks, to wallet keys stored on Railway, Analytics Insight reports. She dates the first theft to 19:36 UTC on 21 October, before Railway's public notice. Railway has not confirmed the link.

Zeabur

The hosting platform Zeabur published a preliminary report on an intrusion on 14 and 15 October. The attacker used non-expiring admin tokens stored in plaintext in a configuration repository, read the settings and secrets of every service on the shared cluster, gained root on 101 servers and read the platform database. Zeabur counts 3,218,965 environment variable records and 321,810 account records with email, username and phone number among the exposed data. It tells every user to replace every password and key stored on Zeabur, including those already replaced after an earlier incident in August. Zeabur will shut down on 31 December 2026.

OpenCode Console

An intruder reached a legacy system at OpenCode on the night of 16 October, The Hacker News reports. The third-party AI provider keys that 1.4% of Console users had saved may have been exposed; the local CLI and desktop apps are not affected. OpenCode links the incident to "a large-scale distillation attack". Some users have reported unexpected charges on their AI accounts. Deleting a key in Console does not revoke it: revoke it with the provider.

State Bank of India

In a regulatory filing on 21 October, State Bank of India said a preliminary review of about 375,000 records allegedly leaked on the dark web found 3,897 customer records with personal data, according to The Tribune: mobile numbers, dates of birth, names, email addresses, home addresses and loan details. The bank was alerted on 16 October by its threat intelligence provider and CERT-In. Authenticity and source are still under investigation.

The common thread: secrets and data, not only servers

Look at what was taken rather than at the bug classes. Railway, Zeabur and OpenCode held customer secrets so that customers did not have to manage them, and that convenience put many companies' keys in one place. LiteLLM began with tokens in a log file and ended with a stealer aimed at cloud, SSH and AI tool credentials. php2shell can read the memory of a web worker, where passwords and tokens pass through. State Bank of India shows where such a chain ends: records that have already reached the dark web.

AI provider keys are now a target of their own. Railway notified upstream providers to revoke keys, some OpenCode users reported charges on their AI accounts, and LiteLLM's stealer looked for AI tool credentials. A stolen model key turns into a bill within hours, and a cloud or GitHub token turns into the next breach.

A patch closes the hole. It does nothing about a key that was copied before the patch, which keeps working until someone revokes it.

What to do this week

1. Patch what you run. PHP, self-managed GitLab and Node.js, using the versions in the table above. Restart PHP workers after the update, rebuild container images, and check the GitLab version even if you patched on 12 October.

2. Rotate secrets at the source, most damaging first. Revoking a key in the platform that stored it is not enough. Revoke it with the service that issued it:

1. Crypto wallet private keys. They cannot be rotated: move the funds to a new wallet whose key was never stored on the platform.
2. Cloud credentials and IAM roles (AWS, GCP, Azure), because they lead to everything else.
3. GitHub and GitLab tokens, deploy keys and CI/CD secrets, because they lead to your code and your releases.
4. AI provider and payment keys (OpenAI, Anthropic, Google, Stripe), because they are spent the fastest.
5. Database passwords and connection strings.
6. Application keys and session signing secrets, then end active sessions.

Railway customers whose builds were paused faced a hard choice: rotate now and break the running app, or wait and leave a stolen key valid. For anything that spends money or moves funds, an outage costs less than a drained account. Revoke those keys now, set spending limits with the provider, and redeploy with the new values as soon as builds return.

3. Hunt back to 17 October. Amazon recorded the first php2shell exploit attempt on 17 October, four days before disclosure, so that is where log reviews should start. Check provider billing and usage, cloud audit logs (for AWS, GetCallerIdentity calls from unfamiliar addresses), GitHub audit logs, and new accounts, roles or tokens that nobody created.

4. Fix the trust stores. Update operating systems, browsers, language runtimes and container base images so they stop trusting the eMudhra keys. If your own site has a certificate that chains to emSign ECC Root CA - G3, replace it before 27 October.

5. Pin dependencies. Install exact versions in CI and production, and keep unpinned latest tags out of builds. The poisoned LiteLLM release was live for less than two hours on PyPI and about two and a half hours on Docker Hub, which was enough.

6. Watch for your data outside. Customer records, staff accounts and keys taken in this wave can resurface weeks later, as State Bank of India's case shows. EDG3 watches dark web forums, marketplaces, channels and leak databases for a domain you have authorized, and CEM checks your leadership team's email addresses against leak databases.

How to tell whether your data is already circulating

Stolen data follows known routes. Credentials and records are posted or sold on dark web forums and marketplaces, in Telegram and other channels, and end up in leak databases that criminals query like a search engine. Stealer malware of the kind shipped in LiteLLM 1.107.0 produces stealer logs: bundles of passwords, cookies and keys from one machine, traded as a product. Our overview of how stolen data is sold follows that path from the theft to the buyer.

Leaked data usually reaches a company through someone else. State Bank of India heard first from its threat intelligence provider and the national CERT. Without such a source, a company tends to find out from customers reporting fraud, or from a ransom note. An EDG3 briefing answers the question earlier: what has been posted about your domain, where, and by whom.

Records like the ones in the State Bank of India data, with names, phone numbers, dates of birth and home addresses, are what fraudsters use for convincing pretexting calls. For executives, the same details are often easy to find on people-search sites, which is why removing them there is part of the response.

How WebThreat can help

WebThreat does not patch servers or scan them for these vulnerabilities; that is work for your hosting, operations and security teams, and the checklist above is where it starts. Our part is the data that may already have left.

• EDG3 is WebThreat's threat intelligence for leaked data. It watches the places where stolen data is posted and sold, including dark web forums and marketplaces, Telegram and other channels, and leak databases. For a domain you have authorized, it traces a leak back to its first post and the seller behind it, and links reposted copies while keeping the provenance of each. A briefing with a threat intelligence analyst shows what has been posted about your domain, with every finding tied to its source.
• CEM looks at your leadership team. It starts from your company name, finds the leadership team and their current and past email addresses, and searches each address in leak databases, from the outside and with nothing to install. If staff accounts were in a stolen database, this is where they tend to reappear. The methodology explains how findings are ranked.
• Information removal is a specialist service for executives' personal data. Our specialists audit the people-search profiles and broker records that list an executive's home address, phone number and family, file the opt-outs and legal requests, verify each removal and re-check every 30 days. Family members are covered on request.

If your company used one of the affected platforms or ran an unpatched server this month and you want to know whether anything about it is already circulating, book an EDG3 briefing or contact us.

This article reflects the state of the disclosures on 22 October 2026. Several investigations are ongoing; the vendor advisories linked above are the authority for versions and fixes.