A week of critical vulnerabilities: what happened with PHP, GitLab, Node.js, and Linux

In just a few days, several important security notices have accumulated. Two critical vulnerabilities in PHP, an urgent update for GitLab, several flaws in Node.js, a vulnerability in the Linux kernel, and an incident that has compromised a version of LiteLLM.

They are very different technologies, but they have something in common: they are part of the digital infrastructure we use every day, often without being aware of it.

Why have so many notices appeared in such a short time? What risks do they represent? And what should you check if you use any of these technologies?

Let’s break it down.

PHP: two critical vulnerabilities that we have already fixed in cdmon

On October 21, 2026, the PHP security team published two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, with a severity score of 9.2 out of 10.

Both could allow remote code execution without authentication. Simply put: under certain conditions, an attacker could exploit these flaws to execute malicious instructions on a server without having access credentials.

The issue affected different ways of running PHP on web servers, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

How did we respond from cdmon?

When the severity of these vulnerabilities became known, our team began working to reduce the exposure of the affected services.

On October 21, at 07:30 AM, we applied a temporary mitigation while waiting for the official patches to be released.

That same afternoon, after the release of the new PHP versions, we applied the corresponding security updates at 7:00 PM.

The difference between both actions is important. A temporary mitigation allows reducing certain risks while a definitive solution is developed or published, but it does not replace a security update.

Therefore, from the very beginning, our goal was to apply the patched versions as soon as they were available.

The PHP vulnerabilities we communicated on October 21 are already fixed in cdmon’s services. Clients do not need to take any action to apply these updates.

If you manage your own PHP installation on a server, you should check that you are using a patched version.

Which PHP versions fix these vulnerabilities?

The official PHP team released the following versions:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

If you manage your own installation, check which version you have and consult the updates available for your system.

You can find the details of both flaws in the official PHP security notice.

Another important date: PHP 8.2 will stop receiving support in December

Although PHP 8.2 has received the patches for these vulnerabilities, on December 31, 2026, it will reach the end of its life cycle.

From that date, it will stop receiving official security updates. This means that new vulnerabilities discovered may remain unpatched by the PHP project.

If your website still uses PHP 8.2, it is advisable to start planning its update to a supported version.

Before doing so, check that your CMS, plugins, and other components are compatible. At cdmon, you can use our Staging environment to perform tests without directly affecting your live website.

You can check the support dates on the official PHP website.

GitLab: a critical vulnerability in self-managed installations

GitLab is a platform used by development teams to manage code repositories, automate tests, and organize deployments.

On October 21, it released an urgent update to fix several vulnerabilities, including CVE-2026-110264, with a severity of 10 out of 10.

This flaw could allow an unauthenticated attacker to execute code on the server under certain conditions.

The vulnerability affected self-managed GitLab installations, making it especially relevant for organizations running this tool on their own infrastructure.

What should you do?

If you manage a GitLab installation, check that you have applied one of the patched versions: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13, depending on the branch you use.

GitLab recommends updating as soon as possible and has published additional information to help identify potential exploitation attempts.

You can check the versions and recommendations in the official GitLab notice.

Node.js: several vulnerabilities requiring update

Node.js allows running JavaScript outside the browser and is used in web applications, backend services, development tools, and automated processes.

On October 21, its team released updates to fix ten vulnerabilities, four of them with high severity.

Among the detected issues is CVE-2026-111497, a vulnerability in the Brotli decoder that could allow remote code execution.

Brotli is a compression technology that helps reduce the size of transmitted data. A flaw in how those data are processed can become a security issue if it allows manipulating an application’s memory.

Which versions are fixed?

The published updates are:

• Node.js 22.23.4
• Node.js 24.22.1
• Node.js 26.12.1

If you use Node.js in your applications or servers, check the installed version and update it following the official guidelines.

Keep in mind that Node.js can also be part of development tools and applications that include their own version. Updating the main installation does not guarantee that all those components are updated.

You will find more information in the Node.js security notice.

Linux Kernel: a vulnerability affecting virtual machine isolation

Another relevant notice these days affects the Linux kernel, the core component of the operating system that manages the computer’s resources and the communication between hardware and software.

The vulnerability CVE-2026-99999, known as PwnEscape, affects certain virtualized environments.

Under specific conditions, it could allow a process running inside a virtual machine to access memory of the physical server hosting it.

