Black October: The Week Cybersecurity Broke

Trend Micro’s Zero Day Initiative (ZDI) ignited “Black October” on October 22nd, when it mistakenly published a cache of unpatched Linux kernel vulnerabilities to the public Linux Kernel Mailing List, rather than the private security list. Linux stable maintainer Greg Kroah-Hartman-Hartman publicly challenged ZDI on the list, demanding an explanation for the premature disclosure of zero-day exploits.

Critically, the leak exposed two severe Server Message Block (SMB) vulnerabilities, both rated CVSS 9.0 and capable of remote code execution. One flaw, an integer underflow in SMB Direct (ZDI-CAN-33549), allowed buffer overflows by manipulating buffer size values. The second, a race condition in ksmbd (ZDI-CAN-33774), enabled unauthenticated remote code execution.

The reports landed before fixes were broadly available, exposing millions of systems. This was not a deliberate publication or evidence of an active attack, but rather an accidental disclosure, underscoring the escalating pressure on coordinated vulnerability disclosure. SMB’s design, processing external network data for file sharing, made these bugs particularly dangerous, reminiscent of the 2017 WannaCry epidemic.

Server Message Block, or SMB, is the network protocol that enables sharing files and folders. Its architecture makes it inherently dangerous: services handling incoming network data, like SMB, often run before login, making them reachable by unauthenticated attackers. This direct exposure to the internet amplifies the blast radius of any flaw.

We saw this danger firsthand in 2017 with WannaCry, a ransomware outbreak that exploited a Windows SMB vulnerability. While the current Linux bugs are distinct, WannaCry serves as a stark reminder of how quickly SMB flaws can compromise entire networks. The Linux kernel’s SMB vulnerabilities, both rated 9.0 on the CVSS severity scale, present similar remote code execution risks.

Beyond the critical SMB flaws, other reported issues include:

• Local privilege escalations in the networking stack (skb_zerocopy)
• A local privilege escalation in the VMware graphics driver (vmwgfx)
• An information leak in the NVMe target code (nvmet)

The exposure to these additional vulnerabilities varies dramatically based on system configuration and deployment. While not as immediately catastrophic as the SMB RCEs, these issues underscore the systemic fragility revealed during "Black October."

Black October wasn't just a Linux leak; it was a deluge. The accidental exposure of unpatched kernel vulnerabilities arrived amid a storm of critical security disclosures, pushing global organizations to the brink. Most notably, two severe PHP flaws (CVE-2026-109618, CVE-2026-109619) forced governments in France, the Netherlands, and Finland to take public websites offline for emergency patching.

This wasn't a coordinated attack, but rather simultaneous pressure from multiple fronts. Additional reports piled on:

• eMudhra’s certificate authority compromise, necessitating rapid browser-level revocations.
• A CVSS 10 GitLab bug dating back to 2014.
• A remote code execution fix in Node.js.
• Reports of unauthorized AI agents showing up in US bank accounts.

This wave of public disclosures, though intense, is not equivalent to a wave of confirmed attacks. Many of these issues, including the Linux kernel bugs detailed by Phoronix, had been discovered weeks or months earlier. Organizations were simply racing to patch them as they became public knowledge. Several Linux Kernel Vulnerabilities Accidentally Posted To Public Kernel Mailing List - Phoronix This "Black October" served as a stark preview: the bottleneck has shifted from finding bugs to fixing them fast enough.

AI accelerated discovery of legacy flaws, yet human-driven patching remains stubbornly slow. Maintainers now face a "vulnerability patch wave," as AI tools like Anthropic's Mythos uncover hundreds of critical bugs in products like SharePoint, vastly outstripping human capacity. Google's Chrome team, for instance, now ships security updates twice weekly.

This creates a shrinking window for defenders. Public fixes inherently reveal what changed, providing attackers a roadmap for exploit development. Simultaneously, defenders gain access to AI-assisted security tools, potentially leveling the playing field once the initial flood of easily discoverable bugs subsides.

Practical priorities emerge from this new reality. Organizations must:

• Inventory all internet-facing systems
• Update PHP and other affected software immediately
• Watch for Linux kernel fixes, checking if ksmbd is enabled
• Disable unused components
• Automate safe patching processes wherever possible

Patching must become a continuous operation, not a quarterly task. The NCSC recommends an "update by default" policy, prioritizing internet-exposed systems and replacing unpatchable legacy software.

What happened in the Linux kernel vulnerability leak?

Trend Micro’s Zero Day Initiative accidentally sent unpatched vulnerability reports to the public Linux kernel mailing list instead of a private security channel.

Why were the Linux SMB flaws considered dangerous?

The two reported flaws were rated CVSS 9.0 and could enable remote code execution in SMB-related code that processes network traffic.

Does the leak mean Linux systems were being actively attacked?

Not necessarily. The disclosure made the vulnerabilities public, but the video describes a broader wave of vulnerability disclosures rather than confirming attacks exploiting these specific flaws.

What should Linux administrators do?

Apply relevant distribution updates promptly, check whether ksmbd is enabled, and disable unused exposed services or components while awaiting fixes.