The "php2shell" Emergency

On October 21, 2026, cybersecurity agencies worldwide—including CISA, the NSA, and Japan’s JPCERT—issued an urgent directive to system administrators: patch PHP immediately.

Dubbed “php2shell” (CVE-2026-109618 and CVE-2026-109619), this pair of critical vulnerabilities carries a 9.2 CVSS severity score. Because PHP powers roughly 70% of the web—including platforms like Drupal, Drupal Commerce, Open Social, WordPress, Laravel, and Magento—millions of cloud servers and DigitalOcean Droplets remain exposed until patched and restarted.

Here at Droplet.is, we audited and patched our own Ubuntu 24.04 production stack within hours of the disclosure. Below is our breakdown of what the vulnerability actually does, why your CMS status report might be misleading you about your version number, and the exact terminal commands you need to lock down your server right now.

What Is “php2shell” and Why Is It So Dangerous?

Unlike vulnerabilities that require a specific third-party module or misconfigured plugin, CVE-2026-109618 and CVE-2026-109619 sit directly inside the core PHP engine handling web requests:

• The Mechanism: The flaw exploits out-of-memory conditions during multipart file upload parsing and state corruption following a fatal error.
• The Impact: An unauthenticated attacker can send specially crafted HTTP requests to any PHP-backed website and achieve Remote Code Execution (RCE)—allowing them to drop a web shell, read database credentials, or compromise the underlying file system without logging in.
• The Scope: Any public-facing web server running an unpatched PHP-FPM, FastCGI, or Apache mod_php stack is vulnerable out of the box.

Step 1: Check If Your Ubuntu Droplet Is Vulnerable

If you run a CMS like Drupal on Ubuntu 24.04 LTS (Noble), checking your site’s admin dashboard can give you a false sense of security—or unnecessary panic.

When we checked the Drupal Status Report on Droplet.is, it simply reported PHP 8.3.6. That happens because Ubuntu’s official repositories keep the base version frozen at 8.3.6 and backport security fixes using an Ubuntu-specific build suffix (-0ubuntu0.24.04.xx), which most web dashboards strip out.

To see what your Droplet is actually running, SSH into your server and run:

dpkg -l | grep php8.3

Compare your output against the two common Ubuntu 24.04 configurations below:

Note: If you are running PHP 8.2 or 8.4, substitute php8.2 or php8.4 in the command above. Upstream PHP patched this issue in releases 8.2.30, 8.3.36, and 8.4.15.

Step 2: Patch and Restart PHP-FPM Immediately

When we ran dpkg -l | grep php8.3 on our NYC3 Droplet, we saw 8.3.6-0ubuntu0.24.04.12—one revision shy of the security fix. Because our server also had the popular ppa:ondrej/php repository configured, running a targeted upgrade jumped us straight to upstream PHP 8.3.36.

Run these commands as root (or prepend sudo) on your DigitalOcean Droplet:

# 1. Refresh package metadata and upgrade all installed PHP 8.3 packages
apt update && apt --only-upgrade install -y 'php8.3*'

# 2. CRITICAL: Restart PHP-FPM and your web server to flush vulnerable workers from memory
systemctl restart php8.3-fpm
systemctl restart nginx

Using Apache instead of Nginx? Run systemctl restart apache2 on that final line.

Step 3: Verify the Patch in Your Debian Changelog

Never assume an upgrade succeeded without verifying both the active packages and the changelog. Run these two commands to confirm the patch is installed:

# Confirm your new package version
dpkg -l | grep php8.3

# Verify the exact CVE patch entries exist in your installed changelog
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz

If your server is protected, the zgrep command will output the following confirmation line:

+ (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

Bonus: Don’t Ignore Pending Kernel Upgrades

While patching PHP, keep an eye on the bottom of your apt terminal output. During our update, Ubuntu flagged a Pending kernel upgrade! warning, noting that the server was running kernel 6.8.0-142-generic while 6.8.0-147-generic was staged and waiting on disk.

If you can spare 45 to 60 seconds of maintenance window, wrap up your security sweep by upgrading the rest of your system packages, clearing out orphaned dependencies, and rebooting into the latest kernel:

apt upgrade -y && apt autoremove -y && reboot