PHP2Shell, Node.js and eMudhra: what broke this week and what to do now

This week’s security updates affect software beneath your application code. PHP disclosed two critical flaws in its interpreter. Node.js released fixes for ten vulnerabilities. eMudhra’s compromised intermediate certificate keys forced updates to the trust stores that HTTPS clients depend on.

For an engineering team, these are three separate fixes. Updating application dependencies does not necessarily replace the running interpreter, restart a bundled Node.js process or change the certificates trusted by a deployed binary. This review covers the releases available on October 21, 2026, what they fix and the evidence to collect before closing the work.

Details circulated on October 20, ahead of the planned disclosure. Cloudflare reported early attacks on the morning of October 21, before the PHP update was released. The NSA and the FBI urged organizations to update promptly and take affected systems offline when an immediate update was not possible. The FBI also advised watching for PHP processes launching shells or downloading files, preserving logs when compromise is suspected and reporting incidents to a local field office or IC3.

Exposure map · October 21, 2026

Three layers beneath your application

Check the interpreter, runtime and trust store in each deployed environment.

01InterpreterPHP2ShellRequest handling → memory corruption → possible code executionPatch PHP
Restart workers ↗ 02RuntimeNode.jsDecompression, DNS, TLS and permission checksUpdate runtime
Redeploy services ↗ 03Certificate trusteMudhraCompromised CA keys → certificates an outdated client may acceptUpdate trust
Rebuild clients ↗

PHP2Shell: a flaw below application code

PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, two PHP core vulnerabilities that can allow unauthenticated remote code execution. PHP’s advance notice rated both CVSS v4.0 9.2. Its October 21 security advisory puts every PHP installation serving web requests in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The PHP team considers mod_php the riskiest configuration because a demonstrated attack reaches the vulnerable code before the application runs. Updating WordPress, a plugin or your framework leaves that interpreter untouched. In the demonstrated mod_php attack, application login checks run too late.

Swipe or scroll horizontally to compare all columns.

The OOM advisory and stale state advisory are the technical references. Early reports discussed different trigger paths. Use the published advisories when deciding whether a workaround covers your deployment.

PHP request lifecycle · simplified

The request can fail before your app can reject it

External inputRequest reaches a PHP worker

An unauthenticated client supplies data the interpreter must handle.

↓

CVE-2026-109618Initialization is interrupted

Cleanup encounters invalid, partially initialized data.

CVE-2026-109619Old request state survives

A later request encounters state whose memory was freed.

↓

Possible outcomeCode executes with the worker’s authority

Accessible files, credentials and network destinations determine the potential damage.

Fix the interpreter.A login screen, an application update or a read only business workflow does not remove the memory flaw.

If an attacker executes code in a worker, review the secrets and resources that process could reach. Database credentials, session material and API keys may be in scope. That is a reason to investigate the exposure and plan credential replacement. It is not evidence that every exposed server has already leaked its secrets.

PHP: fixed versions and temporary measures

The PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution packages may carry a backported fix under a different version string. Keep the vendor advisory and package build number as evidence rather than comparing only the upstream version.

Swipe or scroll horizontally to compare all columns.

Check the runtime serving traffic. The PHP binary in an administrator’s terminal can differ from the one loaded by the web server. A new container image in the registry also says nothing about the version running in an old replica.

In its October 21 advisory, PHP asked users of the volunteer maintained rpms.remirepo.net repository to switch to distribution packages or build from source, saying that the repository would not provide updates that day. PHP 8.2 reaches end of life on December 31, 2026, so treat 8.2.35 as a stopgap and plan the move to 8.3 or later.

Until a fixed runtime is deployed, the PHP advisory describes settings that reduce specific attack paths. Apply them at server or pool level and restart workers where instructed. They are incomplete mitigations.

• Session upload progress. Setting session.upload_progress.enabled=0 blocks confirmed session paths, not all variants. It must apply before request parsing. An application’s ini_set() call is too late.
• PHP 8.5 fatal backtraces. Setting fatal_error_backtraces=0 blocks the confirmed fatal backtrace path only.
• Memory and input limits. The advisory describes memory_limit=-1 alongside request size controls and container or cgroup limits. Removing PHP’s limit alone can create availability problems, and underlying allocation failures can still reach the vulnerable path. Follow the complete vendor guidance for your environment.
• Edge filtering. Managed WAF rules and restrictions on unnecessary upload requests can reduce reachable attack paths. They do not repair PHP, and traffic that bypasses the proxy bypasses its rules.

