PHP2Shell Fixes Are Out: Patch PHP 8.2, 8.3, 8.4 and 8.5—Legacy Options Explained

Update checked 22 October 2026 at 07:35 Beirut time. This replaces the pre-release briefing originally published on 21 October. Official fixes and technical advisories are now available. The earlier uncertainty about CVE identifiers and remote code execution is resolved; “no patch yet” and “no exploitation reported” are no longer appropriate summaries. [1][2][3][10]

If your project runs PHP, the task is now to deploy a verified fix—not wait for the announcement.

PHP’s security advisory confirms that PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fix two critical vulnerabilities that can allow unauthenticated remote code execution, each rated CVSS v4.0 9.2. The fixes were announced on 21 October; this guide was rechecked the following morning. [1][2][3]

Which version should you install?

These are the first fixed upstream releases in their respective branches, not interchangeable version requirements: [1][2][3][4]

PHP 8.2: update to 8.2.35, or a later security-maintained release in that branch.
PHP 8.3: update to 8.3.36, or a later maintained release in that branch.
PHP 8.4: update to 8.4.27, or a later maintained release in that branch.
PHP 8.5: update to 8.5.12, or a later maintained release in that branch.

For a supported branch, an in-branch update can be the fastest validated response. Do not turn a narrow security deployment into an unrelated framework rewrite unless your application has no viable alternative.

Distribution packages are a separate case. Ubuntu or another vendor may backport these fixes while retaining an older base PHP version. Verify the complete package revision, repository and vendor advisory. A version string such as 8.3.6 by itself does not prove that the package is vulnerable—or patched. [1][8]

What PHP now confirms

The official notice treats all PHP installations serving web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, with a demonstrated unauthenticated attack before application code runs. This does not mean every stack has an identical exploit path. [1][2][3]

CVE-2026-109618 — RCE via OOM corruption: out-of-memory handling can interrupt a request while internal memory is only partly initialized; cleanup can then use invalid state. [2]
CVE-2026-109619 — RCE via stale global state: a worker can retain references to request-owned memory after it has been freed, and a later request can consume that state before normal initialization. The advisory documents multiple paths with different application and configuration conditions. [3]

Do not assume a login screen, a framework upgrade or PHP-FPM instead of mod_php makes the runtime safe. Also do not confuse this advisory’s web-facing scope with proof of a remote exploit against a genuinely CLI-only workload. Inventory both: workers and scheduled commands still need the correct runtime, but exposure depends on how the system is used.

Has exploitation been observed?

Cloudflare reports observing attack traffic targeting its customers, including payload changes intended to bypass protections. That is a direct provider observation of attacks—not proof that every attempt succeeded or that a particular server was compromised. [10]

The earlier “none reported” wording reflected pre-release observations. It must not be used now as reassurance. Patch promptly, review telemetry, and investigate suspected compromise separately from patch installation. Updating PHP does not remove a web shell or reverse prior data exposure.

PHP 7.4, 8.0 and 8.1: a correction to the earlier briefing

The PHP project still does not restore normal support for these branches. However, its official notice now links exceptional source backports, tested by PHP developers, for: [1][7]

These are source branches, not new numbered upstream releases or automatically installed binary packages. Applying a complete backport requires a suitable build/package process, extension compatibility testing and verification of the exact artifact deployed. Prefer a documented vendor package when available; a source build on a production server is not a shortcut. [1][7]

For PHP 7.4 projects, the practical choices are:

Move to a supported branch, with application and dependency testing.
Use a vendor-maintained patched package where your repository and support entitlement explicitly cover these CVEs.
If migration cannot be completed immediately, have a qualified packaging team evaluate the linked source backport as a temporary bridge—not a declaration that the rest of an EOL runtime is secure.

PHP 7.4’s upstream support ended 28 November 2022. Fixing these two flaws does not fix every other unsupported-runtime risk. [13]

Ubuntu: backports can protect older-looking versions

Canonical’s advisory lists fixed revisions, including these examples: [8]

Ubuntu 20.04, PHP 7.4: 7.4.3-4ubuntu2.29+esm5 through the relevant ESM coverage.
Ubuntu 22.04, PHP 8.1: 8.1.2-1ubuntu2.28.
Ubuntu 24.04, PHP 8.3: 8.3.6-0ubuntu0.24.04.13.
Ubuntu 26.04, PHP 8.5: 8.5.4-0ubuntu1.5.

