PHP2Shell, explained.

At a glance

• Vulnerabilities: CVE-2026-109618 and CVE-2026-109619, publicly known as PHP2Shell, published by the PHP security team on 21 October 2026.
• Severity: critical, rated 9.2 (CVSS v4.0) each. Both can allow remote code execution without authentication.
• Affected: PHP installations that serve web requests. The researchers found affected releases dating back to PHP 5.4.
• Fix: update PHP. The PHP project states that there are no complete mitigations and updating is the only safe choice.

What the vulnerabilities are

Both flaws are memory-safety bugs in the PHP runtime, not in WordPress, Drupal, Laravel or other applications built on it. A website can be exposed even when its own code and plugins are fully up to date.

• Out-of-memory corruption, CVE-2026-109618: running out of memory can interrupt PHP while internal request data is only partly initialised. Request cleanup can then treat that invalid data as valid.
• Stale request state, CVE-2026-109619: internal state that belongs to one request can outlive the memory behind it. A later request handled by the same PHP worker may use that stale state, which can expose worker memory or lead to code execution.

The researchers demonstrated unauthenticated remote code execution against WordPress and Drupal, and Joomla for the first issue. A minimal “Hello World” application on an affected runtime can also be exposed.

Who is affected

According to the PHP advisory, the issues affect all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php carries the highest risk: a demonstrated exploit triggers the attack with an unauthenticated request before any application code runs.

PHP 8.1 and older no longer receive updates from the PHP project. Minimal source backports for PHP 7.4, 8.0 and 8.1 are linked from the advisory, but older runtimes are best moved to a supported version.

Fixed versions

Earlier releases in each supported branch should be treated as vulnerable.

PHP 8.2 reaches end of life on 31 December 2026.

Distribution packages

Linux distributions received the patches in advance and publish fixed packages under their own version numbers. A distribution package can be fixed even when its version looks older than the upstream release. On Ubuntu 24.04 LTS, for example, the fixed package is 8.3.6-0ubuntu0.24.04.13, not 8.3.36.

Check your own distribution’s security notice for the exact package versions. The PHP advisory also asks users of the remirepo repository to switch to distribution packages or build from source, because that repository did not have updates on release day.

Interim mitigations

If you cannot update immediately, the PHP advisory lists settings that reduce exposure to specific attack paths. They do not make an installation safe, and they must be applied in php.ini, the PHP-FPM pool or the server configuration, followed by a restart of every PHP worker.

• Disable session upload progress: session.upload_progress.enabled = 0. Do not rely on ini_set() or .user.ini files.
• Remove the PHP memory limit with memory_limit = -1, set so that applications cannot override it, and use a container or cgroup memory limit instead. Do not use RLIMIT_AS or RLIMIT_DATA; they can trigger the vulnerable path.
• Limit request size, for example post_max_size = 8M, or 32M when uploads are required, and enforce request limits at the web server or proxy.
• On PHP 8.5, set fatal_error_backtraces = 0.

Hiding errors does not help. Treat these settings as a short bridge to the update, not as a fix.

Web application firewalls

Cloudflare deployed managed WAF rules for PHP2Shell before public disclosure, including on its free plan. A WAF is a useful extra layer while you update, but attackers have been seen changing payloads to avoid detection, and updating website code or plugins alone does not fix a runtime flaw. Update PHP even when a WAF is in place.

After updating

• Restart PHP: restart PHP-FPM, Apache or the PHP application server so that every worker loads the fixed code.
• Check the runtime that serves the website: the command-line PHP version can differ from the version that handles web requests, and servers often run several PHP versions side by side.
• Check every server and hosting account: staging sites, old installations and secondary servers are easy to miss.
• Review limits: the fix adds a hard memory limit that ends the process when reached, so review memory and request-size settings for legitimate heavy requests.

On managed hosting, ask your provider to confirm that the fixed runtime is in place.

Signs worth investigating

The researchers list signals that deserve a closer look. On their own, they do not prove that a server was attacked.

• Unusually large or malformed PHPSESSID cookies.
• Multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
• Unexplained PHP worker crashes.

If you suspect a compromise, updating PHP does not remove anything an attacker may have left behind. That requires a separate investigation.

How we can help

Our verification identifies the PHP runtime that actually serves your website, checks its vendor patch status and gives you written findings with a clear next step. Nothing on your server changes until we agree the scope with you.

Sources

• PHP security advisory, 21 October 2026
• PHP2Shell research summary
• Ubuntu security notice USN-8948-1
• Cloudflare: WAF protection for the PHP vulnerabilities

Reviewed 22 October 2026. This summary is general information, not advice about your systems. Refer to the PHP advisory for the latest details.