PHP2Shell: Affected Versions, Fixes & Checklist

Last verified: 23 October 2026. PHP2Shell is the name used for two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619. If you operate a PHP website, your immediate task is to identify the runtime serving it, install a fixed build and verify that the running workers have restarted. Updating WordPress alone does not replace this work.

This guide separates confirmed technical findings, dated attack observations and provider-specific claims. It also includes PHP’s 23 October follow-up advice, which matters even after the initial emergency update.

PHP2Shell: the actions to prioritise

Find every PHP deployment: production websites, staging, containers, control panels and software with bundled runtimes.
Patch the runtime: use the fixed branch releases below or a vendor package explicitly documented as fixing both CVEs.
Restart and verify: confirm the web-serving runtime, not just the command-line installation.
Check today’s session upload progress advice: review the separate follow-up described below.
Investigate suspicious activity: patching closes vulnerabilities; it does not remove an existing intrusion.

Which PHP versions are affected and fixed?

Both PHP security advisories list these fixed releases. Compare versions within the same branch; PHP 8.3.35 is not safe simply because its number is higher than 8.2.35.

PHP2Shell emergency releases, published 21 October 2026
PHP branch	Affected upstream releases in branch	First fixed release	Action
8.5	Earlier than 8.5.12	8.5.12	Install a fixed build
8.4	Earlier than 8.4.27	8.4.27	Install a fixed build
8.3	Earlier than 8.3.36	8.3.36	Install a fixed build
8.2	Earlier than 8.2.35	8.2.35	Patch now and plan migration
8.1 and older	Legacy deployments require assessment	No normal upstream supported release	Upgrade or obtain documented vendor backports

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

A distribution may backport security fixes while retaining an older base version. Ask for its security notice and full package revision before concluding that a package is vulnerable or patched. PHP exceptionally supplied minimal source backports for 7.4, 8.0 and 8.1; these do not restore normal upstream support. See Huntress’s backport summary. PHP 8.2 reaches upstream end of life on 31 December 2026: check PHP’s support schedule.

What do the two vulnerabilities do?

Confirmed mechanisms and important limits
Vulnerability	Mechanism	Evidence and limits
CVE-2026-109618	Out-of-memory handling can leave partially initialised request data for cleanup to process incorrectly.	Unauthenticated code execution was validated against Apache mod_php. The OOM advisory describes FPM susceptibility from source analysis but no complete demonstrated exploit for this particular flaw.
CVE-2026-109619	A worker retains references to freed request memory, which a later request can access.	Session lifecycle code execution was validated against mod_php and FPM. FPM exploitation depends on a suitable application operation. Memory disclosure is also a confirmed impact.

Both advisories rate severity at CVSS v4.0 9.2, Critical. Successful execution has the web worker’s privileges; it does not automatically establish root access. Exploitability depends on configuration, application behaviour and build details. Sources: CVE-2026-109618 and CVE-2026-109619.

Who needs to act?

PHP’s warning covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest risk because a demonstrated attack can run before application code. See the official PHP notices.

For a WordPress or WooCommerce owner, ask the hosting provider to verify the underlying PHP build. For a VPS administrator, include every configured PHP handler and site pool. For software appliances, use the vendor’s approved update route rather than replacing bundled libraries independently.

ProjectDiscovery’s discovery guide highlights hidden PHP in administration tools, non-standard ports, subdirectories and customer containers. An absent PHP version header is not evidence that PHP is absent. Its Nuclei version check reads advertised version information; it is not proof of successful exploitation or complete safety.

PHP2Shell timeline: what is verified?

