Mongoose Weekly Round-Up: PHP RCE, Node.js Fixes and the eMudhra Certificate Compromise

Introduction

This was a heavy week for anyone responsible for web infrastructure. The PHP project fixed two critical remote code execution flaws in the language itself. The Node.js project shipped security releases across every supported line. And a certificate authority's intermediate keys turned out to be recoverable by anyone, prompting browsers and operating systems to block them within hours.

The three stories share a theme. Each one sits underneath your applications rather than inside them, and each one is easy to miss if your asset inventory stops at the application name. This round-up summarises what happened, who is affected and what to do, then explains what we would check on a test.

PHP: Two Critical RCE Flaws in the Interpreter

What happened

On 21 October 2026 PHP released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. The first involves request state left invalid after an out-of-memory condition during request parsing (GHSA-w8hw-w9fx-j79w). The second is a use-after-free caused by global state surviving from one request into the next on the same worker (GHSA-6wmf-4rv5-p3rp). Both can allow unauthenticated remote code execution.

Who is affected

PHP says the risk applies to all installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers Apache mod_php the highest-risk deployment. PHP 8.1 and older receive no official releases, although the PHP security team published minimal source backports for 7.4, 8.0 and 8.1. The NCSC has encouraged UK organisations to take immediate action.

What to do

Update to a fixed release or your distribution's patched packages, then confirm the running version rather than the installed one. Include appliances and supplier products that bundle PHP. Where you cannot patch, the NCSC and CERT-EU advise considering isolation and checking for signs of compromise.

We covered both flaws in detail, including how testers find exposed PHP, in our deep dive: PHP Just Patched Two Critical RCE Flaws. Find Every Server Before Attackers Do.

Node.js: October Security Releases

What happened

On 21 October 2026 the Node.js project published security releases for the 26.x, 24.x and 22.x lines, fixing ten vulnerabilities. The highest severity across all three lines is High. The four High-rated issues are:

• CVE-2026-111497: an out-of-bounds write in the Brotli decoder that, in the project's words, "permits remote code execution". It affects 26.x, 24.x and 22.x.
• CVE-2026-105483: a TLS certificate hostname bypass when an IP address is written with fullwidth digits. It affects 26.x and 24.x.
• CVE-2026-106069: a TLS certificate hostname bypass when the host loosely resolves to an IP address. It affects 26.x, 24.x and 22.x.
• CVE-2026-105482: dns.resolve truncates names that contain a NUL character. It affects 26.x, 24.x and 22.x.

The Medium-rated fixes cover a keep-alive socket processing a response written before the request was sent (CVE-2026-105481), non-canonical IPv4 hostnames letting DNS names in certificates authenticate IP endpoints (CVE-2026-106072), and crypto.randomUUID() and randomInt() entropy caches being saved into startup snapshots and single executable applications, so every process repeats the same values (CVE-2026-106074). The Low-rated issues are a ZipFile header validation flaw (CVE-2026-106070) and two Permission Model weaknesses (CVE-2026-106071 and CVE-2026-106073).

The releases also update bundled dependencies, including c-ares, OpenSSL (24.x and 22.x), SQLite (22.x), Undici and the root certificate store. The certificate update relates to the third story below.

Who is affected

Anyone running Node.js 26.x, 24.x or 22.x before the fixed versions. The project also notes that end-of-life versions are always affected when a security release occurs, so older lines should be treated as vulnerable.

What to do

Upgrade to Node.js 26.12.1, 24.22.1 or 22.23.4. Remember that Node.js is often baked into container images, serverless runtimes and desktop applications, so a host update is not the end of the job. If you build startup snapshots or single executable applications, rebuild them after upgrading, because the CVE-2026-106074 issue lives inside the built artefact.

eMudhra: Compromised Intermediate CA Keys

What happened

On 17 October 2026 a security researcher reported to the browser root programs that the private keys of eight eMudhra intermediate CA certificates were compromised. Google says the keys were generated with insufficient randomness, which enabled anyone to forge trusted HTTPS certificates. The researcher's disclosure page says the keys can be recovered from the certificates themselves, and that this would have been possible since the intermediates were created in April 2025.

The response was fast. Chrome blocked the affected keys through a CRLSet update the same day, and Mozilla blocked them through OneCRL within three hours of its report. According to the disclosure page, Apple devices were protected from 19 October and Microsoft platforms from 20 October. eMudhra says it revoked all eight intermediates on 18 October, that seven were never used in production, and that the eighth had not issued a single certificate.

The root that signed them is also going. Google is removing emSign ECC Root CA - G3 from the Chrome Root Store, with the change expected for all devices on 27 October 2026 (Pacific time). Mozilla is removing the root from NSS in version 3.131.1. eMudhra describes the root distrust as a precaution.

Who is affected

Two groups. First, clients that do not consume browser revocation mechanisms and rely on a static trust store, such as command-line tools, language runtimes and embedded devices. These may still trust certificates forged with the compromised keys until their trust store is updated. The disclosure page notes that there are no Certificate Transparency entries for these intermediates, so CT-enforcing browsers could not have been attacked, but many clients outside browsers do not enforce CT, and it is not known whether attackers exploited the weakness against them.

Second, website operators with legitimate certificates chaining to emSign ECC Root CA - G3. Google says those operators must immediately obtain a new certificate from another hierarchy to avoid breakage.

What to do

Apply trust store updates across your estate. Ubuntu has shipped updated ca-certificates packages, and the disclosure page lists patched versions for many other platforms and runtimes, including Debian, Fedora, Alpine, NSS, Go, Java, Python certifi and the Node.js releases above. Check whether any of your own certificates chain to the affected root, and replace them now rather than after 27 October.

What We'd Check on a Test

All three stories reward the same discipline: knowing what actually runs, not what you think runs.

• Version fingerprinting. We look for PHP and Node.js versions disclosed in response headers, error pages and exposed diagnostic pages, and compare them with the fixed releases above. A patched host behind an unpatched container image is a common gap.
• Bundled runtimes. We check appliances, supplier products and internal tools for embedded PHP or Node.js that does not appear in the main patch process.
• Trust stores outside the browser. On internal and build infrastructure, we check whether scripts, CI runners and services still trust the compromised intermediates. The disclosure page provides test endpoints for exactly this purpose.
• Certificate chains you serve. We review the certificates on your external estate to confirm none chain to emSign ECC Root CA - G3.
• TLS validation in your own code. Where Node.js services call internal APIs by IP address, we test whether hostname verification behaves as expected after the update.

Key Takeaways

1. Patch PHP now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and plan for anything older.
2. Upgrade Node.js to 26.12.1, 24.22.1 or 22.23.4. Then rebuild the images, snapshots and executables that embed it.
3. Update trust stores everywhere. Browsers protected themselves within hours. Many other clients did not.
4. Replace certificates chaining to emSign ECC Root CA - G3 before Chrome's root removal lands on 27 October.
5. Inventory the layers underneath your applications. Runtimes and certificate bundles are easy to miss and quick to exploit.
6. Verify, do not assume. Confirm the running version and the trust store in use on each system, not the package list.

Conclusion

None of this week's issues needed a clever attacker to find an unusual application bug. They sat in shared foundations: the interpreter, the runtime and the chain of trust. That is why they spread so widely, and why they are so easy to overlook during a routine patch cycle.

The organisations that respond well this week will be the ones that can answer a simple question quickly: where does this run? If that question takes days to answer, a manual test by a CREST-accredited team is a practical way to find the gaps before someone else does.

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation.

Card image: PHP logo by Colin Viebrock, licensed under CC BY-SA 4.0, shown with the Node.js and eMudhra logos on a plain background.