Black October 2026: When Cybersecurity Became a Horror Movie (And My Coffee Couldn't Keep Up)

PHP2Shell, Node.js, Fortinet, compromised certificates, poisoned software packages, and a never-ending parade of security advisories. Welcome to October 2026, where the real horror isn't Halloween. It's the vulnerability dashboard.

There's something rather appropriate about the cybersecurity industry deciding to have a collective meltdown in October.

Halloween decorations are going up. Pumpkins are appearing on doorsteps. People are preparing to dress up as ghosts, zombies, and monsters.

Meanwhile, those of us working in cybersecurity don't need costumes.

We've already got the dark circles under our eyes, the suspiciously high caffeine consumption, and the thousand-yard stare of someone who just discovered another internet-facing server running a vulnerable software version.

Welcome to Black October 2026.

The name has been circulating informally in parts of the security community, and after this week, I think it's rather fitting.

Not because we've confirmed some coordinated, world-ending cyberattack. We haven't.

But because the volume of vulnerabilities, supply-chain incidents, and security advisories arriving in such a short period has been absolutely ridiculous.

And somewhere in the middle of this circus, security professionals like myself are trying to answer three seemingly simple questions:

1. Do we have anything affected?
2. How badly could it hurt us?
3. Who owns the system, and how quickly can we fix it?

That third question, as anyone working in enterprise security knows, is occasionally more difficult than the vulnerability itself.

So grab a coffee. Preferably something strong enough to double as industrial degreaser.

Let's talk about what's happening.

The October Cybersecurity Avalanche

Normally, cybersecurity follows a somewhat predictable rhythm.

A vulnerability gets disclosed. Security researchers investigate. Vendors publish updates. Security teams identify affected assets, assess their exposure, and work with system owners to schedule remediation.

Sometimes it's urgent. Sometimes it's routine.

And sometimes October 2026 walks through the door, flips over the coffee table, and announces that we're doing everything simultaneously.

Consider just a few of the issues that landed this month:

• PHP2Shell: Two critical PHP vulnerabilities potentially allowing unauthenticated remote code execution.
• Node.js: A security release addressing multiple vulnerabilities, including memory corruption, DNS handling, and TLS certificate validation.
• Fortinet: Coordinated security updates affecting FortiOS, FortiManager, and FortiAnalyzer.
• LiteLLM: A compromised software release containing credential-stealing malware.
• eMudhra: Certificate-authority trust problems involving weak cryptographic keys.
• Zeabur: A cloud-platform security incident involving access to environment variables and other sensitive information.

And those are just the incidents I'm choosing to focus on.

Additional reports throughout October have involved developer platforms, ransomware operations, cloud services, networking infrastructure, compromised software updates, and AI-assisted intrusion activity.

Not every report has been independently confirmed. Not every incident represents the same level of risk. And not every organization will be affected.

But collectively?

It's enough to make you wonder whether somebody accidentally enabled chaos mode on the internet.

PHP2Shell: When Your Web Server Becomes Someone Else's Playground

Let's start with PHP, because this one deserves everyone's attention.

On October 21, 2026, the PHP project released security updates addressing two critical vulnerabilities:

CVE-2026-109618 and CVE-2026-109619

Both received critical severity ratings of CVSS 9.2 and can potentially allow unauthenticated remote code execution.

For anyone unfamiliar with that terminology, let me translate.

An attacker may be able to convince a vulnerable server to execute code without first needing legitimate credentials.

That's bad.

That's put down your coffee and check the inventory bad.

What makes PHP2Shell particularly concerning?

These aren't simply vulnerabilities in a particular WordPress plugin or an obscure web application.

They affect PHP itself.

One involves corruption during out-of-memory handling. The other involves stale global state and unsafe memory handling.

In certain circumstances, manipulating how PHP processes a request can result in memory corruption and potentially code execution.

The PHP project specifically identifies Apache installations using mod_php as a particularly concerning deployment scenario, with exploitation demonstrated before normal application code begins executing.

That's important because traditional application-layer protections cannot necessarily prevent a vulnerability that occurs before the application gets an opportunity to inspect the request.

The affected deployment landscape also includes PHP-FPM, CGI-based deployments, and other PHP runtimes, although actual exploitability and exposure depend on configuration.

The patch situation

The October 21 releases include:

Older, unsupported branches require special attention because they may not have an official supported fix.

And here's the uncomfortable part: the PHP security team has explicitly stated that there are no complete mitigations that replace updating.

A web application firewall, restricted connectivity, and monitoring might reduce exposure, but none should be treated as a guaranteed fix.

Why this matters to my day

PHP is everywhere.

Websites, internal applications, legacy administration portals, content management systems, and those mystery servers someone deployed seven years ago and apparently forgot existed.

The challenge isn't necessarily running the update.

It's finding every installation.

Especially the one called webserver-old-final-v2 that nobody remembers owning.

You'd be surprised how often cybersecurity turns into digital archaeology.

Except instead of finding ancient pottery, we find unsupported PHP versions and expired certificates.

Honestly, the pottery sounds more relaxing.

Reference: PHP Security Releases — October 21, 2026

Node.js: Because Apparently JavaScript Needed to Join the Party

Just when the PHP inventory starts looking manageable, Node.js decides it's feeling left out.

On October 21, Node.js released security updates for its supported 22.x, 24.x, and 26.x branches.

The release addresses ten security issues, including four classified as High severity.

One of the more concerning vulnerabilities is:

CVE-2026-111497 — Node.js Brotli Decoder Out-of-Bounds Write

Brotli is a compression technology used to reduce the size of data transmitted between applications and services.

Under affected conditions, the vulnerability can result in an out-of-bounds memory write and potentially remote code execution.

That's the kind of sentence that turns an ordinary morning into a very long afternoon.

But it doesn't stop there

The release also addresses weaknesses involving TLS hostname validation and DNS resolution.

For example:

• CVE-2026-105482 involves DNS name truncation when a NUL character is present.
• CVE-2026-105483 involves a TLS hostname validation bypass involving fullwidth digits.
• CVE-2026-106069 affects TLS hostname validation when a hostname is interpreted as an IP address.

These issues are important because certificate validation and name resolution are foundational security controls.

If an application incorrectly determines which endpoint it's communicating with, supposedly secure connections may not provide the protection developers expect.

The actual risk depends on how an application uses the affected functionality.

Fixed Node.js versions

The real headache: dependencies

Finding Node.js installed on a server is relatively straightforward.

Finding every application, container, build pipeline, development environment, and third-party tool that uses a vulnerable Node.js runtime?

Now we're having fun.

And by fun, I mean staring into a vulnerability scanner until the numbers lose all meaning.

You also need to distinguish between applications that actually expose vulnerable functionality and those where the vulnerable code path may never be reachable.

It's not enough to scream "PATCH EVERYTHING!" and throw your keyboard across the room.

Although I suspect a few keyboards have seriously considered early retirement this week.

Reference: Node.js October 21, 2026 Security Releases

Fortinet: The Firewall Is Supposed to Protect Me, Not Add to My To-Do List

Now we're getting into something particularly close to my heart.

Network security infrastructure.

Firewalls. Centralized management. Logging platforms.

The systems that are supposed to protect everything else.

On October 22, Fortinet released coordinated security updates affecting several important products, including FortiOS, FortiManager, and FortiAnalyzer.

Recent updates also affected FortiMail and FortiAuthenticator.

Fortinet has described this as a coordinated security-hardening effort involving vulnerabilities identified through advanced, AI-assisted security testing.

The vendor has advised customers to prioritize the updates, especially where systems are internet-facing.

Why this is different from updating a regular application

Updating a web application is one thing.

Updating firewalls that handle production traffic, VPN connectivity, security inspection, and network segmentation?

That's a different conversation.

Before applying firmware to critical networking infrastructure, there's a reasonable checklist:

• Verify affected versions and approved upgrade paths.
• Review known issues and platform compatibility.
• Confirm backups are available and restorable.
• Validate HA configurations and failover behaviour.
• Schedule suitable maintenance windows.
• Coordinate with application and infrastructure owners.
• Verify connectivity and security functionality after the upgrade.

And that's assuming everything goes according to plan.

Anyone who's worked with enterprise network infrastructure knows that according to plan is a charming little phrase we use to make change requests feel better.

What about the vulnerabilities themselves?

As of October 23, not all technical details and associated CVEs for the coordinated Fortinet updates have been publicly disclosed.

Fortinet has indicated that additional public advisories are planned for November 10.

That means we should not pretend to know every exploit condition or claim that every affected version is actively being exploited.

What we do know is that the vendor is recommending accelerated updates and that the affected products occupy sensitive positions within enterprise environments.

Compromising a security management platform can have a much wider operational impact than compromising an isolated workstation.

And vulnerabilities in edge infrastructure deserve particular attention because these systems frequently sit at important network trust boundaries.

The patching reality

Fortinet's October release identifies updated versions across multiple supported branches.

For example, the listed FortiOS fixes include:

FortiManager and FortiAnalyzer have their own updated builds, which must be checked against product-specific release notes and supported interoperability requirements.

This isn't a situation where blindly upgrading every device to the newest version is automatically the best approach.

Network security engineers still need to consider compatibility, upgrade paths, dependencies, and operational stability.

Because security isn't just about keeping attackers out.

It's also about making sure the business still functions after you've secured it.

A perfectly secure network that nobody can use is technically impressive, but probably won't win you Employee of the Month.

Reference: Fortinet Coordinated Security Hardening Release

Software Supply Chains: Even Your Updates Need a Background Check

If critical vulnerabilities weren't enough, October has also reminded us that the software supply chain remains a particularly attractive attack surface.

And some of the incidents are frankly unsettling.

LiteLLM: A malicious software release

On October 21, LiteLLM disclosed that its software-release pipeline had been compromised.

An attacker managed to distribute malicious version 1.107.0 through PyPI and Docker distribution channels.

According to the project's incident report, the malicious artifacts contained credential-stealing malware and remote-code-execution tooling.

Several Docker image tags were temporarily affected, including tags commonly used to retrieve the latest release.

The compromised artifacts were subsequently removed or replaced, but the incident creates an important distinction.

Updating a compromised package doesn't automatically undo the damage caused by running it.

If credential-stealing malware executed, defenders need to investigate potential secret exposure, rotate affected credentials, inspect relevant systems, and rebuild from trusted artifacts where appropriate.

This is why software supply-chain security cannot consist entirely of running pip install and hoping for the best.

Neither can it consist of trusting Docker's latest tag like it's a reliable childhood friend.

Spoiler: latest is not a security strategy.

Zeabur: The risk of cloud-platform secrets

Zeabur disclosed a security incident involving compromised internal credentials and unauthorized access to infrastructure and sensitive platform data.

Its preliminary report describes attackers accessing environment variables, account information, and project-related data.

Environment variables are particularly interesting because modern applications frequently use them to store sensitive configuration information.

API keys. Database credentials. Access tokens. Cloud service secrets.

All those things we carefully avoid committing to GitHub, only to discover they might be exposed through a different part of the infrastructure.

Once secrets are exposed, the affected organization may need to rotate them across multiple interconnected systems.

One leaked credential can trigger a surprisingly large amount of remediation work.

eMudhra: When trust itself becomes the problem

Another troubling October development involved eMudhra and weaknesses affecting certificate-authority keys.

Certificate authorities underpin much of the trust used in HTTPS and other certificate-based systems.

When that trust is weakened, the implications can extend beyond one individual website or application.

The incident highlights the importance of certificate trust-store updates, cryptographic key management, and understanding how applications validate remote identities.

The interesting part?

Your website might be properly configured, your TLS settings might be excellent, and your certificate might appear valid.

But if a trusted part of the certificate ecosystem is compromised or weakened, some of those assumptions need to be re-evaluated.

It's rather like discovering the person checking everyone's identification at the door has been handing out duplicate keys.

Suddenly, the problem is bigger than who's standing in the hallway.

References:

• LiteLLM October 21 Incident Report
• Zeabur Security Incident Updates

The Real Horror: Finding Everything That's Actually Vulnerable

Here's what I think gets lost in many cybersecurity headlines.

The vulnerability itself is often only the beginning of the workload.

An advisory arrives and says something terrifying like:

Critical remote code execution. Unauthenticated. Network exploitable. Patch immediately.

Wonderful.

Now comes the real work.

Where is this software deployed?

Which applications depend on it?

Does the affected version exist inside any container images?

Are the assets internet-facing?

Is the vulnerable code path reachable?

Is there a compensating control?

Who owns the application?

Can we safely patch it?

What happens if we don't?

What happens if the patch breaks production?

And why does the asset inventory still list a server that was supposedly decommissioned in 2021?

Vulnerability management isn't just vulnerability scanning

A scanner can tell you a server has vulnerable software.

It cannot always tell you whether that particular vulnerability is exploitable in the actual environment.

It might not even see embedded runtimes, dormant applications, dependencies inside container images, or shadow IT deployments.

Likewise, a critical CVSS rating tells us about severity under defined conditions.

It doesn't automatically tell us which vulnerability represents the greatest risk to our organization.

For that, we need context.

I spend a significant amount of time thinking about the intersection of four things:

Severity + Exposure + Exploitability + Business Impact

A critical vulnerability on an isolated, tightly controlled system may deserve a different immediate response than a High-severity vulnerability on a publicly accessible service with demonstrated active exploitation.

That doesn't mean ignoring the critical issue.

It means prioritizing intelligently.

When everything has a red warning label, colour-coding alone stops being particularly useful.

My Black October Survival Strategy

After a week like this, I think every security professional deserves two things.

A decent cup of coffee.

And an asset inventory that doesn't require detective work.

Unfortunately, the second one is surprisingly difficult to obtain.

Here's how I approach periods of concentrated vulnerability disclosure.

1. Stop treating every headline as an equal emergency

A vulnerability disclosure, a confirmed compromise, a ransomware group's unverified claim, and an actively exploited zero-day are not the same thing.

They require different responses.

I start with authoritative vendor advisories, credible technical analysis, available indicators of compromise, and evidence of exploitation.

Then I determine whether the affected technology actually exists in the environment.

The goal is to avoid both panic and complacency.

2. Prioritize internet-facing infrastructure

Publicly exposed systems are frequently the first places I want to investigate.

That includes:

• Firewalls and remote-access services.
• Public web applications and their underlying runtimes.
• Reverse proxies and application gateways.
• Cloud-hosted application services.
• Exposed administrative or management interfaces.

But external exposure isn't the only concern.

Internal management platforms, high-privilege identities, software distribution systems, and widely trusted services may deserve equal urgency because of their potential blast radius.

3. Inventory versions, not just product names

Knowing that an environment uses Node.js isn't enough.

I need to know which version, where it's running, which application owns it, and whether the runtime is actually affected.

The same applies to PHP installations, Fortinet devices, Docker images, build agents, and third-party software.

If your vulnerability-management process doesn't connect software versions to real assets and owners, you're going to have a difficult week.

Ask me how I know.

Actually, don't.

I haven't finished the coffee yet.

4. Don't confuse compensating controls with patches

Restricting management access, removing unnecessary internet exposure, enforcing stronger access controls, and increasing monitoring can reduce risk.

These controls are useful, especially when a production patch needs testing.

But they aren't magical.

If the vendor says there is no complete mitigation, believe them.

The goal of a compensating control is to reduce exposure while remediation is underway, not provide an excuse to leave the vulnerable software running indefinitely.

5. Remember that a supply-chain compromise is different

When an ordinary vulnerability is patched, the immediate technical exposure may be resolved.

When malicious software has actually run, the response becomes much broader.

Now we need to consider:

• Credential theft and secret rotation.
• Persistence and unauthorized access.
• Container and host integrity.
• Pipeline and artifact trust.
• Scope of compromise.
• Investigation and recovery.

This is incident-response territory, not just routine patch management.

And yes, that probably means another coffee.

6. Document everything and keep communicating

Security professionals sometimes become so focused on fixing the issue that we forget the importance of communication.

Stakeholders need useful answers.

Not a fifty-page vulnerability report filled with acronyms.

They need to know what's affected, how serious the actual exposure is, what's being done, and when the risk is expected to be reduced.

Tracking vulnerable assets through to remediation is essential.

Because the words we're working on it are not the same thing as a completed fix.

AI Is Accelerating the Security Arms Race

One interesting aspect of October's disclosures is the growing role of AI in security research.

Fortinet specifically described using advanced AI-assisted testing to help identify vulnerabilities in its own products.

This is an encouraging development.

AI-assisted analysis can help uncover unusual code paths, generate test cases, identify potentially unsafe behaviour, and support researchers investigating complex software.

But here's the uncomfortable reality.

Defenders aren't the only ones gaining access to these capabilities.

Attackers can also use AI to assist with reconnaissance, analyze software behaviour, improve malicious content, and accelerate parts of their operations.

That doesn't mean AI has suddenly made every attacker unstoppable.

It means the cost and time required for some security activities are changing.

For defenders, this could create significant opportunities to improve vulnerability discovery and remediation.

But those improvements only matter if organizations have processes capable of responding to what gets discovered.

Finding vulnerabilities faster is wonderful.

Unless the patching process is still moving at the speed of a government fax machine.

The Industry Doesn't Need More Panic. It Needs Better Visibility.

There's a temptation during weeks like this to assume cybersecurity is spiralling completely out of control.

I don't think that's the right conclusion.

Some vulnerabilities being disclosed now are the result of increasingly capable security research.

Better testing means more problems are being found.

That's good.

Vendors releasing security updates before attackers can exploit undisclosed issues is also good.

But disclosure volume creates a very real operational challenge.

Organizations need accurate asset inventories, clear ownership, defined vulnerability-management procedures, dependable change processes, and tested incident-response plans.

Without those foundations, each new critical advisory turns into a scavenger hunt.

And nobody enjoys a scavenger hunt where the prize is discovering a production server running an unsupported operating system.

The bigger lesson from Black October

What concerns me most isn't the number of CVEs.

It's how interconnected our environments have become.

A vulnerable runtime affects applications.

A compromised package affects build pipelines and production deployments.

A cloud platform incident affects customer credentials and workloads.

A certificate-authority problem challenges assumptions about trusted communications.

A vulnerable firewall or management appliance threatens the infrastructure we rely on to enforce security.

These aren't isolated technical concerns anymore.

They're operational risks tied together by dependencies, trust relationships, and systems that often span multiple teams and providers.

Cybersecurity professionals don't just need better vulnerability scanners.

We need better ways to understand how all those pieces fit together.

Final Thoughts: Can We Please Have a Normal November?

October 2026 has been one of those stretches where every time I think I've caught up, another security advisory appears.

PHP needs patching.

Node.js needs reviewing.

Fortinet releases need evaluating.

Software dependencies need checking.

Cloud-provider incidents need investigating.

And somewhere, a system owner is replying to an urgent security email with:

"Is this really critical? We haven't updated that server in years and it's been fine."

Yes.

That is precisely what worries me.

The truth is, cybersecurity isn't about preventing every vulnerability from ever existing.

That's impossible.

It's about understanding your exposure, reacting intelligently, prioritizing the highest risks, and making sure the technology supporting your organization remains trustworthy and operational.

For me, Black October has reinforced something I've believed for a long time:

You cannot secure what you don't know exists, and you cannot prioritize what you don't understand.

So to everyone in cybersecurity spending their evenings reviewing advisories, hunting down application owners, validating software versions, and trying to negotiate emergency patch windows:

I hope your asset inventory is accurate, your backups are current, your change requests are approved, and your coffee machine is functioning.

Because if the coffee machine goes down too, that's not a high-severity incident.

That's a full-blown disaster recovery event.

Stay patched, stay caffeinated, and please, for the love of all things secure, stop deploying production software with the latest tag.

— Brewing Bytes & Beans

Further Reading & Official References

• PHP — Security Releases and Advisories
• Node.js — October 2026 Security Release
• Fortinet — Coordinated Security Hardening Release
• Fortinet PSIRT Advisories
• LiteLLM — October 21 Security Incident
• Zeabur — Security Incident History
• CISA — Known Exploited Vulnerabilities Catalog

Editor's note: This article reflects information available as of October 23, 2026. Some investigations and coordinated vulnerability disclosures remain ongoing. Technical details, affected versions, and remediation recommendations may change as vendors publish further updates.