# PHP2Shell: the PHP bugs being exploited right now, and exactly how to check and patch

> Two critical flaws in PHP's default upload-progress feature allow unauthenticated remote code execution. Here are the fixed versions, a one-line check, and the config change that buys you time.

Published Oct 27, 2026 by TechMeasured Staff · Security · Canonical: https://techmeasured.com/security/php2shell-patch-guide

If you run PHP anywhere — WordPress, Laravel, a forgotten admin panel, a firewall appliance's web UI — this is the patch to prioritize this week.

**PHP2Shell** is the name for two critical, unauthenticated remote-code-execution bugs in PHP core, **CVE-2026-109618** and **CVE-2026-109619**. CISA has added both to its Known Exploited Vulnerabilities catalog, and exploitation has been seen in the wild.

## The 60-second version

- **Affected:** essentially every PHP build with session upload progress turned on — which is the **default**.
- **Fixed in:** PHP **8.5.12, 8.4.27, 8.3.36 and 8.2.35** (released October 21, 2026).
- **No upstream fix:** PHP 8.1, 8.0 and 7.4 — you need a distro/vendor backport or an upgrade.
- **Stopgap:** set `session.upload_progress.enabled=0` and restart *every* PHP worker.
- **Hunt:** review logs back to at least **October 17**, when Amazon's threat intel team saw an exploit attempt against its honeypots.

## How the bugs work (briefly)

Both bugs live in PHP's **upload progress** feature, which tracks file uploads in the session *before your application code even runs*. That's why an endpoint that ignores uploads entirely can still be attacked.

- **CVE-2026-109619 (use-after-free):** the progress code caches raw pointers into the session data. A second progress update flushes and re-reads the session, freeing the old structure — and leaving those pointers dangling. An attacker who pauses an upload stream for just over a second (the default `min_freq`), then resumes, can reclaim the freed memory with crafted form fields and steer PHP into calling `system()`.
- **CVE-2026-109618 (memory corruption on out-of-memory):** pushing PHP into its `memory_limit` makes it jump straight to request shutdown, skipping cleanup. Shutdown then reads uninitialized memory that an attacker has pre-filled.

Researchers have chained these with a Linux kernel privilege escalation to get **root** on firewall appliances. Public proof-of-concept code is fragile — Rapid7 found it only works on specific OS/PHP/web-server combinations — but warns a portable exploit could appear at any time.

## Step 1: check your version

```bash
php -v
# and for the version your web server actually uses:
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*
```

Distro packages often **keep the old version string** while carrying the fix. On Ubuntu 24.04, for example, `8.3.6-0ubuntu0.24.04.13` is patched. Check your package changelog rather than trusting the version number:

```bash
# Debian/Ubuntu
apt changelog php8.3-common 2>/dev/null | grep -m3 -i "CVE-2026-10961"
# RHEL/Alma/Rocky
rpm -q --changelog php-common | grep -m3 -i "CVE-2026-10961"
```

## Step 2: patch

- **Ubuntu:** both CVEs rated Critical; fixed packages for supported releases (older ones via Ubuntu Pro).
- **Debian:** fixes for bookworm (DLA-4848-1) and trixie (DSA-6574-1).
- **Red Hat:** fixed packages for RHEL 8, 9 and 10 as of October 24 — but **PHP 8.4 on RHEL 9 was still listed as affected**.
- **Remi repo:** fixed builds for EL8+ and Fedora 43+; none listed for 7.4/8.0/8.1.
- **cPanel (EasyApache 4):** release 25.91 backports the fix to ea-php74, 80 and 81.
- **Windows builds:** PHP re-spun them on October 26 (e.g. 8.3.36-1) for an unrelated Brotli bug; Linux needs nothing extra for that.

Then restart PHP-FPM / Apache so the new binary is actually loaded.

## Step 3: if you can't patch today

Add this to `php.ini` or your **PHP-FPM pool config** (not `.user.ini`, not `ini_set()` — those apply too late):

```ini
session.upload_progress.enabled = 0
```

Restart every worker. This also blunts **CVE-2026-115560**, a third related flaw disclosed October 23. Additional hardening:

- On PHP 8.5, set `fatal_error_backtraces=0`.
- Lower request body limits — around **8 MB** for sites without uploads, **32 MB** with uploads — and match them in Nginx/Apache.

These reduce exposure; they don't replace the patch.

## Who should worry most

Anyone running **end-of-life PHP** (7.x, 8.0, 8.1) on internet-facing hosts, appliances with embedded PHP web UIs, and shared hosting. If you inherited a server you didn't build, assume it's vulnerable until you've proven otherwise.


## Sources

1. [Akamai — Understanding PHP2Shell: everything you need to know](https://www.akamai.com/blog/security-research/understanding-php2shell-everything-you-need-to-know)
2. [StackHarbor — PHP2Shell (CVE-2026-109618 / 109619): what we know](https://stackharbor.com/en/blog/php2shell-cve-2026-109618-109619-what-we-know/)
3. [myITforum — IT Pros Weekly Roundup, Oct 26–30 (CISA KEV listing)](https://myitforum.substack.com/p/it-pros-weekly-roundup-october-2630)