October Patch Week: PHP, Plex, Node, and a CA Key of 4
Four incidents in mid October forced emergency internet work. Here is what was exploited, what was only probing, and what operators should patch first.
6 pontos. É o que as pessoas costumam lembrar. O texto completo está no outro separador.
1 / 6 · Start here
This is about servers you run, not your phone.
You are in this if you run a PHP website, a Plex server the internet can reach, a Next.js or Node app, or a certificate from eMudhra or emSign. Update that thing. PHP means the software under the site, not a WordPress update. Plex means version 1.43.3.10861 or newer, and a reinstall if the old one was open to the internet. If none of that is yours, you are reading about someone else's machine.
2 / 6 · Patch now
PHP powers a huge part of the web.
Two flaws may let an attacker run code on a server without logging in. Attacks were being attempted, but no large confirmed breach was public yet. Update PHP itself, not just WordPress or another app.
3 / 6 · Already exploited
Outdated Plex servers are being taken over.
Attackers are installing crypto miners and proxy software on exposed servers. If your Plex server was reachable from the internet and below version 1.43.3.10861, treat it as potentially compromised.
4 / 6 · Patch this week
Next.js and Node.js fixed serious bugs.
These bugs could crash servers, bypass checks, or let attackers run code. No attacks were confirmed when this post was written, but waiting for proof is not a safe update strategy.
5 / 6 · Refresh trust
A digital master key was basically guessable.
Certificate authorities help devices decide which websites and software to trust. eMudhra created keys so weak that outsiders could recreate them. Browsers blocked them, but older apps and devices may still need updates.
6 / 6 · Less worried
Visiting a website does not give you these bugs.
Chrome, Firefox, Safari, and Edge already blocked the bad certificates. A site you only edit in the browser is the host's update, not yours. Plex that stays inside the house, or a Plex app watching someone else's server, was not the group being mined. Install the normal phone and browser updates. These headlines are not a reason to wipe your computer.
Isto não é aconselhamento financeiro, jurídico, fiscal ou de investimento. Não é uma oferta nem uma recomendação para negociar. Os exemplos são ilustrativos. Os termos das plataformas, as restrições geográficas e a lei local prevalecem. Os avisos completos estão no artigo.
Between October 14 and 21, 2026, four separate incidents forced emergency work across the public internet. Two were runtime RCE stories. One was a trust store cleanup. One was already being mined before most operators noticed.
The four stories are easy to blur together on social feeds. They are not the same urgency. Plex was already exploited in the wild and listed in CISA's Known Exploited Vulnerabilities catalog. PHP was under active probing with emergency patches and no named production victim by late October 21. Next.js and Node.js shipped real high severity fixes with no confirmed wild use. eMudhra's intermediate CA private keys were recoverably weak. One of them was the integer 4.
This post is a status map for operators, not a claim that the public web collapsed.
Who This Affects
These bugs sit on computers that serve other people: a website, a media server, or the certificate that says a site is real. Opening a normal webpage does not put them on your phone or laptop.
If this might be you
- You run a website on PHP. A lot of WordPress sites do. Update PHP itself to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, then restart it. Updating WordPress, a theme, or a plugin does not fix this. People were already trying the attack. No large named break-in was public yet. If you cannot update, take the site offline.
- You run Plex and people outside your house can reach it. You need version 1.43.3.10861 or newer. Version 1.43.3.10828 is still vulnerable. Prefer 1.43.4.10903. If the server was older and open to the internet, assume someone got in. Reinstall it, change the Plex password, and sign out every device. Attackers have been installing crypto miners and proxy tools.
- You run an app on Next.js or Node.js. Update this week. No confirmed attacks yet. Node 20 does not get this fix, so leave it.
- Your site certificate came from eMudhra or emSign. Major browsers already blocked the bad keys. You still need a new certificate. Old phones, gadgets, and servers that never refresh their list of trusted certificates can still be fooled.
What to do
Update the one thing you actually run, then stop. You do not need a new computer, and you do not need to change every password you own.
If a company hosts the whole site and you only edit it in the browser, ask them whether PHP is updated. If you rent the server yourself, you are the one who updates it.
Who can worry less
- You browse with Chrome, Firefox, Safari, or Edge and you do not run a server. Those browsers already blocked the bad certificates. These bugs do not spread because you visited a page.
- Your Plex server never leaves the house, and remote access is off. Or you only use the Plex app to watch a server someone else runs. They are the one who updates it.
- You do not ship a Next.js or Node app. That update is for the people who do.
A normal phone and browser update is still worth installing. These headlines are not a reason to wipe your computer.
How to Read the Week
Same news cycle. Four different urgency levels.
Treat the four incidents as different jobs:
- Plex: exploited now. Patch and assume compromise if the server was reachable from the internet and running a build before 1.43.3.10861.
- PHP: patch immediately. Probing is real. A named mass RCE event is not confirmed yet.
- Next.js and Node.js: patch this week. No confirmed wild exploitation as of October 21.
- eMudhra / emSign: refresh trust stores everywhere TLS runs outside browsers. Browsers already blocked the bad intermediates.
Social volume roughly matched operational urgency for PHP and Plex. Scott Helme's "the key was 4" line made eMudhra the viral PKI story. Next and Node stayed quieter in vendor channels even though they shipped serious fixes.
Incident 01
PHP2Shell: Leak, Then Emergency Patches
On October 20, embargoed details of two critical unauthenticated remote code execution bugs in core PHP leaked. PHP had already scheduled an emergency release for October 21 at 14:00 UTC. The community named the pair PHP2Shell.
On October 21, PHP shipped 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The CVEs are CVE-2026-109618 and CVE-2026-109619. Official severity is CVSS v4.0 9.2 Critical for both, not the leaked 10.0 scores. Attack complexity is High. Impact reaches back through much older PHP, including EOL branches that only get vendor backports.
CISA, Wiz, Cloudflare, and national CERTs treated the bugs as a runtime issue because they sit in PHP itself, not in WordPress or Laravel application code. Updating a CMS does not patch the engine.
Exploitation status
CISA said on October 21 that it had not observed exploitation and did not add these CVEs to KEV. Cloudflare saw attack traffic after WAF rules went live, about nine hours before public disclosure, and said attackers mutated payloads against those rules. Cloudflare's CTO called WAF a stopgap only. watchTowr honeypots saw attempts around patch time. Huntress had not seen it in partner telemetry as of late morning Eastern on the 21st.
No named compromised organization was public by late October 21. Some government and SaaS sites went offline as a precaution, not as confirmed victims.
What to do
Patch now to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or a distro package that includes both fixes. Restart every PHP worker and rebuild containers. PHP.ini tweaks and WAF rules are incomplete. If you cannot update, or still run PHP 8.1 or earlier, take public PHP systems offline. After patching, hunt for workers spawning shells or download tools. An update does not undo an earlier break in.
Incident 02
Plex2Shell: Already Mining Unpatched Servers
This one is an exploitation week, not a new bug week.
Researcher Zach Main publicly described Plex2Shell on October 16: four bugs chained into unauthenticated RCE as the Plex service account. He reported the issues in July. A fix shipped in early August. CVEs landed in September. A public proof of concept appeared on October 16. A honeypot saw successful exploitation on October 17. On October 19, Plex said the chain was "actively and widely exploited" for cryptominers and residential proxy software. CISA added all four CVEs to KEV on October 20.
The CVEs are CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. Individually they look mostly Medium to High. Chained, they are unauthenticated RCE. Affected builds are Plex Media Server before 1.43.3.10861. Current public build cited this week was 1.43.4.10903.
One trap matters in practice: 1.43.3.10828 is still vulnerable. "I installed 1.43.3" is not enough.
Exploitation status
Confirmation exists at three levels: honeypot success on October 17, vendor confirmation on October 19, and CISA KEV on October 20. Observed payloads include XMRig class miners and residential proxy software. Censys measured exposure, not infections: roughly 324,000 Plex hosts, about 30% still on a vulnerable build, with almost no movement in the first days after the public chain.
What to do
Confirm Settings → General shows 1.43.3.10861 or newer. Prefer 1.43.4.10903. NAS app stores lag, so use Plex's manual install when needed. Docker pinned tags do not update themselves. If the server was older than 1.43.3.10861 and reachable from the internet, assume compromise for incident response: rebuild from a clean install, rotate the Plex password, and sign out all devices. Hunt for myawesomeproxy, mylovelyminer, x12345, and outbound traffic to proxystream.st. Patching does not remove an implant or a stolen owner token. Turn off Remote Access and port 32400 forwarding if you do not need them.
Incident 03
Next.js and Node.js: High Severity Patches Only
These are two separate patch jobs. Neither had confirmed wild exploitation as of October 21.
Next.js shipped an out of band update on October 14: v16.4.1 and v15.5.28. The set includes Critical unauthenticated RCE issues in App Router cache components and in Image Optimization / SVG handling on glibc Linux, plus a High Server Actions denial of service issue. This is not the May 2026 middleware auth bypass story.
Node.js shipped a HIGH security release on October 21: v22.23.4, v24.22.1, and v26.12.1. Node 20.x is EOL and was not patched. The same release also refreshed CA certificates for the eMudhra incident. Earlier October 14 Node bumps do not include the October 21 security fixes.
Among the Node issues, the standout High is a Brotli decoder out of bounds write that can permit RCE. There are also TLS hostname bypass bugs and several Medium and Low items. Bun and Istio need their own Brotli patches where they share the vulnerable code.
What to do
Move Node to 22.23.4, 24.22.1, or 26.12.1. Leave 20.x. For Next, install [email protected] or [email protected], rebuild, and redeploy. On 15.x, verify sharp is at least 0.35.5. A lockfile can keep an older sharp after the Next bump. Patching Next does not replace patching Node, and vice versa.
Incident 04
eMudhra: The Private Key Was Literally 4
This was a publicly trusted WebPKI failure at eMudhra Limited, whose TLS brand is emSign. It was not Let's Encrypt, and it was not a stolen HSM story in the usual sense.
Researcher Wayne found eight NIST P-384 intermediate private keys that were integers below 256 while testing Google's paranoid_crypto against the Common CA Database on October 17. One intermediate, EM OV TLS CA G3C, has private scalar d = 4. Chrome and Firefox blocked the keys the same evening. eMudhra revoked them as cACompromise on October 18. The story went public on October 20.
The weak certificates were created on April 30, 2025, so they were recoverable for about 17 months. All eight were also cross signed by Sectigo. eMudhra's preliminary account points to a wrap and unwrap test that created a second, weak key set with similar labels, then humans used the weak keys for CSRs. The root cause analysis is not finished.
Exploitation status
Independent recovery of the keys is confirmed. Chrome reported that no TLS certificates chaining to the six TLS intermediates were logged to Certificate Transparency before the October 17 block, so browsers that enforce CT by default could not have trusted a fraudulent leaf in that window. eMudhra says the eight issuers minted no end entity certificates. It is still unknown whether clients without CT, including curl, Python, Node, and IoT devices, were targeted during the open window.
Filippo Valsorda told Ars the cleanup would be bigger than Heartbleed because of frozen CA bundles in IoT, containers, and language runtimes. That is about long tail trust stores, not a claim that every eMudhra certificate on the internet is suddenly worthless.
What to do
Update OS ca-certificates and every bundled trust store. Known cleanup releases include Node 22.23.4, 24.22.1, and 26.12.1; Go 1.27.3 and 1.26.10; the curl CA bundle dated October 20, 2026; and cloudflared 2026.10.2. Verify that the affected intermediates and the emSign ECC Root CA G3 are no longer trusted. The living patch table tracks other runtimes, including Electron, Deno, and Python bundles. eMudhra TLS subscribers on the ECC G3 hierarchy need to reissue onto G1 RSA. Custom origin and mTLS stores still need manual action even if browsers and Cloudflare edges are already blocked.
Also This Week
A few other operational headlines sat beside the four named stories:
- ConnectWise Cloud Backup credentials were abused against Microsoft 365 tenants around October 15 and 16. Huntress reported unauthorized Graph tokens in 162 partner tenants.
- CISA and the FBI warned on SafePay ransomware.
- Oracle's October Critical Patch Update bundled more than a thousand CVEs.
- WordPress Core LFI CVE-2026-87902 landed in KEV around the middle of the month.
Those matter to the teams that run them. They do not have the same blast radius as core PHP or a CA ceremony failure.
What Operators Should Know
- Patch urgency is not the same as confirmed mass exploitation. Read the status before you reuse Log4Shell language.
- Treat an exposed, vulnerable Plex server as potentially compromised. Stale NAS packages and pinned Docker tags are the failure mode, not missing vendor guidance.
- PHP is the largest emergency by blast radius. Updating the CMS is not enough. Restart workers after the runtime update.
- Next and Node were crowded out of the social timeline. They still need the same calendar.
- Browser blocks do not finish a CA incident. Frozen trust stores in containers, IoT, and language runtimes are the long cleanup.
- A patch does not erase an earlier implant, stolen token, or fraudulent cert minted while a key was weak.
The common thread across PHP, Plex, and eMudhra is old code and old ceremonies meeting faster discovery. The operator response is simpler: patch PHP and Plex tonight, bump Next and Node this week, and refresh trust stores everywhere curl still runs.
References: PHP advisory, October 21, CISA PHP alert, Plex security notice, CISA KEV, October 20, Next.js October 14 update, Node.js October 21 releases, Scott Helme on eMudhra, eMudhra statement, and Cloudflare on eMudhra.