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

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

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:

# 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):

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.