Black October 2026: critical vulnerabilities and solutions

Information verified as of October 24, 2026.

A system can keep ringing up sales, processing orders, and sending emails while one of its core components has a vulnerability that already has a fix.

That was the worrying part of October. In just a few days, relevant patches appeared for PHP, GitLab, Node.js, NGINX, Java, and Windows. Tools that sit behind online stores, enterprise applications, and services that many small and mid-sized businesses use without knowing exactly which versions they have installed.

We can call this cluster of alerts Black October 2026. It's an editorial name to sum up what happened, not the official designation of a coordinated attack. And it's worth clarifying because publishing a vulnerability doesn't mean every affected system has been attacked.

What happened during October

Between October 13 and 23, a series of notices piled up that deserves a review.

• October 13: Microsoft released updates for more than 1,400 vulnerabilities, according to Tenable's count. CISA added a Windows flaw with confirmed exploitation.
• October 14: NGINX fixed several flaws related to request processing, memory, and sessions.
• October 20: Oracle released its quarterly update with 1,295 new security patches spread across different product families.
• October 21: PHP, GitLab, and Node.js released important fixes. Oracle issued an additional alert related to Java certificates.
• October 23: PHP added a preventive recommendation for an unusual configuration that kept a residual risk.

Microsoft's and Oracle's numbers are not directly comparable: one counts vulnerabilities and the other counts patches distributed across products.

Sources: Tenable, Oracle, and PHP.

The vulnerabilities you should review

These are some of the most relevant alerts for a business environment. The list is not intended to include every CVE published during the month.

1. PHP: the risk was there before the application

PHP powers a large number of websites and administrative systems.

On October 21, your team released fixes for two vulnerabilities collectively known as PHP2Shell. Under certain conditions, an attacker without an account could execute code on the server.

The tricky part is that the flaw is in the PHP engine itself. Having a well-built form or using a well-known framework doesn't eliminate the problem of the vulnerable version.

What to do:

• Identify the actual version each site is running.
• Install the fix for the branch you're using.
• Check for provider updates if you use managed hosting.
• Plan your migration if you're still on PHP 8.1 or earlier, versions without official support from the project.
• Review logs and suspicious behavior if the server was exposed.

On October 23, PHP also recommended temporarily disabling file upload progress tracking in a very specific combination of configurations. That additional measure should be evaluated against the official advisory and does not replace the main updates.

Documentation: Official PHP advisory from October 2026.

2. GitLab: a 10-out-of-10 flaw

GitLab published CVE-2026-110264, a vulnerability that, under certain conditions, could allow unauthenticated code execution on installations managed by its own users.

The published score was CVSS 10.0.

Think of a company that stores its source code, automations, and configurations in its own GitLab instance. A vulnerability in that server requires reviewing both the application and the credentials and access it manages.

GitLab published the fixed versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13.

What to do: update the self-managed installation, check the versions in use, and review the indicators of possible exploitation attempts published by GitLab. GitLab.com had already been fixed by the provider.

Documentation: GitLab Critical Patch Release.

3. Node.js: requests and certificates that were not always validated correctly

Node.js fixed several high-severity vulnerabilities.

One of them, CVE-2026-111497, affects the processing of data compressed with Brotli. If an application decompresses malformed content controlled by an attacker, memory corruption and potentially remote code execution could occur.

There were also flaws related to TLS certificate verification and name resolution.

What to do: update to 22.23.4, 24.22.1, or 26.12.1, depending on the branch, and check whether your applications use the affected functions.

Versions that are out of support require special attention. Updating a small dependency does not automatically fix a vulnerability included in the main environment.

Documentation: Node.js Security Releases, October 21.

4. NGINX: configuration determines part of the risk

NGINX usually receives requests before they reach an application.

In October it fixed issues related to memory, HTTP/3, and TLS sessions. Its official listing classifies these flaws as medium severity, although other vendors assign higher scores to certain exploitation conditions.

Here, configuration matters.

A vulnerable feature that isn't enabled can pose a different exposure than the same feature published directly on the internet.

What to do: update to a patched version, review the affected modules and directives, and verify that the service keeps working after the change.

Documentation: NGINX Security Advisories.

