DEV Community

JonPatchWarden
JonPatchWarden

Posted on

The October PHP RCEs: a patching checklist for WordPress sites

#wordpress #webdev #security #php

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

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

Top comments (0)