PHP2Shell: how to fix the critical PHP flaws (CVE-2026-109618 & 109619)

On 21 October 2026 the PHP project shipped emergency security releases for every supported branch. They fix two memory-safety bugs, CVE-2026-109618 and CVE-2026-109619, which people have been calling "PHP2Shell" because the end result can be an attacker running their own code on your server.

I run and maintain PHP (Laravel) systems at work as well as Django ones, so I spent the week patching. Here's what I learned, written for both developers and the people who own the websites.

What happened, in plain English

Every time someone visits a PHP page, PHP sets up some memory for that request, runs your code, and cleans up afterwards. Both bugs live in that setup-and-cleanup cycle:

• CVE-2026-109618, "OOM corruption": if PHP runs out of memory at exactly the wrong moment, some request data is left half-built. The clean-up step then treats that half-built data as valid, which corrupts memory. A carefully crafted request can turn that corruption into code execution.
• CVE-2026-109619, "stale global state": some data that belongs to one request can outlive the memory it points to. A later request handled by the same PHP worker can then use that freed memory, which is a classic use-after-free.

The PHP team says the risk is highest for mod_php (PHP running inside Apache), but PHP-FPM setups should be patched too.

Timeline

Am I affected?

Almost certainly yes, if you run any PHP version older than the ones above. That includes WordPress, Laravel, Magento, Drupal and any custom PHP app. Check three things:

1. Your PHP version. On the server run php -v. For the version your website actually uses (it can differ from the command line), put <?php echo PHP_VERSION; in a temporary file, open it once, then delete it.
2. How PHP runs. php -i | grep "Server API" or phpinfo() shows Apache 2.0 Handler (mod_php, highest risk) or FPM/FastCGI.
3. Old branches. PHP 8.1 and older no longer get official releases. The PHP team published minimal backport patches for 7.4, 8.0 and 8.1, and some Linux vendors ship their own fixes, but the real answer is to move to a supported version.

How to fix it

Pick the setup that matches yours. After any update, restart PHP, because running workers keep the old code in memory.

Ubuntu / Debian (apt)

# update packages (distro repos or the ondrej/php PPA)
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
php -v                          # confirm the patched version from your source
sudo systemctl restart php8.3-fpm   # or: sudo systemctl restart apache2

Distribution packages sometimes keep the old version number and add a patch on top, so check your distro's security notice for the CVE IDs rather than only reading php -v.

Docker

# Dockerfile: pin the patched release
FROM php:8.3.36-fpm

# then rebuild without cache and redeploy
docker build --pull --no-cache -t my-app .
docker compose up -d --force-recreate

If your image uses a floating tag like php:8.3-fpm, you still need --pull and a rebuild; an image that's already built won't update itself.

Shared hosting / cPanel

Open MultiPHP Manager (or your host's PHP selector) and make sure each site uses the latest 8.2+ version. If you can't see the patch level, open a ticket and ask your host directly whether they've applied the fixes for CVE-2026-109618 and CVE-2026-109619.

Windows

Download the new builds from windows.php.net. Grab the -1 rebuilds from 26 October (for example 8.4.27-1), which also include the Brotli fix for CVE-2026-111497, then restart IIS or Apache.

Can't update today? Reduce the risk

• Memory limit: set memory_limit=-1 where applications can't override it, and enforce a real limit with a container or cgroup limit instead. Don't use RLIMIT_AS or RLIMIT_DATA for this.
• Request size: keep post_max_size low (around 8M without uploads, 32M with uploads) and upload_max_filesize below it.
• Session upload progress: set session.upload_progress.enabled=0 in php.ini or the pool/server config (not with ini_set() or .user.ini), then restart workers.
• PHP 8.5 only: set fatal_error_backtraces=0 and restart workers.

; php.ini (temporary hardening until you patch)
memory_limit = -1                 ; enforce a real limit at the container/cgroup level
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0

The 23 October follow-up

Two days after the release, PHP recommended turning session.upload_progress.enabled off even on patched versions until the next bugfix release. It only matters for an unusual setup (switching session.serialize_handler with ini_set() before session_start()), but turning it off costs most sites nothing. A full advisory (CVE-2026-115560) is due with that next release.

After patching: a 5-minute checklist

1. Confirm the version the website sees, not just the CLI.
2. Restart PHP-FPM / Apache on every server and container.
3. Look through error logs from the past couple of weeks for unusual out-of-memory errors or worker crashes.
4. If anything looks suspicious, rotate database passwords, API keys and .env secrets.
5. Put a reminder in the calendar: PHP 8.2 reaches end of life on 31 December 2026. Plan the move to 8.4 or 8.5 now.

My take

Bugs like these aren't caused by your code, but you're still responsible for the server it runs on. The teams that patched fastest this week all had the same things: pinned versions in Docker, a staging server to test on, and a one-command deploy. If your PHP stack doesn't have that yet, now is a good time to set it up.

Need help checking or patching a PHP or Laravel server? Send me a message and I'll take a look.

Source: official advisories and release notes on php.net (20–26 Oct 2026).

Shubham Nirmal

Python & Django developer in Lalitpur, Nepal. I build fast backends, automation and AI tools, and mentor people starting out in IT.