Critical Security Patches This Week: PHP2Shell, Node.js, GitLab and eMudhra, and What to Patch First

Four security disclosures that need action landed within days of each other: emergency PHP releases for the PHP2Shell vulnerability, a Node.js security release, two GitLab critical patch releases, and a certificate authority incident at eMudhra. Each security advisory is serious on its own. Together they create the real problem for an engineering team: deciding which critical security patches to apply first. Getting the order wrong is costly in plain business terms: the most exposed system stays open longest, the team spends days on the least urgent item, and patch management turns into guesswork, because nobody can show afterwards what was fixed and when.

Patch internet-facing PHP first (PHP2Shell is unauthenticated remote code execution), then self-managed GitLab, then Node.js services that handle Brotli data from outside, and update trust stores and replace any certificates issued under eMudhra's distrusted root. The rest of this guide explains that order, what "patched" means for each stack, and a 72-hour plan you can hand to your team today.

Patch by exposure, not by headline. Then verify the running process, not the installed package.

This week's critical security patches at a glance

Mark a row done only when the running version is verified, which is the point of the section on installed versus patched below. Pin this table in your team channel as the single list of critical security patches still open.

How we ranked them: exposure, not headlines

Every security advisory this week is labelled critical or high, so severity alone does not sort the queue of critical security patches. Exposure does. We score each item on three questions: can an attacker reach it from the internet, do they need to log in, and how much of a typical estate runs it?

The PHP2Shell vulnerability scores highest on all three. GitLab's flaws are also unauthenticated, but they only matter if you run GitLab yourself. The Node.js Brotli flaw depends on what each service does with compressed input. eMudhra is a trust problem rather than a code flaw, so it follows a different track and needs calendar time, which is why it starts this week even though it ranks last. That is the core of vulnerability triage: the order you agree on before you start matters more than how fast anyone types.

PHP2Shell: patch internet-facing PHP today

The PHP security advisory describes two flaws that can allow unauthenticated remote code execution, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, with the highest risk on mod_php. PHP 8.1 and older no longer get updates from the PHP project, so those branches depend on distribution or vendor backports. CISA's alert, Critical Vulnerabilities in PHP Require Immediate Patching, asks organizations to inventory every system running PHP, patch internet-facing systems first, and take PHP systems offline if they cannot be updated immediately or still run PHP 8.1 or older, until they are fixed.

Because the flaw is in the engine, updating WordPress, WooCommerce, Magento or Laravel does nothing for it. Commerce sites deserve extra care because they often run older PHP to keep extensions working; our Adobe Commerce development team treats the PHP runtime as part of the platform for that reason. For the step-by-step check, see our guide on how to confirm your site is really patched for PHP2Shell.

GitLab: two unauthenticated RCEs in ten days

GitLab shipped two critical patch releases this month. The October 12 patch release (19.4.2, 19.3.5, 19.2.8) fixed CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler. The October 21 patch release (19.5.1, 19.4.3, 19.3.6 and older lines) fixed CVE-2026-110264, an integer overflow in the regular expression compiler. GitLab says each issue could, under certain conditions, have allowed an unauthenticated user to execute arbitrary code, and it published threat detections for self-managed customers.

Each GitLab critical vulnerability belongs to whoever runs the instance. GitLab says GitLab.com is already running the patched version, and Dedicated tenants on the listed builds need no action. A self-managed server is yours: upgrade to the latest patch release for your line, then run GitLab's detections against your logs, because the first of the two fixes shipped on October 12. The October 21 fix was also backported to 19.2.9, 19.1.9, 19.0.10 and 18.11.13; instances on lines older than 18.11 have no patch release and need to move to a supported line.

Node.js: redeploy every service on a patched runtime

The Node.js October security releases fix several high-severity issues in the 22.x, 24.x and 26.x lines, including CVE-2026-111497, an out-of-bounds write in the Brotli decoder that permits remote code execution. The fixed releases are v22.23.4, v24.22.1 and v26.12.1. The same Node.js security release updates the bundled CA certificates for the eMudhra intermediate CA compromise.

For Node.js, the patch lives in the runtime your application ships with, so the fix is real only when you redeploy the application on a patched version: bump the base image or version pin, rebuild, redeploy. On hosted platforms, read the provider's guidance; Vercel's Node.js security bulletin explains how its runtimes pick up the fix. Vercel's bulletin notes that a service is exposed when it decompresses Brotli data an attacker controls, whether in a request body or in a response it fetches, and only the runtime patch covers fetched responses. So every Node.js service should move to the patched line this week, because this Node.js security release fixes more than one flaw. Node.js 20 has reached end of life and will not receive this fix; projects on 20.x must move to 22.x or 24.x and redeploy.

eMudhra: update trust stores and check your certificate chains

eMudhra is not a software bug. Help Net Security reports that eight eMudhra intermediate certificates were secured with private keys so weak that anyone could recover them from the public certificates. Six issue TLS certificates for websites and two are for code signing. eMudhra revoked them on October 18. A forged certificate from a recovered key could impersonate any domain to a client that still trusts the chain. Mozilla then removed trust in the eMudhra root certificate that signed the intermediates, Google says Chrome will do the same, and eMudhra estimates that about 30,000 customer certificates need to be replaced.

