How to patch PHP CVE‑2026‑109618 and CVE‑2026‑109619 (October 2026)

On 21 October 2026 the PHP project released PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both let an attacker who has no account and does not sign in run code on a server through PHP, and PHP rates both 9.2 (critical). Ubuntu and Debian published fixed packages the same day.

The short answer:

• Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, or to your distribution's fixed package (the tables below list them).
• Restart everything that runs PHP: PHP-FPM, Apache if it uses mod_php, and long-running PHP processes such as queue workers. Until they restart they keep running the old, vulnerable code.
• PHP 8.1 and older get no fix from the PHP project. Ubuntu 22.04's own PHP 8.1 package is fixed; anything else on 8.1 or older should move to a supported branch.
• PHP says there is no complete workaround: "updating is the only safe choice."

What was fixed?

PHP published the two flaws as GitHub security advisories on 21 October 2026. Both are rated CVSS v4.0 9.2 (critical) and need no sign-in or user interaction; PHP rates the attack complexity as high.

In PHP's words, the first allows "unauthenticated remote code execution as the web worker account", and the second "heap use-after-free, memory disclosure and remote code execution with the web worker's privileges". Either is enough for an attacker to run their own code with the permissions of the account that runs PHP for a website.

Which PHP versions are affected?

Every release of the supported branches before the fixed one. PHP 8.1 and older are past the end of their support and receive no updates from the PHP project at all.

Which Ubuntu and Debian packages fix it?

Distributions often backport a fix into the PHP version they already ship, so the upstream number stays the same and only the package revision changes. Compare the full package version with this table, not the PHP version number.

If your PHP comes from a third-party repository, such as the ondrej/php PPA on Ubuntu or Remi on RHEL-family systems, those packages follow PHP's own numbers: you need 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later.

How do I check whether my server is patched?

On Ubuntu or Debian, list the installed PHP packages and their versions:

dpkg -l 'php*-common'

Then ask apt which version is installed and which is available, for each PHP version you found (8.3 here):

apt policy php8.3-common

A distribution package's changelog names the CVEs it fixes:

zgrep -o -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz | sort -u

If both CVE IDs are printed, the installed package includes both fixes. Packages from the ondrej/php PPA follow PHP's own version numbers instead, so compare those with the first table. php -v shows only the command-line PHP; websites usually run PHP-FPM or mod_php, which can be a different version, so check every installed PHP version, not just the default one.

How do I update PHP on Ubuntu and Debian?

Take a backup or snapshot first if you can, then install the updates:

sudo apt update
sudo apt upgrade

apt upgrade installs every pending update, PHP included. If unattended-upgrades is on, it may already have installed the distribution's PHP fix for you: check with the commands above. On RHEL, AlmaLinux or Rocky Linux, run sudo dnf upgrade instead.

Why do I have to restart PHP after updating?

Because a running PHP process keeps the code it started with. Installing a fixed package replaces the files on disk, but a process that is already running carries on with the old, vulnerable code in memory until it restarts. Some packages restart their own service when they are upgraded, but not every PHP process is covered, so a server can show the fixed version in apt policy and still be exposed.

Restart PHP-FPM for every PHP version you run, and Apache if it loads mod_php:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Restart anything else that runs PHP for a long time too: queue workers, daemons run by Supervisor or systemd, and anything started with php -S. On Ubuntu and Debian, needrestart lists the services that still use replaced files:

sudo needrestart -r l

What if I cannot update straight away?

PHP published interim measures, and is clear that they "do not make an installation safe". Use them only to buy time, test your sites after each change, and restart every PHP worker for a setting to take effect:

• For CVE-2026-109619: set session.upload_progress.enabled = 0 in php.ini, an FPM pool or the server configuration (not with ini_set() or a .user.ini file). On PHP 8.5, also set fatal_error_backtraces = 0. If performance does not matter, pm.max_requests = 1 in the FPM pool also helps.
• For CVE-2026-109618: PHP suggests memory_limit = -1, set where applications cannot override it (such as php_admin_value in the FPM pool), with a container or cgroup memory limit instead, and a smaller post_max_size (8M without uploads, 32M with them, keeping upload_max_filesize below it).

Some of these change how sites behave, such as upload limits or upload progress bars, so update as soon as you can and then review them.

What about shared hosting and other control panels?

On shared hosting your provider updates PHP: check their status page or ask them, and confirm the version your site runs with your hosting panel's PHP selector or a phpinfo() page you delete afterwards. On a VPS or a dedicated server, updating is your job, even with a hosting panel. cPanel & WHM ships its own PHP builds (EasyApache 4 packages such as ea-php83) and Plesk its own (plesk-php packages): install the vendor's PHP updates, then check the version and restart PHP as above.

How does Vanta Panel handle it?

Vanta Panel 5.54 patches PHP by itself. Right after the update it installs the fixed PHP packages for every installed PHP version, from the distribution or the ondrej/php repository, and restarts PHP-FPM, Apache and both panels once their configuration checks pass. From then on it installs PHP updates every day while automatic PHP patching is on (the default), restarts PHP after any PHP update, including Ubuntu's and Debian's own automatic security updates, and emails the server's alerts address when it does.

vWHM → PHP Security shows, for each PHP version, whether it is patched, which package it runs and whether anything still runs old code, with buttons to install updates and restart. As extra hardening, Vanta Panel also switches off session upload progress; it can be switched back on there. Servers with automatic updates on (the default) install 5.54 by themselves within a day. The details are in advisory VP-2026-007.

Frequently asked questions

What are CVE-2026-109618 and CVE-2026-109619?

Two critical vulnerabilities in PHP itself, fixed on 21 October 2026. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption") and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, "RCE via stale global state") each let an attacker with no account run code on the server with the permissions of the account that runs PHP. PHP rates both 9.2 (critical).

Which PHP versions fix them?

PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and every later release. Distribution packages carry the fix under their own version numbers, such as 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04 and 8.2.35-1~deb12u1 on Debian 12.

Is PHP 8.1 affected?

PHP 8.1 and older no longer get updates from the PHP project, so there is no official PHP 8.1 release with the fix. Ubuntu 22.04 fixed its own php8.1 package in 8.1.2-1ubuntu2.28. Other PHP 8.1 installations should move to PHP 8.2 or newer.

Is updating the PHP package enough?

No. A PHP process that was already running keeps the old code until it restarts. Restart PHP-FPM, Apache if it uses mod_php, and long-running PHP processes after the update, and check with sudo needrestart -r l that nothing still uses the replaced files.

Is there a workaround if I cannot update?

Only partial ones. PHP lists interim settings, such as turning off session.upload_progress.enabled, but says they do not make an installation safe and that updating is the only safe choice.

Does unattended-upgrades fix this automatically?

On Ubuntu and Debian it can install the distribution's fixed PHP package. Whether every running PHP process is restarted afterwards depends on the packages and the server's settings, so check the package version, run sudo needrestart -r l, and restart whatever still uses the old files.

Is my site on shared hosting affected?

It is if the server runs an unpatched PHP. Your hosting provider is responsible for updating PHP on shared hosting; check their announcements and the PHP version your site reports.

Sources

• PHP news, 21 October 2026: the security releases
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Ubuntu USN-8948-1 and USN-8948-2
• Debian DSA-6574-1 and DLA-4848-1
• GoDaddy: Important PHP security update, what website owners need to do
• Vanta Panel security advisory VP-2026-007