← All posts

Black October: what a business running on cloud apps and AI tools should check this week

Black October is a label for a cluster of security disclosures published between 19 and 22 October 2026, not one attack. An AI gateway package shipped a release that stole credentials, and two hosting platforms said customer secrets were or may have been read. The shared lesson: your software's suppliers hold your keys. This week, list every key, confirm the business owns each account, ask your developer in writing, and change exposed keys at the issuing service first.

Illustration: a row of three tiles joined in order, a parcel box, then a key, then a shop, with a key highlighted in olive.

What is Black October?

On 21 October 2026, Railway, a platform that hosts other companies' applications, told all of its customers to change every key and password they had stored with it, immediately, and paused deployments while it investigated. That same day an AI software package called LiteLLM said one of its releases had shipped with malware that steals credentials. Black October is the label for that run of disclosures, published between 19 and 22 October 2026. It is not one attack, and no company involved has named one attacker.

Everything below is stated as of 23 October 2026. Every company named here is still investigating, and its own pages are still changing. Where a company describes the scope of its incident, this post uses its words. Where it has not said who did it, how it happened or how many customers were affected, neither does this post.

This is general guidance for owners and managers, not a security audit of your systems. If you think you were affected, someone technical needs to look at the actual machines and accounts.

What happened at LiteLLM?

LiteLLM is an open-source package that developers place between an application and the AI services it calls, so it holds the keys to those services. Its incident report of 21 October 2026 says: "LiteLLM's release pipeline was compromised and pushed v1.107.0 to the docker registry and PyPi. This version contained compiled malware which steals credentials and loads remote-code execution tools."

The window was short. The report says the poisoned package was live on PyPI, the public library developers install Python packages from, for "approximately 2 hours (11:39 UTC to 13:23 UTC)", and that the Docker images were "compromised from 11:46 UTC to 14:20 UTC." LiteLLM says all previous versions are safe and that customers on its private enterprise release were not affected.

Its advice to anyone who did install it is blunt: "If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded." It tells them to rotate every AI provider key stored in the gateway, its master keys, the database password and "any secret that was in the environment of any process on the host", and to reinstall pinned to version 1.106.2.

The report's account of how it happened is the part an owner should read twice. LiteLLM says it found "an unexpected, innocuously named user account in our internal LiteLLM deployment, which was exposed to the public internet." It believes the attacker reached that deployment, took developers' GitHub tokens from its logs, and used them to run the release process. It also says that earlier that week it had "temporarily expanded release permissions" for two engineers. As of 23 October 2026, LiteLLM says it has not confirmed how the attacker first got into the internal deployment. A forgotten account, a key in a log file, a permission widened for convenience: none of those is exotic.

What happened at Railway?

Railway hosts applications and stores the settings they run on, including what developers call environment variables: the keys, passwords and addresses an app needs to reach its database and the outside services it uses. Railway's security disclosure of 21 October 2026 says "an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents."

Read its words on scope carefully. Railway says its "initial analysis suggests the impact may be limited to a subset of users," and still recommends that every customer "immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials, and review logs for those services for unusual activity." To roll a variable is to replace the secret in it with a new one.

Railway also wrote the sentence that ties the week together: "We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." Inference providers are the companies that run AI models and bill by use. Railway says it asked them to revoke keys proactively.

Its status page adds detail as it goes. On 22 October Railway said API tokens created before the incident "remain invalidated", so anyone using one needs a new one. On 23 October at 08:09 UTC it said it had "notified customers with a very high likelihood of impact by email" and was still running forensic analysis. It had said it planned to publish a preliminary incident report around midday Eastern Time on 23 October. Railway has published guides for specific services, including one for checking Amazon Web Services keys that this post returns to below.

Which other disclosures landed in the same days?

Three more, each confirmed here from the company's or project's own statement: a second hosting platform, two flaws in the PHP programming language, and a certificate authority's weak keys. Other incidents were reported in the same week; this post leaves out any it could not confirm from a primary source.

Zeabur: a second hosting platform

Zeabur, another platform that hosts applications, published a preliminary report on 19 October 2026. It says that on 14 and 15 October an attacker "used leaked Zeabur internal credentials to break into the shared cluster, some Dedicated Servers, and Zeabur internal systems, and eventually read the platform database." Its own table lists 3,218,965 records of service environment variables, names and values, as read, and marks that figure "Confirmed".

Zeabur states the cause without hedging: "The root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext and could be used from the public internet." It says the attacker "was mainly looking for API keys they could use directly, especially keys for AI services", and that its rotation after an earlier incident in August "did not cover the credentials used this time." Its instruction to customers: "Replace every password and key stored on Zeabur, even if you already replaced them after the August incident."

PHP: two critical flaws in the language itself

On 21 October 2026 the PHP project published two advisories rated critical, CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The first advisory says "The confirmed impact is unauthenticated remote code execution as the web worker account": someone who is not logged in can run their own code on your server. The second describes another route to "full remote code execution (RCE)."