These revisions apply to the named Ubuntu release and package source, not arbitrary PPAs, other distributions or container images. A vendor’s later fixed revision may supersede the one listed. Confirm repository origin and any required Ubuntu Pro/ESM entitlement; do not compare only the first three PHP version components. [8]

Update instructions: choose the path that matches your deployment

1. Inventory the actual web runtime before changing packages

Record every application, server/replica, PHP branch, full package revision or image digest, loaded extensions and configuration. Include:

FPM pools or the Apache module serving the website.
CLI jobs, queue workers, schedulers and long-running application servers.
Native/proprietary extensions, framework or CMS plugins and the deployment’s package repository.

php -v checks the binary selected by that shell. It does not prove that the website or all workers use it.

# CLI inspection only; repeat inside each relevant container or host.
php -v
php --ini
php -m
php -r 'printf("PHP=%s SAPI=%s binary=%s\n", PHP_VERSION, PHP_SAPI, PHP_BINARY);'

Inspect the web-server/FPM configuration and processes too. If an internal diagnostic is needed, authenticate and remove it after use; do not expose a public phpinfo() page.

2. Back up, stage and prepare rollback

Confirm a recent backup and a tested restore path for database, uploads, configuration and deployable artifacts. Protect secrets in backups. Test login, permissions, payments/refunds, uploads, webhooks and queued/scheduled jobs on staging with sanitized data and disabled real notifications.

A rollback can restore availability and restore the vulnerability. If necessary, treat it as a temporary incident decision with isolation or other controls, not a completed remediation.

3. Debian/Ubuntu package example: an existing PHP 8.3 FPM installation

This example is not a universal patch command. It assumes the named packages are already installed from a trusted repository that has published fixes. Use your distribution’s advisory, actual branch and package list. Do not add an unreviewed repository or perform a surprise branch switch. [8][9]

# Refresh package metadata, then inspect installed and candidate revisions/origins.
sudo apt-get update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
dpkg-query -W -f='${Package} ${Version}\n' \
  php8.3-fpm php8.3-cli php8.3-common

# Preview the change before approving it.
sudo apt-get --simulate install --only-upgrade \
  php8.3-fpm php8.3-cli php8.3-common

# Run only after confirming the candidate includes both fixes.
sudo apt-get install --only-upgrade \
  php8.3-fpm php8.3-cli php8.3-common

Include the other installed branch-specific extensions in your reviewed update plan. Check the simulation for removals, held packages, unavailable fixes and dependency changes. If the candidate is still vulnerable, stop: refreshing the repository or running a command is not evidence of remediation.

For Ubuntu 24.04’s own packages, the documented fixed PHP 8.3 revision is 8.3.6-0ubuntu0.24.04.13 or an applicable later revision. For upstream-versioned third-party packages, look for 8.3.36 or their documented backport. Do not apply the Ubuntu revision test to a different package source. [8]

After installation, test the matching FPM configuration, restart the actual service and verify health in your maintenance/rolling-deployment plan:

# Only for an installation actually using the standard PHP 8.3 FPM binary/unit.
sudo php-fpm8.3 -t &&
  sudo systemctl restart php8.3-fpm &&
  sudo systemctl is-active php8.3-fpm

This may interrupt requests; use draining or a maintenance window appropriate to the service. mod_php requires the corresponding Apache process replacement; FrankenPHP, LiteSpeed and other deployments need their own vendor procedure. Gracefully recycle queue workers and other long-running PHP processes too. Verify all replicas, not only the machine on which you ran the package manager.

4. Laravel Forge: unattended updates are not enough

Forge explicitly says its automatic security updates do not patch PHP, because it uses a separate PHP package source. In the server dashboard, open the PHP tab, select the version’s dropdown and choose Update PHP X.X. Repeat for every installed PHP version on every server; manual update instructions are also documented. [9]

Verify the actual installed revision and restart status afterward. Forge’s guidance is for Forge-managed packages, not evidence that Ubuntu’s official ESM package or PHP’s exceptional source backport is unavailable. Prefer the relevant maintainer’s current advisory if older secondary guidance conflicts. [1][8][9]

5. Containers, managed hosting and Windows

