php2shell Vulnerability Game Server Protection: The 6-Hour Patch Runbook

Your game's PHP tier is probably the part of your stack nobody looks at. The web store that sells cosmetics. The admin panel your community manager uses. The legacy leaderboard endpoint you wrote in 2022 and never touched again. That is the surface php2shell attacks.

On October 21, 2026, Calif.io, Wiz, OpenAI, and Quarkslab disclosed two PHP runtime vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619, collectively named php2shell. CVSS v4.0 scores them at 9.2. They affect every PHP installation from 5.4 onward, they allow unauthenticated remote code execution, data exposure, and denial of service, and Cloudflare observed live attack traffic mutating payloads against real customers before public disclosure even landed.

This is not a WordPress plugin problem. It is a memory-safety bug in the PHP runtime itself. Updating your framework, your CMS, or your Composer dependencies does nothing. If you operate a game backend with any PHP in it, this runbook is for you.

What php2shell Actually Breaks

Both CVEs live in how PHP handles memory when request processing goes sideways. Normally PHP allocates memory for a request, uses it, and releases it when the request finishes. The bugs appear when that cleanup path runs against state that was never valid in the first place.

CVE-2026-109618: out-of-memory corruption

PHP hits its memory ceiling mid-request and aborts before some internal structures finish initializing. The cleanup routine then treats that half-built data as legitimate. An attacker who can reliably force OOM conditions — large request bodies, deeply nested input, oversized uploads — gets a shot at controlling what that unfinished memory contains.

The practical trigger for game backends is obvious: any endpoint that accepts a body without a size cap. Match result submission, screenshot upload, mod metadata, telemetry batches.

CVE-2026-109619: stale global state across requests

A fatal error interrupts a request, leaving the PHP process holding references to memory that gets freed at request end. When the same worker process picks up the next request, it may follow those dangling references. That is data exposure — one player's session data or database credentials bleeding into another player's response — and under the right conditions, code execution.

This is the more insidious bug for game servers because PHP-FPM workers are long-lived by design. A single poisoned worker can serve hundreds of subsequent requests before it gets recycled. If you run pm.max_requests = 0 (the default, meaning never recycle), a corrupted worker can persist for the lifetime of the container.

Step 1: Inventory Every PHP Runtime You Own

You cannot patch what you have not found. Most studios discover, mid-incident, that three of their services run PHP and one of them is on 8.1 from a base image built two years ago. Run this before you do anything else.

#!/usr/bin/env bash
# php2shell exposure inventory (CVE-2026-109618 / CVE-2026-109619)
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" )
SERVICES=("game-api" "web-store" "admin-panel" "forums")

for svc in "${SERVICES[@]}"; do
  ver=$(docker compose exec -T "$svc" php -r 'echo PHP_VERSION;' 2>/dev/null | tr -d '[:space:]') || {
    echo "SKIP  $svc (no php binary)"; continue; }

  branch="${ver%.*}"          # "8.3.12" -> "8.3"
  min="${FIXED[$branch]:-}"

  if [[ -z "$min" ]]; then
    echo "EOL   $svc on $ver -> no upstream patch, upgrade required"
  elif php -r 'exit(version_compare($argv[1], $argv[2], ">=") ? 0 : 1);' "$ver" "$min"; then
    echo "OK    $svc on $ver"
  else
    echo "VULN  $svc on $ver (fixed in $min)"
  fi
done

Two things this script deliberately does: it flags EOL branches separately, and it never assumes php -v on the host reflects the container's actual runtime. If you are on Kubernetes, swap the docker compose exec for kubectl exec and iterate over deployments rather than service names.

The fixed upstream versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Anything on 8.1, 8.0, 7.x, or 5.x is end-of-life and will never receive a fix. You are upgrading, not patching.

Step 2: Patch the Runtime, Not the Application

The most common failure mode in the first hour of an incident like this is a team that updates application code, redeploys, sees green CI, and assumes they are done. They are not.

