P1R4T3Security
HUSign inRequest a proposal
Menu
Threat analysis · Web · PHP

PHP2Shell: critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619)

Unauthenticated remote code execution in every web-facing PHP deployment, exploited before the fix was released. Who is affected, what to do and what to look for in the logs.

3 November 2026 · P1R4T3 Research

In short

On 21 October 2026 the PHP project shipped an out-of-band security release for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, collectively known as "PHP2Shell"). Both allow unauthenticated remote code execution and are scored 9.2 on CVSS v4.0. The attack takes place in PHP's request parser, before any of the application's own code runs, so login screens, some WAF rules and application-level protections do not stop it. On 26 October CISA added both flaws to its Known Exploited Vulnerabilities (KEV) catalog.

Who is affected?

  • Every web-facing PHP deployment before 8.2.35, 8.3.36, 8.4.27 and 8.5.12: Apache module (mod_php), PHP-FPM, php-cgi, LiteSpeed and FrankenPHP. The risk is highest with mod_php.
  • PHP 8.1 and older are affected too. For 7.4, 8.0 and 8.1 only minimal source backports and distribution or LTS vendor packages are available; there is no fix for 7.3 and older.
  • Products that embed PHP: web interfaces of NAS devices, firewalls and appliances. Vendors ship their own updates, often without changing the PHP version number, so check the vendor advisory.
  • Many small businesses run WordPress, online shops or custom PHP sites on shared hosting. There, patching is the provider's job, but it is worth asking and checking that the PHP version selected for your site points to a fixed branch.

What is the flaw?

  • CVE-2026-109618 – memory corruption on out-of-memory. If PHP runs out of memory (memory_limit) while building a request, an internal data structure is left half-built and the cleanup code treats it as valid.
  • CVE-2026-109619 – stale state in the next request (use-after-free). Worker-wide state can point to freed memory that belonged to an earlier request. One known path is upload processing (session.upload_progress, enabled by default and active even without session_start()).

A single crafted, unauthenticated HTTP POST request is enough for both. Successful exploitation does not necessarily crash the worker or change the HTTP response, so it can easily go unnoticed in the logs.

Timeline

  • 17 October – AWS reported exploitation attempts four days before public disclosure (Datadog).
  • 20 October – Details leaked early; the PHP project announced an emergency release.
  • 21 October – Fixed versions released; watchTowr's honeypot network observed exploitation the same day.
  • 23 October – PHP disclosed a third, still unpatched flaw (CVE-2026-115560, possible remote code execution in upload progress tracking); details and the fix will come with the next regular release.
  • 26 October – CISA added both CVEs to the KEV catalog, with a 29 October deadline for US federal agencies.

What to do now

  1. Inventory: every PHP runtime counts – servers, container images and devices with embedded PHP. Internet-facing systems first.
  2. Update to a fixed version (8.2.35, 8.3.36, 8.4.27, 8.5.12) or to the distribution or vendor package.
  3. Restart: rebuild container images and restart every PHP worker. As long as an old worker runs, the old code runs.
  4. Interim measures if patching is delayed (these narrow the risk but do not remove it):
    • session.upload_progress.enabled = 0 – closes one path of CVE-2026-109619 and also covers the still unpatched CVE-2026-115560; restart the workers;
    • on PHP 8.5, fatal_error_backtraces = 0;
    • memory_limit = -1 at administrator level, together with request size limits on the reverse proxy and container memory limits;
    • restrict internet exposure of systems that cannot be patched.
  5. Because exploitation started before the fix was released, look for signs of compromise even after patching.

What to look for in the logs

  • PHP "Allowed memory size of … bytes exhausted" errors at Unknown on line 0, i.e. during request initialization – especially several within a short window on the same worker.
  • In Apache, AH00052: child pid … exit signal Segmentation fault (11); unexpected PHP-FPM worker crashes.
  • Multipart fields named PHP_SESSION_UPLOAD_PROGRESS or PHPSESSID where the application does not use them; <?php or |O: in uploaded file names; requests with unusually many parts or deeply nested field names.
  • The strongest signal: a shell or download tool (sh, bash, curl, wget) started by the web server or a PHP worker.

How we help

Our external attack surface monitoring (ASM) matches exposed services against the CISA KEV catalog and alerts when an actively exploited vulnerability appears on a client's systems. If you are not sure where PHP runs in your organization, or you need a compromise assessment after patching, get in touch.

References

This article reflects the situation as of 3 November 2026. Always verify specific version numbers and settings against the official advisories of the PHP project and your own vendor before making changes.