PHP2Shell: two critical PHP vulnerabilities and what server administrators should do

On October 21, 2026, the PHP Security Team released patches for CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both vulnerabilities can allow unauthenticated remote code execution.

The issues affect the PHP runtime handling HTTP requests and do not necessarily depend on a flaw in application code. PHP considers Apache with mod_php at particularly high risk, while also listing PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

The first issue involves memory handling during cleanup after out-of-memory errors. The second involves request-owned global state that may remain accessible after its backing memory has been freed.

The fixed versions are **PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35**. Administrators should identify the runtime actually serving web requests and deploy the appropriate update.

Older branches need a supported vendor patch or migration. On systems with backported security fixes, the displayed PHP version alone may not establish patch status.

Before updating, create and verify backups of application files and databases. Afterwards, test the application, confirm the active PHP release and make sure affected processes have restarted.

Review HTTP and PHP error logs, unexpected file changes and suspicious processes, including activity from before the patch release. Applying an update does not remove changes introduced by an attacker before remediation.

If immediate patching is impossible, the PHP Security Team documents temporary risk-reduction measures. They require configuration-specific assessment and do not cover every exploitation path. Updating remains the only complete fix.

Amazon Threat Intelligence reported observing exploitation attempts through its MadPot infrastructure as early as October 17, 2026, four days before public disclosure.

These observations do not establish how many production servers were successfully compromised. The NCSC-NL maintains operational information for defenders.

For organizations operating PHP services, the practical priorities are identifying exposed instances, verifying patch status and retaining the evidence needed to investigate possible incidents.