• PHP-FPM and mod_php: rebuild the base image or bump the package. Debian/Ubuntu: apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common. Alpine: apk upgrade php83. Verify with php -r 'echo PHP_VERSION;' inside the running container, not on the build host.
• FrankenPHP / php-cgi: these bundle the runtime, so you need a new release binary or base image, not a package bump.
• Managed hosting: if a provider controls PHP, open a ticket immediately and ask for the advisory reference. Do not accept "we are aware" as a resolution.
• Docker base images: pin by digest, not by tag. php:8.3-fpm can resolve to a different build on the next pull, which is great for patching and terrible for reproducibility. Pin the digest after you verify the version.

After patching, kill every existing worker. A rolling restart that leaves old processes alive on a shared socket keeps vulnerable workers serving traffic. docker compose restart or kubectl rollout restart — confirm the process start time changed.

Step 3: Shrink the Blast Radius While You Wait

Patching takes time. You have a window between "we know" and "every environment is rebuilt." Use it.

Cap request bodies at the edge

# Shrink the php2shell trigger surface
client_max_body_size 2m;          # game APIs rarely need more than this
client_body_timeout 10s;
client_header_timeout 10s;
large_client_header_buffers 4 8k;

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass php-fpm:9000;
    fastcgi_read_timeout 15s;
    fastcgi_buffering on;
}

A 2 MB cap does not stop a determined attacker — they can trigger OOM with many small requests — but it eliminates the trivial single-request trigger and it costs you nothing.

Recycle workers aggressively

; /usr/local/etc/php-fpm.d/zz-php2shell.conf
php_admin_value[memory_limit] = 256M
php_admin_value[max_execution_time] = 20
pm.max_requests = 500
pm.max_children = 24
request_terminate_timeout = 20s

Here is the trade-off math. At 200 requests per second across 24 workers, each worker handles roughly 8.3 req/s. With pm.max_requests = 500, every worker is recycled every ~60 seconds. That caps how long a CVE-2026-109619-corrupted process can serve traffic, but it also means 24 process spawns per minute — measurable overhead on cold-start-heavy frameworks.

Raising memory_limit from 128M to 256M reduces how often you hit OOM (fewer CVE-2026-109618 triggers) but doubles worst-case memory: 24 children × 256M = 6 GB of headroom you now need on the node. If your node has 4 GB, lower pm.max_children instead of pretending the memory exists.

None of this is a fix. It buys you hours. Treat it as triage.

Step 4: Detect Whether You Were Already Hit

Disclosure does not equal first exploitation. Attack traffic was observed before the official release date. Assume you were probed.

# 1. OOM aborts — strongest single signal for CVE-2026-109618
grep -c "Allowed memory size" /var/log/php-fpm/error.log

# 2. Worker crashes — signal for both CVEs
journalctl -u php8.3-fpm --since "48 hours ago" \
  | grep -Ei "segfault|SIGSEGV|exited on signal 11"

# 3. Which paths are generating 500s
awk '$9 == 500 {print $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# 4. Same source IP hitting the same 500-ing path repeatedly
awk '$9 == 500 {print $1, $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Baseline first. If your PHP-FPM log already had 40 OOM aborts a day from a memory-hungry export endpoint, that number is noise. What you are looking for is a change in rate — a spike in signal 11 exits, a new path appearing in the 500 list, or a single IP generating dozens of failures against one endpoint.

If you find evidence of successful exploitation, treat it as a full breach: rotate database credentials, session signing keys, payment provider secrets, and any API keys reachable from the PHP process. The playbook for that is not PHP-specific — the same discipline that lets a studio architect game backends to survive compromises applies here, and it starts with assuming the attacker had code execution, not just read access.

If your backend is already dropping requests and you are unsure whether it is load or an attack, the crash triage order in this server freeze diagnostic protocol applies: isolate the failing tier before you touch configuration.

Why Request-Only WAF Rules Failed

