# How to Fix the Critical PHP RCE Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

By Dinesh Uprety
Published: 2026-10-23
Updated: 2026-10-23
Canonical: https://laranepal.com/blog/how-to-fix-the-critical-php-rce-vulnerabilities-cve-2026-109618-cve-2026-109619

On 21 October, PHP shipped an emergency security release fixing two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. Both flaws can let an attacker run code on your server **without any login**, and attack attempts were spotted in the wild the same day the fixes landed. We covered the news in [our earlier article](https://laranepal.com/blog/php-drops-a-critical-security-update-today-and-php-86-lands-on-november-19); this guide is the practical follow-up: exactly how to check whether you are exposed, and how to fix it, step by step.

The PHP team's own summary is blunt: there are no complete mitigations — **updating is the only safe fix**. The good news is that for most servers the whole job takes about ten minutes.

## Step 1: Check your PHP version

On your server, run:

```bash
php -v
```

You will see something like `PHP 8.4.20 (cli)`. Write down the full version number — the small number at the end matters, not just the branch.

One warning: the command-line version and the version your website actually runs can be different. If your site runs through PHP-FPM or Apache, confirm the web version too — ask your hosting panel, or temporarily load a page that calls `phpversion()` and delete it right after. Check every server and every site you look after, including staging boxes and Docker containers. Forgotten servers are how these flaws get exploited.

![The fix in four steps](https://laranepal.com/storage/e3tKpDlC64Ru0vvGfCQoXPa8jyD5wwbY74EwSkk9.png)

## Step 2: Compare against the fixed versions

The patched releases came out on 21 October 2026:

| Your branch | You are safe on |
| --- | --- |
| PHP 8.5 | **8.5.12** or newer |
| PHP 8.4 | **8.4.27** or newer |
| PHP 8.3 | **8.3.36** or newer |
| PHP 8.2 | **8.2.35** or newer |
| PHP 8.1 and older | No official fix — see Step 6 |

If your version is lower than the one in the table, you are exposed. Every setup that serves web requests is in scope — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest on mod_php, where an attack can trigger before any of your application code runs.

## Step 3: Update PHP

Pick the path that matches how your PHP was installed.

**Ubuntu / Debian (including the popular ondrej/php PPA):**

```bash
sudo apt update
sudo apt install --only-upgrade 'php8.4*'
```

Swap `8.4` for your branch (8.5, 8.3 or 8.2). One nuance: Linux distributions sometimes deliver the fix as a distro security update without the version number matching the table exactly. If `apt` says you are up to date but your version looks older, check the package changelog before panicking — and prefer your distro's patched package over a manual install.

**Docker:** change your image tag to the fixed release and rebuild:

```dockerfile
FROM php:8.4.27-fpm
```

```bash
docker compose up -d --build
```

Do the same for every image that contains PHP — app containers, queue workers, cron and CI images are easy to forget.

**cPanel / shared hosting:** you usually cannot update PHP yourself. Look for the fixed version in your panel's PHP selector (for example MultiPHP Manager). If it is not there yet, open a ticket with your host and ask directly when the patched build for CVE-2026-109618 and CVE-2026-109619 goes live. Good hosts applied it on release day.

**Windows / XAMPP:** download the matching build from windows.php.net, replace the PHP folder with the new one, and keep your existing `php.ini`.

**Built from source:** download the fixed tarball (8.5.12, 8.4.27, 8.3.36 or 8.2.35) from php.net/downloads.php and rebuild as usual.

## Step 4: Restart PHP — do not skip this

Updating the files is not enough. PHP processes that are already running keep using the old, vulnerable code until they restart. This is the step people forget, and it silently leaves them exposed.

```bash
# PHP-FPM (swap in your version)
sudo systemctl restart php8.4-fpm

# Apache with mod_php
sudo systemctl restart apache2
```

On Docker, recreating the containers in Step 3 already does this. On shared hosting, your host handles it — another reason to confirm with them rather than assume.

## Step 5: Verify the fix

Run `php -v` again and confirm the new version number. Then check the web version the same way you did in Step 1, load your site, and click through the important flows — login, forms, file uploads, checkout if you have one. A patch-level update inside the same branch should not break anything, but five minutes of checking beats a surprise later.

For Laravel apps, remember what this update is and is not: it is a **PHP runtime** update, not a framework update. `composer update` cannot fix it. Check the PHP version on your servers (Forge, Ploi and similar tools show it in the server panel), inside your Docker base images, and in your CI pipelines.

## Step 6: On PHP 8.1 or older? Your fix is an upgrade

PHP 8.1 and everything below it received **no official release** — those branches are end of life. The security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build from source, and some Linux distributions and LTS vendors backport the fix into their own packages, so check with your vendor first. But treat those as a bridge, not a destination: the real fix is moving to a supported branch (8.3 or 8.4 are good targets today).

And if you are on 8.2: patch to 8.2.35 now, but put a branch upgrade on the calendar too — 8.2 security support ends on **31 December 2026**, after which no fix like this one will ever arrive for it.

## Can't update today? Reduce the risk while you schedule it

There is no complete mitigation — PHP says so itself — but two things genuinely help while you arrange the update:

- **Turn off session upload progress if you do not use it.** Set `session.upload_progress.enabled = 0` in `php.ini` and restart PHP. Most Laravel and WordPress sites never use this feature, and PHP recommends disabling it.
- **Put a WAF in front if you have one.** Hosts and CDNs such as Cloudflare pushed protective rules for these flaws on release day. That buys time; it does not replace the patch.

Then book the update for today, not next week. Public technical details and proof-of-concept code circulate quickly after a release like this, and mass scanning follows.

## The 10-minute checklist

1. `php -v` on every server, container and site — note the full version.
2. Compare with the table: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.
3. Update through your distro, Docker image, hosting panel or php.net download.
4. Restart PHP-FPM / Apache so no old process keeps running.
5. Verify the version again — CLI **and** web — and test your key pages.
6. On 8.1 or older: ask your vendor about a backport today, and plan the branch upgrade now.

That is the whole job. Patch first, verify second, and let the PHP 8.6 upgrade planning wait until your servers are safe.

## Need a hand fixing your own application?

If your PHP or Laravel application is still running an unpatched — or simply old — version of PHP, and you would rather have an experienced developer handle the fix safely for you, contact us through the [LaraNepal contact page](https://laranepal.com/contact). Tell us your current PHP version and a little about your application, and we will patch, upgrade and verify everything end to end, so you can get back to building instead of firefighting.

**Sources:** [php.net — Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5), [GitHub Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), [GitHub Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)