PHP2Shell Exposure Depends on More Than Whether You Use PHP

What it is

A Horizon3.ai post (October 2026 catalog entry) on working out whether you are exposed to PHP2Shell, which covers CVE-2026-109618 and CVE-2026-109619, two related memory-handling flaws in PHP. It is not a technical primer. Mechanism and fix details are in Horizon3.ai's separate PHP2Shell technical advisory.

How it works

The page gives little mechanism. For the stale-state flaw, the demonstrated path has state survive one request and get used by a later request handled by the same worker. Reachable paths depend on server integration, application behavior, configuration and request lifecycle. Code execution starts with the web worker's permissions, so impact depends on which data, credentials and services that account can reach.

Preconditions / Affected

Horizon3.ai says it has validated feasible exploitation, but only under specific preconditions it has not yet published. It warns that these conditions are not an exhaustive list of exploitable paths. Affected PHP can sit in:

• third-party applications that bundle their own runtime
• containers whose PHP version differs from the host's
• managed hosting, where the customer sees only the CMS

The page treats these as places to look, not as proof of exposure.

What to do

Start inventory and remediation now, without waiting for exploitability research. Find affected runtimes, assign an owner to each, apply PHP or vendor fixes, and confirm the corrected build is actually serving requests. Updating the server's PHP package does not change a bundled copy inside a product or container.

For managed services, ask the provider:

1. Does our service use an affected PHP runtime?
2. Has a release containing both fixes, or an applicable vendor backport, been deployed?
3. Have the relevant services and workers been restarted?
4. Does that confirmation cover our service and all relevant instances?

The page says a provider offering patched PHP is weaker evidence than confirmation that the patched runtime serves your application. Where authorized testing is available, retest alongside that runtime evidence.

Caveats

• A failed exploit attempt only describes the tested path under those conditions. It does not show the runtime is safe or rule out earlier compromise.
• A working exploit in one environment does not imply the same result elsewhere.
• Horizon3.ai says its validation is not yet a production-ready assessment. It is still defining coverage and operational effects, and it has not released a reliable exposure check.