Cloudflare's writeup contains the most transferable engineering lesson in the whole incident. Their initial protections were request-based, and attackers responded by mutating payloads — probing which variants matched and which slipped through, using the match/no-match signal as an oracle.

Request data alone could not separate exploit traffic from legitimate traffic, because a large POST with nested arrays is also what a normal game client sends when it submits a match summary. The signal that resolved the ambiguity was the response: did the origin return a 500 with a PHP fatal error trace? That combination — suspicious request plus diagnostic response — is high confidence. The request alone is not.

Cloudflare shipped this as "full transaction detection," correlating request and response inside the same HTTP transaction and blocking the response before it reaches the requester. If you run your own edge or reverse proxy, the pattern is worth copying:

def is_probable_php2shell(resp) -> bool:
    """Correlate request shape with origin response, not request alone."""
    body = resp.body[:4096]
    return (
        resp.status == 500
        and b"Fatal error" in body
        and resp.origin_latency_ms < 50      # exploit aborts fast
        and b"Allowed memory size" in body   # OOM path = 109618 signature
    )

The lesson generalizes past this CVE: any detection system that only sees inbound traffic will be bypassed by an attacker who can see the outbound result. Log responses. Correlate them. It is the difference between a rule that holds and a rule that becomes a puzzle.

Best Practices

1. Patch on a schedule, not on disclosure. The gap between "CVE published" and "exploit in the wild" is now measured in hours, sometimes negative. Rebuild PHP base images weekly even when nothing is announced, and keep a rollback path.
2. Never run pm.max_requests = 0 in production. Unbounded worker lifetime turns every memory-safety bug into a persistent foothold. 500–1000 is a sane default for game APIs.
3. Cap every request body at the edge. 2 MB for JSON APIs, 10 MB for uploads, and reject anything without a matching content type. This kills entire classes of memory-pressure exploits before they reach PHP.
4. Log response bodies for 5xx errors, sampled. You cannot build full-transaction detection if your origin responses are invisible to your observability stack. Sample 10% and keep 7 days.
5. Keep an inventory of every runtime you operate. Not just PHP — Node, Python, Go, whatever runs your web tier. The studios that responded to php2shell in under an hour had a service catalog. The ones that took a day were grepping Dockerfiles.

The Bigger Lesson: Your Web Tier Is the Attack Surface

php2shell is a reminder that game backends accumulate cruft. You ship a PHP admin panel in year one because it was fast to build. Year three, it is still there, still on 8.1, still holding a database credential with write access to the player table — and it is the thing that gets popped, not your hardened game server binary.

The structural fix is to reduce how much runtime you own. If the only reason you are operating a PHP web tier is to handle player accounts, cloud saves, and leaderboards, those are exactly the capabilities horizOn exposes as managed APIs — end-user authentication with account-bound sessions, Cloud Save with revision-aware reads and writes where the client resolves conflicts, leaderboards, and remote configuration. No PHP-FPM pool to patch at 3 a.m. because there is no PHP-FPM pool.

That is not an argument that managed services are immune to vulnerabilities. It is an argument that every runtime you operate is a runtime you must inventory, patch, and monitor — and that most studios have more of them than they think.

Do This Now

If you take one action from this article, make it the inventory script in Step 1. Run it against every environment — production, staging, the forgotten demo server from that publisher pitch. You will almost certainly find a runtime you forgot about, and it will almost certainly be on an EOL branch.

Then patch, recycle the workers, and leave the edge rules in place. The WAF rules and the body caps are defense in depth, not a substitute for the vendor fix — the PHP advisory is the source of truth and it is the thing that actually closes the hole.

If the inventory turns up more PHP than you want to own going forward, horizOn covers the account, save, and leaderboard tier as managed services, which is the fastest way to shrink the surface you are responsible for patching. Either way: inventory first, patch second, and stop assuming the boring part of your stack is the safe part.

---

Source: Cloudflare deploys protections against php2shell vulnerability