The October 2026 vulnerabilities one week on: what was exploited, who patched, and what is still open

The week of 20 October 2026 produced more security work than most quarters: an emergency PHP release, a Node.js release, four BIND fixes, an Oracle update and alert for Java, a compromised certificate authority and a set of Linux kernel reports that went public before their fixes. A week later the picture has changed. One of these is now confirmed as exploited, several vendor patches have landed, and a few gaps are still open. This is the status as of 29 October 2026, issue by issue, with what each one does, where the fixes stand across the hosting stack, and what to do on both the server and the application side.

Where does each issue stand?

PHP2Shell: what does it do, and where is it now?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two memory-safety bugs in PHP’s request handling rated 9.2 on CVSS v4.0. An unauthenticated request can trigger them while PHP is still parsing input, before any application code runs, which is why a hardened WordPress or a strict framework offers no protection. Every web SAPI is affected, and the PHP advisory rates Apache with mod_php as the highest risk.

The status changed on 26 October, when CISA added both CVEs to its Known Exploited Vulnerabilities catalog with a remediation deadline of 29 October for US federal agencies. Researchers reported successful exploitation against a honeypot running Apache with mod_php on PHP 8.4.26, and public exploit code is circulating. On 23 October the PHP project also published an informational advisory for a separate issue, CVE-2026-115560, in the session upload progress feature, which the October releases do not fix. Its mitigation is the same setting many servers already used as a stopgap: session.upload_progress.enabled = 0.

Which vendor patches have shipped for PHP2Shell?

On the hosting side the rollout was fast. cPanel shipped EasyApache 4 release 25.91 on 21 October with fixes for ea-php74 through ea-php85, plus a cPanel and WHM security update for its internal PHP in builds 138.0.18, 136.0.50, 134.0.66 and 110.0.153. CloudLinux released backported ea-php52 through ea-php85 the same evening, keeping the old version numbers, then php.net-numbered builds such as ea-php84 8.4.27-1 on 23 October. Its alt-php packages reached the stable repositories for CloudLinux 7, 8 and 9 on 22 October and for CloudLinux on Ubuntu 22.04 on 21 October; CloudLinux 10 takes them from the TuxCare ELS repository, and CloudLinux 6 is listed as not confirmed.

Imunify360 shipped five WAF ruleset updates between 21 and 23 October, from 8.83 to 8.88, and from 8.84 they also block on LiteSpeed. CloudLinux states plainly that no rule covers the out-of-memory path of CVE-2026-109618, so the rules are an interim layer, not a fix. Among distributions, Red Hat published errata on 21 October for RHEL 8, 9 and 10 PHP streams and AlmaLinux mirrored them the same day, Debian fixed bookworm and trixie, and Ubuntu released USN-8948-1 for its supported releases. The exception is RHEL 9’s php:8.4 module, which was still listed as affected without an advisory on 29 October.

What should you do now about PHP2Shell?

• Server side. Confirm every PHP build by changelog or package version, restart PHP-FPM and any mod_php Apache, and keep session.upload_progress.enabled = 0 because of CVE-2026-115560. On RHEL 9 with php:8.4, move to a patched stream or keep the WAF rules in place until Red Hat ships a fix.
• Application side. Rebuild container images that bundle PHP, restart queue workers and long-running servers, and check web roots for files created since mid-October that no deployment explains.

The full patch-day procedure is in the PHP2Shell patch-day runbook.

Node.js: did anything follow the 21 October release?

The 21 October release fixed ten CVEs, including CVE-2026-111497, an out-of-bounds write in the Brotli decoder that can permit remote code execution. No exploitation has been reported. A post-disclosure proof of concept reportedly reached code execution only on a deliberately weakened test build. The same Brotli bug affects other software that embeds the decoder, and Microsoft shipped out-of-band .NET updates on 25 October; on RHEL and AlmaLinux the system brotli library received errata on 26 October.

On 28 October Node.js published two follow-ups: 24.22.2 with V8 backports and a stream fix, and 26.13.0, which starts the 26 line’s LTS period under the name Lithium. No new 22.x release followed 22.23.4. Docker’s official node images were rebuilt on 28 October, and cPanel’s EasyApache 4 release 25.92 moved ea-nodejs22 to 22.23.4.

