Are you affected?
Yes, if you run PHP 8.2 below 8.2.35 behind a web server. Both vulnerabilities are in PHP itself, so every site on the server is affected, whatever framework or CMS it uses.
How PHP runs changes the risk:
- Apache with mod_php carries the highest risk. An unauthenticated request can reach the bug before any of your code runs.
- PHP-FPM, LiteSpeed (LSAPI), php-cgi and FrankenPHP are listed as affected too.
- The command line (
php -vin a terminal) is not the web-facing path, but it usually tells you which version the web side runs.
Distribution packages often keep an older version number and add the fix as a patch. On Ubuntu or Debian, 8.2.x+deb12u… or a similar suffix can be fixed even though it reads below 8.2.35. For those builds, go by the distribution's security notice for both CVE numbers instead of the version string.
The official fix
The PHP project released PHP 8.2.35 on 21 October 2026. It fixes both CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. Branch 8.2 itself reaches end of life on 31 December 2026, ten weeks after this release. After that date, new PHP vulnerabilities in 8.2 will not be fixed by the PHP project.
Upgrade, free
Restart after you upgrade
Installing the package does not change PHP processes that are already running. Until you restart PHP-FPM, Apache or LiteSpeed, they keep serving requests with the old code.
1. Read the version the web server runs.
php -v
php-fpm8.2 -v # Debian and Ubuntu name the FPM binary per version
2. Upgrade the package. On Debian or Ubuntu:
sudo apt update
sudo apt install --only-upgrade 'php8.2*'
On RHEL, AlmaLinux or Rocky with Remi's repository:
sudo dnf upgrade 'php*'
From a Docker image, rebuild on php:8.2.35-fpm (or the matching tag) and redeploy every container.
3. Restart every PHP worker.
sudo systemctl restart php8.2-fpm
sudo systemctl restart apache2 # if you use mod_php
4. Check the running version, not the installed one. The steps are on after patching.
On shared hosting you cannot run these commands. Ask your host which build they run and when it was patched; the questions are on the triage page.
If you cannot upgrade today
The PHP project lists settings that reduce exposure. They do not make you safe; only the upgrade does. Put these in php.ini or the FPM pool, not in .user.ini or ini_set(), then restart:
; FPM pool, for example /etc/php/8.2/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M if the site takes uploads
php_admin_value[upload_max_filesize] = 4M
php_admin_value[max_input_nesting_level] = 16 ; default 64; lower it
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[log_errors] = on
php_admin_value[error_reporting] = E_ALL
Also limit request size, field count, multipart parts, headers and nesting at the proxy in front, including requests without a Content-Length header. Do not set RLIMIT_AS or RLIMIT_DATA: a failed allocation is the path the first bug needs. The full list with reasons is on the home page.
Before 31 December 2026
8.2.35 fixes PHP2Shell, but 8.2 stops receiving security fixes at the end of the year. That leaves three options:
- Move to 8.3 or 8.4. Supported until 31 December 2027 and 31 December 2028. Most code that runs on 8.2 runs on 8.3 with few changes; test plugins and extensions first.
- Stay on a distribution that maintains 8.2. Debian 12 ships 8.2 and its security team keeps patching it inside that release. Check your distribution's own support dates.
- Pay for extended support. Vendors patch PHP after the project stops; see old PHP versions.
If you need more than a guide
- Running several servers or a fleet of client sites: we can patch them with you, scoped in writing and invoiced.
- Planning the move off 8.2 before 31 December: we can scope it with you.
- Our recommendations page lists other options, with any paid links marked.
Last reviewed on 22 October 2026.