PHP2Shell Response Guide

PHP2Shell Response Guide is an independent security resource for assessing and responding to CVE-2026-109618 and CVE-2026-109619, two memory safety flaws in the PHP engine. It combines a passive website checker, a local version checker, remediation guidance, platform specific instructions, and a compact record of what is known about exploitation. The site is aimed at people who need to answer a practical question quickly. They want to know whether a website or PHP runtime may be exposed and what they should do next. It clearly states that it isn't affiliated with the PHP project, the PHP Foundation, or the research teams, and it directs readers to confirm important decisions against official PHP advisories.

The public website checker accepts a domain and looks for signs of exposure using ordinary GET requests. It doesn't send exploit payloads, submit forms, or upload files. The target will see normal access log entries, query strings are removed before the check, and results aren't published. Its output is designed around clear verdicts instead of simply repeating a server banner. The checker can identify visible PHP versions, recognize fingerprints from WordPress, Drupal, Laravel, and more than twenty other PHP applications, and compare findings with OSV advisories. It also accounts for distribution backports by sending Ubuntu, Debian, RHEL, and similar packages for a vendor check instead of declaring an old looking version vulnerable without context.

There is also a version checker for text copied from php -v, individual version numbers, or lists covering a fleet. That check runs in the browser. The guide repeatedly warns that a command line PHP version can differ from the build used by PHP-FPM or Apache, so it asks readers to verify the runtime that actually serves web traffic. Its version table identifies fixed releases for supported 8.2 through 8.5 branches and explains that older branches may need a vendor backport or a full upgrade. This distinction matters because distributions can apply security patches without changing the upstream looking version number. The site therefore treats package history, server configuration, and the active process as evidence that must be considered together.

The response workflow is concrete. It tells teams to find every runtime across web servers, containers, base images, shared hosting, staging systems, and long running workers. They then install a fixed release or an appropriate patched distribution package, restart every process that loads PHP, verify the web facing version, and review recent logs. The guide notes that application updates do not update the PHP interpreter and that old PHP-FPM or Apache processes keep old code in memory until restarted. It also covers temporary mitigations while an upgrade is pending, but presents patching as the complete fix. Separate guides address WordPress, Drupal, Joomla, hosting providers, Cloudflare WAF users, and the session.upload_progress setting.

Beyond the checker, the site explains what the two CVEs can enable and how exposure differs across common server setups. It separates confirmed behavior from likely susceptibility and from configurations that the advisories do not cover. Readers can see why Apache with mod_php receives particular attention, why PHP-FPM still needs the patch, and why a command line worker isn't the same as an internet reachable web request path. The detection material also puts memory disclosure alongside code execution. That is useful because leaked worker memory may contain credentials, session tokens, or request data without creating an obviously malicious process. A timeline and status notes provide context, while prominent cautions discourage running unknown exploit repositories against production systems.

This resource fits hosting providers, managed service providers, security teams, agencies, and tool builders responsible for public PHP estates. It is also approachable enough for a site owner who knows the application they run but not the server stack beneath it. Its main strength is the connection between a quick, nonintrusive check and the operational work that follows. It doesn't pretend that a passive scan proves safety. Instead, it shows the limits of visible evidence, distinguishes upstream versions from distribution packages, and reminds teams to check every place PHP runs. That makes it more useful as a response guide than a simple vulnerability headline or one field version form.

The guide and both public checking paths are free to use. A separate $99 one-time purchase provides the passive analyzer as full TypeScript source for teams that want to run it in their own pipeline. The package includes a test suite, a README, runnable examples, unlimited local use, offline fleet checks, and access to updated releases in the purchasing browser. It has no license server and records the requests and responses used for its evidence while redacting secrets. Buyers should understand that the paid code is still a passive analyzer, not an exploit test, and that a security decision should include local inventory and vendor advisories. For a fast moving incident, the site offers a focused starting point with unusually clear boundaries around what its checker can establish.