Updated: October 29, 2026

On October 21, 2026, the PHP project fixed two critical vulnerabilities, nicknamed "php2shell". Because they sit in PHP itself, almost every PHP site on the internet was exposed until the server's PHP was patched. This is what happened, what we've already done on shared cPanel hosting, and what you need to do if you run your own server.

What happened

PHP fixed CVE-2026-109618 and CVE-2026-109619 on October 21, 2026. Both are rated CVSS v4 9.2. Exploit details leaked before the release, and honeypots recorded an exploitation attempt on October 17, 2026, four days before disclosure.

On October 23, 2026, PHP disclosed a third related flaw, CVE-2026-115560. Its fix will arrive in PHP's next regular release.

CVEWhat goes wrong
CVE-2026-109618An out-of-memory condition interrupted at the wrong moment leaves request data half-built, and PHP's cleanup later treats it as valid.
CVE-2026-109619After an error interrupts a request, request-owned internal state survives after its memory is freed, and the next request on the same PHP worker can reach it.
CVE-2026-115560A related flaw disclosed on October 23, 2026. The fix comes in PHP's next regular release. Setting session.upload_progress to Off fully protects against it.

How serious is it?

The worst case is remote code execution, reading secrets held in PHP memory (database passwords, API keys), or taking a site down. A working exploit reportedly needs a single unauthenticated request and fires before your application's own code even runs.

What's affected

  • Every PHP version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35, going back to at least PHP 5.4.
  • Every SAPI: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP.
  • WordPress, WooCommerce, Laravel, CodeIgniter and custom PHP code alike.

Updating WordPress, plugins or themes does not fix this. Only patched PHP does.

PHP 8.1 and older get no upstream releases, and PHP 8.2 security support ends on December 31, 2026.

What SkyServer did on shared cPanel hosting

All of this was completed by October 29, 2026:

  • PHP was updated to the patched builds 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
  • session.upload_progress.enabled = Off was set in the server-level php.ini of every installed PHP version, and all PHP workers were restarted so no old, vulnerable worker kept running.
  • Sites on end-of-life PHP 7.4, 8.0 and 8.1 were moved to patched PHP 8.2. Each move was checked automatically: the homepage was tested before and after, with automatic rollback if anything broke. No site needed a rollback.
  • Sites on CloudLinux alt-php were moved to the patched cPanel PHP build of the same version, because no patched alt-php build is available yet. Those alt-php versions are disabled in PHP Selector until a patched build ships.
  • New hosting accounts now default to patched PHP 8.2.
  • Imunify360 stays active as an extra layer.

What you need to do

1. Shared / cPanel hosting

Nothing is required. If you'd like to check, open cPanel → MultiPHP Manager. If your site was moved from PHP 7.4, 8.0 or 8.1 to 8.2 and something looks off (an admin page, checkout, an old plugin), contact support on +91 75096 83151 or open a ticket. It's also a good time to update old themes and plugins, and to plan a move to PHP 8.3 or newer.

2. VPS, Windows RDP and self-managed servers running PHP

SkyServer doesn't manage PHP on these servers, so the update is yours to apply.

  1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distro's patched build. Debian bookworm ships 8.2.35-1~deb12u1 and Debian trixie ships 8.4.27-1~deb13u1. Ubuntu backports keep the old version string, so check the package changelog rather than the version number. 
    # AlmaLinux / Rocky
dnf update -y 'php*'

# Ubuntu / Debian
apt update && apt install --only-upgrade -y 'php8.*'

# cPanel on a VPS
yum update -y 'ea-php*'
  2. Restart PHP-FPM and the web server. Workers started before the update keep running vulnerable code.
  3. Turn off upload progress. Set session.upload_progress.enabled = Off in php.ini or the PHP-FPM pool config (not with ini_set() or .user.ini), restart all workers, then verify: 
    php -i | grep upload_progress.enabled
  4. Stopgap hardening: disable unused uploads and keep post_max_size and upload_max_filesize sensible.
  5. Check your logs. Look through web and PHP-FPM logs from October 17, 2026 onward for unusual multipart upload or session upload-progress requests, and for PHP workers spawning shells or downloading files. If anything looks suspicious, rotate database passwords and API keys.
  6. Can't patch right now? Consider taking the site offline until you can. SkyServer support can do a managed update for you.

Why the PHP update matters more than firewall rules

Firewall (WAF) rules block known request patterns. Attackers tweak their requests, and a rule that matches today's exploit can miss tomorrow's variation. The update fixes the bug itself, which is why we treated it as the real fix and keep Imunify360 only as an extra layer.

Frequently Asked Questions

Do I need to update WordPress to fix php2shell?

No. Updating WordPress, plugins or themes does not fix it. Only patched PHP does. Updating old themes and plugins is still good practice, but it won't close these holes.

How do I check which PHP version my site uses?

On cPanel hosting, open MultiPHP Manager and look at the version listed next to your domain. On a VPS, run php -v, and remember that distro builds may keep an older version string even when patched, so confirm against your distro's changelog.

My site was moved to PHP 8.2. Will it break?

Each move was tested automatically, with the homepage checked before and after and automatic rollback if it broke. No site needed a rollback. If an admin page, checkout or old plugin looks wrong, contact support on +91 75096 83151 or open a ticket.

I have a VPS with SkyServer. Is it patched automatically?

No. SkyServer doesn't manage PHP on VPS, Windows RDP or other self-managed servers, so you need to apply the update yourself using the steps above. Support can do a managed update if you'd rather not.

What is CVE-2026-115560?

It's a third related flaw that PHP disclosed on October 23, 2026. Its fix will come in PHP's next regular release. Setting session.upload_progress to Off fully protects against it, and also closes one known route to CVE-2026-109619.