DEV Community: JonPatchWarden

The October PHP RCEs: a patching checklist for WordPress sites

JonPatchWarden — Wed, 28 Oct 2026 16:25:49 +0000

On October 21, the PHP project shipped emergency fixes for two unauthenticated remote code execution vulnerabilities ("php2shell", CVE-2026-109618 and CVE-2026-109619). Per CISA, they affect PHP installations serving web requests across several SAPIs, and the PHP project considers Apache with mod_php the highest-risk setup. On October 26, CISA added them to its Known Exploited Vulnerabilities catalog, meaning confirmed active exploitation.

Why a WordPress checklist: PHP is used by 69.2% of the websites whose server-side language W3Techs can identify, and WordPress alone powers 39.5% of all websites (W3Techs, October 2026). Those are market-share figures, not exposure figures: a WordPress site is only affected if its server runs a vulnerable PHP build. But WordPress is PHP code, and the component at risk here is the PHP runtime underneath it - updating WordPress core, themes or plugins does not touch that runtime. It gets patched at the server layer, by you or by your host, so that is where to look.

Sources

CISA alert, revised Oct 26, 2026: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
W3Techs server-side language usage, October 2026: https://w3techs.com/technologies/overview/programming_language/
W3Techs WordPress usage, October 2026: https://w3techs.com/technologies/details/cm-wordpress

1. Know your exposure

Find the PHP version each site runs. In the WordPress dashboard: Tools > Site Health > Info > Server lists the PHP version.
Find out how PHP is served on that server: Apache with mod_php (highest risk per the PHP project), PHP-FPM, php-cgi, FrankenPHP or LiteSpeed.
On shared or managed WordPress hosting, your provider controls the runtime. The question to ask them: which PHP build is my site on, and when will the php2shell fix reach it?

2. Match versions to fixes

php2shell is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 from the upstream PHP project. Upstream no longer provides security fixes for PHP 8.1 and older, though distro or extended-support channels may ship their own backports.
Many hosts run PHP from Linux distribution packages, and distros often backport a fix without adopting the upstream version number. Check the distro or vendor advisory for the CVE IDs instead of comparing version strings alone - an older-looking version can already be fixed.
For genuinely unsupported runtimes, CISA's advice is to take affected systems offline until they can be patched or updated. Base that call on your vendor's advisory and your own exposure.

3. Patch at the right layer

If you manage the server: patch PHP through the same package channel it was installed from, like any other change - backup or snapshot first, know your rollback path, test the site afterwards.
If your host manages it: track their advisory and the PHP version selector in your panel; moving a site to a patched PHP build is usually a panel setting, but test before switching production.
If patching has to wait: for the php2shell case specifically, CISA notes a web application firewall may provide some protection until systems are updated. Treat that as a bridge, not a fix.

4. Verify the fix actually landed

Confirm the running build is the vendor-fixed one (package version plus your distro's or host's advisory, not just the upstream number).
Follow your vendor's instructions to make the fixed code live - typically reloading or restarting the affected services. Not every reload swaps in the new code; the vendor advisory says what is required.
Rescan as a supporting check. A clean rescan supports that the vulnerable package is gone; it does not prove the host was never compromised.
Patching closes the hole going forward. If a server was exposed while vulnerable, check it for signs of compromise - CISA suggests watching for PHP worker processes launching shells or downloading tools.

5. Make it routine

Track PHP version end-of-life dates and budget upgrades before security support ends.
Scan on a schedule rather than when someone remembers, and route alerts somewhere you actually look (email, webhook).

The honest plug

That loop - scan installed OS packages against CVE data, patch the affected ones, rescan to check the fix - is what we built PatchWarden to do for Linux servers. It connects over SSH, scans every 6 hours, patches with one click after approval or automatically for severities you choose, upgrades only the affected packages, and verifies with a rescan. It works on OS packages managed by your package manager; it does not handle WordPress plugins or themes, application-level dependencies (Composer, npm), containers, or runtimes installed outside the package manager. One honest caveat: we have not yet verified PatchWarden's coverage of these specific CVEs or of third-party repositories such as the widely used PHP PPAs, so treat this article as the general workflow, not a coverage promise for your exact setup.