• Server side. Update every Node.js copy, including cPanel’s ea-nodejs packages and the system brotli library, then restart services and process managers.
• Application side. Move to 24.22.2 or 26.13.0 where you can, rebuild images from the 28 October tags, and avoid accepting Brotli-compressed bodies you do not need.

BIND: why are most servers still waiting?

ISC’s October release fixed four issues in BIND 9, led by CVE-2026-94300, memory corruption from concurrent GSS-TSIG messages that can crash named and potentially allow code execution, with no workaround. Upstream the fix is 9.20.30 or 9.21.27. ISC reported no active exploitation, and none has been reported since.

The gap is in the distributions. On 29 October Red Hat listed bind, bind9.16 and bind9.18 as affected on every supported RHEL release with no advisory, AlmaLinux had no BIND erratum, and Ubuntu listed bind9 as vulnerable on all supported releases. Debian fixed trixie, but bookworm’s 9.18 branch was still unfixed. Red Hat’s suggested mitigation is to remove the tkey-gssapi-keytab and tkey-gssapi-credential options where GSS-TSIG is not needed, or restrict access to port 53.

Check a BIND build against the upstream ranges:

• Server side. Find every running named, remove GSS-TSIG options you do not use, restrict recursion and port 53 to your own networks, and watch your vendor’s errata.
• Application side. If you ship BIND in a container for development or a sidecar resolver, rebuild it on 9.20.30 rather than waiting for a distribution package.

Java and eMudhra: is the trust problem closed?

Mostly. eMudhra revoked all eight compromised intermediates on 18 October, and Sectigo finished revoking the cross-signed copies on 19 October. Mozilla went further and removed the emSign ECC Root CA – G3, and Chrome’s root store removal of the same root was due to reach all devices by 27 October. Some legitimate certificates that chain to G3 now fail, and eMudhra has announced it is leaving the global public TLS business, so sites using its certificates need to move to another CA.

Oracle’s Security Alert CVE-2026-91403 lists fixed Java builds 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1. Eclipse Temurin shipped 17, 21 and 25 on 22 October, and Amazon Corretto shipped on 23 October with rebuilds on 26 and 27 October. Temurin 8 and 11 builds had not appeared on 29 October, and Red Hat lists its OpenJDK fixes as deferred. On the operating system side, AlmaLinux released critical ca-certificates errata on 22 and 23 October, Debian and Ubuntu removed the G3 root, and certifi shipped several releases from 18 October onward.

• Server side. Install the ca-certificates errata, update every JDK and restart Java and Node.js services so they load the new trust lists.
• Application side. Update certifi, pin a Java build from the alert list, and check that none of your own certificates chain to emSign ECC Root CA – G3.

The trust-store background is in Node.js, BIND and Java in one week.

The leaked kernel reports: what has been fixed?

The five Linux kernel reports that reached public mailing lists on 20 and 21 October still had no CVE ids on 29 October. The most relevant one for shared servers, a local privilege escalation in the networking code, has a fix posted to the netdev list with a review, but its merge into mainline was not confirmed. The two in-kernel SMB server (ksmbd) reports do not apply to AlmaLinux, CloudLinux or RHEL kernels, which do not build ksmbd.

Vendors did not wait for the CVE. AlmaLinux released patched kernels to production on 28 October for versions 8, 9 and 10, ahead of RHEL. TuxCare’s KernelCare shipped live patches for EL10 on 23 October and EL9 on 26 October, with EL8 ready for release. CloudLinux had CloudLinux 7 hybrid and CloudLinux 8 kernels in beta on 26 October, a live patch for CloudLinux 10, and CloudLinux 9 builds following AlmaLinux. Its published mitigation is the one we described in five kernel settings for a shared Linux server: set user.max_user_namespaces to 0 where nothing needs it.

• Server side. Keep the namespace limit in place, confirm KernelCare auto-update is on, verify the applied patch with kcarectl --patch-info, and plan a reboot only for kernels that cannot be live-patched.
• Application side. Container hosts that need user namespaces should take the new kernel or live patch first, since they cannot use the configuration mitigation.

What about cPanel itself?

Apart from the PHP security update of 21 October, cPanel published no Targeted Security Release in October; the most recent was on 29 September. EasyApache 4 had six releases in the month, including 25.88 on 2 October with Apache 2.4.69 and a batch of security fixes, so servers that skipped updates during the month are missing more than the PHP fix.

