Five Security Alerts in One Week: PHP, Laravel, Node.js, GitLab, eMudhra

Between 17 and 22 October 2026, five security alerts came out within days of each other: two critical flaws in PHP, the language behind most websites, known as PHP2Shell; a flaw in Laravel that lets an attacker act as another user; ten fixes in Node.js; a critical flaw in GitLab servers that companies run themselves; and weak keys at eMudhra, a company that issues the certificates behind secure website connections. A company with a Laravel website, its code on its own GitLab and a few online services may need to act on all five.

Our view: the first question is not which flaw is the worst. It is where your company uses each of these products, and which of those systems anyone can reach from the internet. A team can only fix what it knows it has.

This software is everywhere

PHP runs about 7 in 10 websites in the world, and more than 8 in 10 Spanish .es websites, according to W3Techs (October 2026). WordPress, which is built on PHP, alone powers almost 40% of all websites. Drupal is built on PHP too.

The tools developers build websites with are just as widespread. Laravel has been downloaded more than 600 million times. Symfony, which Drupal and Laravel themselves rely on, more than 900 million times.

Yet many owners do not know what their own website runs on. An agency chose the website platform, a contractor chose the tools, the hosting provider runs the server. A company that "just has a WordPress site" runs PHP, and the PHP2Shell alert applies to it.

Attackers do not wait for owners to find out. Amazon's security team writes that AI tools make it cheaper to turn a published fix or advisory into a working attack, so the time from fix to first attacks keeps shrinking. For PHP2Shell, attack attempts started even before the fix was out.

Start with the list, not with the patch

The official advice for PHP2Shell starts in the same place. CISA, the US cybersecurity agency, asks organizations to "identify and inventory systems running any version of PHP", starting with those reachable from the internet, and warns that PHP "is often a component of other software". The UK's NCSC gives the same first step.

The other four alerts raise the same question. Which of our websites run on PHP or Laravel? Is our own GitLab open to the internet? Which of our systems still use an old Node.js or an outdated list of trusted certificates? A team can answer only for the systems it knows about. A system missing from the list can miss the update, for example:

• a test copy of a website left online after a project ended;
• a GitLab server set up years ago by a developer who has since left;
• a website a contractor built and still hosts on their own account;
• a regional office's website run outside central IT.

A one-off check gives a snapshot. This week shows why the list has to stay current: five alerts in six days, each needing its own answer to "where do we use this?". Regular external scanning keeps that list current as websites appear and change. It shows which of your systems anyone can reach from the internet, and which technologies and versions they give away: the web server, the website platform, the programming language.

Hiding the version helps a little: from outside, it is harder for anyone to tell whether your site is affected. It does not protect you. Attackers' automated tools do not stop at the version number; they try the flaw itself. A hidden version also means an outside scan cannot match it to a known flaw, and some things, such as the exact components inside an application, cannot be seen from outside at all. Those answers come from your IT team and your providers.

Is this a coordinated attack?

The sources we checked do not link these five problems to one campaign. The vulnerability tracker cve.tools counted 203 new critical vulnerabilities that week, about the usual number for six days (214 on average since April). What made the week unusual is that several parts of the same common web software needed fixes at once, and that for PHP the attacks started before the fix.

The five alerts, one by one

1. PHP2Shell: flaws in PHP itself (CVE-2026-109618, CVE-2026-109619)

• What it is. Two flaws in PHP that, according to PHP's own advisory, "can allow unauthenticated remote code execution": an attacker could take control of the server without logging in. PHP rates both 9.2 out of 10.
• Who is affected. PHP names "all PHP installations serving web requests". That includes websites built with Laravel, WordPress, Drupal and other PHP software. Updating the website or its platform does not update the PHP underneath.
• Is it attacked? Yes, attempts. Amazon saw the first one on its decoy servers on 17 October, four days before the fix, and writes that PHP2Shell "is now seeing broad exploitation attempts in the wild". Amazon does not say whether that first attempt succeeded.
• What to do. Ask whoever runs your websites to update PHP and restart it. Old PHP versions that no longer get updates need a fixed package from the provider or a move to a supported version. Versions are in the checklist below; more in our PHP2Shell note.

2. Laravel: acting as another user without logging in (CVE-2026-114509)

• What it is. With certain database settings, an attacker without an account can make Laravel's built-in check of access keys accept the wrong user, and then act as that user. Laravel rates it critical, 9.2 out of 10.
• Who is affected. Laravel websites and apps that use this built-in check, called TokenGuard, on an older Laravel version. Laravel published the fix on 19 October.
• Is it attacked? Laravel does not report attacks.
• What to do. Ask your developers whether your app uses TokenGuard, and to update Laravel. Versions are in the checklist.

3. Node.js: ten fixes, four rated high

• What it is. On 21 October Node.js fixed ten flaws. The most serious could let an attacker run code on a server, or get around the check that a secure connection really goes to the right site.
• Who is affected. All supported versions, both on live servers and in the systems that build your applications. Old versions past their support date get no fixes.
• Is it attacked? Node.js does not report attacks.
• What to do. Ask your developers to move every application, and the systems that build it, to a fixed version and redeploy. Versions are in the checklist.

4. GitLab: taking over a company's own code server (CVE-2026-110264)

