Two critical vulnerabilities in PHP are prompting urgent patching after exploit code became publicly available and security researchers reported live exploitation attempts. Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively dubbed PHP2Shell, the flaws can let an unauthenticated attacker execute arbitrary code on a server processing web requests.
The PHP development team rates both vulnerabilities 9.2 under CVSS 4.0, or critical. CVE-2026-109618 involves corruption associated with out-of-memory handling, while CVE-2026-109619 involves stale global state left behind after fatal-error processing. In both cases, specially crafted requests can exploit PHP’s internal error and memory-handling paths, potentially resulting in code execution with the privileges of the web-server account.
The exposure is broader than a single PHP application framework. The PHP project says affected deployments include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Fixed releases published Oct. 21 are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end-of-life and do not receive regular upstream security updates, leaving operators on those branches dependent on a distributor backport or an upgrade to a supported release.
Exploitability has moved beyond a theoretical concern. Sophos reported publicly available proof-of-concept code and multiple exploit attempts consistent with PHP2Shell activity, including one successful exploitation. That report does not establish a named threat actor or a broad, coordinated campaign, but it means defenders should treat internet-facing PHP services as active intrusion targets rather than wait for attacks to be confirmed in their own logs.
Organizations should inventory PHP versions across web servers, containers, hosting platforms and bundled products, then update to the applicable fixed release through their operating-system or vendor channel. After patching, teams should review web-server, PHP-FPM and application logs for unusual requests, worker crashes, unexpected child processes, modified files, new credentials and outbound connections. Because successful exploitation may provide control under the web-server identity, incident responders should investigate the host and adjacent systems rather than assuming a routine package update removes all attacker persistence.
The PHP project says there is no complete substitute for updating. Configuration workarounds described in its advisory, including disabling affected session-upload paths or controlling memory and fatal-error settings, may block specific exploitation paths but do not address every variant. Operators unable to patch immediately should restrict public access, place the service behind a carefully monitored protective layer and accelerate migration from unsupported PHP branches.