CERT-EU advised identifying PHP applications and considering isolation of services exposed to the internet when immediate patching is not feasible. Cloudflare reported enabling its managed WAF protections on October 21. Neither an edge rule nor a successful package installation is sufficient evidence that the origin is patched.

Record the exposure window and investigate it. Review web and PHP logs, worker crashes, unexpected child processes, new files in web directories and outbound connections. Treat a PHP worker spawning an unexpected shell or downloader as a lead to investigate. Preserve relevant evidence before rebuilding a suspected compromised host. A lack of alerts is inconclusive when process or network telemetry was absent.

Node.js: update the runtime that actually runs

The October 21 Node.js release fixes ten CVEs, four rated high, in supported release lines. The fixed releases are 22.23.4, 24.22.1 and 26.12.1. The update also includes certificate changes related to eMudhra.

Swipe or scroll horizontally to compare all columns.

The table shows five of the ten fixes. The remaining fixes cover socket responses, certificate validation, entropy caches, ZIP validation and a filesystem permission lookup. Use the complete release notice for your branch. Move unsupported versions to a supported line rather than waiting for an upstream patch.

Start with services that process untrusted compressed data or make outbound connections using Node’s DNS and TLS APIs. Then check background workers, CI runners, desktop tools and local MCP servers. A runtime installed through a version manager may be unrelated to the executable used by a service manager or an agent client.

For each service, retain the executable path, runtime version, deployment artifact and replacement process start time. An npm install updates packages. The Node.js executable can stay exactly the same.

eMudhra: a browser update does not update every client

On October 17, Mozilla received a report that private keys associated with eight eMudhra intermediate certificates had been compromised. An attacker holding an intermediate CA key can issue fraudulent certificates. To use that capability to intercept HTTPS, the attacker also needs to reach the connection path and the client must accept the resulting chain.

The public Mozilla incident record says its engineers independently recovered the affected private keys, confirming a flawed key generation process. Six certificates were for TLS and two for code signing. The weak keys exposed signing authority, rather than an individual website’s application code.

Mozilla reports distributing a OneCRL block within three hours for Firefox users with standard configurations. Later releases addressed clients whose settings prevented that update. Applications using a derived certificate bundle do not necessarily receive Firefox’s revocation updates.

TLS trust · simplified

The same certificate meets two different clients

A compromised intermediate key can produce a fraudulent server certificate.

Certificate controlled by the attackerSigned with a compromised CA key

Presented during a connection the attacker can intercept or redirect.

↓

Client AUpdated trust or revocation data

The affected chain is rejected by the client’s validation rules.

↓

Connection rejectedKeep certificate validation enabled.

Client BOld bundled trust store

The chain may remain trusted without an effective revocation check.

↓

Connection may be acceptedCredentials and traffic can be exposed.

Inventory the trust implementation used by each deployed client. Some use the operating system store, some bundle certificates and some have custom validation or pins. Updating the browser on a developer’s laptop does not establish what a production API client trusts.

• Go. The Go vulnerability record for CVE-2026-111943 identifies fixes in 1.27.3 and 1.26.10 for crypto/x509. Rebuild and redeploy affected binaries with a fixed toolchain. Updating the compiler on a build machine does not change binaries already deployed.
• Python. The certifi advisory recommends 2026.10.19 or later. Update pinned dependencies and images that vendor the bundle. Check the virtual environment actually used by the service.
• Node.js and other clients. Apply the runtime and certificate updates supplied by the relevant vendor. Check custom CA files and application overrides as well as system packages.

Test normal outbound connections after the change. If a vendor endpoint stops validating, investigate the certificate chain with that vendor. Disabling TLS verification to restore service would remove the control the update is intended to repair.

A response that ends with evidence

Assign an owner to each affected service and record four things before patching: the runtime or trust bundle, where it runs, whether it is exposed and which credentials it can use. That small inventory makes it possible to distinguish a fixed service from an updated package somewhere else.

Oktsec response workflow

Patch the exposure. Investigate the past.

01 · IdentifyLocate affected running workloads

Include origin servers, containers, vendor appliances, CI and local agent tools.

↓

02 · TriageAre there signs of compromise?

Unexpected processes, files, connections or credential use.

Yes, or incident response is warranted

Isolate and preserve evidence

