PHP2Shell: two critical PHP vulnerabilities, the fixed versions, and what GigeNET did

Last updated: October 23, 2026. We will update this post if new information appears.

Two critical vulnerabilities in PHP itself, together called PHP2Shell, let an attacker run code on a web server without logging in. Details leaked online on October 20, 2026. The PHP project released fixes at 14:00 UTC (9:00 AM Central) on October 21. If you run PHP on your own server, update PHP and restart it today. Updating WordPress, Magento or any other application does not fix this.

Below: what happened, who is affected, the fixed versions, how to update and check, and what GigeNET did.

What happened

The two flaws are CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both 9.2 out of 10 (CVSS v4.0).

• CVE-2026-109618: if PHP runs out of memory while it is still reading a request, cleanup can treat half-built request data as valid.
• CVE-2026-109619: data from one request can survive after its memory is freed, and the next request on the same PHP worker can use it.

Researchers at Calif, OpenAI and Wiz found them and reported the first one to PHP on August 11, 2026. Calif named the exploit chain PHP2Shell. The CVE numbers and some details leaked on October 20, so the PHP project posted an advance notice that day. It then shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21 with a security advisory.

Security firms reported exploit attempts the same day. Mass exploitation has not followed so far: researchers at Sansec found that the public exploits don’t work against a default PHP setup and need specific conditions on the server. That is a reason not to panic. It is not a reason to wait.

Who is affected

Any server that uses PHP to answer web requests. The PHP project lists PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed and FrankenPHP. It rates mod_php as the highest risk, because a demonstrated exploit fires before any application code runs.

The flaw is in how PHP reads incoming requests, so the application on top doesn’t matter. Calif confirmed attacks against WordPress, Drupal, Joomla, Magento, WHMCS, phpMyAdmin, Nextcloud, MediaWiki, Roundcube, Laravel and Symfony. According to Calif, the affected code goes back to PHP 5.4 (2012), so treat any PHP server that hasn’t been patched as vulnerable.

The exposure is large. One analysis by CybelAngel, based on Shodan counts, found about 2.24 million internet-facing hosts advertising PHP. Of the roughly 1.5 million that report a version, 59% run a branch with no official PHP release for this fix, though some of those may be patched by their Linux distribution.

Fixed PHP versions

Debian, Ubuntu, Red Hat, AlmaLinux, cPanel (EasyApache 4) and CloudLinux have all published patched packages, including for some older branches. See the Debian, Ubuntu and Red Hat trackers, cPanel’s notice and CloudLinux’s notice.

What to do if you manage your own server

1. Check which PHP you run. php -v shows the command-line version, which can differ from the one serving your site. Also check php-fpm -v (or php-fpm8.3 -v). On cPanel, check every version in WHM’s MultiPHP Manager.
2. Update. Debian and Ubuntu: apt update && apt upgrade. AlmaLinux, Rocky and RHEL: dnf upgrade 'php*'. cPanel: /scripts/update-packages (on our cPanel dedicated servers with management, we run this for you). CloudLinux: dnf upgrade 'ea-php*' 'alt-php*' (a security-only update won’t list these packages). Plesk: update PHP from the panel, then check the package changelog for the CVE.
3. Confirm a backported package has the fix. On Debian or Ubuntu: zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz (use your version). On RHEL-family systems: rpm -q --changelog php-common | grep CVE-2026-109618.
4. Restart every PHP worker. The fix isn’t active until you do. For example systemctl restart php8.3-fpm, systemctl restart apache2 (or httpd), or systemctl restart lsws for LiteSpeed. On cPanel: /scripts/restartsrv_httpd and /scripts/restartsrv_apache_php_fpm.

If you can’t update today: the PHP advisory lists stopgaps that reduce the risk but, in its words, don’t make an installation safe. In php.ini, the FPM pool or the server config (not .htaccess or ini_set()), set session.upload_progress.enabled=0 and memory_limit=-1. On PHP 8.5, also set fatal_error_backtraces=0. Then restart every worker. PHP also suggests request size limits at the web server. Keep session.upload_progress.enabled=0 after you update: a related PHP notice on October 23 recommends it until the next regular release. For a broader hardening list, see our guide to securing a server.

Rather not do this yourself? With Enterprise Server Management, our engineers run the operating system and the software our SLA covers, PHP included, and patch, monitor and troubleshoot it for you. It’s $99 a month per dedicated server or cloud VM, or $79 on a cPanel server. Get a managed server quote.

What GigeNET did

• Before the fix: we were tracking the issue ahead of mainstream news coverage.
• October 21, by 9:00 AM Central, the hour the fixes came out: we had sent advisories to our customers.
• October 21, by the end of the day: every customer environment we manage was patched. Customers on managed servers didn’t have to do anything. Our most public-facing systems were also patched that day, some of them that evening, once third-party software vendors published their fixes.
• Interim protections: where it made sense, we applied the stopgaps from PHP’s own advisory. We disabled the PHP feature these exploits abuse, and blocked file-upload requests at the web server for services that don’t accept uploads.

From the first advisory to patched customer environments, the response took less than one business day. Work on our remaining internal systems continues.

If you run your own server with us (an unmanaged dedicated server, a colocated server or a self-managed cloud server), you control PHP on it, so please follow the steps above. If you’d like our team to do it or check it for you, open a support ticket. To hand patching to us for good, add Enterprise Server Management to a dedicated server or cloud VM.

How to tell if you were hit

There is no official list of signs. These are the signs researchers at watchTowr suggest checking for:

• PHP workers that crashed or hit their memory limit, in the PHP-FPM or web server error logs.
• Unusually large or deeply nested file-upload (multipart) requests in the access logs.
• Files in your web root you didn’t put there, new cron jobs or user accounts, and outbound connections from PHP processes.

As the PHP advisory notes, a clean log doesn’t prove nothing happened. If something looks wrong, open a support ticket and we’ll help you look.

FAQ

Does updating WordPress, Magento or WHMCS fix PHP2Shell?
No. The flaw is in PHP, not the application. Update PHP and restart it.

I’m on PHP 7.4, 8.0 or 8.1. What should I do?
The PHP project won’t ship a new release for these. Install your distribution’s, cPanel’s or CloudLinux’s patched package and check its changelog for the CVE, or move to PHP 8.3 or 8.4.

Does a web application firewall protect me?
Only partly. Firewall rules can block known exploit requests, and vendors describe them as a stopgap. Patch PHP. Our comparison of firewalls and cloud WAFs covers what each one can stop.

Do I need to restart anything after updating?
Yes. Restart PHP-FPM, Apache or LiteSpeed. Until the workers restart, they keep running the old code.

Is PHP2Shell being exploited?
Exploit attempts were reported on October 21. As of October 23, mass exploitation has not been reported.

Already a customer? Open a support ticket or chat with us 24/7. Want someone else to handle patching from now on? Our managed servers include OS patching and 24/7 monitoring, or get a quote.