Dates and observations available by 23 October 2026
Date	Finding	How to interpret it
17 October	Amazon retrospectively identified an exploitation attempt in MadPot telemetry.	An observed attempt against a honeypot, not proof of a successful customer intrusion.
20 October	Huntress documented leaked details; PHP announced an emergency release scheduled for 21 October at 14:00 UTC.	The public warning preceded the fixed releases.
21 October, 02:00–08:00 UTC	Amazon identified additional attempts from anonymised infrastructure.	Amazon said real-world success was unclear.
21 October	PHP published the four emergency releases. Huntress placed availability around 09:30 ET; Upsun reported about 13:36 UTC.	14:00 UTC was the announced release time; reports indicate availability slightly earlier.
21 October, after disclosure	Amazon observed broader exploitation attempts. Huntress reported no observed exploitation in its partner systems as of 16:30 ET.	These describe different monitoring populations and are compatible.
23 October	PHP published separate session upload progress advice referencing CVE-2026-115560.	Review this follow-up alongside the original fixes.

Sources: Amazon Threat Intelligence, Huntress, Upsun and PHP.

SecurityWeek’s coverage draws attention to pre-patch activity. For incident decisions, retain the narrower wording from Amazon’s underlying evidence: attempts were observed, but their success against real systems was uncertain. The origin of the early exploit knowledge also remains unknown; the timing alone does not identify who leaked information.

23 October update: session upload progress

PHP now suggests session.upload_progress.enabled=0 until the next regular bugfix release. The follow-up concerns an unusual application that configures session.serialize_handler as php_binary or php_serialize, then switches to php with ini_set() before session_start(), while upload progress remains enabled. PHP identifies this separately as CVE-2026-115560, with a full advisory planned for the next release. Applications that never switch the handler at runtime can retain the feature, according to the notice. See PHP’s 23 October informational advisory.

A practical patch and verification workflow

The following is DigitalBerg’s recommended operational checklist. Keep an evidence record for each site rather than closing the incident after one server update.

1. Assign an owner and record the deployment

Record the hostname, origin server, PHP handler, package source, application owner and change owner. Include inactive sites that may return to service. Put containers and appliances on separate rows if their update lifecycle differs from the host.

2. Confirm what serves the website

Use the hosting control panel and server configuration to map each site to its actual PHP executable or container image. A command-line version check is useful:

php -v
php --ini

However, it describes that command-line binary. Compare it with the web handler and active pool. In WordPress, Tools → Site Health → Info → Server provides another useful check. Avoid leaving a public diagnostic page online.

3. Install from the appropriate package source

Use your operating system, hosting panel or appliance vendor’s supported instructions. Confirm both CVEs in the vendor notice if using a backport. For a branch upgrade, test extension compatibility, encoded applications, login, uploads, checkout and scheduled jobs. Maintain a recovery plan that does not leave an unpatched service publicly exposed.

4. Restart the relevant workers and redeploy containers

Coordinate the service restart with the actual handler. Rebuilding a host package will not update PHP inside a container. Confirm the deployed image and every replica; an old replica behind a load balancer can be missed by a single successful request. ProjectDiscovery emphasises the need to restart after installing the fixed package.

5. Verify through the production route

Test the application through its normal hostname, proxy and load balancer. Check each origin and worker pool administratively. Record package revision, restart time, deployed image identifier and test results. Monitor errors and resource consumption after the change.

Suggested evidence for closing each deployment
Check	Evidence to retain
Both vulnerabilities addressed	Fixed upstream version or vendor notice plus package revision
Correct runtime updated	Site-to-handler mapping and running process or image confirmation
Application works	Login, form, upload, checkout and job results as applicable
Follow-up reviewed	Upload progress configuration and handler-switch assessment
Incident review complete	Investigation owner, findings and unresolved actions

What if you cannot patch immediately?

Prefer restricting access upstream or serving a static response without invoking the vulnerable runtime while arranging the update. Record who owns the decision, what remains reachable and when the exception expires.

PHP’s OOM advisory describes administratively enforcing memory_limit=-1 as partial protection. Removing PHP’s memory cap introduces availability concerns and still permits underlying allocation failures. Use conservative request limits and an appropriate container or cgroup boundary; the advisory warns against substituting RLIMIT_AS or RLIMIT_DATA. Have the server administrator assess this tradeoff. See the OOM mitigation details.