Collect relevant telemetry. Investigate persistence and access. Recover from trusted artifacts and rotate exposed credentials.

No signs identified

Patch promptly and review exposure

Rebuild, redeploy and restart affected workloads. If patching is delayed, isolate the exposed service and record the exception.

↓

03 · Verify before closingConfirm the running version and effective trust storeRecord replacement artifacts, process start times, validation results and remaining investigation work.

For a startup with a small engineering team

Give one engineer responsibility for the affected services and another person responsibility for checking the result. Start with public PHP origins and externally reachable vendor products. Ask the hosting provider for the fixed package or backport reference and confirmation that workers were restarted. Then update Node services and the outbound clients that carry business credentials.

Keep a short patch record in the incident or deployment ticket. Include the old version, new artifact, deployment time, verification and any unresolved exposure. Avoid closing the ticket with only “dependencies updated.”

For an enterprise with many owners

Separate centrally managed runtimes from bundled ones. Platform engineering may patch the standard image while a business application, appliance or service managed by contractors continues running its own copy. Require the service owner to attest to the running artifact, with a vendor reference for backports and an expiry for temporary exceptions.

Check autoscaling templates, disaster recovery environments and rollback images. Otherwise the next scaling event or rollback can restore the vulnerable version. Preserve a trusted recovery option without making an old vulnerable image the default deployment target.

Include agent tools in the inventory

None of these incidents needs an AI agent to be exploitable. Agents matter here because their tools run on the same infrastructure and often carry credentials. A local MCP server may use Node.js, a tool may call a PHP backend and an outbound client may rely on a bundled CA store. The relevant question is which executable and trust configuration each workflow actually uses.

1. Trace the launch path. For each MCP server, plugin or hook, identify its owner, command, runtime path, package or image version and update mechanism. Include machines outside the production cluster.
2. Check delegated access. Document which credentials the tool can read and which systems those credentials can reach. Prefer scoped access that expires, where supported.
3. Control outbound requests. Restrict destinations where practical and keep TLS verification enabled. Domain allowlists do not repair a broken certificate validator.
4. Review execution permissions. Limit shell access, writes and privileged tools to the workflow’s needs. A policy gateway cannot compensate for a compromised runtime that can bypass it.
5. Keep useful evidence. Correlate tool call decisions with host telemetry and downstream results. A signed policy record can establish what the gateway decided, but cannot prove that an unmonitored process did nothing else.

Oktsec’s Assessment can examine runtime exposure, reachable code paths and the credentials available to a workflow within an agreed scope. Control applies configured policies to agent actions routed through its enforcement points and provides audit evidence. Runtime patching, host investigation and certificate store maintenance remain necessary.

Before you mark the work complete

• PHP: fixed upstream release or documented vendor backport is running in every affected worker.
• Node.js: services, bundled tools and local MCP servers use the intended fixed runtime.
• TLS clients: deployed binaries and bundles contain the relevant trust updates. Verification remains enabled.
• Recovery: scaling, failover and rollback will not silently reintroduce the affected artifacts.
• Investigation: the exposure window, telemetry gaps and credential decisions are recorded. Suspicious activity has an owner.
• Reporting: in the US, report suspected or confirmed compromises to a local FBI field office or IC3.

For the broader recovery process, see our guide to preparing for a disruptive cyber attack. For PHP persistence and Linux host investigation, the Unit 42 campaign review describes behaviors worth looking for after an initial compromise.

Sources and review date

Reviewed October 21, 2026. Release details and vulnerability descriptions come from the maintainers and incident responders below. The diagrams, prioritization and closure checks are Oktsec’s analysis. These fixes are current as of October 21. Newer versions may replace them.

1. PHP: critical remote code execution advisory and fixed releases, October 21.
2. PHP: CVE-2026-109618, RCE via OOM corruption.
3. PHP: CVE-2026-109619, RCE via stale global state.
4. CERT-EU: Security Advisory 2026-018.
5. Cloudflare: WAF protections against PHP2Shell.
6. FBI Cyber Division: notice on CVE-2026-109618 and CVE-2026-109619, October 21.
7. NSA: advisory on PHP updates, October 21.
8. Tenable: PHP2Shell FAQ and Cloudflare’s early attack reports.
9. Node.js: October 21 security releases.
10. Mozilla: response to the eMudhra intermediate certificate compromise.
11. Go: GO-2026-6809 / CVE-2026-111943 and release history.
12. certifi: emSign root CA security advisory.