Vercel's bulletin of the same day, which calls the pair php2shell, says frameworks and content systems built on PHP, "including WordPress, Drupal, Laravel, and Magento," are affected when they run on a vulnerable PHP version, and that "Updating your application code or plugins does not fix these vulnerabilities." The fix is an upgrade of PHP on the server, which is your developer's or your host's job. Ask them to confirm it is done.

eMudhra: certificates browsers stopped trusting

eMudhra, a certificate authority, issued a statement on 21 October 2026 on the distrust of "select Global TLS Intermediate and one Root CA". It says "A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys," and that 8 of its intermediate certificate authorities were affected. It also says "Its infrastructure was not compromised" and "No data was breached."

This one is a different kind of supplier problem: the company that vouches for your website's identity to browsers. eMudhra says it is working with customers who may be affected to give them replacement certificates. If your website's security certificate came from eMudhra's global TLS business, ask whoever manages the site whether it has been replaced.

What do these incidents have in common?

Each one is a supplier holding someone else's keys. A business that used any of these services did nothing wrong, and still has keys to change this week. A key to an AI service, a payment gateway or a database works for whoever holds a copy, and every supplier that stores a copy is one more place it can leak from. Your software has suppliers, and their keys are your keys.

Look at what the attackers were after, in the companies' own words. Railway believes the aim was "compromising AI inference providers." Zeabur says the attacker was mainly after keys for AI services. LiteLLM's poisoned release stole credentials from the machines it ran on, and the software exists to hold AI service keys. An AI key is worth stealing because it can be spent directly, and the usage is billed to the account that issued it.

The second thing in common is how ordinary the gaps were, by the companies' own accounts: admin credentials stored in plaintext and usable from the internet, an internal account nobody expected, tokens left in logs, a rotation that missed some keys. These are teams that build infrastructure for a living. A business with one outside developer has the same gaps, with fewer people looking for them.

Does this affect a business that has never heard of these companies?

Possibly, and you may not be able to tell without asking. If a developer, an agency or an AI coding tool built an app for you, that app runs on suppliers you never chose: a host, packages pulled from public libraries, an AI service, perhaps a gateway in between. Owners rarely see that list. The only reliable way to know whether any of this week's names are in your systems is to ask the people who built and run them, in writing, and keep the answers.

This is the inherited-system problem in a new place. Our guide to the second-generation operator's first 100 days is about taking over a business whose processes live in people's heads. An app whose keys and accounts live in one developer's head is the same thing, and it fails the same way: on the day you need it, the person who knows is not available.

What should a business check this week?

Five things, in this order, none of which needs a security team. Each is explained in the sections that follow, with the questions to ask and the order to work in.

  1. Build the key register: every key your systems use, where copies live, who can change it.
  2. Check who owns each account: the business, with your developer as a user.
  3. Send the written questions to your developer and every software vendor.
  4. Rotate what may be exposed, at the issuing service first.
  5. Pin versions and name who applies security fixes.

How do you build a key register in an afternoon?

Ask your developer for every key, password and token your systems use, and put them in a sheet with five columns. Do not put the secrets themselves in the sheet. The register records where each key is and who controls it, not what it is, so it can be shared with the people who manage it without becoming one more thing to leak.

The five columns:

  • ·What it is. "Payment gateway key", "database password", "AI service key for the quoting tool". Names a non-developer can read.
  • ·Which outside service issued it. The company whose dashboard can deactivate it. This is where you change it first.
  • ·Where copies are stored. Hosting platform settings, an automation tool, a developer's laptop, a shared password manager. Every copy is a place it can leak from.
  • ·Who can change it. Named people, and whether each is staff or a contractor.
  • ·When it was last changed. "Not yet set" is an honest entry, and it tells you where to start.

Why will the first version be incomplete?

Because nobody has ever been asked for the whole list. Expect gaps and keep going. Zeabur's report shows why the list matters even with an engineering team: its August rotation "did not cover the credentials used this time." A key nobody knows about is a key nobody rotates.

Give automation tools their own rows. Zeabur reports that the attacker read "credentials in n8n and new-api/one-api at scale"; n8n is an automation tool. Any tool that connects your systems to each other holds a key to each of them, so one leak there opens all of them.

Give the register itself an owner and a review date, the same rule we use for branches you cannot visit: a named person and a fixed time. A register nobody updates is accurate for about a month.

Who should own the accounts your software runs on?

The business. Every account that issues a key your systems depend on, the hosting platform, the AI service, the domain, the code repository, the payment gateway, should be registered to a company email address the business controls, billed to a company card, with your developer added as a user rather than as the owner. If the only person who can log in is a contractor, the business cannot rotate its own keys on the day a supplier tells it to.

This is not about whether you trust your developer. Developers move on, get sick, change numbers and lose phones. An account owned by the business survives all of that; one owned by a person does not. Our Hidden Hours Audit counts how much of a process exists only in someone's head. Access to your own systems is the most expensive line on that list.

Two minutes per account will tell you where you stand. Log in, open the team or members page, and see who is listed as owner. If you cannot log in at all, that is the finding, and it goes to the top of the list.

In what order do you change keys after a provider's warning?

