Disclaimer: This article is not a primer on how the CVEs (CVE-2026-109618/CVE-2026-109619) work. For that, see our PHP2Shell technical advisory.
“We don’t use PHP” may describe your development stack, but it doesn’t directly describe every product, container, or hosted application your organization depends on.
There are two important challenges when confirming the exploitability of PHP2Shell. The first challenge is finding the affected runtime—including the copies another team or provider manages. The second is understanding whether an attacker can exploit it in that particular environment.
The PHP you didn’t choose
An organization doesn’t need to write PHP applications to depend on PHP. A third-party application may bundle its own runtime. A container may carry a different version from its host. A hosting provider may manage PHP beneath a site whose administrators only see the content-management interface.
These are sources to investigate, not evidence that every such product is affected. Establishing the actual exposure means identifying the actual runtime and checking the applicable vendor guidance. From a red-team perspective, the important question is which reachable systems depend on affected PHP, not which programming languages appear in the organization’s development standards.
That also changes who can fix the problem. Updating the PHP package on a server does not establish that a bundled copy inside a product or container has also changed.
Hosted applications change the responsibility
With a fully managed website, the customer may have neither visibility into the PHP runtime nor permission to patch it. With self-managed hosting, that responsibility may sit with the customer.
For a managed service, ask the provider:
- Does our service use an affected PHP runtime?
- Has a release containing both fixes—or an applicable vendor backport—been deployed?
- Have the relevant services and workers been restarted?
- Does that confirmation cover our service and all relevant instances?
A statement that a provider offers patched PHP is less useful than confirmation that the patched runtime is serving your application.
Presence is only the beginning of exploitability analysis
Finding affected PHP establishes a remediation need. It does not, by itself, prove that a particular exploit will succeed.
PHP2Shell covers two related memory-handling failure patterns. The server integration, application behavior, configuration, and request lifecycle can influence which paths are reachable. For the stale-state vulnerability, the demonstrated mechanism involves the state surviving one request and being used by a later request handled by the same worker.
That is why a working exploit against one environment does not automatically establish identical results everywhere. It is also why an unsuccessful attempt does not establish that an affected runtime is safe. The useful finding is specific: which path was tested, under which conditions, with what observable result?
What our validation establishes
We’ve validated that these vulnerabilities can be feasibly exploited in practice, but it requires specific preconditions. We’re still characterizing those conditions and what they mean for real-world exposure; we’ll share further technical detail when it’s ready.
That is where our research stands. The conditions of our validated exploit should not be treated as an exhaustive description of every possible path covered by these vulnerabilities. As the work develops, we will distinguish what we have demonstrated from what remains under investigation.
Successful research validation and readiness for production assessment are also separate milestones. Getting an exploit, or even a reliable check, to work establishes a capability, but making that testing suitable for customer environments requires understanding its operational effects, defining its coverage, and interpreting its results accurately.
Our attack team is working on a reliable way to validate exposure. We want to be precise about what is ready rather than let the pace of the conversation outrun the evidence.
The blast radius depends on what the worker can reach
Once exploitation succeeds, the next question is what access it provides. Code execution begins with the web worker’s permissions. The potential business impact then depends on the data, credentials, and services accessible to that account.
A worker that can read application credentials may expose more than website content. Whether those credentials enable database access, access to another service, or further movement depends on their privileges and the surrounding environment.
Investigate and remediate while the research continues
You do not need to wait for a complete map of exploitability to start addressing affected PHP. Teams can begin inventory and remediation while research continues. Find affected runtimes, establish who owns each one, and apply PHP or vendor fixes. Confirm that the corrected build is actually serving requests.
Where authorized validation is available, retest alongside that runtime evidence and the assessment’s coverage. An unsuccessful attempt tells you about the tested path under those conditions. It does not establish universal protection or rule out an earlier compromise.
PHP2Shell deserves an informed response: investigate dependencies you may have overlooked, examine the conditions that enable exploitation, and verify the changes you make.
For up-to-date vulnerability details and remediation guidance, see our full PHP2Shell technical advisory.