For confirmed stale-state paths, PHP recommends disabling session upload progress administratively and restarting workers; PHP 8.5 can also disable fatal_error_backtraces. These settings do not cover every variant. Suppressing displayed errors does not fix the stale-state flaw. Consult the full stale-state advisory before applying temporary controls.

Can a WAF or maintenance mode protect WordPress?

A WordPress maintenance plugin runs within the application and should not be relied on for an attack that can occur earlier. A reverse proxy or edge WAF can block selected requests before PHP receives them, but its effectiveness depends on rules, routing and whether the origin can be reached directly.

xCloud reports temporary mitigation followed by package deployment, with exceptions including customer-managed containers and some legacy environments. Upsun reports edge rules followed by runtime updates and restarts. These are dated provider statements, not evidence about DigitalBerg infrastructure or a guarantee for another host. Ask for confirmation covering your specific service.

DigitalBerg’s Cloudflare information explains an additional protection layer. Keep that layer alongside runtime maintenance.

How to investigate possible compromise

As an operational precaution, preserve access, proxy, PHP, service and security-monitoring logs before retention policies remove them. Include dates before public disclosure in the review because Amazon’s observations predate it.

Look for unexpected PHP worker child processes, new executable files, altered application files, unfamiliar administrator accounts, scheduled tasks and unusual outbound connections. Correlate findings across systems; an error spike or blocked request alone is not proof of code execution.

If evidence supports compromise, isolate the affected service, preserve evidence and engage your incident-response process. Restore from a trusted baseline and rotate exposed credentials from a clean system after containment. Neither a successful update nor a clean homepage proves that an earlier intrusion has been removed.

Lessons from the six source articles

The sources address different parts of the problem: xCloud and Upsun describe their platform responses; ProjectDiscovery focuses on finding overlooked runtimes; Huntress provides dated monitoring observations; SecurityWeek reports early attack activity. ARO’s article argues for clearer asset ownership and faster response decisions. That governance lesson is useful, but patching remains essential. The technical advisories provide the basis for assessing each deployment’s attack paths.

Frequently asked questions

Is PHP2Shell a WordPress plugin vulnerability?

No. It concerns PHP itself. Keep WordPress, plugins and themes maintained, and separately verify the PHP runtime with your host.

Does PHP-FPM mean I am safe?

No. The advisories distinguish attack paths, and the stale-state advisory documents a validated FPM path with application prerequisites. Check the runtime rather than relying on the handler name.

Does a scanner’s version warning prove vulnerability?

No. Treat it as a finding to verify against the actual package and vendor backport documentation. Equally, a hidden or missing version header does not establish safety.

Do the emergency releases fix the two PHP2Shell CVEs?

PHP lists them as fixed releases for the original pair. Also review the separate 23 October session upload progress notice described above.

Does an attack attempt mean my website was hacked?

No. Distinguish probing, blocked requests, attempted exploitation and confirmed compromise. Use evidence from your own environment to decide the response.

What should I ask my hosting provider?

Ask: “Which PHP build serves each of my sites? Does it fix both CVEs? When were its workers restarted? Are staging, containers and bundled runtimes included? Has the 23 October follow-up been assessed?”

Getting help with your DigitalBerg deployment

Use the DigitalBerg knowledgebase and your existing support channel to request a service-specific check. Include your domain, hosting plan and any package evidence you already have; never include passwords or API keys. For longer-term planning, our WordPress VPS guide discusses hosting choices. This article does not certify the patch status of any individual account.

Editorial method: the six supplied articles were reviewed alongside PHP’s two technical advisories, its dated notices and Amazon’s primary telemetry report. Sources were checked on 23 October 2026. Follow the live vendor advisories if subsequent guidance changes.