Incident Response

How our cyber Black October resembled the crash of 1987 — and how teams should respond

Stressed stock trader looking at falling market data on a large screen in the exchange.

COMMENTARY: On October 22, a post on X called the previous 48 hours the most serious in cybersecurity history. It said people had a name for them: Black October.

The list behind it was long. Two critical flaws in PHP, the language behind roughly 70% of websites. A poisoned release of LiteLLM, an open-source gateway for AI models. Exposed secrets at Railway, a hosting platform for developers.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

Some caution about the label being too harsh. No government agency has called these incidents coordinated. Several began weeks or months earlier and only surfaced that week. Different attackers, different methods, one calendar.

That last part contains the lesson.

The anniversary nobody in security marked

Finance remembers that week for something else. The worst of Black October landed right after October 19, the anniversary of Black Monday. On that day in 1987, the Dow Jones Industrial Average fell 508 points, or 22.6%, in a single session.

One strategy became the cautionary tale. Portfolio insurance promised investors a floor. It did not buy that protection in advance. It planned to sell as prices fell, and it assumed buyers would be there when it did.

On Black Monday, too many funds needed to sell into the same falling market on the same morning. The Federal Reserve's history of the crash says the strategy “accelerated the crash's pace as initial losses led to further rounds of selling.” Bruce Jacobs, a money manager who later wrote a book on it, put it in three words: “Liquidity wasn't there.”

The analogy has a limit. In 1987, the selling fed on itself, and one company's patching does not make another's worse. Security teams do share a pool, though. The same managed service providers, incident response firms, and small open-source teams get called in the same week.

Security runs on the same assumption

Most security programs carry that assumption. Much of what they buy is a plan to react in time. Spot the alert, apply the patch, rotate the key. The liquidity those plans depend on: people and maintenance windows.

That works when problems arrive one at a time. Black Octobers happen when they arrive together.

Count what landed on one ordinary company. Oracle's quarterly release of 1,295 security patches on October 20. Emergency fixes from PHP and a maximum-severity GitLab flaw, plus a secrets rotation at Railway, the next day. A company running a few of those products had them land on the same team in the same week. Few teams staff for that.

Attackers did not wait their turn. Cloudflare's chief executive, Matthew Prince, said attempts against the PHP flaws reached millions within a day of the announcement, and by October 24 a researcher's decoy servers, set up to be easy targets, had logged attackers opening command shells through one of the flaws 35 times.

Watch the official advice, too. The UK government's cyber agency told organizations that could neither update nor apply stopgap fixes to consider taking the system offline until it can be fully mitigated. Several European governments took their own websites down as a precaution.

That’s a circuit breaker, pulled by hand, after the fact. Most organizations had never wired one in.

Not every failure has the same fix

It’s fair to argue that much of the cyber Black October had nothing to do with fast exploits. Some of the worst incidents began with a key sitting where it should not have been. LiteLLM's own review traced its poisoned release to a master key committed to a public code repository in May and never revoked. At Railway, the attackers were hunting for exactly those keys, customers' credentials for AI providers.

No endpoint product fixes that. Rotation discipline and secret scanning do, and they cost little.

The PHP flaws are different. They are memory-safety bugs in the language itself, and the project's advisory says that on common Apache setups the attack lands, with no login, before any application code runs.

The first protection in place was set before anyone read an alert. Cloudflare says its web firewall rules went live about nine hours before disclosure, for every customer running that firewall, free plans included. It still told customers to patch.

What markets built afterward

After 1987, regulators overhauled how trades clear, but everyone remembers the circuit breaker reform. Rules agreed in advance pause trading automatically when prices fall too far. Nobody has to make the call in the moment. That’s the point of them.

Security can build its own and much of it doesn't cost that much:

Write the isolation rules for internet-facing systems before the next emergency, and name the person allowed to pull them without a meeting. Then “take it offline” represents a switch, not a debate.

Pre-approve edge filtering, so new rules can go live the moment a fix gets announced rather than after the change board meets.

Limit what internet-facing servers are allowed to launch, so one break-in does not become 10. On laptops and servers, use protections that can block on their own, with no person in the loop. Make keys expire on their own, and revoke anything that was ever exposed.

Patching and response still matter. Circuit breakers did not replace traders. They bought time for the work only people can do.

Then run the test a risk desk would. Count the critical fixes the team shipped in the 72 hours after October 20, and compare that with the number that landed. The gap functions as the part of the plan that only works in a quiet week.

Black Monday taught finance that a plan to react is not a floor. Black October should teach security the same thing.

Ron Reinfeld, chief executive officer, Morphisec

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds