Which client site should I patch first after the October 2026 PHP CVEs?

Start with public sites on Apache with mod_php. In that setup the attack is unauthenticated and lands before your application code runs, so a login wall or a plugin firewall is not part of the conversation. PHP-FPM hosts come next, then container workloads, then internal and CLI-only tooling.

How do I check PHP versions across many client sites quickly?

Run one read-only check per host instead of logging into forty dashboards. The self-check script reads the machine and reports: exit code 0 means every PHP it found is patched, 1 means something is vulnerable or end-of-life, and 2 means it found no PHP at all. Read it once, then run it everywhere.

What do I tell a client still running PHP 8.1?

Tell them plainly that 8.1 and anything older is end-of-life, so no patch is coming for that branch at all. The fix is a branch upgrade to 8.2 or newer, which is a scoped project with a quote attached rather than a same-day task, and the site stays exposed until it happens.

PHP RCE October 2026: Forty Client Sites, One Afternoon

October 22, 2026 2 min read

Dark banner reading 'Forty client sites. Which one first?' beside a table of PHP branches 8.5, 8.4, 8.3 and 8.2 with their patched releases and 8.1 marked end of life

Forty client sites, one afternoon, and an inventory spreadsheet that was last accurate in March. That is the real shape of this week for most agencies. The vulnerability itself is not complicated; the queue is. You cannot touch everything at once, so the only decisions that matter are which site you open first and what you say to the client while you work.

What you are sorting, in version numbers

Two PHP flaws, CVE-2026-109618 and CVE-2026-109619, give an unauthenticated attacker remote code execution. The fixes shipped on 21 October as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below those numbers inside the same branch is still exposed, no matter how tidy the site on top of it is.

One configuration jumps the queue: Apache with mod_php. There the attack arrives before any application code runs, which means the client’s admin password and their security plugin never get a vote. PHP-FPM setups are vulnerable too, just less convenient for whoever is spraying the internet right now.

Then there is the legacy shelf. PHP 8.1 and everything older is end-of-life and gets no patch whatsoever, so those clients need a branch upgrade rather than an update.

The order that gets you through the day

Public sites on Apache with mod_php, oldest PHP first.
Public PHP-FPM hosts, and restart the workers afterwards so they stop serving the old binary.
Containerised sites, recreating the container rather than only pulling a new image.
Internal tools, staging boxes and anything CLI-only.
End-of-life branches, logged as a migration conversation with a date on it.

Write the client email once and reuse it. Three sentences do the job: the PHP version their site runs, whether that number is at or above the patched release, and when you touched it or will.

Confirm it instead of assuming it

Per host, read the script first and then run it:

curl -fsSL https://blog.limewire.com/content/files/2026/10/php-exposure-check.txt -o php-exposure-check.sh
less php-exposure-check.sh
sh php-exposure-check.sh

Its SHA-256 is c13cd5690c9d352c6a95e854602be2f330a0799435c05a8261037401fcf50255. Exit code 0 means every PHP it found is patched, 1 means something is vulnerable or end-of-life, and 2 means it found no PHP at all. When a locked-down client box will not reach the blog, the same file sits on our platform, published by the verified @limewireofficial account, with no signup, no download cap and no expiry on the link.

Everything above is triage. The per-platform detail — distribution packages, container images, the end-of-life branches and the awkward mitigations — is already written up in full: the complete PHP RCE breakdown. Forward it to the client who wants to read more than three sentences.

A small disclosure, since our name is on this page. LimeWire had nothing to do with this PHP bug. We simply hold vivid institutional memories of Shared folders that handed strangers rather more than their owner intended, and we have spent twenty years becoming a different sort of company about it.