SECURITY Advisory
Three significant issues disclosed between 17 and 21 October 2026 that may affect your web applications, APIs and supporting infrastructure, and exactly how to fix them.
Three issues, one week to act
This advisory consolidates three significant security issues disclosed between 17 and 21 October 2026 that may affect web applications, APIs and supporting infrastructure. Each is detailed in its own section with remediation and priority.
PHP2Shell: PHP remote code execution
CVE-2026-109618
CVE-2026-109619
Exploited in the wild; public PoC
Node.js Brotli decoder RCE & TLS hostname bypass
CVE-2026-111497
CVE-2026-106069
CVE-2026-105483
Public details; no confirmed exploitation
eMudhra (emSign) intermediate CA private key compromise
CVE-2026-111943 (Go denylist)
CA incident
Keys publicly recoverable; browsers have blocked
Are you affected?
Version is 8.5.11 or earlier, including all end-of-life branches (5.x – 8.1)
Version is 22.x, 24.x or 26.x below the fixed release, or any 18.x / 20.x
Certificates chain to emSign ECC Root CA – G3, or CA bundles have not been updated since 17 Oct
eMudhra weak CA keys reported
Browsers & OS vendors block CAs
PHP2Shell details leak; attacks begin
PHP & Node.js emergency patches
This advisory issued
Active exploitation is under way.
Upgrade all affected release lines.
Apply across all systems.
PHP2Shell: unauthenticated RCE in the PHP runtime
| Category | CWE-416: Use After Free / CWE-824: Access of Uninitialized Pointer |
|---|---|
| CVE IDs | CVE-2026-109618, CVE-2026-109619 |
| CVSS v4.0 | 9.2 (Critical) for each CVE, as rated by the PHP Security Team |
| Exploitation | Public proof-of-concept available; early in-the-wild exploitation reported (Cloudflare, watchTowr) |
| Disclosure | Details leaked 20 Oct 2026; emergency patches released 21 Oct 2026 |
- Patch todayUpgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker.
- End-of-life PHP (5.x – 8.1)No fix will be released. Isolate or take the service offline until migrated.
- Assume exposureReview any host that was internet-facing before patching for signs of compromise.
Two critical memory-safety vulnerabilities in the PHP runtime, collectively named PHP2Shell, were disclosed by researchers from Wiz, OpenAI and Calif. The PHP Security Team pre-announced an emergency release for 21 October 2026, but technical details and a proof-of-concept leaked ahead of coordinated disclosure, and exploitation attempts began before official patches were available.
Unlike typical web-application flaws, these vulnerabilities sit in PHP’s own runtime and are reachable regardless of the application code deployed on top of it. Successful exploitation yields full remote code execution without authentication or user interaction. Other demonstrated effects include worker crashes (denial of service), arbitrary file reads and disclosure of server memory.
Given the breadth of affected installations and public exploit tooling, mass automated exploitation is expected. Several organisations have temporarily taken PHP services offline until patching is complete.
PHP runtime: session handling (session.upload_progress), OPcache class caching, fatal-error backtrace generation, multipart request parsing
PHP 5.4.0 through 8.5.11 (effectively all versions). End-of-life branches 5.x, 7.x, 8.0 and 8.1 will not receive fixes.
Every PHP installation serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache mod_php is rated highest risk.
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
PHP can leave its memory in a corrupted or stale state when a request terminates abnormally (e.g. out-of-memory or fatal error). An unauthenticated attacker can trigger this with a crafted HTTP request and achieve remote code execution with the privileges of the web worker, in some configurations before any application code executes.
How the attack works
RCE via out-of-memory corruption
An out-of-memory condition can halt PHP while request data (e.g. multipart parsing into $_POST / $_FILES) is only partially initialised. Cleanup routines then treat the partial structures as valid, producing memory corruption that can be turned into code execution.
RCE via stale global state
Global state owned by one request (error/backtrace data, session data, objects, extension state, serialize buffers) can survive after its memory is freed, because fatal errors skip the reset path. The result is a heap use-after-free enabling memory disclosure and RCE.
Target identification
Attacker scans for hosts serving PHP (5.4 to 8.5.11), identified via response headers, error pages or framework fingerprints.
Abnormal termination
A crafted, unauthenticated request (malformed multipart upload or session.upload_progress abuse) exhausts memory or raises a fatal error at a precise point.
Memory corruption
PHP stops processing but fails to clean up internal state, leaving freed or uninitialised memory reachable by the next request.
Code execution
By shaping heap contents, the attacker gains code execution as the web worker, then deploys a web shell, reverse shell or persistence.
What this means for your business
Unauthenticated RCE
Full control of the PHP process without credentials or user interaction.
Pre-application exploitation
On mod_php the exploit can trigger before any application code runs, so in-app controls (authentication, WAF rules) offer no protection.
Memory & file disclosure
Leakage of server memory and arbitrary file reads, exposing credentials, keys and session data.
Denial of service
Repeated worker crashes causing service outage.
Data breach & regulatory exposure
Compromise of customer, financial or personal data may trigger mandatory breach notification.
Defacement & backdoors
Attackers can alter content, inject malicious scripts targeting visitors or establish long-term persistence.
Mass-exploitation risk
With public exploit tooling, every exposed PHP host is a candidate for automated attack within hours.
Service disruption
Outages from crashes or from precautionary shutdowns during emergency patching.
How to fix it
Upgrade PHP immediately
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for your branch. This is the only complete fix. Restart all PHP-FPM pools, Apache workers and containers, and rebuild any Docker/CI base images that bundle PHP.
Migrate unsupported versions
PHP 5.x, 7.x, 8.0 and 8.1 will not be patched. Plan an urgent migration to a supported branch; until then, restrict network access to affected hosts or take them offline.
Apply interim mitigations (stop-gap only)
Disable upload progress and restart every worker; enable the emergency WAF rules from your CDN/WAF provider (Cloudflare, Imperva and others have deployed signatures). These reduce exposure but do not eliminate it.
session.upload_progress.enabled = 0
Prefer PHP-FPM over mod_php
Where feasible, run PHP under PHP-FPM with a dedicated low-privilege user and strict open_basedir / disable_functions settings to limit post-exploitation impact.
Hunt for compromise
Review web-server and PHP-FPM logs for abnormal request terminations and memory-exhaustion errors, new or modified files in web roots, unexpected child processes and unusual outbound connections. Treat any host exposed before patching as potentially compromised.
Node.js: Brotli RCE & TLS hostname bypass
Informally dubbed “Node2Shell”
| Category | CWE-787: Out-of-bounds Write / CWE-297: Improper Validation of Certificate with Host Mismatch |
|---|---|
| CVE IDs | CVE-2026-111497 (Brotli RCE), CVE-2026-106069 and CVE-2026-105483 (TLS hostname bypass), plus 7 further medium/low issues |
| Severity rating | High (Node.js Security Working Group); 4 of 10 issues rated High |
| Exploitation | No active exploitation confirmed at time of writing; technical details are public |
| Disclosure | 21 Oct 2026 (Node.js October 2026 Security Releases) |
- Patch within 24–48 hoursUpgrade to Node.js 22.23.4, 24.22.1 or 26.12.1.
- Node.js 18 / 20End-of-life with no fix. Migrate to a supported release line.
- Everywhere Node runsRebuild Docker images, CI/CD runners, serverless runtimes and developer machines.
On 21 October 2026 the Node.js project released security updates for all supported release lines, addressing ten vulnerabilities, four rated High. The most serious, CVE-2026-111497, is an out-of-bounds write in the Brotli decoder bundled with Node.js that permits remote code execution. It was reported by a member of the Node.js Technical Steering Committee.
The release also fixes two High-severity TLS certificate hostname-verification bypasses, plus medium-severity issues affecting HTTP keep-alive sockets, DNS resolution, random value generation, ZIP processing and filesystem permission checks.
The community has informally called this release “Node2Shell”, but the Node.js project has not named it; the CVEs are the authoritative identifiers. No in-the-wild exploitation is confirmed, but the attack surface is broad (any service accepting compressed input) and details are public.
Node.js core: bundled Brotli decoder (zlib), TLS certificate hostname verification, HTTP keep-alive handling, DNS, ZIP processing and filesystem permission checks
Node.js 22.x, 24.x and 26.x. Node.js 18.x and 20.x are end-of-life and remain vulnerable without a fix.
Node.js 22.23.4, 24.22.1, 26.12.1
Production servers, Docker images, serverless runtimes, CI/CD agents and developer workstations are all in scope.
A Node.js process that decompresses attacker-controlled Brotli data (via built-in fetch(), undici, body-parser/compression middleware or direct zlib.brotliDecompress calls) can be made to write out of bounds, corrupting memory and allowing arbitrary code execution. Separately, TLS hostname checks can be bypassed when the host loosely resolves to an IP address, so a certificate issued for a different server is accepted.
How the attack works
Brotli out-of-bounds write
The Brotli decompression routine fails to bound a write when processing a crafted stream. An attacker who can supply Brotli data (a request body with Content-Encoding: br, a response consumed by outbound fetch(), or an uploaded file) can corrupt heap memory and execute code with the Node.js process’s privileges.
TLS hostname bypass
When a hostname loosely resolves to an IP address (or under similar edge conditions), Node.js does not correctly match the certificate’s Subject Alternative Names against the intended host. An on-path attacker could present a valid certificate for an unrelated domain and intercept “verified” TLS.
Find a Brotli ingestion point
An endpoint accepting compressed bodies, an upload later decompressed, or an outbound client (webhook fetcher, link previewer, proxy) that accepts br responses.
Deliver malformed stream
A crafted Brotli payload is sent directly, or served from an attacker-controlled server that the application fetches.
Memory corruption
The decoder writes beyond the allocated buffer, corrupting adjacent heap structures.
Code execution or crash
Depending on heap layout, the attacker gains code execution in the Node.js process (process, child_process, filesystem) or crashes the service.
What this means for your business
Remote code execution
Arbitrary code within the Node.js process, inheriting its privileges, secrets and network reach.
MITM of outbound TLS
Applications may accept certificates for the wrong server, exposing API tokens and data sent to third parties.
Denial of service
Process crashes via malformed Brotli, DNS, URL or HTTP/2 inputs.
Build-chain exposure
CI/CD runners, build tools and developer machines running Node.js are equally affected.
App & API server compromise
Theft of customer data, credentials and signing keys held by the service.
Supply-chain risk
Compromised build pipelines could inject malicious code into shipped software.
Service availability
Crash-based denial of service against customer-facing applications.
Compliance exposure
Failing to patch known RCE vulnerabilities promptly may breach contractual or regulatory obligations.
How to fix it
Upgrade Node.js
Update to Node.js 22.23.4, 24.22.1 or 26.12.1 (or newer) across production servers, Docker images, serverless runtimes, CI/CD agents and developer workstations alike.
Migrate end-of-life versions
Applications on Node.js 18.x or 20.x will not receive fixes and must move to a supported release line (22.x or later).
Temporary mitigation if upgrade is delayed
Reject or strip Content-Encoding: br at the reverse proxy, remove “br” from Accept-Encoding on outbound HTTP clients, and avoid decompressing untrusted Brotli data until patched.
Verify TLS hostname handling
After upgrading, ensure outbound HTTPS clients still use default certificate verification and do not rely on IP-address hosts for services that present domain-based certificates.
rejectUnauthorized: true
Audit dependencies
Run npm audit or your SCA tooling to find libraries bundling their own Brotli implementations (e.g. native modules) and update them as fixes land; the Bun runtime has indicated a fix is in progress.
eMudhra (emSign): CA private key compromise
Forged certificate risk
| Category | CWE-331: Insufficient Entropy / CWE-295: Improper Certificate Validation |
|---|---|
| Identifiers | CA incident (Mozilla / Chrome Root Program); CVE-2026-111943 (Go crypto/x509 denylist); vendor advisories USN-8944-1/2, DSA-6572-1 |
| Exploitation | Private keys publicly demonstrated as recoverable; no forged certificates observed in Certificate Transparency logs to date |
| Disclosure | Reported 17 Oct 2026; confirmed by Mozilla and Chrome Root Program 20 Oct 2026 |
- Replace certificatesAnything chaining to emSign ECC Root CA – G3 or the G3B/G3C intermediates.
- Update trust storesOS CA bundles, certifi, Go, Rust, Composer, Java and container images.
- VerifyConfirm clients reject the public eMudhra test endpoints listed in this advisory.
On 17 October 2026 a security researcher reported to the Chrome Root Program that the private keys of eight eMudhra intermediate CA certificates were compromised, proving control by signing a message with each key. The keys were not stolen in a breach; they were inherently weak due to flawed key generation. eMudhra has confirmed the finding, revoked the eight certificates, stopped issuing under the G3 root and stated its infrastructure was not breached. CERT-In has also issued a statement.
Mozilla (OneCRL), Google Chrome (CRLSet) and Apple blocked the intermediates between 17 and 19 October; Microsoft followed on 20 October. Chrome has also removed emSign ECC Root CA – G3 from its Root Store and is reviewing eMudhra’s remaining roots. Ubuntu, Debian, Go, Python certifi, Rust webpki-roots, Composer and Homebrew have shipped updates.
Browsers are protected, but servers, APIs, mobile apps, IoT devices, mTLS deployments and any software with its own trust store or no revocation checking will keep trusting forged certificates until updated.
eMudhra Limited (India), operating under the emSign brand
Six TLS-issuing CAs (EM DV TLS CA, EM OV TLS CA, EM EV TLS CA – G3B / G3C) and two code-signing CAs (EM OV CS CA – G3B / G3C), operated by eMudhra BV (Netherlands) and eMudhra Inc (USA)
emSign ECC Root CA – G3 and emSign Root TLS CA – G3 (and cross-signs via AAA Certificate Services on older trust stores)
All eight intermediate keys were created in April 2025 during a flawed key-generation ceremony.
The private keys of the eight intermediate CA certificates were generated with cryptographically weak (low-entropy) values. A researcher demonstrated they can be trivially recovered; one published key had the value 4. Anyone holding these keys can issue certificates for any domain, or sign code, that unpatched systems will trust.
How the attack works
Insufficient entropy at key generation
The ECC private keys for the eight subordinate CA certificates were produced with insufficient entropy during eMudhra’s April 2025 key-generation ceremony.
Equivalent to a trusted CA
The intermediates chain to roots trusted by all major root programs, so holding these keys is equivalent to holding a fully trusted CA. Revocation (CRL/OCSP) only protects clients that check it, and many non-browser TLS clients do not.
Key recovery
An attacker recovers a weak private key from the published intermediate certificates. The method is public and near-instant.
Forged certificate
Using the key, the attacker issues a certificate for any target domain (a bank, SaaS API or update server) or a code-signing certificate for a malicious binary.
Interception
Through DNS hijacking, BGP manipulation, a rogue Wi-Fi network or a compromised router, the attacker goes on-path and presents the forged certificate.
Trust & compromise
Unpatched clients accept it, enabling traffic decryption and modification, credential theft, malicious updates or execution of signed malware.
What this means for your business
MITM on any domain
Forged certificates would be trusted by unpatched clients for any website or service.
mTLS / client-cert bypass
Systems accepting client certificates chaining to the affected roots can be impersonated.
Malicious code signing
Software signed under the two compromised code-signing CAs may be trusted by Windows systems lacking the update.
Disruption for eMudhra customers
Legitimate certificates under the affected intermediates or G3 root are now distrusted and will produce errors.
Data interception
Credentials, API tokens and customer data sent by vulnerable clients can be captured or altered.
Outages
Organisations using eMudhra G3 certificates face immediate availability impact until certificates are replaced.
Procurement risk
Chrome is reviewing eMudhra’s remaining roots; further distrust could invalidate more certificates at short notice.
Compliance
Continued trust of a known-compromised CA may breach PKI governance and security-baseline requirements.
How to fix it
Inventory & replace certificates
Identify every certificate chaining to emSign ECC Root CA – G3 or any of the eight G3B/G3C intermediates and replace it with one from an unaffected CA. Avoid procuring new eMudhra certificates until Chrome concludes its review.
Update trust stores on all systems
Apply Ubuntu USN-8944-1/-2, Debian DSA-6572-1, Go 1.27.3 / 1.26.10, Python certifi 2026.10.19, Rust webpki-roots 1.0.10, Composer ca-bundle 1.6.0 / 1.4.16, Homebrew ca-certificates 2026-09-25_1 and the latest Windows, macOS, Java and .NET updates. Rebuild container images.
Explicitly distrust where needed
Where automatic updates aren’t available, import the intermediates (and cross-signs) into the Windows Untrusted Certificates store, or remove emSign ECC Root CA – G3 from app-specific stores (Java cacerts, embedded devices, mobile pinning).
Verify remediation
Test each client against the public verification endpoints. A certificate error confirms the client correctly rejects the compromised intermediates.
curl https://dv-g3b-emudhra.we-have-a-problem.com/ curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
Review code-signing & mTLS
Confirm software-allowlisting and code-signing policies do not trust the two compromised code-signing CAs, and mTLS peers reject client certificates chaining to the affected roots.
Enable revocation & CT enforcement
Where supported, enable OCSP/CRL checking and Certificate Transparency enforcement in non-browser clients to reduce exposure to future CA incidents.
We’re here to help you act fast.
Wattlecorp can support exposure assessment, emergency patching windows and validation of remediation for every issue in this advisory. We will issue a further update should the situation change materially.
[email protected]or reach out through your account manager.
Disclaimer: This advisory is based on information published by the PHP Security Team, the Node.js project, the Mozilla and Chrome Root Programs, eMudhra and reputable security researchers as of 22 October 2026. Version numbers and mitigations should be verified against the official vendor advisories at the time of remediation. No part of this publication may be reproduced, copied or transmitted in any form or by any means without prior written permission from the Owner.