Patch Tonight Won: Why “Mitigate and Wait” Loses the PHP RCE Fight

PHP runs something like seven in ten websites, which is also roughly the share Krebs says needs to update right now. Today the PHP maintainers shipped patches for two remote code execution flaws — CVE-2026-109618 and CVE-2026-109619 — both unauthenticated. No login, no stolen token, no social engineering. A request hits your server and the attacker is running code as whatever user your web stack runs as. Working exploits are already circulating, which means the scanning started before you finished your coffee.

So you have a decision to make tonight, not next sprint. There are two realistic plays, and I’ve watched teams pick both. Let me run them head to head, because the wrong one is seductive and I want to talk you out of it.

The two options on the table

Option A — Patch tonight. Update every PHP install to the fixed release on its branch: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Restart PHP-FPM, Apache mod_php, or your container, and eat whatever outage that causes.

Option B — Mitigate and wait. Leave the vulnerable binary in place, wrap it in compensating controls — WAF, network segmentation, disabling PHP where it isn’t actually used — and schedule the real patch for a proper change window.

Both are defensible on paper. Only one survives contact with how these bugs get exploited at scale. Let’s score it.

Round 1 — How fast the exposure window closes

Mass exploitation of a pre-authentication PHP flaw isn’t a targeted operation. It’s a botnet spraying the entire IPv4 space, and 70% of what it hits is a plausible target. Patching removes the vulnerable code path. Mitigation hopes the attack doesn’t match your filter.

Here’s the uncomfortable part: the brief, and the source, confirm the vulnerability is unauthenticated RCE and nothing more specific about the mechanism. That means I can’t tell you a WAF rule reliably blocks it, because nobody has published a verified signature as I write this. A control you can’t validate against the actual payload is a prayer with a dashboard. Patch wins. 1–0.

Round 2 — Blast radius of the action itself

This is the round Option B actually wins, and it’s why people reach for it. Patching PHP means restarting the runtime. On a busy site that’s a visible blip; on a fragile monolith with version 8.1 pinned in three Dockerfiles, it’s a genuine risk of not coming back up. Mitigation changes nothing about the app, so it breaks nothing about the app. If your constraint is “this service cannot restart during business hours and it’s 2pm,” that’s a real constraint, not an excuse. Mitigate wins. 1–1.

Round 3 — Durability

Compensating controls leak. A WAF you can’t tune to the specific exploit will either miss variants or false-positive your legitimate traffic into the ground. Segmentation helps only if the vulnerable host wasn’t already reachable from where the attacker lands — and for a public website, it is, by definition. The patch, by contrast, is durable: the bug is gone whether or not anyone’s watching the dashboard at 3am. Controls are something you maintain forever; a patch is something you do once. Patch wins. 2–1.

Round 4 — What it forces you to confront

Patching surfaces a truth mitigation lets you hide: PHP branches older than 8.2 are end of life. There is no 8.1.x or 8.0.x fix coming. If your audit turns up a 7.4 box — and it will — “the patch” is actually a major-version upgrade with real compatibility work. That’s bad news, but it’s news you need. Mitigation lets you keep pretending that box is fine. Patch wins on honesty. 3–1.

Find out what you’re actually running first

You can’t patch what you haven’t counted. Start with discovery, report-only. On Linux hosts and containers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#!/usr/bin/env bash
# Report-only PHP exposure audit. Prints version + verdict, changes nothing.
set -euo pipefail
​
declare -A FIXED=( [8.5]="8.5.12" [8.4]="8.4.27" [8.3]="8.3.36" [8.2]="8.2.35" )
​
check_version() {
  local label="$1" ver="$2"
  local branch="${ver%.*}"
  if [[ -z "${FIXED[$branch]:-}" ]]; then
    echo "[EOL/UNSUPPORTED] $label -> $ver  (no patch exists; upgrade the branch)"
    return
  fi
  # dpkg-style version compare: is $ver >= fixed?
  if [[ "$(printf '%s\n%s\n' "${FIXED[$branch]}" "$ver" | sort -V | head -1)" == "${FIXED[$branch]}" ]]; then
    echo "[OK]       $label -> $ver"
  else
    echo "[VULN]     $label -> $ver  (patch to ${FIXED[$branch]})"
  fi
}
​
# Local CLI / FPM binaries
for bin in php php-fpm php8.2 php8.3 php8.4 php8.5; do
  if command -v "$bin" &>/dev/null; then
    v=$("$bin" -v 2>/dev/null | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
    [[ -n "$v" ]] && check_version "host:$bin" "$v"
  fi
done
​
# Running containers
if command -v docker &>/dev/null; then
  for c in $(docker ps --format '{{.Names}}'); do
    v=$(docker exec "$c" php -v 2>/dev/null | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
    [[ -n "$v" ]] && check_version "container:$c" "$v"
  done
fi

Don’t forget CI/CD. Runners build and test PHP images with whatever base tag someone pinned two years ago, and those runners often have outbound internet and credentials. A quick grep across your pipeline definitions and Dockerfiles catches the ones that never show up in a server inventory:

1
2

# Hunt pinned PHP base images across your repos (report-only)
grep -rInE 'FROM\s+php:[0-9]+\.[0-9]+' . 2>/dev/null | sort -u

On Windows, PHP hides behind IIS, XAMPP, and the occasional forgotten dev box. And if you run Microsoft Defender for Endpoint, let its software inventory do the fleet-wide sweep instead of logging into hosts one at a time — run this in Advanced Hunting:

1
2
3
4
5
6
7
8
9
10
11
12

# Local Windows check
Get-ChildItem -Path 'C:\','D:\' -Recurse -Filter 'php.exe' -ErrorAction SilentlyContinue |
  ForEach-Object {
    $v = (Get-Item $_.FullName).VersionInfo.ProductVersion
    [pscustomobject]@{ Path = $_.FullName; Version = $v }
  } | Format-Table -AutoSize
​
# Fleet-wide via Defender Advanced Hunting (KQL — paste into the portal or Graph security API):
# DeviceTvmSoftwareInventory
# | where SoftwareName contains "php"
# | project DeviceName, SoftwareName, SoftwareVersion, OSPlatform
# | sort by SoftwareVersion asc

The verdict, and the one time you pick the loser

Patch takes it 3–1. Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 tonight, accept the restart, and be done. The outages everyone’s bracing for aren’t caused by the patch — they’re caused by waiting until an exploit forces an emergency restart at a worse hour.

Now the honest exception. Option B is the right call in exactly one situation: a system you genuinely cannot restart inside tonight’s window — a frozen regulated service, or an EOL branch where “patching” means a major upgrade you can’t safely rush. In that narrow case, pull the host off the public internet or front it with the tightest filtering you have, and treat the patch as the most urgent item in tomorrow’s change window. Not next quarter. Tomorrow.

Understand what you’re buying, though. Mitigation buys you hours against a bug with public exploits and no verified signature. It does not buy you a week, and it never bought you a pass. The teams who’ll be fine next month are the ones who restarted PHP tonight and went to bed annoyed. The ones who’ll be writing an incident report are the ones who found a dashboard easier than a deploy.