PHP2Shell: critical PHP vulnerabilities, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35

On October 21, 2026 the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 under CVSS v4.0 and allow code execution on the server without authentication. The pair has been nicknamed PHP2Shell. The PHP team urges everyone to update immediately.

What happened

According to Habr, the details leaked before the planned disclosure, and some administrators took their sites offline to apply the fixes by hand, including the Internet Archive and the .de domain registry. Sansec expects mass exploitation to start within 15 minutes of the patches being released.

• CVE-2026-109618, RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat that invalid data as valid.
• CVE-2026-109619, RCE via stale global state. Request-owned state can survive after its memory has been freed, and a later request on the same worker may use it before normal initialization resets it.

Who is at risk

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. That includes sites on Magento, Laravel, WordPress, OpenCart and any other PHP platform.

What to do now

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so check your vendor or hosting provider for updated packages.
2. PHP 8.1 and older no longer receive updates from the PHP project. The team published minimal source backports for 7.4, 8.0 and 8.1 in php-src; moving to a supported version is the safer option.
3. Restart every PHP worker after the update and check that the new version is running.

If you cannot update right away

The PHP team lists interim measures. They block the known attack paths but do not make an installation safe: only an update fully removes the vulnerabilities.

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration), and a low post_max_size of 8M, or 32M if file uploads are needed, with upload_max_filesize below it. Enforce limits on request size, field, header and multipart part counts at the web server or proxy too, including for requests without a Content-Length. Do not use RLIMIT_AS or RLIMIT_DATA instead.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration (not via ini_set() or .user.ini), and on PHP 8.5 also fatal_error_backtraces=0; then restart every worker.

We have been working with PHP and Magento for more than ten years. We will check which PHP version runs on your server and how, update it or apply the interim measures, and move old branches to a supported version, with a staging environment and a rollback plan.

Sources: PHP security advisory, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, Habr news (in Russian).