The week leading up to October 25, 2026 packed in a string of incidents that tested security teams: critical vulnerabilities in PHP, the Linux kernel, and GitLab, a malicious version of LiteLLM, a flaw in the Brotli compression library used by Node.js, and a digital certificate incident that affected trust in certain TLS connections. Artificial intelligence (AI) helped uncover some of these issues, but the main challenge for defenders was figuring out which systems were actually exposed and what each incident required.
Cybersecurity’s Black Week in 30 seconds
- PHP and GitLab were behind two of the most severe alerts, with CVSS scores of 9.2 and 10.0, respectively.
- The Linux kernel racked up technical advisories about vulnerabilities whose patches were not yet available.
- A malicious version of LiteLLM could steal credentials and maintain access to affected environments.
- The Brotli flaw reached beyond Node.js, while the eMudhra incident forced a review of certificates and trust stores.
- The priority was identifying affected systems, containing possible attacks, and confirming that fixes had reached every deployment.
Piling up this many problems in just seven days illustrates a growing challenge for security teams: it’s no longer enough to rank alerts by severity score and roll out the available updates. Some vulnerabilities are hard to exploit in typical configurations; others let an attacker compromise an environment without even exploiting a flaw in the installed software. There are also cases where technical details become public before a fix is ready.
A report published by ESET on WeLiveSecurity, titled Lessons from cybersecurity Black Week, describes this string of incidents and their operational consequences. The analysis notes that AI-assisted research helped uncover at least two of the flaws, though each problem called for a different response.
From PHP to GitLab: a Critical Score Doesn’t Tell the Whole Story
PHP2Shell drew much of the media attention. The name covers two memory-safety vulnerabilities in the PHP core, tracked as CVE-2026-109618 and CVE-2026-109619. Both received a score of 9.2 out of 10 under the CVSS 4.0 system and could allow unauthenticated remote code execution on certain vulnerable servers.
The flaws affected PHP versions between 5.4 and 8.5.11. The project released fixes on October 21 for the 8.5, 8.4, 8.3, and 8.2 branches. It also prepared source-code fixes for some older branches that had already reached end of life.
The potential severity justified a quick response, especially on servers reachable from the internet. However, early testing showed that exploitation wasn’t as simple on every configuration. According to the research cited by ESET, the proof-of-concept exploits circulating publicly did not work against a default PHP installation. That didn’t eliminate the risk, but it did show that a high score alone doesn’t describe the likelihood of a successful attack.
PHP isn’t found only on conventional web servers, either. It can be embedded in network devices, management equipment, and third-party products, which can make locating every affected installation harder than updating a known set of servers.
GitLab presented the opposite scenario. On October 21, it released an out-of-cycle update fixing 12 vulnerabilities. The main one, tracked as CVE-2026-110264, received a CVSS 3.1 score of 10.0. The flaw stemmed from an integer overflow when processing specially crafted regular expressions and could allow arbitrary code execution on the server under certain conditions.
The update also fixed issues related to credential exposure, cache manipulation, and authorization controls. For organizations running their own GitLab instances, installing a fixed version was only part of the job: they also had to check which components had been updated and assess whether any secrets or private data could have been exposed.
The incident had another quirk. Some older versions released as backported fixes included only the critical flaw, while later versions incorporated the full set of patches. Because of that, confirming an installation was up to date didn’t always mean every vulnerability in the advisory had actually been resolved.
Linux and LiteLLM: When Installing a Patch Isn’t Enough
The Linux kernel case raised a different problem: technical details were disclosed before fixes were widely available.
On October 21, Trend Micro’s Zero Day Initiative sent reports on several kernel vulnerabilities to the project’s private security address, but also included public mailing lists. The early disclosure of the details drew criticism from Greg Kroah-Hartman, maintainer of the stable branch.
Two of the most serious flaws affected KSMBD, the SMB server built into the Linux kernel. Both received a score of 9.0 from the Zero Day Initiative and could open the door to remote code execution. However, one of them required specific conditions, including an RDMA-capable interface, a KSMBD share with write permissions, and SMB Direct negotiation.
Exposure, then, depended on how each system was configured. While verified fixes were on the way, administrators had to check their distributions’ advisories, review exposed services, and apply containment measures where needed. They also had to reboot affected machines to start up on the fixed kernel and confirm which version was actually running.
The LiteLLM incident called for a different response. On October 21, a malicious version 1.107.0 of this tool, used as a proxy to connect applications with language model providers, was published to the PyPI repository. Compromised container images were also distributed.
According to the project’s report, the attackers used GitHub CLI credentials tied to three developers to gain access to the release pipeline. One of the credentials belonged to a GitHub organization owner, which allowed them to modify branch protections and alter the release flow.
The malicious payload combined a credential-stealing mechanism with a remote access trojan. It also abused Python startup mechanisms, including a .pth file, to run code when the interpreter started, even if an application never explicitly imported LiteLLM.
That’s why updating the package wasn’t enough. Environments that had run the affected version had to be treated as potentially compromised. The response called for isolating the systems, rebuilding them from clean sources, rotating any credentials that might have been exposed, and reviewing logs across cloud services, code repositories, and continuous integration and deployment platforms.
Brotli and Certificates: the Risk Extends Beyond One Application
The vulnerability known as Node2Shell, tracked as CVE-2026-111497, affected the Brotli decoder built into Node.js. Manipulating compressed data could cause crashes, leak memory contents, or, under certain circumstances, even allow code execution.
Early research showed exploitation was technically feasible in some configurations, though not universally. Node.js released fixes for the 22, 24, and 26 branches on October 21. The problem, however, didn’t end with this runtime.
Brotli is also embedded in Python packages and other software components. That meant tracking down applications, containers, serverless services, and libraries that included the vulnerable decoder. The fix landed in Brotli version 1.2.1, but each dependent project had to pull in the corresponding update.
The report credits OpenAI’s Codex Security with discovering the original flaw. The fix had already been present in Brotli’s source code since February, but it hadn’t been identified as a security issue. The case shows that discovering a flaw, fixing it, and getting the fix out to every affected component are three separate stages.
The eMudhra incident, involving its emSign certificate infrastructure, added another dimension. This wasn’t a conventional application vulnerability, but insecure private keys tied to several intermediate certificate authorities. The problem could allow the issuance of certificates that some systems would consider trustworthy.
Although browsers had updated their trust and revocation mechanisms, some Python tools still used their own certificate bundles that trusted the affected authorities. That could make man-in-the-middle attacks against TLS connections easier.
The response required updating components such as certifi, pip, and uv, and rolling the changes out to existing teams, virtual environments, and containers. In the latter cases, rebuilding the images could also be necessary to ensure they included the updated certificates.
The operational takeaway from this week isn’t that every alert carries the same severity, but that each one requires understanding what could happen in the specific environment. AI can speed up research and increase the number of vulnerabilities detected, but defensive teams still need reliable inventories, protective mechanisms while patches arrive, and the ability to separate relevant incidents from noise.
ESET suggests using multi-layered protection and analysis tools such as NeoCortex and the LiveCortex correlation engine to help link signals from different systems and turn them into understandable incidents. That’s the pitch from a security vendor, not a solution that by itself removes the need to update, contain, and verify affected systems.
Frequently Asked Questions
What was cybersecurity’s Black Week in October 2026?
A string of vulnerabilities and incidents disclosed over seven days, affecting PHP, Linux, LiteLLM, Node.js, GitLab, and the eMudhra certificate infrastructure.
Which vulnerabilities had the highest scores?
GitLab disclosed a flaw with a CVSS 3.1 score of 10.0. The PHP2Shell vulnerabilities scored 9.2 under CVSS 4.0, while two of the Linux kernel flaws reported scored 9.0 according to the Zero Day Initiative.
Why isn’t updating LiteLLM enough?
The malicious version could execute code and steal credentials. Systems that had run it needed to be treated as potentially compromised, rebuilt from clean sources, and have their credentials and logs reviewed.
What role did artificial intelligence play in these incidents?
ESET’s analysis notes that AI-assisted research helped uncover at least two of the flaws, PHP2Shell and the Brotli vulnerability. Automating research doesn’t remove the need to assess risk and apply the right remediation measures.
Sources:
