Send files

PHP RCE October 2026: The Agency Triage Playbook

7 min read

Dark banner reading 'Forty client sites. Which one do you patch first?' with the triage sequence and the four patched PHP versions

You Did Not Build These Servers, and You Are Still the One Who Has to Fix Them

If you maintain websites for other people, this week is not a reading exercise. Two PHP core vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed together and patched on 21 October 2026. Both are rated CVSS v3.1 9.8 CRITICAL (CVSS v4.0 9.2), both allow remote code execution, and proof-of-concept exploit code is public. Researchers nicknamed the pair “PHP2Shell”.

The awkward part of agency life is that your exposure is the sum of every environment you inherited: the hosting panel from 2017, the client who insists their VPS is “managed”, the legacy site nobody has touched since the rebuild. You did not choose those stacks. You will still be the first phone call.

What to do in the next 60 minutes

  1. List every host you touch, including the ones you do not bill for.
  2. Flag the internet-facing Apache + mod_php hosts. They go first, no debate.
  3. Run a read-only version check on each host (script below).
  4. Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the branch.
  5. Restart the workers. An upgraded package with a stale PHP-FPM process still serves the old binary.
  6. Send one short, factual note per client. Silence is what turns an incident into a complaint.

Why this one outranks a normal PHP release

The flaw lives in PHP core, specifically the longjmp() path taken when PHP hits its memory limit, combined with multipart request parsing. It is not an extension you can switch off. Per Wiz research, the vulnerable code path has existed since PHP 5.4, which is another way of saying the oldest client site in your portfolio is probably the one most worth checking.

The worst configuration is Apache with mod_php, where the attack is unauthenticated and executes before any application code runs. That detail matters commercially as much as technically: a client paying for a WAF, a login wall or an IP allowlist on /wp-admin is not covered by any of them here. Cloudflare published a rule to every plan including Free at 03:02 UTC on 21 October and reported seeing real exploitation attempts before the patch was public. The SANS Internet Storm Center raised InfoCon to YELLOW. The release itself was moved up from 22 to 21 October because details leaked on 20 October, after Chainguard broke the embargo.

For the engineering detail behind all of this, including per-platform fixes, see the full technical breakdown and per-platform fix guide.

The version numbers to patch to

PHP branch Safe from Still vulnerable
8.5 8.5.12 8.5.0 – 8.5.11
8.4 8.4.27 8.4.0 – 8.4.26
8.3 8.3.36 8.3.0 – 8.3.35
8.2 8.2.35 8.2.0 – 8.2.34
7.4 / 8.0 / 8.1 no release exists all versions

Step 1: Build the client inventory before you build the plan

Most agencies discover during an incident that the asset list lives in three places: the billing system, somebody’s bookmarks, and the DNS account. Reconcile them once, now, and keep the result.

For each entry record four columns only: hostname, who owns root, PHP version, and server API (apache2handler, fpm-fcgi, cli). That is enough to sort the queue.

To collect the version data without installing an agent, we published a plain POSIX sh script. It makes no network calls, collects nothing and needs no root. It inspects PHP binaries on disk, including cPanel, Plesk, Remi and LiteSpeed paths, running PHP-FPM workers and whether a restart is still pending, Docker containers, and WordPress or Laravel installs. Read it first, 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

SHA-256: c13cd5690c9d352c6a95e854602be2f330a0799435c05a8261037401fcf50255

Client’s sysadmin prefers an attachment to a shell one-liner? Point them at the browser copy published from our verified account @limewireofficial: php-exposure-check.sh. The link is permanent and ungated, so it survives being forwarded around a client’s IT department.

Exit codes make it pipeline-friendly: 0 means everything found is patched, 1 means something vulnerable or end-of-life is present, 2 means no PHP was found at all.

Step 2: Patch in blast-radius order

  1. Internet-facing Apache + mod_php. Unauthenticated pre-application execution. These are tonight’s work.
  2. Internet-facing PHP-FPM behind nginx or LiteSpeed. Still critical, marginally less trivial to reach.
  3. Container workloads. Official images were rebuilt quickly, but a pull is not a deployment.
  4. CLI, cron and internal tooling. Lower urgency, not zero.

On Ubuntu, the fix is carried by USN-8948-1. If a client box runs the Remi repository, be aware it was behind at release time; php.net recommended temporarily switching to distribution packages. If a client stack is Alpine-based, check carefully: Alpine 3.21 stable still ships php84-8.4.14, which is vulnerable, and only alpine:edge carried php83-8.3.36 and php84-8.4.27 at the time of checking.

For containers, docker compose pull && docker compose up -d is the actual fix, because a running container keeps the old binary no matter what you pulled. The official PHP image page is the reference for tags.

Step 3: The legacy client problem nobody wants to own

Every agency has them: sites on PHP 7.4, 8.0 or 8.1, maintained under an agreement that quietly expired, usually belonging to the client least willing to pay for a rebuild.

Those branches get no release. The PHP project made a one-off exception and published source-only backports in php/php-src, on branches named like PHP-8.1-CVE-2026-109618-109619. You compile them yourself, there is no tarball and no distro package, and you receive no further security support afterwards. Treat a backport as an emergency stopgap; the real fix is moving to 8.2 or later.

Put the choice in writing today, in one paragraph: the site is on an unsupported branch, exploit code is public, here are the two options and their costs, please confirm which you want. Whatever the client answers, you now have a record — and records are how agencies survive other people’s decisions.

Step 4: The note you send clients

Keep it to four sentences. What happened, whether their site was affected, what you did, what they need to do (usually nothing). Avoid the word “hacked” unless it is true, and avoid the word “safe” unless the version number supports it.

Clients who want to verify the story themselves can be pointed at primary sources: the PHP release announcement for 21 October 2026, the GHSA-w8hw-w9fx-j79w advisory, the NVD entry for CVE-2026-109618 and the SANS Internet Storm Center. Sending a client to a primary source is cheaper than arguing with a forwarded blog post.

If a client genuinely cannot patch tonight

Partial measures that reduce exposure without making anyone safe: set memory_limit administratively so applications cannot raise it, lower post_max_size, set session.upload_progress.enabled=0, and on 8.5 only, fatal_error_backtraces=0. The PHP project’s position is unambiguous — there is no complete mitigation, and updating is the only safe choice.

One disclosure, since we are a file-sharing company talking about untrusted input: LimeWire has institutional memory of what happens when untrusted bytes meet a trusting parser, mostly because in the 2000s we were the delivery mechanism. We had nothing to do with this bug, but we did recognise the shape of it immediately.

The version-check habit worth keeping

The agencies that got through this week calmly were not the ones with the best tooling. They were the ones who already knew which client ran which PHP version. Keep the inventory you just built, re-run the check quarterly, and the next critical CVE becomes a scheduled afternoon instead of a scramble.