• What it is. On 21 October GitLab fixed a flaw that, "under certain conditions", could let someone without an account run code on a GitLab server, where a company keeps its source code. GitLab rates it 10 out of 10, the top of the scale. It fixed another 10-out-of-10 flaw on 12 October.
• Who is affected. Companies that run GitLab on their own servers, on any version before the fix. GitLab.com, the cloud service, is already fixed.
• Is it attacked? GitLab does not report attacks. It has published rules to detect attempts.
• What to do. Update. If your GitLab can be reached from the internet, start with it.

5. eMudhra: a certificate authority with keys anyone could work out

• What it is. eMudhra issues certificates, the digital IDs that secure connections to websites (the padlock in the browser). The secret keys behind eight of its certificates were made so badly that anyone can work them out from the public certificates. With one of them, an attacker could pose as a website or service to software that still trusts these certificates. The keys date from April 2025; the problem was found in October 2026.
• Who is affected. Up-to-date browsers are protected: Firefox and Chrome have blocked these certificates since 17 October, Microsoft since 20 October and Apple since 22 October. The exposed side is software that does not get these updates: servers, containers and apps with their own list of trusted certificates, for example a website that calls a payment or shipping service.
• Is it attacked? Unknown. The researchers who found the problem write: "We do not know if attackers exploited the flawed key generation."
• What to do. Ask your IT team to update the list of trusted certificates on servers and in containers, and to run the test in the checklist.

For your IT team: first checks, in order

1. List your internet-facing websites, subdomains and services, including those run by contractors, subsidiaries and hosting providers. Mark which ones run PHP, Laravel, Node.js or GitLab.
2. PHP: confirm the running version is 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a fixed distribution package, and that PHP processes were restarted. In containers, rebuild from the patched base image. php -v shows only the command-line PHP: separately confirm the version the web server uses (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed), and restart or redeploy its workers.
3. Laravel: run composer show laravel/framework. If it is below 12.68.0, or 13.x below 13.29.0, and the app uses TokenGuard, update it first.
4. Node.js: move to 26.12.1, 24.22.1 or 22.23.4 in Dockerfiles (FROM node:), CI and .nvmrc files, then redeploy and check the running version.
5. GitLab: if you run your own, update to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, and check whether it can be reached from the internet.
6. Certificates: update ca-certificates on hosts and in images, and the runtimes that carry their own certificate list (the researchers' disclosure page lists fixed versions of Node.js, Go, Python and others). Then test: curl https://dv-g3b-emudhra.we-have-a-problem.com/ should fail with a certificate error. If it connects, that client accepts the tested chain.
7. Look back: for PHP2Shell, Amazon advises reviewing activity from at least 17 October, not from the release day. Look for unusual requests to PHP sites, PHP worker processes starting shells or downloading tools, and unexpected file changes. If you find any, treat the server as compromised: an update alone does not remove an attacker who is already in.

Frequently asked questions

Which of these are attackers using?

PHP2Shell: Amazon reports attempts, both before and after the fix. Laravel, Node.js and GitLab: the vendors do not report attacks. eMudhra: unknown, and the researchers say so. None was on CISA's list of confirmed attacks when we checked, which does not prove there are none.

Our site runs on Laravel. Is updating Laravel enough?

No. Laravel runs on PHP, and PHP2Shell is in PHP itself. PHP needs its own update, and Laravel a separate one for its own flaw.

My browser is up to date. Am I safe from the eMudhra problem?

If your browser and operating system have their latest updates, yes. That says nothing about your servers and the services your website talks to: ask your IT team to update their certificate lists.

We use GitLab.com, not our own server. Do we need to act?

Not for this flaw. GitLab says GitLab.com already runs the fixed version.

Not sure which of your systems face the internet and what they run? SeguriScan, the IntruForce platform, looks at your company's internet-facing systems from the outside. See how SeguriScan shows a finding on one of your assets and what to fix first. To try it on your own systems, request a free SeguriScan pilot with the form below. First we agree with you on the scope and the systems to assess, and confirm you may authorize the check. Nothing is scanned before that. Then you get access to the SeguriScan platform with the discovered assets, findings and reports. No obligation to proceed.

---

Sources

• PHP: security advisory of 21 October 2026 and advisories GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.
• Laravel: advisory GHSA-f9x3-7vq9-cph6 (19 October 2026).
• Node.js: October 2026 security releases (21 October 2026).
• GitLab: critical patch release 19.5.1 (21 October 2026) and patch release 19.4.2 (12 October 2026).
• eMudhra: the researchers' disclosure page and Mozilla Bugzilla bug 2083449 (comments 5 and 11).
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot (21 October 2026).
• CISA: alert on critical PHP vulnerabilities (21 October 2026) and the Known Exploited Vulnerabilities catalog, version 2026.10.21.
• NCSC: critical security issue affecting PHP.
• Week statistics: cve.tools, which also has a detailed timeline and charts.
• Usage figures: W3Techs, 23 October 2026: PHP 69.3% of websites whose server-side language it detects, 82.8% of such .es websites; WordPress 39.6% of all websites; Drupal 0.6%. Download totals from Packagist, the PHP package directory, 23 October 2026: Laravel (laravel/framework) 602 million; Symfony's core component symfony/http-kernel 946 million.