Free consultation

Describe the problem or goal. I will reply with a practical next step — free, no commitment.

Or pick a time on Calendly

On 21 Oct the PHP project shipped 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They close two holes, CVE-2026-109618 and CVE-2026-109619. A stranger with no login can run their own code on the server: take the database and passwords, drop something extra on the box, send mail as the site.

The hole is in PHP itself. Updating WordPress, Joomla, MODX, Bitrix, Laravel, Symfony, or Yii2 does not close it.

What Breaks in Production

The PHP that answers a web request is the one in scope: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed.

Where the site sitsOn 22 Oct
Ordinary hosting, the host runs PHPThe patch is in. A VPS where you install PHP is not that plan.
The site opens through CloudflareThe WAF blocks the known requests. A hit on the raw server IP skips that filter.
Your own serverOld PHP, until the package is updated and the workers restart.

What to Change Technically

First, whose PHP is it.

Ordinary hosting. You will not install the package yourself. Write support: "Was PHP updated after 21 Oct for CVE-2026-109618 and CVE-2026-109619?" If the panel lets you pick a version, pick 8.3 or newer.

Your own server. Update the PHP packages and restart PHP. Without a restart the old code stays in memory. Put your version in the commands. If PHP lives inside Apache, restart Apache.

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm

On Ubuntu and Debian, php -v often still shows the old number after the fix is inside the package. Read the package build: dpkg -l | grep php.

SystemBuild that has the fix
Ubuntu 24.048.3.6-0ubuntu0.24.04.13
Ubuntu 22.048.1.2-1ubuntu2.28
Ubuntu 26.048.5.4-0ubuntu1.5
Debian 138.4.27-1~deb13u1
Debian 128.2.35-1~deb12u1

If PHP is upstream, not the distro package, php -v should show 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

Two traps showed up on 21 Oct for people who updated the same evening. The hoster's mirror lags behind security.ubuntu.com: apt says there is nothing to upgrade, and the patch is already out. The Ondrej Sury repo (ppa:ondrej/php, how panels like HestiaCP install PHP) shipped builds late, and Launchpad returned 503. Try again in an hour. Remi (CentOS, Alma, Rocky) did not promise a same-day build.

PHP 7.4, 8.0, and 8.1 no longer get fixes from the PHP project. Ubuntu 22.04's own 8.1 is closed by the build in the table. Debian 11 and older have no free build. Use the week to move to 8.3 or 8.4. On the move, set date.timezone in php.ini: a new branch does not pick the zone up from the system. ionCube loaders are built for one PHP version and will not start on the next.

If the upgrade cannot ship today, you can only narrow the hole. In php.ini or the FPM pool config (.htaccess and ini_set apply too late):

session.upload_progress.enabled = 0

Then restart. That closes a confirmed path for one of the two holes. If the site takes no uploads, post_max_size = 8M narrows the other. It does not replace the package.

Leave Cloudflare on. It blocks the known requests. The PHP on the server still needs the update.

Production Pattern

  1. The panel says PHP 8.2 or 8.3. The fixed builds shipped on 21 Oct.
  2. The owner reads "hosting already updated" and stops. That line was about the plan where the host runs PHP.
  3. The domain is on Cloudflare, so the known requests die at the edge. A request to the raw IP does not.
  4. That evening WordPress or Bitrix gets its own update. The php-fpm process does not.
  5. The package is installed and the workers are not restarted. The old code is still in memory.
  6. apt said nothing to upgrade, because the mirror was behind.

What holds: the package that contains the fix, workers restarted, the version read from the PHP that answers the site.

What to Check This Week

  1. No shell required: one note to support about an update after 21 Oct. If you are the one who SSHs in, the check is yours.
  2. Compare the package build to the table. An old php -v on Ubuntu does not by itself mean the hole is still there.
  3. After the install, restart PHP and open the site.
  4. If the domain is on Cloudflare, traffic has to pass through it, not hit the raw IP. Update PHP anyway.
  5. If the package waits until morning: session.upload_progress.enabled = 0 and a restart. Put the real upgrade on the next window.

If the server is yours and you want it closed today, leave a request. Schedule a consultation

Recent articles