Issuing service first, stored copies second. Changing only the copy in your hosting platform leaves the original key working for whoever took it. Railway's guide for Amazon Web Services keys starts at the issuing service: create the replacement there, deactivate the exposed key, then update the copy stored on Railway and redeploy. Expect a short interruption between the last two steps. For a key that may already be in someone else's hands, that is the right trade.

  1. Start with keys that spend money or reach customer data. AI service keys, payment keys, cloud provider keys and database passwords come before everything else.
  2. At the issuing service, create a new key and deactivate the old one. Deactivate rather than delete where the service allows it. Railway's guide gives the reason: "so you can reactivate briefly if a service you forgot about breaks."
  3. Update every stored copy listed in your register, then have your developer redeploy the apps that use it.
  4. Check the issuing service's usage and billing for the days since the warning. Railway's guide tells customers to "review CloudTrail and billing for activity you didn't generate." Report charges you do not recognize to that provider's support, in writing.
  5. Record the date in the register's last-changed column, so the next warning starts from a known point.

What should you ask your developer or vendor in writing?

Five questions, sent by email so the answers are on record. A written answer protects both sides: the developer states what they checked, and you have something specific to act on if it later turns out to be wrong. Send the same questions to every vendor whose software holds your data, not only the developer who built your own app.

  • ·Did any system you built or run for us use LiteLLM, and was version 1.107.0 installed or run anywhere on 21 October 2026?
  • ·Is any of our software hosted on Railway or Zeabur? If so, has every key and password stored there been changed since the platform's warning, at the services that issued them?
  • ·Does anything of ours run on PHP, and has the server been upgraded to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a later fixed release?
  • ·Was our website's security certificate issued under eMudhra's global TLS business, and if so, has it been replaced?
  • ·Which accounts our systems depend on are registered to you personally rather than to the business, and when can they be transferred?

What if the answer is "I don't know"?

Then the register comes first. If the answer to any of the first four is yes, ask what was changed, on what date, and what the logs or bills showed, and keep the replies with the register.

Why does pinning software versions matter to an owner?

Because the LiteLLM release reached people who never chose it. LiteLLM's report says "You are affected if you used an unpinned version of LiteLLM between 11:39 and 13:23 UTC via pip." Unpinned means the app was set up to take whatever the newest release was at the moment it was installed or rebuilt. Pinned means it installs one named, tested version until someone decides to move.

Pinning is not a reason to stop updating. The PHP flaws are the opposite case: a fix you want quickly. The rule to ask for is short. Versions are pinned, updates are made on purpose, and one named person applies security fixes within an agreed number of days. If nobody is named, that is a gap in the process, not in the software.

Why fix the process before buying a security tool?

Because a tool automates whatever routine you already have, and many businesses of this size have no routine for keys at all. I hold that you fix and document a process before you automate it, and security routines are no exception. A secrets manager or a monitoring service is worth paying for once you know which keys exist, who owns them and how they get changed. Before that, it is a faster way to lose track of them.

It is the same sequence as build, buy, or fix what you have: when only the record has broken, fix the record. Here the record is the key register and the account list. Both cost an afternoon and a few emails, and neither needs a purchase order.

The same holds if an AI tool built part of your system. What AI actually does in a business that runs on paper argues that AI belongs at the capture end of an operation, not the judgment end. Deciding who holds the keys to your business, and who can change them, is judgment. It stays with a person, and that person should work for you.

What could still change after 23 October 2026?

Scope, mostly. Railway said it would narrow the scope as its review went on. LiteLLM said it was still confirming parts of the attack chain. Zeabur's report is labeled preliminary. Any of them may add affected customers, remove them, or state a cause they have not stated yet. Read their own pages for updates, not roundups. The checks above do not depend on how the scope settles: a key register, accounts the business owns and a written answer from your developer are worth having before the next warning, whichever supplier it comes from.

Common questions

Was Black October one attack?

No. It is a label for several separate disclosures published between 19 and 22 October 2026, including LiteLLM's poisoned release, Railway's warning about customer environment variables and Zeabur's report of a platform database read. Railway says it believes its incident is "part of a series of attacks recently targeting platform companies." As of 23 October 2026, none of the companies covered here had publicly named an attacker.

I don't use LiteLLM, Railway or Zeabur. Do I need to do anything?

You may not know which suppliers your apps use; owners often do not. Ask your developer and vendors in writing whether any affected package, platform, PHP version or certificate is in your systems. Build the key register either way: the next warning may name a supplier you do use, and the register is what lets you act on it the same day.

Is changing the password in my hosting platform enough?

No. If a key leaked, the old key keeps working at the service that issued it until it is deactivated there. Create a new key at the issuing service, deactivate the old one, then update every stored copy. Railway's guide for Amazon Web Services keys says an exposed key "works until you deactivate it."

Is this post a security audit?

No. It is general guidance for owners and managers, based on the affected companies' own statements as of 23 October 2026. It cannot tell you whether your systems were affected. If you think they were, have your developer or a security firm examine the actual machines, accounts and logs.

Sources

If this is the problem you're sitting with, show us the task and we'll audit one workflow for free.

Show us the task

One email, now and then

Where the hours actually go

Every new post, and nothing else. No pitch, no schedule to keep up with, one click to leave.