PHP2Shell: How to Verify That Your Running PHP Application Is Patched

Trace the fix from the security advisory to the application actually handling requests.

When a critical PHP advisory lands, updating a package is an obvious first step. Closing the incident requires more evidence.

Which PHP installation did you update? Does the web server use it? Have all application instances been replaced? Does the application still work?

These are the operational questions behind a useful PHP2Shell response.

PHP2Shell refers to CVE-2026–109618 and CVE-2026–109619. Cloudflare's disclosure describes potential remote code execution, denial of service, and data exposure when affected applications process specially crafted HTTP traffic. Cloudflare disclosure.

This walkthrough explains how to investigate patch status and verify the deployed application. It has not yet been validated in the author's environment. Security sources were checked on October 31, 2026.

Find the PHP runtime behind the request

Begin with the path a request follows through your application: client → proxy or load balancer → web server → PHP runtime → application dependencies.

Your environment may combine these components or distribute them across several machines. Identify the actual hosts, containers, and replicas before choosing an update procedure.

Check background workers and scheduled jobs too. Record them separately so that web exposure and other uses of PHP remain clear.

If PHP is available in the terminal on the application host, start with these commands. The example uses PowerShell; run it on the intended host, rather than assuming your workstation's PHP installation matches the application.

php -v
if ($LASTEXITCODE -ne 0) {
    throw "PHP version check failed."
}
php --ini
if ($LASTEXITCODE -ne 0) {
    throw "PHP configuration check failed."
}

php -v
if ($LASTEXITCODE -ne 0) {
    throw "PHP version check failed."
}
php --ini
if ($LASTEXITCODE -ne 0) {
    throw "PHP configuration check failed."
}

Record the version, build information, executable location, and configuration files.

These results describe the CLI runtime. Establish separately which runtime the web server uses. A correct CLI version does not establish the state of PHP-FPM workers, an Apache module, or another serving process.

Match the installation to the right security fix

PHP's October 21 security releases included versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Check the applicable branch and subsequent security guidance when selecting the release to deploy. PHP release archive.

For a vendor-maintained installation, use that vendor's advisory and complete package revision to establish patch status. Record both the advisory and the installed artifact.

For containers, Docker recommends updating affected PHP images and rebuilding and redeploying applications that depend on them. Docker security guidance.

If your application uses Docker, inspect its container from a PowerShell terminal connected to the intended lab daemon. Replace the placeholder with the exact container name.

$ContainerName = '<your-lab-application-container>'
docker inspect --format '{{.Id}} {{.Image}} {{.Config.Image}}' $ContainerName
if ($LASTEXITCODE -ne 0) {
    throw "Container inspection failed."
}
docker exec $ContainerName php -v
if ($LASTEXITCODE -ne 0) {
    throw "PHP version check inside the container failed."
}

$ContainerName = '<your-lab-application-container>'
docker inspect --format '{{.Id}} {{.Image}} {{.Config.Image}}' $ContainerName
if ($LASTEXITCODE -ne 0) {
    throw "Container inspection failed."
}
docker exec $ContainerName php -v
if ($LASTEXITCODE -ne 0) {
    throw "PHP version check inside the container failed."
}

Save the container ID, image ID, configured image reference, and PHP version together. They help connect a running instance to its deployment artifact.

The PHP command still checks the CLI binary inside that container. Compare it with the serving process before treating it as evidence of web-runtime patch status.

Replace running instances and investigate differences

Apply the fix through your normal deployment mechanism. The exact package, build, restart, and rollout commands depend on the operating system and deployment model.

After deployment, compare the approved artifact with every instance intended to receive traffic.

If an instance reports an unexpected build, investigate before declaring the rollout complete. Check whether an old replica remains active, the deployment references an older artifact, or the web server uses a different PHP installation.

Treat each explanation as a hypothesis. Use deployment records, process information, and instance-specific checks to establish which one applies.

For runtime identification, prefer existing internal diagnostics. If you need a temporary endpoint, restrict it to the isolated lab and expose only the minimum information required. Avoid publishing a full phpinfo() page.

Check application behaviour after the update

Patch verification and application validation answer different questions. You need evidence for both.

From a PowerShell terminal on a machine that can reach the lab application, request its health endpoint. Replace this illustrative URL with the real endpoint.

$HealthUrl = 'https://your-lab-app.example/health'
$Response = Invoke-WebRequest -Uri $HealthUrl -UseBasicParsing
$Response.StatusCode
$Response.Content

$HealthUrl = 'https://your-lab-app.example/health'
$Response = Invoke-WebRequest -Uri $HealthUrl -UseBasicParsing
$Response.StatusCode
$Response.Content

Compare the response with the application's documented healthy condition. A successful HTTP response establishes that this request succeeded; it does not establish that every replica is patched.

Repeat representative application operations as well. Depending on the service, these might include authentication, file uploads, database access, session handling, and background-job processing.

Keep the checks consistent before and after the change so that differences are meaningful.

Decide what the evidence supports

A completed verification should connect four things:

• The applicable security advisory and approved fixed build.
• The artifact deployed to each intended serving instance.
• The PHP runtime handling requests.
• Successful representative application checks after replacement.

No execution results are available for this walkthrough yet. These are completion criteria, not observed outcomes.

Even after successful validation, keep the conclusion narrow: the checks establish the recorded patch and application state at the time of testing. They do not establish that no earlier compromise occurred.

Keep the exercise scoped and clean up afterward

Use an isolated application for the demonstration. Exploit traffic is unnecessary for this workflow.

Account for image downloads, registry storage, CI builds, and hosted compute when choosing the lab. Confirm any applicable charges rather than assuming the exercise is free.

Remove temporary diagnostic endpoints and lab-only access rules after collecting evidence. Stop disposable resources using their recorded identities. Preserve redacted runtime records, artifact identifiers, deployment results, and application checks.

A useful patch record allows another engineer to follow the fix all the way to the application serving requests.