The week leading up to October 25, 2026, was every cyber defender’s nightmare: a barrage of critical vulnerabilities in PHP and the Linux kernel, a compromised LiteLLM release, a maximum-severity flaw in GitLab, a Node.js Brotli flaw, and a certificate authority incident affecting TLS trust.
A few years ago, a backlog like this would have filled a defender’s to-do list for a whole month. In the age of AI, all of this was reported within a single “Cybersecurity Black Week,” an exceptionally eventful seven-day period amid an already turbulent Black October. AI-assisted research helped uncover at least two of these flaws: PHP2Shell and the Brotli bug. On top of the breakneck patching pace, security teams faced mounting pressure to deliver status reports to other departments, management, customers, and the media.
Beyond their severity, the issues stood out for the variety of responses they demanded. Some required emergency runtime patches and upgrades; others called for containment, credential rotation, or the replacement of outdated certificate trust bundles. In several cases, installing the latest version was only the beginning of a long remediation process.
With so many problems landing at once, the main challenge was separating real risk from hype and prioritizing accordingly. Here is our assessment.
PHP2Shell: The loudest headline, with real-world limits
PHP2Shell generated the biggest media frenzy of the lot and, with it, a major headache for security teams, prompting many organizations to take their websites offline and look for emergency fixes. The name refers to two memory-safety vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, affecting PHP versions 5.4 through 8.5.11. Both vulnerabilities received a CVSS v4.0 score of 9.2 and can allow unauthenticated remote code execution (RCE) on vulnerable PHP servers. In the highest-risk setups, a demonstrated exploit can trigger the vulnerability before application code runs, meaning application-level authentication offers no protection.
With PHP powering an estimated 69% of websites whose server-side programming language is known, government agencies in the United States, Europe, and elsewhere urged organizations to patch immediately, with some advising that affected internet-facing systems be isolated or taken offline if they could not be patched promptly. Government websites in the Netherlands, Germany, France, and other countries were temporarily taken offline as a precaution. The PHP project released fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, along with source-only backports for the end-of-life 7.4, 8.0, and 8.1 branches. The rollout was complicated by a premature public leak, which forced the coordinated disclosure timeline forward.
While the flaws clearly belonged near the top of the patching list, early evidence suggested they were considerably harder to weaponize than initially feared. Successful exploitation requires specific conditions and knowledge of the target, and public proof-of-concept exploits did not work against a default PHP installation, according to Sansec.
On October 22, ESET was among nine security companies that told NBC News they had not seen any successful attacks, even though more than 200 proof-of-concept exploits were circulating. The remediation challenge extends beyond obvious web servers: PHP can also be embedded in appliances, network devices, management interfaces, and third-party products, while end-of-life PHP branches do not receive normal upstream binary releases.
Linux kernel: Reports went public before fixes were ready
As if the PHP issues weren’t severe enough, on October 21, Trend Micro’s Zero Day Initiative (ZDI) sent several reports on unpatched Linux kernel vulnerabilities to the kernel’s private security address while also copying public mailing lists. As a result, technical details of vulnerabilities for which fixes were not yet generally available became public, prompting stable kernel maintainer Greg Kroah-Hartman to question why the reports had been sent to public lists without patches.
The two most severe issues, both rated CVSS 9.0 by ZDI, affect KSMBD, the Linux kernel’s built-in SMB server. ZDI-CAN-33549 is an integer underflow in the SMB Direct path that could lead to RCE, while ZDI-CAN-33774 is a race condition that could also lead to RCE. Exploiting ZDI-CAN-33549 requires an RDMA-capable interface, a writable KSMBD share, and SMB Direct negotiation, significantly narrowing the number of systems exposed to that particular attack. Other reports concerned local privilege escalation vulnerabilities in the networking stack and the VMware graphics driver, as well as an information disclosure issue in the NVMe target code (NVMET).
To remediate, security teams had to track each report independently, consult distribution advisories, and restrict exposed services where practical while awaiting verified fixes. Kernel updates also required rebooting into the patched kernel and checking the running version, not merely confirming that a new package had been installed.
LiteLLM: Compromised, not merely vulnerable
On October 21, attackers published a malicious version of LiteLLM, 1.107.0, to PyPI and pushed compromised images to the project’s official container registries. According to the project’s incident report, its release pipeline was breached using GitHub CLI credentials associated with three developers. One of the stolen tokens belonged to an owner of the project’s GitHub organization, allowing attackers to disable branch protections and modify the release workflow to point to a lookalike repository. LiteLLM, a Python proxy for LLM providers, has about 23 million weekly downloads, and the malicious version remained available on PyPI for roughly two hours before it was quarantined. It was the project’s second supply-chain compromise of 2026, after malicious versions 1.82.7 and 1.82.8 appeared in March.
The payload combined a credential stealer with a second-stage remote access trojan (RAT). By abusing Python’s startup mechanisms, including a .pth file, it ran every time Python started, even if an application never imported LiteLLM. Execution therefore did not depend on exploiting an application flaw: simply running Python in an affected environment could be enough.
Affected environments had to be treated as potentially compromised, not merely vulnerable. According to LiteLLM, these included environments that ran litellm==1.107.0 and containers that executed affected images distributed under the v1.107.0, latest, main-latest, or main-stable tags during the compromised intervals. Removing or replacing the package was insufficient: teams needed to determine whether the malicious code had run, contain affected systems, rebuild from clean sources, and rotate exposed secrets from a clean environment. Cloud, source-control, and CI/CD logs also had to be reviewed for unauthorized activity.
Node2Shell: From Node.js to HTTP2Shell
Node2Shell (CVE-2026-111497) is an out-of-bounds write in Google’s Brotli decoder, which Node.js bundles. Malformed compressed input can cause crashes, memory disclosure, or potentially RCE when an application decompresses attacker-controlled Brotli data. This can happen through explicit decompression, compressed request bodies, or automatically decompressed responses. Node.js rates the flaw as high severity, while the broader Brotli vulnerability carries a CVSS v4.0 score of 9.2. According to Aikido, researchers demonstrated code execution against the official, unmodified Node.js 24.22.0 image on Linux ARM64. Although the exploit did not work on every attempt, the demonstration showed that exploitation was practical, if not universally reliable.
Node.js shipped fixes on October 21 in versions 22.23.4, 24.22.1, and 26.12.1, and Bun followed with version 1.4.4 or later. Node.js 25.x, 23.x, 20.x, and earlier releases are end-of-life and will not receive the fix. Within days, the story outgrew Node.js. The same decoder is compiled into the Python Brotli and brotlicffi packages as well as into other HTTP software, which led researchers to rename the issue HTTP2Shell. The operational challenge was therefore not simply upgrading a single runtime but identifying every container, serverless deployment, and library that bundles the vulnerable decoder. The issue was fixed upstream in Brotli 1.2.1. Notably, OpenAI’s Codex Security had reported the underlying bug, and the fix had been present in the Brotli source since February without being recognized as a security issue.
GitLab: Credential leaks and authorization failures
On October 21, GitLab shipped a critical out-of-band patch release (versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13) addressing 12 security vulnerabilities. The headline flaw, CVE-2026-110264, rated 10.0 under CVSS v3.1, is an integer overflow triggered when GitLab compiles a specially crafted regular expression. Under certain conditions, it could allow an unauthenticated attacker to execute arbitrary code on the server. The affected versions date back to GitLab 7.0.
The other fixes addressed credential exposure, cache poisoning, authorization bypasses, and failures to enforce membership or merge-request approval policies. Reported unauthenticated attack paths included exposure of sensitive credentials through internal response headers and manipulation of a shared OAuth/OIDC discovery cache, while other issues required authenticated access. GitLab did not publish individual severity scores or exploitability details for these issues.
GitLab.com and GitLab Dedicated were already patched, so the work fell on administrators of self-managed instances. GitLab strongly recommended upgrading immediately, but with a catch: the older backport releases (19.2.9, 19.1.9, 19.0.10, and 18.11.13) included only the critical fix, while the remaining 11 issues were fixed only in 19.3.6 and later. Administrators also had to verify that all deployment components had been updated and assess the potential exposure of credentials and private project data due to the fact that patching would not invalidate stolen credentials or reverse unauthorized changes.
eMudhra/emSign: Compromised certificate trust
The high-priority eMudhra/emSign incident involved no software vulnerability at all. Several eMudhra intermediate certificate authorities (CAs) had insecure private keys, meaning attackers could potentially create certificates that would be trusted through the affected emSign certificate chain. While browsers had updated their trust stores and revocation lists, some Python tooling continued to trust the compromised intermediate CAs through its own certificate bundles. This created a risk of man-in-the-middle (MITM) attacks against TLS connections, including those to python.org and pypi.org.
The Python Software Foundation urged users to upgrade immediately to at least certifi 2026.10.19, pip 26.2.2, and uv 0.13.4, and the Python core team shipped expedited releases 3.15.2, 3.14.10, 3.13.18, 3.12.16, and 3.11.18 to update the bundled pip. The updates had to reach every host, application, and existing virtual environment. Container images had to be rebuilt with layer caching disabled to fetch the latest system certificates. The decisive check was whether deployed clients rejected the compromised trust paths; simply upgrading Python was not enough.
Cutting through the noise
Cybersecurity Black Week showed that a severity score rarely tells the whole story. A 9.2-rated PHP flaw that attackers struggled to exploit, a 10.0-rated GitLab bug, exposed kernel reports with no patches, and a poisoned package that ran at Python startup each called for a different response. What they all had in common was a window of exposure: the time between disclosure and when the last affected system is patched. For the leaked kernel flaws, that window opened before any fix existed, and for end-of-life PHP versions, it may never fully close. This is where ESET’s multilayered protection comes in, using behavioural detection and other security mechanisms to help block exploitation attempts and keep systems protected until patches are applied.
At the same time, the signals defenders rely on were buried in noise, from scanning that was largely benign to a single behavioural rule firing hundreds of thousands of times in a week. What mattered most was quickly understanding which incidents actually affected an organization's environment and what each incident required. That is the problem ESET’s correlation engine, ESET LiveCortex, and its specialized cybersecurity model, ESET NeoCortex, are designed to solve: turning an overwhelming volume of raw data into understandable incidents so that defenders can act before attackers achieve their goals. To learn how they work, read Beyond the alert: How ESET is teaching AI to understand security incidents.