Which fixes does your stack still need?

Tick what runs on your server to see the open items for it:

A field note: what one week looked like on our servers

On our cPanel servers running CloudLinux 8, the backported ea-php packages installed automatically on the afternoon of 21 October, and they were still the backported builds when we checked days later, even though CloudLinux had published php.net-numbered builds on 23 October. Both are patched; the changelog is what proves it. Live-patch status is checked from the KernelCare configuration rather than its command-line summary, and the namespace limit we applied fleet-wide on 23 October is what covers the kernel gap until the EL8 live patch arrives. Nothing in the week required a reboot.

The short version

A week after disclosure, the work has shifted from patching to closing the remaining gaps. PHP2Shell is now an exploited vulnerability and every server that still runs an unpatched build should be treated as urgent. BIND and the kernel depend on distribution vendors and live patches that are still arriving, so the configuration mitigations matter more there. And the eMudhra changes will keep surfacing as certificate errors for sites that have not moved to another CA.

FAQ: the October 2026 vulnerabilities one week on

Is PHP2Shell being exploited in the wild in October 2026?

Yes. CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 26 October 2026, and researchers reported exploitation against an Apache mod_php setup. Treat any unpatched PHP build as urgent.

What is CVE-2026-115560 and is it fixed by the PHP2Shell releases?

It is a separate session upload progress issue announced on 23 October and it is not fixed by 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Until the next regular PHP release, keep session.upload_progress.enabled = 0 in php.ini or the FPM pool.

Which CloudLinux versions have patched alt-php packages for PHP2Shell?

CloudLinux 7, 8 and 9 have them in stable since 22 October, and CloudLinux on Ubuntu 22.04 since 21 October. CloudLinux 10 uses the TuxCare ELS repository, and CloudLinux 6 is listed as not confirmed.

cPanel ea-php backport vs php.net version: how do you know which build is patched?

Backported builds keep the old version, for example ea-php84 8.4.26-2, while later builds use php.net numbers such as 8.4.27-1. Both are patched; check the package changelog for the CVE ids rather than relying on php -v.

Are the Imunify360 WAF rules enough to protect an unpatched server from PHP2Shell?

No. The rulesets from 8.83 to 8.88 block known exploit tools and patterns, but CloudLinux states that no rule covers the out-of-memory path of CVE-2026-109618. They are an interim layer while you patch.

When will RHEL, AlmaLinux and Ubuntu ship the October 2026 BIND fixes?

No date was published by 29 October 2026; all three listed their bind packages as affected or vulnerable. Until they ship, remove unused GSS-TSIG options and restrict recursion and port 53 to trusted networks.

Node.js 24.22.2 vs 24.22.1: which release should servers run?

Run 24.22.2. It was released on 28 October with V8 backports and a stream fix on top of 24.22.1, which carried the security fixes. Both include the October CVE fixes; the newer build is the better baseline.

Why do some websites show certificate errors after the eMudhra changes?

Because Mozilla and Chrome removed the emSign ECC Root CA – G3, so certificates that chain to it stop validating as clients update. Sites using eMudhra certificates need new certificates from another CA.

Do the leaked October 2026 Linux kernel reports have CVE numbers yet?

No CVE ids had been assigned by 29 October 2026. Vendors track them by their ZDI report numbers, and AlmaLinux, TuxCare and CloudLinux shipped or prepared fixes without waiting for a CVE.

Do servers with KernelCare need a reboot for the leaked kernel bug fixes?

Not where a live patch exists: EL10 and EL9 received one, and EL8 was ready for release. Verify with kcarectl --patch-info, keep auto-update on, and reboot only for kernels that cannot be live-patched.

Sources

• Known Exploited Vulnerabilities Catalog, CISA
• PHP news archive 2026, php.net
• PHP CVE-2026-109618 and CVE-2026-109619 status, CloudLinux
• Release notes, cPanel
• October 2026 security releases, nodejs.org
• CVE-2026-94300, ISC
• CVE-2026-94300, Red Hat
• Protecting users from compromised eMudhra intermediates, Google
• ZDI-CAN-33367 kernel update, AlmaLinux
• ZDI kernel reports and KernelCare status, TuxCare