Black October: When Every Cybersecurity Vulnerability Is an Emergency, Nothing Is
October has been a noisy month for cybersecurity.
Critical vulnerabilities. Emergency patches. Exploitation in the wild. Millions of potentially affected systems. New names ending in “2Shell.” And, inevitably, headlines declaring a “Black October” for the Internet.
Some of those warnings describe real threats. Brotli and PHP2Shell deserve serious attention. Organizations should identify affected systems, understand their exposure, and apply the available fixes. But there is a second problem hiding inside all that urgency.
When every vulnerability is presented as an emergency, the word emergency stops helping.
Cybersecurity has a risk-communication problem. We routinely collapse severity, exploitability, exposure, prevalence, and business impact into a single frightening message: patch everything immediately. That may generate clicks, product interest, and executive attention. It does not necessarily help defenders decide what to do first.
The Difference Between Serious and Urgent
A vulnerability can be serious without being urgent for every organization.
CVSS tells us something useful about how severe a vulnerability could be under defined conditions. It doesn’t know whether you run the affected product, whether the vulnerable function is reachable, whether the system is exposed to the Internet, whether an attacker has a working exploit, or what the compromised system could reach next.
That distinction matters because defenders do not patch in a laboratory. They patch production systems with maintenance windows, dependencies, uptime requirements, limited staff, and competing risks.
I wrote about this earlier in How to Prioritize Vulnerability Remediation (Without Losing Your Mind). Risk lives at the intersection of exposure, exploitability, and impact. A critical vulnerability on an isolated test system may be less urgent than a medium-severity vulnerability on an Internet-facing identity server that attackers are actively exploiting.
Both vulnerabilities may need to be fixed. They don’t necessarily deserve the same position in the queue.
What October Actually Taught Us
October 2026 gave us several useful examples of why context matters.
Brotli: A Real Emergency, With Important Boundaries
CVE-2026-111497 affects the Brotli decoder, a widely used compression component. Specially crafted compressed input can cause memory corruption and may allow information disclosure, denial of service, or arbitrary code execution in an affected application.
This isn’t imaginary risk. Microsoft issued out-of-band updates for affected .NET versions, AWS warned that the issue reached beyond Node.js, and CISA added it to the Known Exploited Vulnerabilities catalog on October 27.
Those are strong signals. Known exploitation, untrusted remote input, and a component embedded across several software ecosystems make this an urgent investigation.
But “Brotli is everywhere” isn’t the same as “everything using Brotli is remotely exploitable.” An application must include a vulnerable implementation and process attacker-controlled Brotli data through the affected code path. Some products bundle their own copy. Others use a system library. Some expose decoding to untrusted input. Others don’t.
The useful message is: move quickly, determine where the risk is real, and prioritize exposed applications that decode untrusted content.
PHP2Shell: Exploitation Changes the Conversation
The two PHP vulnerabilities known as PHP2Shell, CVE-2026-109618 and CVE-2026-109619, also deserve urgency.
Amazon Threat Intelligence reported attempts targeting its MadPot sensors beginning October 17, four days before public disclosure. AWS later described broad exploitation attempts after patches and proof-of-concept material became public. The vulnerabilities can enable unauthenticated remote code execution under affected conditions, and the complete fix is to upgrade to a patched PHP release.
Since those initial warnings, Dream Research documented a campaign that chained PHP2Shell with a Linux privilege-escalation vulnerability to compromise 24 PAN-OS firewalls and an internal management server. Three of the systems were associated with a U.S. government-affiliated environment. The attacker reportedly used an exposed management interface as the starting point and later conducted Active Directory-related activity.
That is real impact, not simply scanning or activity against a honeypot. It is materially different from a theoretical critical vulnerability with no known exploitation. Organizations should patch supported versions, identify unsupported installations, review available indicators, and pay particular attention to forgotten websites and management interfaces exposed to the Internet.
Still, the number of websites that use PHP is not the number of vulnerable, exposed, exploitable websites.
Technology-usage statistics often get transformed into enormous vulnerable-install counts. Those numbers may include patched versions, systems behind protective controls, configurations that do not meet exploit conditions, duplicate observations, and applications that are not reachable by an attacker. The Censys exposure tracker is especially clear that its figures describe observed services and reported versions, not confirmed exploitable organizations.
A large denominator tells us the potential blast radius. It does not tell an individual organization its actual exposure.
PHP2Shell is a genuine threat. Inflating the affected population does not make it more genuine. It makes the communication less precise.
VMware: One Advisory, Several Different Risks
Broadcom’s VMSA-2026-0006 is an almost perfect example of why we should read past the advisory headline.
The advisory is rated Critical because it includes two vCenter vulnerabilities scored as high as 9.8 and an ESX VMXNET3 flaw that can allow a guest administrator to execute code on the host. Those are serious issues.
The same advisory also includes CVE-2026-41709, an insufficient logging vulnerability in ESX with a CVSS score of 2.7. Broadcom said it had no information suggesting that any of the issues in the advisory were being exploited in the wild at the time of publication.
If someone reports that “VMware released a critical advisory for CVE-2026-41709,” the words sound plausible but the meaning is wrong. The advisory is critical. That individual CVE is low severity. When scanners, bulletins, and headlines inherit the most alarming label available, five different risks arrive as five identical emergency tickets.
Binance: What a Real Emergency Looks Like
Late in the month, Binance disclosed unauthorized withdrawals with an estimated impact of approximately $6.3 billion. The company paused withdrawals, worked with partners to freeze affected assets, engaged law enforcement, and committed to covering the losses.
That isn’t a vulnerability score, a theoretical install count, or a prediction about what might happen. Money moved. Services were interrupted. Investigators began tracing billions of dollars. That is a material security emergency.
Binance initially said a compromised DevOps engineer’s laptop may have allowed an attacker to reach a service container and submit unauthorized withdrawal transactions. The company later said investigators had identified additional points of breach. Until the postmortem is complete, we should resist compressing a multistage incident into a story about one employee’s laptop.
The useful questions involve authorization boundaries, transaction controls, separation of duties, monitoring, and how access to one operational system could produce consequences of that magnitude.
AI Changes the Economics, Not the Fundamentals
Cybersecurity has never depended on flawless systems. We have always operated with forgotten servers, overly broad permissions, brittle integrations, weak processes, and controls that work until an unexpected condition appears.
What limited some of the damage was the cost of finding and exploiting those weaknesses. Attackers needed enough knowledge, time, infrastructure, and persistence to examine a target and develop a useful path through it.
AI reduces several of those costs.
It can help more people understand unfamiliar technologies, automate reconnaissance, analyze large amounts of technical information, and test potential attack paths more quickly. Anthropic recently reported that an unreleased research model developed five exploit chains against major browsers and operating systems. Its Chrome research resulted in 62 patched CVEs, including sandbox escapes.
Dream Research also found Claude Code and an AI-enabled offensive security platform in the PHP2Shell attacker’s environment. That is noteworthy, but it is not proof that AI created the exploit or conducted the attack. Dream explicitly said it had no direct evidence of that connection.
AI did not invent insecure software, and it doesn’t turn every inexperienced attacker into a nation-state operator. It increases the number of people who can examine our existing weaknesses and the speed at which they can do it.
That doesn’t mean the sky is falling. It means relying on attacker scarcity is becoming a poor security strategy.
The Incentives Behind the Alarm
No single group created this problem. The incentives simply line up across the industry.
Vendors want customers to install fixes quickly. Researchers and security companies compete for attention and business. Media outlets compete for readers, and “potentially affects millions” travels farther than “exposure depends on configuration.”
That doesn’t mean the research is wrong or the warning is dishonest. It means nearly every stage of the communication chain benefits from emphasizing the largest plausible impact. Very few participants are rewarded for saying, “This is important, but we still need to learn whether it matters to you.”
Names and logos amplify the effect. They can help defenders discuss a complicated weakness, but they also turn it into a media event. “Black October” does the same thing by bundling unrelated vulnerabilities, patches, and incidents into one ominous narrative. That may describe how the month felt. It isn’t a defensible way to prioritize work.
KEV Is Powerful, but It Is Not the Entire Risk Model
CISA’s Known Exploited Vulnerabilities catalog is one of the most valuable prioritization signals we have. If a vulnerability is in KEV, defenders should treat that as evidence that exploitation is not merely theoretical.
But a KEV listing still answers only one question: has reliable evidence shown exploitation in the wild?
It doesn’t tell you whether the vulnerable product exists in your environment, whether the affected function is reachable, whether the system is exposed, what privileges an attacker would gain, or what business process could be disrupted.
KEV should raise priority. It should not replace asset context.
That is consistent with the framework I have used throughout Between The Hacks. Start with what is exposed. Add evidence of exploitation. Understand the potential impact. Then consider the controls already in place and the cost of remediation.
A Better Way to Communicate Vulnerability Risk
Security teams can improve the conversation by separating five questions that often get compressed into one score:
Are we affected? Do we actually run the vulnerable product, component, or version?
Are we exposed? Can an attacker reach the vulnerable functionality with the access they are likely to have?
Is exploitation practical? Is there a working exploit, evidence of active exploitation, or a realistic path to weaponization?
What happens next? What data, systems, identities, or business processes become reachable after compromise?
What can we do now? Is there a patch, mitigation, isolation option, detection, or compensating control?
Then communicate the answer in plain language.
“Critical, patch immediately” is easy to write. “Actively exploited on the Internet, present on three public servers, remote code execution possible, patch available, no evidence of compromise” is a decision.
Leaders also need uncertainty stated clearly. If we do not know whether exploitation is reliable, say that. If an install count represents potential presence rather than confirmed exposure, say that. If a vendor advisory contains vulnerabilities with very different preconditions and impacts, separate them.
Precision does not weaken an urgent message. It gives the message credibility.
Do Not Confuse Skepticism With Complacency
There is a risk in writing an article like this. Some people will hear “not every vulnerability is an emergency” and interpret it as permission to delay patching.
That isn’t the argument.
Brotli and PHP2Shell show why organizations need fast inventory, rapid triage, and the ability to deploy fixes under pressure. The time between disclosure and exploitation can be measured in hours, and sometimes exploitation begins before public disclosure. The volume of new vulnerabilities is also growing, a problem I discussed in The Mythos Discovery.
We need to move faster. But speed without prioritization is just panic with a ticketing system.
There’s another cost to calling everything an emergency: people get tired.
Security teams don’t have unlimited time or attention. Every emergency patch requires someone to identify what’s affected, understand the exposure, test the fix, negotiate downtime, deploy the update, and verify that nothing broke.
If everything is a P1, the most dangerous vulnerability competes with hundreds of merely severe findings. Maintenance windows fill up. Leaders lose confidence in security reporting. Eventually, “emergency” starts to mean “we haven’t evaluated it yet.”
The confirmed PHP2Shell campaign doesn’t prove that the largest predictions were correct, just as a limited number of confirmed victims doesn’t prove the warnings were unnecessary. Patching and existing defenses may have prevented some of the feared damage. A crisis that was successfully managed can look, in hindsight, like a crisis that never existed.
The answer isn’t to stop sounding alarms. It’s to make them more useful. Tell defenders what’s being exploited, what makes exploitation possible, which systems are exposed, and what evidence would justify interrupting everything else.
That’s how we keep genuine warnings from being ignored.
Final Thoughts
October was not quiet. Several of the month’s vulnerabilities deserve immediate attention, and organizations that run affected, exposed systems should act.
But the lesson of “Black October” should not be that the Internet survives only because everyone patches everything at once.
The lesson is that cybersecurity needs a better vocabulary for risk.
CVSS describes severity. KEV identifies known exploitation. Install counts suggest reach. Vendor advisories explain affected products and fixes. Researchers add technical detail. Headlines help people notice.
None of those signals, by itself, tells you what your organization should do first.
That takes context. What do we run? What is exposed? What is being exploited? What matters to the business? What can an attacker do next?
Those questions are less dramatic than “Is this the next global cyber emergency?”
They are also the questions that keep organizations secure.
Patch with purpose. Communicate with precision. Save the word emergency for the moments when it helps people make a better decision.
