php2shell: Two Critical PHP RCE Bugs Patched, Finding Every Runtime Is Hard

Two memory-safety bugs in the request lifecycle

According to Sourcegraph, PHP published the fixes at 14:00 UTC on October 21, 2026, together with a security advisory and two GitHub advisories, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Researchers refer to the pair of vulnerabilities as php2shell.

Both flaws are memory-safety bugs in the request lifecycle. On mod_php they can be reached before application code runs, and a crafted multipart POST is enough to start the chain. Sourcegraph draws the conclusion that the cleanliness of an application does not matter. What matters is which PHP binary answers the request.

PHP 8.1 and earlier are no longer supported by the upstream PHP project, so they will not receive a fix. PHP's own guidance is short: "There are no complete mitigations, updating is the only safe choice."

Why finding PHP is harder than patching it

The vulnerable code sits in the interpreter, not in any single application. Every place an interpreter was pulled in therefore counts, whether or not a PHP developer ever touched it. Sourcegraph lists typical locations:

• official php:* base images
• apt install php8.x-fpm lines buried in Dockerfiles
• Helm charts for off-the-shelf apps such as WordPress or Matomo
• CI images that run Composer
• forgotten internal admin tools

Each of these pins its version in a different place. A scanner shows what is deployed right now, but not which repository builds it, who owns it, or where the next build might pull the old version back in. Sourcegraph says patching may take minutes in simple environments, but in the most complex codebases it can take hours, days, weeks or even months with traditional tools.

You are affected if anything you run serves HTTP through PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The post offers Sourcegraph search queries for Dockerfile base images, OS package installs, Kubernetes and Helm manifests, GitHub Actions workflows and composer.json pins. Because regex only finds known strings, Sourcegraph pitches its Deep Search tool for broader questions asked in plain English, such as which services actually serve traffic through mod_php. According to the company, it runs the code searches and navigation itself and answers with links to the files it used.

Recommended response steps

Sourcegraph advises treating any internet-facing host on a vulnerable build as possibly compromised. Its suggested order of work:

• Patch internet-facing mod_php first, since it is the confirmed pre-application path, then FPM, FrankenPHP and LSAPI.
• Restart every worker, because a new package does not help a worker that still has the old binary in memory.
• Rotate everything the web user can read, including database credentials, API keys in .env files and cloud credentials reachable from the host or its metadata endpoint.
• Run full forensics on every vulnerable, exposed service, saving logs and snapshotting the host before rebuilding. Signs of access should be handled as an incident.
• Rebuild images instead of just redeploying them, bumping pinned tags and pulling fresh bases.
• Isolate or migrate end-of-life hosts running PHP 8.1 or older, pulling them off the public internet until they are on a supported branch.
• Hunt on exposed hosts, going back to at least October 20, when news of the bugs first leaked.

For the mass update, Sourcegraph promotes Agentic Batch Changes. A user describes the change in plain language, and the tool scopes affected repositories with Deep Search and Code Search. It uses a script for mechanical tag bumps and Claude Code or Codex where judgment is needed, starts with a canary, reacts to CI failures and continues until the pull requests are mergeable.

What it means for teams

Sourcegraph expects most teams to finish the supported branches by the end of the week, while the long tail of end-of-life hosts will drag on for months. Its broader point is that the next runtime CVE will look different, but the deciding question will be the same: where does this run, and who owns it? According to the company, a team that can answer that from its code faces an afternoon of pull requests, while one that cannot faces a week of Slack threads.

The post is also a product pitch, so the speed claims for Deep Search and Agentic Batch Changes come from the vendor. The patch advice itself is straightforward: upgrade every PHP runtime and restart the workers.