Black October: Faster Response Starts With Visibility

Key takeaways

• Black October showed that the gap between disclosure and exploitation is shrinking, partly because AI now helps find vulnerabilities faster than teams can patch them.
• The hardest question during the scramble wasn't "how do we patch?" It was "where are we running vulnerable PHP?"
• Vulnerability visibility depends on normalized, queryable telemetry. If your asset, version and activity data live in different schemas, your response time is limited by how fast someone can stitch them together.
• Fast response is a data problem first and a tooling problem second.

In one week, security teams got critical PHP flaws that let attackers run code on web servers, a broken certificate authority, a poisoned release of a popular AI gateway, and a CVSS 10.0 GitLab bug. Every CISO had to answer these two questions: "Are we patched?" and "Were we already compromised?"

The first question is easy to answer, the second one usually isn’t. For PHP2Shell, the vulnerable code sat in PHP for more than a decade. For the eMudhra certificates, the weak keys were live for about 17 months. Patching closes the door, but it doesn't tell you who walked through it.

In this post, we'll break down what Black October revealed, how to measure your own blind window with data you already have, and how to shrink it before the next disclosure wave.

What was Black October?

Black October is the name given to a cluster of major security disclosures in October 2026, concentrated between Oct 19 and Oct 22. It drew attention because AI-assisted research helped find and weaponize several of the flaws, and because the affected software runs a large share of the internet. One pattern stands out the most: almost every exposure existed long before anyone announced it.

So, Black October wasn't the month attackers got in. It was the month everyone found out.

Why did response time matter so much?

Response time is the window between when a threat becomes known and when it gets contained. During Black October, that window was compressed from both ends.

On one end, the early embargo leak meant defenders lost their planned head start. On the other hand, more than 200 proof-of-concept exploits were circulating within days.

Upgrading and restarting PHP was the only complete fix. A firewall rule or configuration change wasn’t enough. PHP2Shell lived in the interpreter, which meant every site/app on versions going back to PHP 5.4 was at risk. Every team had to quickly answer the same question at the same time:: where are we running PHP and which version?

The real bottleneck: you can't patch what you can't see

Vulnerability visibility is your ability to know, at any moment, which of your assets are exposed to a given vulnerability and whether anyone is actively probing them. During Black October, this is where most teams lost hours.

To answer the question “are we exposed?”, you'd need PHP version data from your vulnerability scanner, asset ownership from your CMDB, runtime details from EDR or cloud logs, and web traffic from your WAF or proxy. Each of those speaks a different schema. One tool calls it host, another device.hostname, another src_endpoint. They have to be reconciled before anyone can make a decision.

That reconciliation work is invisible on a calm day and very visible on a day like October 21.

8 ways to shrink the blind window before the next disclosure wave

1. Keep 100% of raw logs, but not in the SIEM. Send the data your detections use to the SIEM, and send everything to low-cost object storage (S3, Azure Blob, Databricks) for 12 months or more. When the next disclosure lands, you rehydrate and hunt instead of guessing.
2. Stop treating "noisy" as "worthless." Web access, package registry, DNS and identity logs rarely fire rules, but they're the first thing you need after a disclosure. Route them to cheap storage instead of dropping them.
3. Normalize your telemetry before you need it. Cross-signal correlation only works if your data shares a common schema. Frameworks like OCSF (the Open Cybersecurity Schema Framework) give security data a shared language, so a query for "hosts running PHP 8.1" returns one answer instead of five partial ones.
4. Make version and asset data queryable, then correlate it with activity. Plenty of organizations had the right data somewhere, in a scanner export or a spreadsheet. Treat software inventory as first-class security telemetry. Knowing a host is vulnerable is step one; knowing that the same host just received unusual POST requests tells you where to look first.
5. Watch your parsers, not just your rules. Alert when a source's schema or field meaning changes, so detections don't fail silently. A rule that never fires might be quiet, or it might be broken.
6. Log your AI stack like production infrastructure. AI gateways, agents and model APIs should send traces that show which keys, tools and data they touched. LiteLLM showed that your AI layer is now part of your attack surface.
7. Onboard new log sources in minutes, not sprints. Your next disclosure may point at a system you don't collect from today. If a new source takes weeks to parse, it stays a blind spot for the whole incident.
8. Track the blind window as a metric, and keep humans on the big calls. Report time to "exposed or not" and time to "hit or not" next to MTTR. What gets measured gets funded. And taking a government site or a storefront offline is a business decision: automation should get the right information to the right person quickly, then let them decide.

The common thread: response speed is decided months before the incident, when you decide what data to keep, where, and in what shape.

What does Black October mean for AI in security?

Black October was an AI story on both sides. AI-assisted research found bugs that had been hiding for over a decade. Meanwhile, banks including JPMorgan, Citi and Wells Fargo moved to restrict third-party AI agents after reportedly spotting unauthorized agents inside customer accounts.

The takeaway for defenders is that AI will raise the speed of both discovery and exploitation. To keep up, AI-assisted defense depends first and foremost on reliable telemetry. An AI agent asked "which of our servers are exposed?" is only as good as the data it can see. If that data is fragmented and inconsistently labeled, the agent either burns time and tokens reconciling it or gives you a confident wrong answer.

How Fleak approaches response time and visibility

At Fleak, we think of this as getting the data foundation right before asking AI to act on it. Our normalization layer converts raw logs from sources like Zscaler and Okta into OCSF before they reach your SIEM, data lake or AI agents. When a new log type shows up, our AI-native mapping agent can generate an OCSF parser in under five minutes.

In a recent benchmark with Gruve, normalized OCSF data let the same LLM agent, using the same logs and prompt, move from surfacing standard alerts to Tier 3 threat-hunting depth, without adding latency or token cost. Gruve's analysis also found that standard pipelines waste around 40% of AI tokens on reconciling unstructured data.

None of that replaces patching. But it does shrink the time between "there's a new critical vulnerability" and "here's exactly where we're exposed."

Frequently asked questions

What is Black October 2026?

Black October refers to the October 2026 wave of emergency patching and site outages caused by two critical, unauthenticated remote code execution vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619).

Which PHP versions fix the Black October vulnerabilities?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fixes. Versions 7.4, 8.0 and 8.1 have no official release, though the PHP security team published source backports. Moving to a supported branch is recommended.

Is a WAF or firewall rule enough to protect against it?

No. Guidance was that upgrading and restarting PHP is the only complete fix. Firewall or configuration changes can reduce risk temporarily but don't replace the patch.

What is vulnerability visibility?

Vulnerability visibility is the ability to quickly identify which assets are affected by a vulnerability and whether they're being targeted. It depends on accurate asset inventory and normalized, correlated security telemetry.

How can security teams reduce response time to new vulnerabilities?

Normalize telemetry into a common schema such as OCSF, make asset and version data queryable, correlate exposure with live activity, onboard new data sources quickly, and keep humans involved in high-impact decisions.

How does OCSF help with incident response?

OCSF gives security data from different vendors a shared structure. That makes cross-source queries and AI-assisted analysis faster and more accurate, because time isn't spent translating field names during an incident.

Closing thought

Black October won't be the last time a decade-old bug surfaces overnight. The teams that moved fastest weren't necessarily the ones with the most tools. They were the ones who already knew where to look.

If your team was part of the October scramble, what slowed you down the most: finding exposure, coordinating owners, or patching itself?