---
title: "Critical PHP RCE (CVE-2026-109618): how to secure your VPS"
description: Two critical PHP flaws, fix due October 21 at 14:00 UTC. Find every PHP version on your VPS, cut exposure before the patch, then update and verify.
---

[is\*hosting Blog & News - Next Generation Hosting Provider](https://blog.ishosting.com/en)

# [Critical PHP RCE (CVE-2026-109618): how to secure your VPS](https://blog.ishosting.com/en/critical-php-rce)

 Written by [is\*hosting team](https://blog.ishosting.com/en/author/team-ishosting) | Oct 21, 2026, 10:49:26 AM

Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, allow remote code execution, according to researchers: a crafted request reaches your server, and someone else's code runs on it. The PHP security team rated both 9.2 on the CVSS v4.0 scale. An emergency security release with the fix is scheduled for today, October 21, at 14:00 UTC.

Sansec expects mass attacks within 15 minutes of the release. A published fix usually shows attackers where to look. If your VPS runs WordPress, Laravel, a forum, a control panel or any other PHP code, today is a patching day.

## What is confirmed and what is still rumor

PHP's [official notice](https://www.php.net/archive/2026.php#2026-10-20-1) confirms two critical vulnerabilities and the release time. It also says the release may ship earlier if details become public or attacks show up in the wild. Affected versions, fixed versions and technical details will arrive with the release itself.

Everything else comes from researchers. The CVE numbers are reported by CERT-EU and watchTowr; the PHP notice does not mention them. watchTowr says it reproduced CVE-2026-109618, so the bugs are real. Leaked claims say every version from PHP 5 onward is affected and that only the supported branches, 8.2 through 8.5, will get fixes. The leaked details point at PHP's session upload progress feature and its handling of multipart requests (the format browsers use to send files). PHP has confirmed none of it, and a PHP core developer has said publicly that the only mitigation is patching.

On exploitation, [Huntress reported](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities) on October 20 that it had seen no attacks in its partners' environments and knew of no public exploit code. By the morning of October 21, that changed. Cloudflare CTO Dane Knecht [wrote on X](https://x.com/dok2001/status/2112811965735202970) that the company was seeing early attacks and had deployed WAF rules for the known exploit vectors, available on every plan, free included. He called the rules a stopgap and urged everyone to patch at 14:00 UTC. If your site sits behind Cloudflare, that buys time, but only for traffic that goes through Cloudflare: requests sent straight to your server's IP skip the WAF.

## Which PHP your server runs

Start by finding every PHP version on the server. The trap here is that the php -v command reports the version PHP uses on the command line. Your site is served by PHP-FPM or an Apache module, which can run a different version entirely.

So check three things: which PHP versions are installed (on Debian and Ubuntu, each one gets its own folder in /etc/php), which PHP services are running, and which version each FPM binary reports on its own. If PHP runs in Docker, check every container too: each one carries its own PHP, and the image name doesn't always say so.

Write the list down.

## Before the patch: cut the exposure

PHP has published no official workaround, and the only complete fix is the update. The steps below shrink the window until it lands.

### Take a fresh backup or snapshot

Last week's copy is a poor rollback point for a same-day PHP upgrade.

### Turn off session upload progress

The [feature](https://www.php.net/manual/en/session.upload-progress.php) is on by default and tracks how far a file upload has got. Turning it off targets the leaked details, not a confirmed root cause. Uploads keep working; only progress bars built on this feature stop. Set session.upload\_progress.enabled to Off for every installed PHP version. A .user.ini file in a site folder can switch the feature back on, so on PHP-FPM also lock the setting in every pool configuration with php\_admin\_flag. Then restart PHP-FPM, or Apache if PHP runs as its module. Sansec also recommends setting session.use\_strict\_mode to 1. Nobody has confirmed that it blocks this particular attack, but the setting is useful on its own: PHP stops accepting session IDs it didn't create itself. Add it alongside the upload progress setting and check that logins still work after the restart.

### Verify it in the PHP that serves your site

The command line won't tell you. The simplest check is a throwaway PHP file with a random name in the site's root folder that prints the value of the setting. Open it in a browser, confirm the feature is off, then delete the file. If you get your site's 404 page instead, the server routes everything through index.php and this check won't work there.

### Block multipart requests at the web server

This is the stronger stopgap: the leak also claims a second route through multipart handling that the upload progress setting does not cover. Setting file\_uploads to Off won't help, since PHP still parses the multipart body and only skips the files. Rejecting the request before it reaches PHP does. In nginx, add a rule that answers 403 to any request whose Content-Type header contains "multipart", and put it in every server block that passes requests to PHP, including the default one that answers requests sent to the bare IP.

In Apache, the same rule goes into the virtual host or .htaccess. Make sure it checks the request's Content-Type header: Apache's CONTENT\_TYPE variable describes the response and lets these requests through. Then test from another machine by sending a file upload to the site. The answer should be 403. The price: every file upload stops until you remove the block. That includes WordPress media uploads and some contact forms that send multipart even without a file field (Contact Form 7 is one). Pages, logins, JSON APIs and most ordinary forms keep working. WordPress security plugins and application login checks don't replace this block, because PHP parses the request body before any of them run.

### If you take a site offline until the patch, stop the web server or return 503

Don't just remove the PHP handler from nginx or Apache: the server will then serve .php files as plain text, database passwords from config files included.

### Save your logs

Copy current nginx or Apache access logs and PHP-FPM logs somewhere logrotate won't reach. If something got in during the gap, those files are the only record of how.

## After 14:00 UTC: update and verify

First check [php.net](https://www.php.net/archive/2026.php) for the release notes and the list of fixed versions. Then update PHP the same way it was installed: through apt on Debian and Ubuntu (distribution packages or the ondrej/sury repository), through dnf on AlmaLinux, Rocky and CentOS Stream. Before you run the upgrade, confirm that your repository already offers the fixed build and that no PHP package is on hold: a held package is skipped without any warning. After the update, restart PHP-FPM, or Apache if PHP runs as its module.

**Control panels** deliver PHP on their own schedule. cPanel, for example, ships PHP as EasyApache 4 packages, so the fix arrives when cPanel publishes updated ea-php builds. Run the panel's update and check its changelog.

**Docker:** rebuild the container on a fresh base image instead of updating PHP inside the running one.

Long-running PHP processes (queue workers, schedulers, Laravel Octane) keep the old binary in memory until they restart, so restart those too. Then go through your list from earlier and check the version of every binary, FPM included.

One detail that confuses people every time: distributions backport security fixes and keep the old upstream number. A patched Ubuntu or Debian package can still read 8.1.2 with a distribution suffix after it. For those, look the CVE numbers up in the [Ubuntu](https://ubuntu.com/security/cves) or [Debian](https://security-tracker.debian.org/tracker/) security tracker instead of comparing version strings with php.net.

Once the fixed version serves your site, remove the multipart block and test a file upload. Upload progress can stay off: most sites never used it.

## If you're on PHP 8.1 or older

PHP 8.0 and 8.1 are out of upstream support, and 7.x has been for years. If the leaked claims hold, these branches get no official fix. Ubuntu 22.04 is still in standard support, so Canonical may backport the patch into its own 8.1 packages; watch the Ubuntu security notices for these CVEs. Everything else needs a move to a supported branch, and the stopgaps above stay in place until then.

Pick 8.3 or 8.4 over 8.2. PHP 8.2 loses security support on December 31, 2026, so upgrading to it today means repeating the exercise in ten weeks. Test the site on a copy first: jumps from 7.4 tend to break old plugins in creative ways.

## Who runs the update

On an unmanaged VPS, PHP is part of your stack, so the update runs on your side. Everything you need is in the steps above, and on most servers the update itself comes down to one command.

On a [managed VPS](https://ishosting.com/en/vps/managed-server), you can hand the update to [is\*hosting support](https://ishosting.com/en/support): open a ticket and ask them to update PHP. Support doesn't log into servers on its own initiative, because only you know what runs there, so the request has to come from you.

Either way, check the PHP version one last time today. Then check FPM too, because that's what serves your site.

[View full post](https://blog.ishosting.com/en/critical-php-rce)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "is*hosting team"
  },
  "dateModified" : "2026-10-21T10:49:26.501Z",
  "datePublished" : "2026-10-21T10:49:26Z",
  "headline" : "Critical PHP vulnerabilities: what to do on your server today",
  "image" : {
    "@type" : "ImageObject",
    "height" : 1348,
    "url" : "https://25913237.fs1.hubspotusercontent-eu1.net/hubfs/25913237/blog/critical-php-rce/critical-php-rce.png",
    "width" : 2396
  },
  "mainEntityOfPage" : "https://blog.ishosting.com/en/critical-php-rce",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60.0,
      "url" : "https://help.ishosting.com/hubfs/ishosting-logo-black.svg",
      "width" : 316.66666
    },
    "name" : "Blog"
  }
}
```