On 21 October 2026 (UTC), the PHP project released builds that fix two critical vulnerabilities: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. An unauthenticated web request can lead to remote code execution. PHP tells every user to update immediately.
This article stays inside the official advisory: what is affected, how to see your version, and why temporary settings are not a fix. It does not describe how to reproduce the issue.
What happened
The two issues are CVE-2026-109618 and CVE-2026-109619. The first can interrupt PHP while request data is only partly initialized, so cleanup may treat that data as valid. The second can leave internal state after its memory is freed, so a later request on the same worker may use it before normal startup resets it.
PHP says every install that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest risk is mod_php, where a demonstrated case runs before application code. The advance notice rated both CVSS v4.0 9.2.
Which version to install
Stay on your current branch and take its fixed release: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP 8.2 reaches end of life on 31 December 2026 and gets no further security fixes after that, so plan the next branch even after 8.2.35.
PHP 8.1 and older no longer receive updates from the PHP project. Ask your distribution or LTS vendor about a backport, or move to a supported branch. Minimal source backports exist for 7.4, 8.0, and 8.1, and PHP does not treat them as a substitute for a supported update. The volunteer repo rpms.remirepo.net was not going to have packages the day of the release.
What to check first
On a server you control, php -v shows the version. A browser may also see it in the X-Powered-By header, and a missing header does not mean PHP is absent. On shared hosting, the host’s maintenance notice is the source of truth. The panel can disagree with the version the public site actually runs. In a container, replace the PHP inside the image, pull the fixed tag, and recreate the container. A floating tag can still point at the old build.
Laravel, WordPress, and similar apps only support a range of PHP versions. Move within that range to the fixed build. Jumping to an unsupported branch can take the site down for a different reason. After the files are in place, restart PHP-FPM or the web server workers. A process that is already running keeps the old build until it restarts.
- Note the version and whether it is FPM or Apache module
- On 8.2 through 8.5, install that branch’s fixed release
- On 8.1 or older, take a vendor fix or move to a supported branch
- Check the PHP versions your application supports
- Restart workers and confirm the version changed
Why waiting on settings is not enough
PHP says an update is the only complete fix. If you cannot update the same day, the advisory lists temporary settings, such as removing the memory limit, capping POST size, and turning off session upload progress. Those steps only reduce specific paths. They do not make the install safe. ini_set() and settings read after the request starts are too late. Keep the update scheduled while those settings are in place.
Patching application code does not close this issue. On the module build, PHP says the request can arrive before the application runs. A login screen or a firewall in front of the app is not a substitute when PHP handles the request first. Use the official advisory for the setting names.
Summary
The safe response is to install the 21 October 2026 release for your branch: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Older than 8.2 means a vendor backport or a move to a supported branch. Temporary settings only shorten the wait. They are not a place to stay. Primary source: the PHP security advisory.
Makoto Tejima can look at the PHP version, how it is served, and which versions the application supports, then lay out the update. Please contact us.