php2shell: Are We Affected?

php2shell puts remote code execution in PHP at the center of today's security response. Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed on October 21, 2026. For teams responsible for deployed PHP applications, the immediate challenge is turning that news into decisions: where are we affected, what can we confirm, and what must change?

A CVE identifier does not answer those questions. Neither does a list of repositories that mention PHP. The relevant software is already deployed, sometimes behind several layers of infrastructure, and the evidence needed to assess it is scattered across advisories, runtime information, configuration, and deployment records.

I built CVE Central to connect those pieces. Its investigation agent inspects configured deployments, collects runtime and advisory evidence, confirms affected-version findings, and produces a manual action plan. php2shell provides a concrete case for explaining how it works: from identifying the PHP actually serving requests to proposing a patch that covers both CVEs.

What php2shell changes

The name php2shell refers to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can lead to remote code execution. The NCSC Netherlands guidance collects information about the pair.

CVE-2026-109618 concerns out-of-memory handling. Interrupted initialization can leave invalid request memory for cleanup to process. PHP's advisory describes a path in Apache mod_php that occurs before application code starts. Application validation alone cannot cover that path. See the PHP advisory.

CVE-2026-109619 concerns stale state between requests. A worker can retain references to memory belonging to an earlier request; a later operation can use that memory after it has been freed. Applicability depends on the operations and configuration involved. See the PHP advisory.

Both advisories list fixes in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Those are branch-specific patch boundaries. For a packaged runtime, the investigation must also check the distributor's security notice and whether a fix was backported. An upstream version comparison needs that context before it can support a conclusion about a vendor package.

The alert becomes a local finding

The first task is to identify where PHP is actually running. A repository dependency file or deployment document may describe an intended version. The response needs evidence from the deployed service.

CVE Central starts from an explicitly configured target with authorized access. Its current PHP adapter inspects the running container, checks the PHP version through the web server, and collects the server interface and configuration. Deployment and network observations help locate the service and identify exposure questions that still need investigation. Package-based deployments also require vendor patch evidence; the current upstream-version assessment does not establish that coverage.

Cross-checking matters. A command-line PHP binary may differ from the runtime behind the website. A container image reference can disagree with the running process. When observations conflict, the agent should preserve the discrepancy and investigate it before issuing a confident finding.

The agent cross-checks the PHP/Apache image reference against the version reported through the web server. That gives its assessment a concrete runtime to compare with the advisory. A declared dependency alone cannot establish what is handling requests now.

The result of detection should be an inventory of observed runtimes tied to deployed services, with evidence and timestamps. Anything the agent could not inspect should remain explicitly unresolved. An incomplete inventory must not become a claim that the remaining applications are safe.

A working service can still need an urgent patch

I designed the assessment around a distinction that matters operationally: confirming an affected version is different from confirming an exploit or a compromise. CVE Central establishes the version finding; the other questions require additional evidence.

CVE Central retrieves the PHP CNA records and retains source URLs and retrieval times. Its version comparison runs in code, using the observed upstream runtime and the supported advisory ranges. Where a distributor backports fixes, the package's security status must inform that comparison. Missing or contradictory evidence should lead to an unresolved finding and a specific follow-up request.

This distinction is especially important for php2shell. Configuration helps interpret the paths described in the advisories, but collecting settings does not reproduce an exploit. Ordinary application checks provide a baseline for the eventual update; passing them cannot establish that the runtime is unaffected.

Similarly, a published Docker port does not prove Internet reachability. External exposure requires additional evidence about routing, firewalls, proxies, and access controls. An affected runtime is already a reason to prepare a patch; proving an exploit against the live service need not become a prerequisite for that work.

This is where an agent's reporting discipline matters most. “Affected version,” “exploitable deployment,” and “confirmed compromise” lead to different operational decisions. Combining them into a single red status loses information the operator needs.

Two findings lead to one proposed change

For an upstream PHP 8.4 deployment running an affected release, the shared patch boundary makes it possible to address both CVEs in one runtime update. The agent's php2shell investigation produced this proposed container change:

That edit is the center of a plan, but the operator also needs a way to deploy it and determine whether it worked. CVE Central produces a manual runbook around that edit, including preparation, service replacement, acceptance checks, and recovery. An operator reviewing it needs to resolve five practical questions:

1. Scope and priority. Identify the affected service, its owner, the evidence, and unresolved exposure questions. If patching must wait, assess temporary containment against current authoritative guidance and the actual deployment.
2. Preparation. Verify the patched artifact, record its digest, preserve deployment configuration, and establish application-data backup and recovery readiness.
3. Execution. Review the exact change and replace the affected service in an agreed window, accounting for interrupted requests and session loss.
4. Acceptance. Confirm the patched PHP version through the web server, record the new running artifact, and repeat the functional baseline.
5. Recovery and closure. Define what happens if the service fails, recognize that restoring the old affected runtime reopens the finding, and retain the evidence required to close it.

The distinction between a written plan and completed remediation must remain visible. Producing a runbook does not update a service. The finding remains open until deployment and post-change verification establish that the affected runtime has been replaced.

From today's disclosure to a verified response

CVE Central connects three kinds of work that are often handed between people: identifying affected runtimes in configured deployments, assessing the evidence, and preparing the change. The model selects tools permitted in each phase; version comparison and runbook construction run in code. Review checkpoints separate collection, assessment, planning, and reporting so the operator can inspect the evidence before continuing.

The companion Agent page and technical report document the agent I built and its current scope: configured PHP targets. That scope matters: an assessment of selected services is not evidence that an entire organization has been checked. Broader coverage requires an inventory and access to the deployments being assessed.

php2shell shows why vulnerability response cannot end at notification. The disclosure is shared news; the affected services, package provenance, exposure, and recovery constraints are local facts. I built CVE Central to gather that evidence and prepare a plan an operator can review and execute. It produces the investigation and runbook; it does not deploy the patch or certify that remediation is complete.

The standard for success is concrete: identify the affected deployment, explain the evidence, specify the corrective change, and verify the runtime after that change. Until then, the organization has an alert or a plan. With that evidence, it has a defensible answer to the question php2shell raised today: where were we affected, and what did we do about it?