Containers: obtain a patched base image from your trusted publisher, rebuild derived images, verify the PHP/package revision, and roll out the new image digest to every replica. Changing a tag in configuration does not replace already running containers. Avoid installing an ad hoc runtime patch inside one disposable replica.
Managed hosting: ask for the exact fixed revision and confirmation of the site runtime and worker restarts. A control-panel label showing only 8.3 is insufficient.
Windows/source installations: use the official downloads and matching installation procedure; check the selected build, extensions and server integration, then replace running processes. Source downloads and platform links are on PHP’s downloads page. [1][5]

6. Check dependencies without mistaking Composer for a PHP scanner

In the candidate environment, with an appropriate Composer installation: [12]

composer validate --strict
composer audit --locked --no-dev
composer check-platform-reqs --lock --no-dev

These check project metadata, package advisories and runtime/extension requirements. A green Composer audit does not prove the PHP interpreter is patched. Run business tests and verify the actual runtime separately. Do not run an uncontrolled composer update on production as a supposed fix for these engine vulnerabilities. [12]

Temporary mitigations: official, incomplete and operationally risky

PHP is explicit: only updating is a complete solution. Its published mitigations reduce specific attack paths, not all variants. If no patch is immediately deployable, use the official advisories with a qualified operator and consider restricting or isolating exposure. [1][2][3]

OOM-corruption path

PHP recommends administratively enforcing memory_limit=-1 to remove the controllable per-request memory-limit failure used by a confirmed path. This is not a general “make PHP safer” setting: underlying allocation failures can still reach vulnerable code, and removing the PHP cap creates availability/denial-of-service risk. Use conservative request limits, monitored capacity and a container/cgroup boundary; do not apply it blindly on a shared host. PHP warns not to substitute RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure. [1][2]

The notice also recommends low post_max_size values—8M without required uploads, 32M when uploads are needed—with upload_max_filesize below that limit, plus frontend enforcement of decoded-body size and multipart/input complexity. Validate application needs, including requests without usable Content-Length. These are layered exposure reductions, not patch substitutes. [1][2]

Stale-global-state paths

PHP recommends session.upload_progress.enabled=0, configured before request parsing, and restarting every worker. It warns that ini_set() and FPM .user.ini are not sufficient for this purpose. On PHP 8.5, fatal_error_backtraces=0 blocks a confirmed backtrace path; it does not cover every variant. Invalid/deprecated per-request settings that emit early diagnostics also need review—merely hiding errors is not protection. [1][3]

Prefer a validated package update over accumulating risky configuration workarounds. Keep them documented and reassess them after patching.

WAF protection is an extra layer, not proof the origin is fixed

Cloudflare reports deploying php2shell protections for its free and paid WAF customers and observing attack traffic. Follow its guidance, review coverage and make sure the origin cannot be reached through an unprotected route. A WAF does not replace patching PHP or establish that a host was never compromised. [10]

Verification and incident-response checklist

Before closing the task, retain evidence of:

The applicable fix: fixed upstream release or vendor package revision covering both CVEs, plus image/source identity where relevant.
The deployment scope: all web runtimes, replicas, FPM/Apache processes, long-running workers and scheduled binaries.
Process replacement: configuration validation and restart/recreation completed safely, with effective web-runtime readback rather than CLI output alone.
Business behavior: authentication, authorization, checkout/refunds, uploads, APIs, webhooks and jobs still work; no duplicate financial actions or unexpected errors.
Threat review: investigate suspicious PHP child processes, new/modified executable files and unusual outbound traffic against your baseline. These are leads, not automatically proof of php2shell. Preserve evidence and follow incident response if compromise is suspected; patching alone is not cleanup.
Follow-up: record owner, time, tested rollback and ongoing monitoring. Avoid public exploit tests against production or claims of safety based solely on HTTP 200.

Maintenance deadlines still matter

As of this update, PHP 8.2 has security support through 31 December 2026; 8.3 through 31 December 2027. 8.4 is actively supported through 31 December 2026 and receives security fixes through 31 December 2028. PHP 8.5 has active support through 31 December 2027 and security support through 31 December 2029. [6]

Patch now, then schedule migration where the support runway is short. A successful emergency patch does not remove the need to retire an unsupported framework or runtime.

What changed from the earlier post?

The Hacker News report remains linked as the early PHP2Shell coverage you asked to include. Where its pre-release wording or other older coverage conflicts with the newly published advisory, the official PHP notice and the relevant package maintainer take precedence. [1][8][11]

This update replaces speculation with confirmed CVEs, fixed versions, official mitigation limits, vendor backports and a dated provider report of attacks. I did not upgrade readers’ servers, run an exploit or verify their production systems for this article.