This is especially relevant in environments where multiple virtual machines share the same physical server, as the isolation between them is a fundamental part of security.

However, it does not mean that any user can directly access the physical server. Exploitation requires certain preconditions, including the attacker being able to execute code within the virtual machine.

What measures are necessary?

The response depends on the kernel, configuration, and virtualization platform used.

Administrators should check if their systems are affected, review the updates published by their providers, and apply the corresponding patches.

It is also important to remember that some kernel updates require restarting the system for the new version to take effect.

You can expand the information in the technical analysis of CVE-2026-99999.

LiteLLM: when the problem is not in the code, but in what you download

The case of LiteLLM is different from the previous ones.

LiteLLM is a tool used to connect applications with different AI models and providers.

On October 21, it was detected that version 1.107.0 had been distributed with malicious software through package repositories and container images.

It was not a conventional vulnerability that could be exploited through a specially crafted request. The problem was that an apparently legitimate version of the software contained malicious code.

This type of incident is known as a software supply chain attack.

It is especially delicate because teams may install an update trusting its origin without knowing that the distribution process has been compromised.

What to do if you use LiteLLM?

The LiteLLM team has removed the affected versions and published a report with response recommendations.

If you installed or ran the compromised version during the period indicated in the notice, you should consider the possibility that the environment has been affected.

In that case, it is not enough to update to another version: it is necessary to follow the official incident response procedure, review the environment, and replace any credentials that may have been exposed.

You can find the details and instructions in the official LiteLLM security report.

What should you review in your projects?

Although these notices have been published almost simultaneously, not all affect the same systems or require the same actions.

If you use cdmon’s shared hosting, the PHP updates we have communicated are already applied. You do not need to intervene to fix those vulnerabilities.

However, it is still important to keep your website’s software updated, especially WordPress, its themes, and plugins.

If you manage your own VPS, dedicated server, or applications, it is advisable to review which technologies you use and which components are under your responsibility.

Some good practices that can help you are:

• Maintain an updated inventory: knowing which versions of PHP, Node.js, operating systems, and applications you use makes it easier to identify if a notice affects you.
• Follow official sources: the teams responsible for each technology publish information about vulnerable versions, patches, and possible temporary measures.
• Plan updates: especially when they involve version changes, possible incompatibilities, or reboots.
• Maintain backups and test changes: having a restore point and a testing environment helps reduce risks during maintenance.
• Review dependencies: an application may incorporate vulnerable components even if you do not use them directly.

The key is not to update everything indiscriminately every time an alert appears, but to understand what affects you, assess its severity, and act wisely.

Why are so many vulnerabilities being discovered at once?

The coincidence of so many important notices in a few days raises an interesting question: is it simply coincidence or is the way we discover security issues changing?

There is no single proven explanation for this concentration of incidents. Vulnerabilities can be present in the code for years before someone discovers them, and their publication dates depend on numerous factors, such as research processes, coordination, and patch development.

But there is another element that is transforming the landscape: artificial intelligence.

AI tools are acquiring capabilities to analyze code, identify suspicious patterns, and help detect errors that previously required many hours of specialized work.

This opens up two possibilities at the same time.

On one hand, security teams can analyze more code, locate vulnerabilities, and develop patches more quickly.

On the other hand, those same capabilities can also facilitate the work of those seeking to exploit the flaws.

Our CEO, Jaume R. Palau, precisely raises this reflection in his article «Is it a coincidence that so many critical vulnerabilities have come together at once?».

His hypothesis is that AI could be significantly accelerating the discovery of vulnerabilities that have been hidden in software for years. And he also raises the other side of the coin: those same tools offer an opportunity to review and improve systems that until now were too costly to audit.

It is a reflection worth reading, especially if you work in development, system administration, or cybersecurity.

Security is an ongoing job

What happened these days is a reminder that security does not depend on a single update nor does it end when a vulnerability is fixed.

Technologies evolve, new flaws are discovered, and threats emerge that force us to review what we considered safe yesterday.

At cdmon, our job is to closely follow that evolution, assess the risks to our infrastructure, and act when necessary.

The response to the PHP vulnerabilities on October 21 is an example: first, we applied temporary measures to reduce exposure, and as soon as the official patches were available, we updated the affected services.

Because protecting an infrastructure does not mean that vulnerabilities will never appear. It means being prepared to identify them, respond, and keep systems updated.

And, of course, keeping you informed about what is happening and the actions you really need to take to protect your projects.