On 21 October 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical bugs in the PHP engine, now nicknamed PHP2Shell. Both can let an unauthenticated attacker run code on a server running PHP, under the right conditions. Both are rated CVSS 4.0 9.2, public proofs of concept exist, and on 26 October CISA added them to its Known Exploited Vulnerabilities catalog.
The bugs sit in PHP itself, below your framework. Updating Laravel, Symfony or WordPress does not fix them: the PHP runtime on the server has to be updated.
The two vulnerabilities
CVE-2026-109618
Memory corruption after running out of memory. When a request hits memory_limit at the wrong moment, PHP abandons the request and leaves half-initialised internal data that its cleanup later treats as valid. Crafted multipart requests can trigger this even within normal size limits.
On Apache with mod_php this can happen before any application code runs, and remote code execution was shown with default settings.
CVE-2026-109619
Use-after-free across requests. A fatal error at the wrong point (memory exhaustion, a timeout) can leave internal state pointing to memory freed at the end of an earlier request. The next request on the same worker can use it.
Code execution was confirmed through session upload progress, which is enabled by default, and on PHP 8.5 through fatal error backtraces.
Who is exposed
- Apache with mod_php: the highest risk, because the first bug can be reached before your application runs.
- PHP-FPM: exposed through application code paths and the session upload path; worker recycling lowers the odds per request but does not remove the risk.
- Also affected: php-cgi, FrankenPHP and LiteSpeed.
- Versions: PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP 8.1 and older no longer receive routine releases; only limited source backports exist.
Fix: update PHP, then restart
- Check the version actually serving web requests, not only the CLI:
php -vcan differ from the Apache module or the FPM pool. - Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later). Distribution packages may carry the fix under an older version number: Ubuntu 24.04, for example, patched
8.3.6-0ubuntu0.24.04.13. Read the package changelog for the CVE IDs. - Restart Apache and every PHP-FPM pool. A worker started before the update still runs the old code in memory.
- If the server was exposed before patching, look for signs of compromise: unexpected PHP files in upload folders, new cron jobs, unknown processes.
If you cannot patch today
These reduce exposure; they do not replace the update. Apply them in php.ini, the FPM pool or the server configuration, never with ini_set() or .user.ini, which come too late, and restart workers afterwards.
session.upload_progress.enabled=0closes the session path of CVE-2026-109619.- On PHP 8.5,
fatal_error_backtraces=0. - Keep
post_max_sizesmall (8M, or 32M if you need uploads) and block multipart requests at the proxy on endpoints that do not take uploads. - Hiding errors with
display_errorsor@does not help: the stale state is still read.
A third PHP issue, still unpatched
A separate flaw, CVE-2026-115560, was disclosed on 23 October. It involves session serialisation and upload progress, needs an unusual configuration, and has no patch yet. Disabling session upload progress also blocks it, which is one more reason to apply that setting now.
What we did on our own servers
We run PHP in production ourselves, so we ran the same checks on our servers: each one serves PHP from a patched build or from a distribution package carrying the fix, and every Apache and PHP-FPM process was restarted after the update. If you are not sure about yours, the three checks above take ten minutes.
Sources
Need a hand checking your PHP servers?
We patch, verify and harden Laravel and PHP stacks in production.
Contact Elaitech