While all eyes were on the PHP vulnerability PHP2Shell on Wednesday 21 October 2026, two more critical security updates came in: one for GitLab and one for Node.js. Do you manage your source code in GitLab, or does one of your applications run on Node.js? Then this concerned your environment too.
GitLab is the platform where software teams manage their code and automatically test and deploy their applications. Node.js is the environment that runs JavaScript on a server, the foundation of many modern web applications. We use both, and we keep track of which version runs where for every application. So after the announcement we knew straight away what needed to happen, and the next morning we could get to work in a targeted way.
Two flaws that worked from the outside
The most serious GitLab flaw received the highest possible score: 10 out of 10. Someone from outside, without an account or password, could make the server run commands, through a bug in the way GitLab processes search patterns. The flaw was present in every version since GitLab 7.0, so for more than ten years. There is no temporary workaround; only updating helps. It was also the second time in ten days: earlier this month, GitLab fixed a similar flaw with the same score, found by the same researcher. If you had dutifully updated then, you had to do it again.
On the same day, Node.js fixed ten vulnerabilities, four of them serious. The worst was in unpacking data compressed with Brotli, a compression format widely used on the web. An application that unpacks such data from outside could end up running an attacker’s code. Two other flaws made it possible to bypass the check on security certificates, the check that ensures an application is talking to the right server. The fixes are in Node.js 22, 24 and 26. Older versions that are no longer supported, such as Node.js 18 and 20, get nothing: they remain vulnerable.
At the time of writing, neither GitLab nor Node.js reports attacks that use these flaws.
A GitLab server is more than an archive
A score of 10 for a GitLab flaw is more serious than it sounds. Whoever takes over a GitLab server can read and change the source code of every application on it, and can reach the servers those applications run on through the automated deployment.
Our GitLab server runs on our own infrastructure, not with GitLab itself. That keeps us in control of where our clients’ source code lives, but it also means the updating is up to us. Wednesday went to PHP2Shell. On Thursday morning at 9:22 we updated GitLab to a fixed version. GitLab also migrates its database during the update, so the server was unavailable for a short while. The Node.js updates followed the same morning.
Where Node.js runs in our work
Our applications are mostly built in PHP, but Node.js runs in a few fixed places alongside them. Because we keep track of those places, and of the version running there, we could tell right away what this flaw meant for each of them.
In most places, Node.js is only part of the build process: it prepares files before a site goes live, on our own website too. It does not run on the server, and nobody can reach it from outside. Where Node.js does run on a server, as the foundation of an application or as a small service next to a PHP application, we updated it to a fixed version on 22 October. Where it made sense, we moved straight to a version with longer support, so security updates are now installed automatically.
Weeks like this will come more often
That three major updates fell on the same day was a coincidence; GitLab and Node.js plan their releases independently. More interesting is how the flaws were found. The GitLab flaw surfaced the classic way, through a researcher who reported it to GitLab’s bug bounty programme. The other two did not. The most serious Node.js flaw was reported by an OpenAI team that turns AI models loose on source code to track down bugs, and PHP2Shell was found with AI as well. Code that people have read for years without anyone spotting the bug is now being read in a different way, and it shows.
That is why we expect days like 21 October to come around more often. The PHP Foundation said the same about its own project that week. In the long run that is good news, because every flaw that is found gets fixed. For anyone running an application, the consequence is mostly practical: the update you schedule once a quarter will increasingly arrive a few times in between, and your maintenance needs to be set up for that. We now also use AI to check our own code for this kind of bug. What such an application could look like for your organisation, you can read under AI implementation.
What you have not mapped does not get updated
With PHP2Shell, the difficulty was timing: the fix existed but was not yet available everywhere. This time the updates were ready straight away, and then speed depends on one thing: knowing where the software runs. You can see a GitLab server standing there, but Node.js does not announce itself. It sits in a build step, a helper service or the foundation of an application, and each place calls for a different answer. A build step can wait for regular maintenance; an application that can be reached from outside and runs on Node.js has to be closed the same day. Every application relies on software made by others, from the programming language to small helper services, and each of those parts stops receiving updates one day. For GitLab 18.10 and older, no fix was released this time. If you are on such a version, you have to upgrade before you can fix.
So there are two questions you can always ask your supplier, even if that supplier is us. Which software made by others runs inside my application? And who keeps track of when it stops receiving updates? A good answer is a list with versions and end dates. How we keep that list, you can read under ongoing development and maintenance.
If you get stuck on the answer, we would be glad to put that overview together with you.