Install your operating system's updated CA bundle, as distributions such as Ubuntu have published, and update runtimes that ship their own bundle, such as Node.js. Then check whether any certificate you use was issued by eMudhra, and replace it before browsers stop trusting it. Each certificate authority incident like this one is a good prompt to keep a list of every public certificate and its issuer.

Installed is not the same as patched

A package manager reporting success is where most critical security patches quietly fail, and where patch management turns into guesswork. The new code is on disk, but the running process still holds the old one until a PHP-FPM pool restarts, a container is replaced, a Node.js service is redeployed, or GitLab finishes its upgrade.

PHP adds a second trap: one server can run several PHP versions at once. While patching our own multi-site server this week, the command line reported one PHP branch while our main website was served by a different PHP-FPM pool. Checking the terminal would have told us the wrong story. Verify from the serving side instead: the handler configuration, the pool's process start time, or a response from the live site. Apply that rule to all four critical security patches, not only PHP.

The same patch week is also a good moment to shrink your attack surface. We disabled sites on that server that nobody needed any more. A forgotten site still runs PHP, still needs every future patch, and is the one nobody remembers to restart.

The 72-hour order of work

Use this sequence for this week's critical security patches, then reuse it next month.

1. Inventory. List every PHP-FPM pool and mod_php site, every self-managed GitLab instance, every Node.js service and runtime, and every public certificate with its issuer. Note each CVE identifier against the systems it affects, so every ticket names the CVE identifier it closes.
2. Check exposure. For each item ask: is it internet-facing, does it need a login, how widely is it deployed? Write the order down; that written order is your vulnerability triage record.
3. Patch. PHP to the fixed release or vendor backport, GitLab to the latest patch release for your line, Node.js to the patched version, and CA bundles to the updated release.
4. Restart or redeploy the application. Restart PHP-FPM pools and web servers, replace containers, redeploy Node.js services, and let the GitLab upgrade finish.
5. Verify the running version from the serving side, and record it per site and per service.
6. Review logs for exploitation attempts across the days before you patched. A finding does not change the patch order, but it turns the work into an incident.
7. Close unused sites and services, because each one widens the attack surface for the next advisory.

Steps 1 and 2 take a morning if you already keep an inventory, and two days if you do not, which is the case for building it before the next wave of critical security patches. For the PHP2Shell vulnerability, step 5 is where most teams find surprises.

Why weeks like this will keep coming

The PHP flaws were found with AI assistance. Wiz's write-up, PHP2Shell: AI uncovers critical RCE vulnerabilities, describes how Wiz Research found them and thanks Calif and OpenAI alongside the PHP team for discovery, coordination and patch verification. When AI makes it cheaper to find bugs in mature code, it is reasonable to expect more coordinated disclosures, and more weeks when several land at once.

The answer is a routine rather than heroics. Good patch management for critical security patches looks like this: a monthly window, a named owner for each stack (PHP runtimes, self-managed platforms, Node.js pipelines, certificates), an inventory that is kept current, and a verification step on every change. Fewer stacks also means fewer owners and fewer surprises, which is why modernizing an end-of-life application one release at a time, with AI-assisted development and modernization and a named engineer accountable for each release, pays off in weeks like this one. For the patching routine itself, our DevOps and cloud engineering services team can help set up the window, the owners and the verification step.

Patch by exposure, verify the running process

This week's critical security patches are one triage problem, not four emergencies. PHP first, then self-managed GitLab, then Node.js, with the eMudhra trust-store work running alongside. Each of these critical security patches is finished only when the running version is verified. Teams that keep an inventory and a monthly cadence will treat the next batch of critical security patches as calendar work. If that inventory does not exist yet, this week is the cheapest moment to start it: the four advisories have already told you which stacks to list and who should own each one.

If you are not sure where your estate stands, bring us that problem. In a free 30-minute Next-Step Review a solution lead walks through what you run and where your attack surface is, and within two working days you get a one-page brief: the likely gaps, the step we recommend and whether it is a patch, a hardening pass or a release to modernize. If improving what you already have is enough, the brief will say so. Book a free Next-Step Review.

Frequently Asked Questions

Which of this week's critical security patches should I apply first?

PHP, if any of your PHP sites face the internet, because PHP2Shell allows remote code execution without a login. Then self-managed GitLab, then Node.js, while updating trust stores for eMudhra in parallel.

I use managed hosting. Do I still need to do anything about PHP2Shell?

Yes. Ask your host in writing which PHP build serves your site, whether it includes both PHP2Shell fixes, and when the PHP process was last restarted. Until you have that answer, treat the site as exposed.

Do I need to do anything about eMudhra if I never bought an eMudhra certificate?

Yes, a little. Update your operating system's CA bundle and any runtime that ships its own, such as Node.js, so your systems stop trusting the affected certificates. Replacing certificates is only needed if yours were issued by eMudhra.

Are GitLab.com users affected?

GitLab says GitLab.com is already running the patched version, and Dedicated tenants on the listed builds need no action. Each GitLab critical vulnerability this month is an action item for self-managed instances.

How often should we review critical security patches?

At least monthly, with an extra review whenever a security advisory affects something internet-facing. A monthly patch management window with named owners keeps weeks like this one routine.