PHP2Shell: How to Patch PHP and Verify Every Running Worker

An updated PHP package on disk is only part of a security fix. You also need to know which PHP runtime serves each application—and whether its workers are actually running the patched build.

PHP2Shell is the name used for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP itself. This guide focuses on identifying, patching and verifying deployments.

Information checked: 23 October 2026. A separate follow-up notice published that day is covered below. Follow the linked advisories for subsequent changes.

Start with the fixed versions

Branch	Affected upstream releases within branch	First fixed release
PHP 8.5	Earlier than 8.5.12	8.5.12
PHP 8.4	Earlier than 8.4.27	8.4.27
PHP 8.3	Earlier than 8.3.36	8.3.36
PHP 8.2	Earlier than 8.2.35	8.2.35

Compare versions within their branch. PHP 8.3.35 does not contain the fix just because its version number is higher than 8.2.35.

Sources: PHP's OOM corruption advisory and stale global state advisory.

For distribution packages, inspect the full package revision and the vendor's security notice. Vendors may backport fixes without changing the upstream base version. A banner alone cannot settle that question.

PHP 8.1 and earlier are outside normal upstream support. PHP exceptionally supplied minimal source backports for 7.4, 8.0 and 8.1, but that does not restore normal maintenance. See the PHP security notices. PHP 8.2 security support ends on 31 December 2026, according to the official support schedule.

What is confirmed about the vulnerabilities?

Both advisories assign CVSS v4.0 9.2, Critical.

CVE-2026-109618 concerns out-of-memory handling. An interrupted operation can leave partially initialised request data that cleanup later processes incorrectly. PHP documents validated unauthenticated code execution against Apache mod_php. Its advisory describes FPM susceptibility from source analysis, without a complete demonstrated FPM exploit for this particular flaw.

CVE-2026-109619 concerns request state retained after its backing memory is freed. A subsequent request handled by the same worker can access that stale state. PHP documents validated session lifecycle RCE against mod_php and FPM, with application prerequisites for the FPM path. Memory disclosure is also a confirmed impact.

Successful execution uses the web worker's privileges. That is serious, but it does not automatically establish root access. Build details, configuration and application behaviour affect exploitability. Read the OOM advisory and stale-state advisory for the distinctions.

Build an inventory you can actually close

Field	Evidence needed
Application	Hostname, environment and responsible team
Runtime	PHP branch, handler and executable or image
Package source	Distribution, control panel or appliance vendor
Fix evidence	Fixed release or vendor notice covering both CVEs
Deployment evidence	Package revision, restart time or image identifier
Verification	Application checks and remaining exceptions

Include staging sites, old campaign domains, administrative interfaces and vendor software that bundles PHP. Give containers their own records when they have a separate release process.

ProjectDiscovery's discovery guide highlights PHP hidden behind non-standard ports, subdirectories and administration tools. Its version-checking Nuclei template uses advertised version information. That is a discovery lead, not a successful exploitation test—and a missing header does not prove PHP is absent.

Verify the runtime, not just your shell

These commands provide a starting point:

php -v
php --ini

They describe the PHP binary resolved in that shell. Your website may use another installation, an FPM pool configured for a different branch, or PHP inside a container.

My recommended sequence is:

1. Map each virtual host to its actual handler or upstream.
2. Identify the executable, package revision or container image behind it.
3. Apply the vendor-approved update.
4. Restart the relevant workers, or rebuild and redeploy the container.
5. Verify every origin, pool and replica.
6. Exercise the application through its normal production hostname.

ProjectDiscovery also stresses that installing the updated package does not replace an already-running worker.

For application checks, cover login, forms, uploads, checkout, API calls and scheduled jobs as applicable. Record the results rather than relying on a single successful homepage request.

For a branch migration, also test extensions and encoded applications. A rollback plan should include a way to restrict access if returning to the previous build would reintroduce exposure.

Understand the attack timeline without overstating it

Date	Observation	Limit of the evidence
17 October	Amazon retrospectively identified an exploitation attempt in MadPot telemetry	A honeypot observation, not proof of a customer compromise
20 October	Huntress documented leaked details; PHP announced the emergency release	The public warning preceded the patches
21 October, 02:00–08:00 UTC	Amazon observed further attempts	Real-world success was unclear
21 October	PHP released the four emergency builds	Announced time: 14:00 UTC; availability reports indicate slightly earlier
After disclosure	Amazon observed broader attempts	An attempt remains distinct from confirmed compromise

Sources: Amazon's primary telemetry report, Huntress's dated response, Upsun's rollout timeline and PHP's notices.

Huntress reported no observed exploitation in its partner systems as of 16:30 ET on 21 October. That does not contradict Amazon's observations: they describe different monitoring populations.

SecurityWeek's coverage highlights the pre-patch activity. For incident decisions, use Amazon's precise qualification: success against real-world systems was uncertain. The early activity does not establish how anyone acquired the exploit information.

Temporary mitigations need an expiry date

If patching is blocked, consider restricting access upstream or serving a static response that does not invoke PHP. Assign an owner and a deadline to the exception.

PHP documents partial configuration measures:

• For the OOM flaw, administratively enforcing memory_limit=-1 removes a controllable PHP memory-limit failure. Underlying allocation failures remain possible. Assess availability implications, request limits and container or cgroup boundaries. PHP warns against substituting RLIMIT_AS or RLIMIT_DATA.
• For confirmed stale-state paths, disable session upload progress administratively and restart workers. PHP 8.5 can also disable fatal_error_backtraces. These controls do not cover every variant.

Consult the OOM mitigation instructions and stale-state mitigation instructions before changing configuration.

A WordPress maintenance plugin operates within the application. It cannot be relied on for a path triggered earlier. An upstream WAF can block selected requests before PHP, but coverage depends on its rules and whether the origin is reachable directly.

xCloud and Upsun describe mitigation followed by runtime patching. Their reports apply to their own platforms and stated exceptions. Request evidence for your specific deployment.

Review PHP's separate 23 October follow-up

PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release for a separate, unusual configuration issue.

The relevant application configures session.serialize_handler as php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and leaves upload progress enabled. PHP identifies the follow-up as CVE-2026-115560, with a full advisory planned for the next release. Applications that never switch the handler at runtime may retain the feature, according to the notice.

See PHP's 23 October informational advisory. Distinguish this follow-up from the original two CVEs and their fixed releases.

Patching and incident response are separate tasks

As an operational precaution, retain relevant proxy, application, PHP and security logs before they expire. Include time before public disclosure in the review because Amazon's observations predate it.

Investigate unexpected worker child processes, changed executable files, unfamiliar administrator accounts, scheduled tasks and unusual outbound connections. Correlate evidence: a blocked request or an error spike alone does not establish compromise.

If evidence supports an intrusion, isolate the affected service and follow your incident-response process. Preserve evidence, recover from a trusted baseline and rotate exposed secrets from a clean system after containment.

A useful question for your host

Which PHP build serves each of my sites, does it address both CVEs, when were workers restarted, and are staging, containers and bundled runtimes included? Has the 23 October follow-up been assessed?

ARO's analysis emphasises asset ownership and decision speed. Those are useful operational lessons: the patch rollout is much easier when you already know who owns every deployment.

For the expanded hosting checklist and FAQs, see the original DigitalBerg PHP2Shell guide. For WordPress deployment planning, DigitalBerg also has a WordPress VPS guide.

Discussion: What evidence does your team require before marking a runtime security update complete—package installation, worker replacement, application checks, or all three?