14-day free trial for one server, no credit card: https://www.patch-warden.com

The Linux server patching checklist (2026 edition)

JonPatchWarden — Wed, 28 Oct 2026 11:49:58 +0000

Last week did the reminding for us. On October 21, PHP shipped emergency fixes for two unauthenticated remote code execution vulnerabilities ("php2shell", CVE-2026-109618 and CVE-2026-109619). Per CISA, they affect PHP installations serving web requests: Apache with mod_php (which PHP considers highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The same day, Node.js shipped security releases for the 26.x, 24.x and 22.x lines, including a Brotli decoder flaw (CVE-2026-111497) that can corrupt process memory and lead to RCE. On October 26, CISA added the PHP vulnerabilities to its Known Exploited Vulnerabilities catalog, meaning confirmed active exploitation.

Sources

CISA alert, revised Oct 26, 2026: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
Node.js October 21, 2026 security releases: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

1. Inventory what you actually run

List every server you own, including staging and test machines; check which of them are reachable from the internet.
On each server, list installed packages: dpkg -l (Debian/Ubuntu) or rpm -qa (RHEL/Fedora). These commands list what is installed; they do not tell you what is vulnerable. For that, compare against CVE data or your distro's security tracker.
Note where each runtime came from. PHP or Node.js installed from the distro repositories, or from a third-party apt/dnf repo such as NodeSource or the widely used PHP PPAs, updates through the package manager - once the repo maintainer publishes the fixed build. A runtime compiled from source, installed with a version manager like nvm, or baked into a container image follows a different update path and needs its own fix.

2. Check versions against the fixes

php2shell is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 from the upstream PHP project. Upstream no longer provides security fixes for PHP 8.1 and older, though distro or extended-support channels may ship their own backports. For unsupported versions, CISA's advice is to take the affected systems offline until they can be patched or updated. Base that call on your vendor's advisory and your own exposure, not on the upstream version number alone - an older-looking version with a vendor backport can already be fixed.
The Node.js fixes land in 26.12.1, 24.22.1 and 22.23.4 (all released October 21 as security releases).
Distros often backport a fix without adopting the upstream version number. Check your distro's security tracker for the CVE ID instead of comparing version strings alone.

3. Patch, carefully

Prioritize internet-facing systems, as CISA recommends.
Prefer updating the affected packages over a full-system upgrade during an incident, and treat it like any other change: have a backup or snapshot, know your rollback path, and test the service afterwards.
If patching has to wait: for the php2shell case specifically, CISA notes a web application firewall may provide some protection until systems are updated. Treat that as a bridge, not a fix.

4. Verify the fix actually landed

Confirm the installed build is the vendor-fixed one (package version plus your distro's advisory, not just the upstream number).
Follow your vendor's instructions to make the fixed code live - typically reloading or restarting the affected services, and for containers rebuilding and redeploying the image. Note that not every reload swaps in the new code; the vendor advisory says what is required.
Rescan as a supporting check. A clean rescan supports that the vulnerable package is gone; it does not prove the host was never compromised.
Patching closes the hole going forward. If a server was exposed while vulnerable, check it for signs of compromise - CISA suggests watching for PHP worker processes launching shells or downloading tools.

5. Make it routine

Scan on a schedule rather than when someone remembers.
Route alerts somewhere you actually look (email, webhook).
Decide ahead of time which severities may patch automatically and which wait for a human.

The honest plug

That loop - scan installed OS packages against CVE data, patch the affected ones, rescan to check the fix - is what we built PatchWarden to do for Linux servers. It connects over SSH, scans every 6 hours, patches with one click after approval or automatically for severities you choose, upgrades only the affected packages, and verifies with a rescan. It works on OS packages managed by your package manager; it does not handle application-level dependencies (Composer, npm packages), containers, or runtimes installed outside the package manager - those need the separate paths described above. One honest caveat: we have not yet verified PatchWarden's coverage of these specific CVEs or of third-party repositories such as NodeSource and the PHP PPAs, so treat this article as the general workflow, not a coverage promise for your exact setup.

14-day free trial for one server, no credit card: https://www.patch-warden.com