PHP, Node.js, Plex and the Trouble With "Already Patched"

Picture opening Monday's security email after spending last week getting updates out the door. PHP is back in the subject line. Your first reaction might reasonably be: didn't we just do this?

On October 26, the PHP team released rebuilt Windows packages that keep the same PHP runtime versions. The change is tucked into the package suffix: 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 now bundle Brotli 1.2.1. A version number that looked reassuring on Wednesday can therefore miss Monday's dependency repair.

That's the thread connecting PHP2Shell, Node2Shell and Plex2Shell. These aren't three brand-new Friday disclosures. Looking across October 23-26, the useful story is the follow-up: another dependency, a narrower PHP attack path, upstream Ruby fixes, and an older Plex problem that still warrants urgent attention. The nicknames are memorable. The work hiding underneath them is easier to miss.

PHP's second look has two parts

The earlier PHP2Shell fixes arrived October 21. CVE-2026-109618 concerns memory corruption during out-of-memory handling; CVE-2026-109619 involves request state surviving after its memory has been released. Both were addressed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The demonstrated mod_php attack can run before application code, while other deployment paths have different prerequisites. Treating every PHP installation as equally exploitable obscures useful information.

Friday brought a separate complication. PHP's October 23 session upload progress notice tracks CVE-2026-115560, which the Canadian Cyber Centre confirms wasn't addressed by Wednesday's updates. It requires an unusual combination: session upload progress remains enabled, the configured serialization handler is php_binary or php_serialize, and application code switches it to php at runtime before starting the session.

PHP recommends session.upload_progress.enabled=0 pending the regular fix. Applications that never switch the handler at runtime aren't exposed to that particular path. Keep an already applied mitigation in place. This is a reason to check the application's behavior, rather than assume every PHP site has acquired another equally reachable hole.

Monday's Windows rebuild addresses something else again: CVE-2026-111497 in Brotli decompression. PHP's cURL extension can reach it when automatic HTTP response decompression is enabled. That's disabled by default in cURL, but application code and HTTP libraries can enable it. The rebuilt package matters even though PHP's own source release and displayed runtime version haven't changed.

Node2Shell reaches beyond Node.js

Brotli is a compression library. If the name sounds like something your business doesn't use, that doesn't tell you whether software you rely on includes it.

Node.js addressed CVE-2026-111497 on October 21 in versions 22.23.4, 24.22.1 and 26.12.1, rating it High. An application must decompress attacker-controlled Brotli data through node:zlib to reach the flaw. Memory corruption can produce a crash, disclose process memory or potentially allow code execution. Simply having Node.js installed doesn't establish a reachable remote attack.

MyCERT's October 24 Node2Shell advisory is a weekend follow-up to those releases. Red Hat added its own Brotli bulletin on October 26, covering the library's presence across runtimes, browsers and other products. That broadens the places to look; it doesn't create another CVE each time the same decoder appears in a different package.

I'd be more interested in which application actually decodes unVertrauened data than in how many alarming names a scanner displays. Red Hat describes public proof-of-concept memory corruption and crashes; its bulletin doesn't establish widespread real-world code execution. That distinction affects incident response, even when the update is clearly worth doing.

Ruby's quieter follow-up belongs here too

Ruby's notice dated October 23 brings the same dependency problem into view from another direction. Ruby 4.0.9, 3.4.12 and 3.3.13 contain the underlying regex compilation fixes associated with GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264. These are existing GitLab CVEs, not four newly assigned Ruby vulnerabilities.

The important boundary is whether an application compiles regular expressions supplied by an attacker. Using developer-written patterns to search ordinary customer input isn't the same thing. Ruby says regex timeouts don't protect against these compilation bugs. A GitLab code execution path therefore doesn't make every Ruby application remotely exploitable.

GitLab had already shipped its corresponding fixes in earlier releases. Its October 21 update includes 19.5.1, 19.4.3 and 19.3.6, plus backports for older lines; GitLab.com and GitLab Dedicated are patched. For self-managed GitLab, follow GitLab's package guidance. Updating a separate system Ruby doesn't establish that the application's bundled Ruby has changed.

Plex is the one where patching may be only half the job

Plex2Shell is older urgent context. The fixed Plex Media Server build, 1.43.3.10861, was available in August. Public research appeared October 16, and Plex's October 19 security update reported active, widespread attacks against unpatched internet-facing servers.

The chain combines CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656 to allow unauthenticated code execution with the server process's privileges. Plex reported compromised machines running miners and proxy software. This is a stronger exploitation signal than a laboratory crash.

CISA added all four to its exploited-vulnerability catalog October 20. The federal remediation deadlines differ: October 23 for 96654 and 96656; November 3 for 96652 and 96655. Those aren't universal business deadlines or a reason to wait.

Plex advises treating an older, internet-reachable server as potentially compromised. Update, but also investigate. If compromise can't be ruled out, its guidance calls for a clean rebuild, account remediation and consideration of what the service account could access. A newly patched version can't tell you what happened yesterday.

A more useful Monday conversation

I'd put an exposed, unpatched Plex server near the front of the queue because the vendor reports actual attacks. Internet-facing PHP and reachable Brotli or regex processing deserve prompt attention based on their real configuration. A hidden runtime inside a container or NAS application still needs an owner.

Ask which running application received which fix, including bundled dependencies and any vendor backport. Then test that the service restarted into the repaired build and still works. Package evidence helps establish remediation; logs and investigation answer the separate compromise question.

There's nothing unreasonable about wanting to close the ticket. Just leave room for the tiny suffix, the embedded library and the follow-up notice that arrives after everyone thought the job was finished.

Share