Skip to content
PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)

PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)

Hacktron.Ai •hacktron • October 22, 2026

Status: Patched · Exploitation attempts reported Severity: Critical, CVSS v4.0 9.2 (PHP security team)

PHP2Shell is two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, that let an unauthenticated attacker run code on servers that use PHP to handle web requests. PHP released fixes on 21 October 2026. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker.

Supported branches: PHP 8.2, 8.3, 8.4 and 8.5 are affected before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 respectively, when serving web requests. PHP 8.6.0 release candidates before RC4 are also affected.

End-of-life branches: PHP 8.1 and older no longer get upstream releases. Independent analysis traces the earliest affected code path to PHP 5.4.0; PHP has not stated a full affected range.

Apache with mod_php: highest risk, according to PHP. Remote code execution is confirmed for both CVEs, and for CVE-2026-109618 with default input and memory limits.

PHP-FPM: CVE-2026-109619’s session upload progress path was validated as RCE on a normal dynamic pool. For CVE-2026-109618, source analysis says FPM is susceptible, but no complete exploit has been demonstrated.

FrankenPHP and LiteSpeed (LSAPI): susceptibility is based on source analysis only. No exploit has been validated, and PHP says this does not make them immune.

List every PHP runtime that serves web traffic: main apps, internal tools, legacy apps, and PHP pulled in by container base images or OS packages.

Check the version that actually serves requests. The CLI ( php -v ) can be a different build from PHP-FPM or Apache’s mod_php.

For distribution packages, compare against your distribution’s advisory. Backported fixes may not change the upstream version number.

After updating, rebuild and redeploy images, restart PHP workers, and confirm the new version is serving requests.

Review activity from at least 17 October 2026. Look for new or modified PHP files, web shells, unexpected admin users and unusual outbound connections. Also look for unexpected child processes or shell commands launched by PHP or the web server: exploitation does not need to leave a web shell on disk.

In request logs, AWS suggests looking for multipart POST requests containing the PHP_SESSION_UPLOAD_PROGRESS field.

Update PHP to a fixed version. If you use your Linux distribution’s PHP packages, follow its security advisory. PHP says updating is the only complete fix.

If you can’t update straight away, PHP’s advisories list settings that reduce the risk but don’t remove it. Set them administratively, so no pool, directory or app setting can override them: CVE-2026-109618: set memory_limit=-1 ; keep post_max_size conservative and enforce request size at the frontend; lower max_input_nesting_level and bound the number of input variables, multipart parts and uploads; block multipart requests at the frontend if your app doesn’t use them. Don’t use RLIMIT_AS or RLIMIT_DATA , which can trigger the vulnerable path. CVE-2026-109619: set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0 . If performance allows, PHP also suggests pm.max_requests=1 .

CVE-2026-109618: set memory_limit=-1 ; keep post_max_size conservative and enforce request size at the frontend; lower max_input_nesting_level and bound the number of input variables, multipart parts and uploads; block multipart requests at the frontend if your app doesn’t use them. Don’t use RLIMIT_AS or RLIMIT_DATA , which can trigger the vulnerable path.

CVE-2026-109619: set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0 . If performance allows, PHP also suggests pm.max_requests=1 .

Restart every PHP worker after updating or changing settings.

PHP 7.4, 8.0 and 8.1: no upstream release. PHP published minimal source backports for people who build from source. Distributions and LTS vendors may ship patched packages.

PHP 5.4 to 7.3: end of life. Migrate, or get a backport from a supported vendor.

AWS says it is unclear whether the attempts it observed would have succeeded against real systems, and recommends investigating from at least 17 October. As of 22 October, no successful compromise of a real-world victim has been publicly documented.

CVE-2026-109618, RCE via out-of-memory corruption: PHP exits out-of-memory errors with longjmp() . If memory runs out while request state is only partly initialised, shutdown can read or branch on invalid memory. An attacker can reach this through request input handling, including multipart parsing.

CVE-2026-109619, RCE via stale global state: request-owned data can stay in worker globals after the request’s memory is freed, and a later request on the same worker can use it before normal initialisation. Confirmed early consumers are INI diagnostics and session upload progress. Impact includes use-after-free, memory disclosure and remote code execution with the web worker’s privileges.

Both: unauthenticated and network-reachable, CVSS v4.0 9.2 ( AV:N/AC:H/AT:P/PR:N/UI:N ). Exploit reliability depends on the build, extensions, frontend and memory allocator layout.

22 October 2026: Initial publication. Status: patched, exploitation attempts reported. Not listed in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.21).

PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)

PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)

PHP security advisory and release announcements, 20–21 October 2026

AWS: Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure

Tenable: PHP2Shell FAQ (earliest affected code path, PHP 5.4.0, citing Calif’s analysis)

CISA Known Exploited Vulnerabilities catalog

Credits, from PHP’s advisories: reported by sagitzadik-wiz, tomash-areion, lcfr-hax and amyb-oai; fixed by arnaud-lb, iluuu1994, bukka and ndossche.