lorenzopasquali.dev

PHP2Shell, Node.js and GitLab: the week software security became a race against time

· 7 min read · also in Portuguese

Over the past few days, a series of critical vulnerabilities in widely used technologies has raised an important question: are we prepared for a world where finding flaws and turning them into exploits keeps getting faster?

Between October 20 and 27, PHP, Node.js and GitLab published significant security updates. These are not just bugs that require highly unusual conditions to cause harm. Some can enable remote code execution, in certain scenarios even without authentication.

There is another detail that makes this sequence especially interesting: it is happening just as artificial intelligence begins to change how vulnerabilities are discovered, analyzed and exploited.

PHP2Shell: two critical flaws at the heart of PHP

The first case to draw attention was PHP2Shell, the name associated with two vulnerabilities in the PHP interpreter: CVE-2026-109618 and CVE-2026-109619.

Both received a CVSS 4.0 score of 9.2, classified as critical, and can allow unauthenticated remote code execution.

The first is related to memory handling when a request triggers an out-of-memory condition. The second involves references to memory regions that have already been freed, a condition known as use-after-free.

In practice, an attacker may attempt to exploit these behaviors to execute commands with the privileges of the web-server process.

The most concerning detail is that the issue is not limited to the PHP application we build. Depending on the configuration, the vulnerability can be triggered while a request is being processed, before the application's own code runs. That limits how much an application can protect itself through internal validation alone.

The risk affects different ways of running PHP, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

On October 21, the project published fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Systems running older, unsupported versions also need special attention.

Sources: PHP announcement, Sophos analysis and Singapore government guidance.

The problem did not end with the first update

On October 23, the PHP project published information about another potential vulnerability, identified as CVE-2026-115560, related to the session upload progress feature.

It was not fixed by the same emergency updates as PHP2Shell. Until a fix is available, the published mitigation is to disable the feature with:

session.upload_progress.enabled=0

The existence of this additional issue matters because it shows how a security investigation can uncover other exploitation paths in related functionality.

We should also be precise: this third CVE should not simply be described as a third flaw already fixed by the October 21 patch. It is an additional issue with its own mitigation guidance.

Source: MyCERT technical advisory, October 24.

Node.js: flaws ranging from DNS to process memory

On October 21, the Node.js project published another round of security updates for the 22.x, 24.x and 26.x release lines.

One of the issues fixed was CVE-2026-111497, a flaw in Node.js's built-in Brotli decoder. Specially crafted compressed data can cause an out-of-bounds buffer write, leading to memory corruption, process crashes and potentially remote code execution.

Exploitation depends on an application accepting and decompressing attacker-controlled content using the affected functionality.

That was not the only issue in the update. The advisory also covered problems involving DNS resolution, TLS certificate validation, HTTP connection reuse and the filesystem permission model.

Some examples:

The lesson is that security is not just about preventing SQL injection or validating form inputs. Fundamental operations such as resolving domain names, validating certificates and decompressing files can also conceal serious flaws.

The published fixed versions were Node.js 22.23.4, 24.22.1 and 26.12.1.

Primary source: Official Node.js security release, October 21.

GitLab: a CVE with the maximum score

GitLab also appeared in this series of alerts with CVE-2026-110264, disclosed on October 21.

The vulnerability received a CVSS 3.1 score of 10.0 and is related to an integer overflow in the regular-expression compiler. Under certain conditions, it may allow an unauthenticated attacker to execute arbitrary code on the server.

The scope deserves attention: the CERT-EU advisory indicates that self-managed GitLab CE and EE versions going back to the 7.0 line fall within the affected range, subject to the specific version boundaries.

This is particularly relevant because GitLab can be much more than a Git repository. In many organizations, it is part of the development infrastructure, holding source code, CI/CD pipelines, environment variables and information about the software delivery process.

A vulnerability that compromises this platform can therefore have consequences beyond service availability.

Fixed versions include 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1.

It is important not to confuse this issue with every other vulnerability GitLab fixed during the period: the October 21 advisory also covered flaws of different severity levels.

Sources: CERT-EU advisory and Brazilian government advisory.