5. Java and Oracle: updating once may not have been enough

Oracle released its quarterly update on October 20.

One day later, it issued an additional alert for CVE-2026-91403, related to intermediate certificates associated with eMudhra that should no longer be considered trusted.

The risk affects certain Java environments and depends on the use of the connections and components involved.

What to do: identify the exact Java distribution and version, check the extraordinary advisory from October 21, and apply the corresponding updates.

If your company uses an ERP or a commercial application developed in Java, validate the update with the vendor to avoid incompatibilities.

Documentation: Oracle Security Alert CVE-2026-91403.

6. Windows: here there was confirmed exploitation

The Windows vulnerability CVE-2026-96951 appeared in CISA's catalog of exploited flaws on October 13.

This changes the priority.

A flaw with confirmed attacks requires action before one whose exploitation is still hypothetical, especially if it affects equipment used to open external files or access important information.

What to do: install the applicable updates, verify the status of the equipment, and look for signs of abnormal activity.

An update eliminates the patched vulnerability, but it does not automatically erase the consequences of a previous attack.

Documentation: CISA advisory of October 13.

How to protect your company without stopping the entire operation

When many advisories appear at the same time, the usual mistake is trying to update everything without assessing what depends on what.

I would follow this order.

First: know exactly what you have

Make an inventory of applications, servers, operating systems, databases, and vendors.

Include tools that often go unnoticed: development servers, internal applications, legacy systems, and services managed by third parties.

Identify which ones are connected to the internet and which ones process sensitive information.

Second: rank the risks

Don't rely on the CVSS score alone.

A vulnerable system that receives public requests requires different attention than an isolated component that doesn't use the affected functions.

My prioritization criteria would be:

1. Vulnerabilities with confirmed exploitation.
2. Unauthenticated remote execution on exposed services.
3. High risks in systems that store important data.
4. Vulnerabilities whose exploitation requires specific configurations.
5. Remaining updates, based on impact and exposure.

If there are signs of compromise, activate the incident response procedure before treating it as routine maintenance.

Third: back up, update, and verify

Before modifying production, verify that a recoverable copy of the necessary data and configurations exists.

Test the changes in a separate environment when possible. Also prepare a procedure to roll back to a working version if the update fails.

Afterward, check that orders, payments, access, and other critical processes are working.

A successful installer run isn't enough. You need to verify the version that actually ended up running.

This approach aligns with the NIST SP 800-40 Rev. 4 guide, which treats patch management as preventive maintenance.

The documentation that should have existed before October

Here I find one of the most costly problems for a small business: depending on someone remembering how everything is configured.

At a minimum, I would keep a log with these fields:

For custom-built applications, it's also a good idea to keep an inventory of dependencies.

There's even a documentation standard called SBOM, the equivalent of an ingredient list for software. It lets you know which components an application uses without having to rebuild everything when an alert comes up.

The 2026 international SBOM guide offers a reference to get started.

The problem with abandoned versions

There's a difference between a system that needs an update and one that no longer receives official fixes.

The second one may require a full migration.

That means budget, testing, compatibility, and time. Ignoring it because the system still works only postpones a decision that can end up costing more later.

My recommendation is to keep a support calendar. Every platform should have its end-of-maintenance date on record, along with a decision about its replacement.

If you can't update right away, limit exposure, use the mitigations recognized by the vendor, and document the outstanding risk.

My takeaways

October left a pretty concrete lesson: you need to know which components keep your operations running and who responds when one of them fails.

A small company doesn't need to buy every cybersecurity tool out there.

It needs an up-to-date inventory, planned updates, backups it can actually recover, and someone responsible for verifying changes.

It also needs to tell a published vulnerability apart from a confirmed attack. Mixing the two ends up creating bad priorities.

Conclusion

October 2026 concentrated important vulnerabilities in technologies used by companies of all sizes.

Fixes exist for a good portion of the documented cases. What's missing in many organizations is the process to identify them, install them, and verify them.

The next alert could affect a different technology. Having your infrastructure and its dependencies documented will make responding a planned task instead of an improvised emergency.

References

• PHP: October 2026 security notices
• GitLab: Critical Patch Release 19.5.1