PHP2Shell fix: CVE-2026-109618 and CVE-2026-109619

Two critical bugs in PHP web runtimes (disclosed 21 October 2026, after an advance notice on 20 October; php.net) can allow unauthenticated remote code execution. Here is what they are, who is affected, how to fix them, and how to check your site.

Last updated: · Current status: Fix available

Patched PHP releases (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) are out. Servers still on older builds, or on end-of-life PHP 8.1 and below without a backport, remain exposed. On 23 Oct PHP also advised session.upload_progress.enabled=0 for a narrower third vector (CVE-2026-115560).

We re-check this status every day against our knowledge base and the CISA Known Exploited Vulnerabilities catalog (last check 25 Oct 2026, 01:39 UTC).

What happened

The PHP project released security updates addressing two critical issues, often discussed together as PHP2Shell:

  • CVE-2026-109618 (CVSS 9.2) — remote code execution via memory corruption during out-of-memory (OOM) handling. PHP uses longjmp() when a request exceeds memory_limit; cleanup can then touch uninitialized request memory.
  • CVE-2026-109619 (CVSS 9.2) — remote code execution via stale global state. State owned by one request can survive after its memory is freed; a later request on the same worker may use that stale state.

Every PHP installation that serves web requests is in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates the risk highest for Apache mod_php, where a demonstrated exploit works with one unauthenticated request before any application code runs. Technical details and early proofs of concept began circulating after the fix release, so patching promptly matters.

Update, 23 October 2026: PHP published an informational advisory about a third, much narrower RCE vector (CVE-2026-115560) in session upload progress. It needs an unusual setup: an application that switches session.serialize_handler to php at runtime with ini_set() before session_start(), with upload progress still enabled. PHP will fix it in the next regular release and suggests setting session.upload_progress.enabled=0 until then (php.net, 23 Oct 2026).

Who is affected

  • PHP 8.2 before 8.2.35
  • PHP 8.3 before 8.3.36
  • PHP 8.4 before 8.4.27
  • PHP 8.5 before 8.5.12
  • PHP 8.1 and older — end-of-life and no longer receive official PHP releases. Given the severity, the PHP security team published minimal source-backports for PHP 7.4, 8.0 and 8.1 for people building from source (php.net, 21 Oct 2026 advisory); otherwise use your distro/LTS vendor backport or migrate to a supported branch.

CMS and app stacks (WordPress, Laravel, Magento, custom PHP sites, etc.) are exposed through the PHP runtime they run on — not because of an application-specific bug.

How to fix it

  1. Upgrade PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or newer) on every internet-facing host.
  2. If you cannot patch immediately, take internet-facing PHP offline or off the public internet until you can (the advice of CISA and CERT-EU). PHP lists partial measures that reduce specific attack paths but do not make a server safe: enforce memory_limit=-1 administratively (for example with php_admin_value), keep post_max_size low, set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0, then restart every worker. A WAF may help for a while but does not replace the update.
  3. Restart PHP workers after upgrading so old processes are gone.
  4. Confirm the running version (php -v on the server, or check that X-Powered-By no longer advertises a vulnerable build — better: remove that header entirely).

How to check if you are affected

On the server, run php -v and compare with the fixed versions above. From outside, a careful scan can spot an advertised PHP version in response headers and flag known-vulnerable builds. Our free Safe Scan does that passively (no exploit attempts). A Deep / Active Scan also runs nuclei templates (including coverage for these CVEs) after you prove you own the domain.

Run free Safe Scan Order Deep Scan (US$45)

What our scanner reports

  • Safe Scan: reads X-Powered-By / related headers and marks PHP2Shell as fail, pass or “not advertised”.
  • Deep Scan: nuclei community templates plus our local version fingerprint template; report lists template engine version and template update date.

We do not claim a clean scan means you are unhackable. It means these automated checks did not see a vulnerable advertised version / matched findings at the time of the scan.

References

Authorization is required for any scan. See our terms.