What does this have to do with artificial intelligence?

This is where the discussion gets more interesting.

It would be easy to put these vulnerabilities together and conclude that AI is making software less secure. That would be premature.

What we are seeing is a change in the speed at which problems can be found and exploited.

In a report published on October 23, Reuters spoke with security experts about this very scenario. According to the report, researchers at threat-intelligence company VulnCheck pointed to a sharp increase in vulnerability discovery, with AI among the factors contributing to the growth.

The report also notes that AI models can continuously examine codebases, find problems and help develop exploits in far less time than would traditionally have been required.

That changes an important security assumption: the time between discovering a vulnerability and exploiting it may keep shrinking.

Historically, finding a flaw, understanding its cause, developing a working exploit and turning it into a reliable attack required time and specialized knowledge. Automated tools can now reduce part of that work.

But there is an essential caveat: more vulnerabilities discovered does not automatically mean more successful attacks. Reuters also reports disagreement among experts about AI's net impact. Some flaws found by advanced tools remain difficult to exploit in practice.

There is also insufficient evidence to attribute every vulnerability from this week to AI. In the Node.js case, for example, the project credited OpenAI Codex Security among those who discovered the Brotli issue. That demonstrates AI's concrete involvement in that case, not a universal explanation for every incident.

Source: Reuters — AI-discovered bugs may soon trigger fresh disruptions, October 23, 2026.

Is the market worried?

Yes, there are concrete signs of operational concern across the security sector, but it is important to distinguish that from an alleged broad financial crisis.

The series of alerts led to urgent patching recommendations, investigations into potential compromises and, according to Reuters, cases in which operators temporarily took websites offline because they could not patch their systems before possible exploitation.

The most visible impact is the additional pressure on infrastructure, security and development teams. Emergency updates must be assessed, tested and deployed quickly without introducing compatibility problems or downtime.

For companies running legacy systems, internet-facing applications or self-managed platforms such as GitLab, the cost can be significant: inventorying assets, updating dependencies, restarting services, reviewing logs and checking for signs of compromise before the patch was applied.

There is not, however, enough evidence to claim these incidents caused a broad decline across the technology market or that investors are reacting uniformly. The clearest signal at this point is concern about the resilience of digital infrastructure.

What would I do as a developer?

For me, the main lesson from this week is that security needs to be part of the development lifecycle, not something we think about only when a critical CVE makes the news.

A few practical steps:

  1. Inventory what is actually running. Knowing the dependencies declared in a project is not enough. Identify runtimes, Docker images, services embedded in appliances and third-party components.
  2. Prioritize real-world exposure. Internet-accessible services, especially those with unauthenticated remote-code-execution vulnerabilities, deserve priority.
  3. Patch and verify. Applying a patch is only one part of the process. Confirm the version actually in use, restart processes where necessary and review signs of compromise.
  4. Automate vulnerability detection. Dependency scanners, static analysis, image monitoring and security alerts should be integrated into the development workflow.
  5. Use AI for defense, too. Assisted analysis tools can help review code, investigate alerts, create regression tests and speed up patch analysis. Their conclusions still need to be verified.

In my development context, with applications, integrations, databases and services running in containers, the lesson is straightforward: knowing the application is not enough. We also need to understand the entire software infrastructure it depends on.

Is security becoming a permanent race?

My impression is that we are entering a phase where response time will matter as much as the ability to prevent vulnerabilities.

AI can help developers find and fix flaws before they reach production. At the same time, it can reduce the effort attackers need to investigate systems and automate parts of exploitation.

That does not mean AI is inherently insecure, nor that software is doomed to become more vulnerable. It means security practices must evolve alongside development tools.

If software implementation is getting faster, analysis, validation, patch distribution and monitoring need to keep up.

PHP2Shell, the Node.js issues and GitLab's critical vulnerability show that even mature, widely used components can hide serious flaws. In a world of accelerated discovery, the difference between a known vulnerability and a real incident may come down to how quickly an organization responds.

Perhaps the most important question is not whether AI will find more bugs.

It is whether our teams, processes and infrastructure will be ready to deal with them at the speed at which they appear.

← All posts