PHP2Shell: patch the runtime, then verify the website.

The October disclosure, without the hype

PHP’s 21 October advisory identifies CVE-2026-109618 and CVE-2026-109619 and fixed releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its web-runtime warning includes unauthenticated remote code execution. Our recommendation: obtain current package or backport evidence from your host, rather than choose an upgrade solely from this dated article.

Was this only a theoretical issue?

Cloudflare reports observing attack traffic and deploying WAF protections during the coordinated response. Its write-up explains why it still recommends patching PHP. Observed attempts across a provider’s network do not establish that your website was exploited. Conversely, a quiet firewall chart is not proof that every route to your origin was protected. Use your own configuration and logs to establish what your site actually exposed.

Find the runtime that serves each website

Our recommended inventory starts with the request path: public domain, proxy or CDN, origin, web server and PHP pool or container. A server can hold several PHP versions. Ask the administrator which one is attached to each virtual host, including a staging site still reachable on the internet. Avoid publishing a phpinfo page to prove the version; retain the necessary package or pool evidence privately. A command-line binary version alone does not show what handled a web request.

• List every public PHP-backed domain, staging host and alternate origin.
• Record the hosting owner, serving runtime and package source.
• Identify separate pools, containers, workers and managed-service responsibilities.
• Mark unknown versions as unresolved until the responsible host confirms them.

Ask for patch evidence, not just a version label

PHP maintains a supported-version schedule; an older branch may need a supported upgrade path or a documented vendor backport. Our suggested acceptance record names the package build, security advisory, affected host and deployment time. If the host says a backport fixes the issue while the visible version looks unchanged, ask for the vendor’s advisory and exact package identifier. Have the site developer review compatibility before changing runtime branches. Keep the evidence tied to the service that actually receives traffic.

Read the follow-up advisories too

PHP’s archive also records a conditional upload-progress issue on 23 October and separate Windows Brotli package rebuilds on 26 October. Our recommendation is to ask your administrator which follow-up notices apply, and retain that answer with the change record.

Make the change safe for the business

Our proposed rollout uses a representative staging environment, an application backup with an understood restoration path and a short list of business acceptance tests. Agree who can stop the release if a checkout, enquiry or login fails. Keep responsibility explicit when a host maintains the runtime and an agency maintains the application. Do not automatically roll production back to a known vulnerable runtime after a compatibility failure; the service owner and incident lead need a containment and recovery decision.

• Test anonymous browsing and the real sign-in route.
• Submit an authorized test enquiry or a sandbox checkout and confirm its stored result.
• Exercise uploads, sessions, scheduled work and integrations that matter to the site.
• Check error rates and worker health after the runtime change.
• Record the running package and test results before closing the change.

Keep firewall protection in perspective

Cloudflare’s origin-security guidance distinguishes a proxied domain from its underlying server. Our operational recommendation is to retain relevant WAF protections while patching, verify the request path and review any origin access that bypasses the proxy. Evaluate temporary controls with the host against the current advisory. Do not copy memory-limit or upload settings from a social post into production without understanding their application and availability impact.

Separate patch verification from incident response

NIST’s incident-response guidance places preparation, detection, response and recovery within risk management. For this change, keep two records: evidence that the runtime is repaired, and the outcome of reviewing possible earlier activity. If your logs or endpoint monitoring suggest unauthorized execution, preserve evidence and involve an authorized responder. A completed update does not answer that historical question. Where evidence is unavailable, state the gap clearly instead of issuing an “all clear.”

What a public website scan can tell you

A public scan can observe an outside response at a point in time. It generally cannot prove the exact private package build, a host’s backport, every origin configuration or whether an attacker accessed data earlier. Use it to identify visible signals and to retest exposed behavior after remediation. Obtain server-side patch evidence from the hosting owner. A deeper assessment should have an agreed scope and permission; reproducing remote-code execution on a live business site is not a routine version check.

Send a useful request to your hosting team

Here is a proposed handover brief you can adapt for your own service. It asks for evidence without requesting secrets or destructive testing.

• Confirm which web-serving PHP runtime and package build handles each of our domains.
• Provide the applicable vendor advisory or backport evidence for the October issues.
• State whether the follow-up upload-progress and Windows dependency notices apply.
• Document the restart or redeployment, then verify our agreed business journeys.
• Report the log period reviewed, any suspicious activity and any remaining uncertainty.