PHP2Shell: two critical PHP vulnerabilities, from discovery to patch

On October 21, 2026, the PHP team released emergency updates: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These versions fix two critical vulnerabilities, nicknamed PHP2Shell, that allow remote code execution without authentication. Here is what happened, and what to do.

The flaw is in PHP, not in your code

• CVE-2026-109618 : if a request hits the memory_limit at the wrong moment, PHP can leave internal data half-initialized, then treat it as valid. The result: memory corruption.
• CVE-2026-109619 : a badly timed fatal error can leave internal state pointing to memory from a previous request. A later request handled by the same worker can then reuse that already-freed memory.

Both are rated 9.2 on CVSS v4.0. On Apache with mod_php, a single request can trigger the attack before the application even runs. Code execution was also confirmed on PHP-FPM through some application code paths.

Because the defect lives in the interpreter, it affects everything running on it: WordPress, Laravel, Drupal, Magento, Joomla and in-house applications. No line of application code can protect against it.

Every version is affected, and some will never be fixed

The problem goes back at least to PHP 5.4. Every installation serving web requests is exposed: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

Branch	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and earlier	No official fix (end of life)

From discovery to patch: a two-year story

Date	Event
2024	PHP's first external security audit in years, carried out by Quarkslab and funded by the Sovereign Tech Agency through OSTIF. While fixing one of the reported issues, a PHP core developer spots the first signs of the memory-handling defect. An exploit is considered in theory, but no concrete vector is found.
2024 – 2026	Several fixes are explored, but each comes at a cost: compatibility breaks, denial-of-service risk, or changes forced on third-party extensions. Work stops and restarts for months. The PHP Foundation itself acknowledges a structural failure, tied to its decision process and lack of resources.
Early 2026	PHP's code is scanned with AI tools, as part of a partnership with Alpha-Omega.
May 2026	The PHP Foundation creates a team dedicated to ecosystem security.
July 30, 2026	Security firm Calif starts an audit of PHP.
August 11, 2026	Calif reports an unconditional remote code execution with the same root cause as the defect spotted in 2024. OpenAI reports the same root cause the same day. Fixing it becomes the top priority.
August 24 and September 18, 2026	Wiz, then OpenAI, report additional attack vectors.
October 20, around 15:00 UTC	The CVE IDs leak on forums and social media, with a wrong release time and an incorrect score of 10.0. No technical details leak.
October 20, 19:30 UTC	PHP publishes a pre-announcement and moves the release from October 22 to October 21.
October 20, around 20:00 UTC	Calif mistakenly publishes a demo video. Deleted, it gets copied and speeds up exploit development.
October 21, 07:41 UTC	Chainguard breaks the embargo by publishing patched images, making it possible to study the fix before its official release.
October 21, 14:00 UTC	Official release of the fixed versions.
October 21, after the release	watchTowr, Patchstack and Aikido (citing Cloudflare) report exploitation attempts. PHP has not confirmed exploitation, and CISA has not added the CVEs to its catalog of exploited vulnerabilities.

Exploit tools are circulating. Assume that exposed servers will be scanned.

Patching: updating is the only real protection

Several workarounds have circulated, such as disabling session.upload_progress. According to watchTowr, changes to .ini files are not enough to prevent exploitation.

Example on Debian/Ubuntu with Ondřej Surý's packages (replace 8.4 with your version):

1. List installed versions and check the active one

ls /etc/php
php8.4 -v

2. Check that the fixed package is available

sudo apt-get update
apt-cache policy php8.4-fpm

The Candidate line should show the fixed version. If not, the repository is not updated yet: wait and try again.

3. Upgrade every package for that version, keeping your configuration

sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Repeat for every installed version, even those no site uses.

4. Restart long-running PHP processes

PHP-FPM restarts with the update, but command-line workers do not. For a Laravel application:

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

5. Check that the fix is active

php8.4 -v
php-fpm8.4 -v

Ubuntu's automatic security updates do not cover third-party PHP repositories: the update has to be run manually.

Security advice to follow

Before updating

• Take inventory of every server, container and VM running PHP, including forgotten internal tools.
• Handle internet-facing servers first , then internal ones.
• Take a snapshot or backup so you can roll back if something goes wrong.

Depending on your environment

• Docker : rebuild images from a patched base image, then redeploy containers. Updating a running container is not enough.
• Shared hosting : check the PHP version in the control panel and contact your host if the fix has not been applied yet.
• PHP 8.1 or older : migrate to a supported branch, or check that your distribution has backported the fix into its package.

While waiting for the fix

• Enable, if possible, web application firewall (WAF) rules. Cloudflare, for example, added emergency rules. This is a temporary layer of protection, not a replacement for the update.
• Disable expose_php so the PHP version does not appear in HTTP headers. This makes it harder for attackers to spot you, without fixing the flaw.

After updating

• Monitor logs and processes: a PHP process spawning a shell or system commands is a red flag.
• Look for signs of compromise on servers exposed before the fix: recent or unknown PHP files (webshells), new scheduled tasks, unusual outbound connections.
• If in serious doubt, rebuild the server from a clean backup and rotate secrets (passwords, API keys, .env file).

AI has changed the scale of the problem

The defect had been spotted as early as 2024 without a concrete exploitation path. Recent audits, backed by AI tools, revealed its real impact. According to Wiz, frontier AI models sharply reduced the effort needed to turn this old flaw into an exploit. The PHP Foundation also notes a sharp rise in reports, and points out that the language's security still relies on a handful of funded developers.

What now?

Update your internet-facing servers first, then the rest. And ask yourself one simple question: how many of your servers still run a PHP version that will never receive another fix?

---

Sources: PHP Foundation · Laravel Forge · php-net.pro · watchTowr · Patchstack · Help Net Security · SOCRadar