2 Critical PHP Vulnerabilities Found (PHP2Shell)

Two major PHP vulnerabilities have just been found and published on October 21, 2026 featuring remote code executing in the PHP engine. They are identified as CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state") and are both rated by CVSS 4.0 with a score of 9.2, meaning ‘Critical’, with both of them allowing an attacker with no login to run code on a web server via basic PHP.

These vulnerabilities affect every PHP version released in the last 14 years - including PHP 5. If you are running PHP,  you should consider it being vulnerable unless you apply the updates/patches yourself.

Fixes have been released, requiring updates to the patched versions of PHP:

• 8.5.12

• 8.4.27

• 8.3.36

• 8.2.35

For older versions, there are no official PHP patches from the Linux distributions.

For PHP 7.4, 8.0 and 8.1, which no longer receive regular releases, the PHP devs have published official minimal source patches, so if you build PHP from source, you can apply the patch for your branch and rebuild.

Also several vendors such as cPanel, DirectAdmin, Plesk and others have released patches for older PHP as well, update and check whether your setup and your running applications are on a version that is patched.

Update immediately to ensure your projects are secure. A restart for every PHP worker is also needed. Although some configuration changes lower the risk for now, they are not permanent fixes and the vulnerabilities can only be mitigated by updating and restarting.

VPSBG’s Response

We are fully aware of these reported exploits and have applied patches to all of our internal systems and infrastructure immediately as updates were released.

If you have a shared hosting service or a VPS with additional paid server support with us, we have already patched all PHP versions affected and we’ve sent out notifications. If you did not receive an email, please contact us for more information.

If you have a VPS or a VDS with standard support, we urge you to update as soon as possible and apply patches yourself.

Evaluate every server running PHP across your workloads, especially bundled systems such as WordPress and other CMS instances, admin panels, legacy apps etc.

Update immediately. You may need specific patches depending on your setup. Updating PHP to a patched version is the only safe option, but there are some minimal mitigations that may lower the risk for a while (see mitigations measures in 4).

If your website/app is on PHP 8.1 or earlier, upgrade to PHP 8.2+ as soon as possible. This will ensure that you are on the latest official patch and are covered for future security updates.

If you cannot update immediately, it is recommended that you restrict public network access to PHP applications that don’t need to be reachable. For apps that are critical to continue running publicly, there are some configuration mitigations, but these are not fixes, only lower the risk a bit until you patch:

Settings for php.ini

; ------------------------------------------------------------------
; Interim mitigation for PHP CVE-2026-109618 and CVE-2026-109619
; This is NOT a fix. It only reduces exposure until you can install
; a patched PHP build. Put it in the main php.ini (or the PHP-FPM
; pool / Apache vhost as php_admin_value) and restart PHP-FPM,
; Apache or LiteSpeed afterwards: running workers keep old settings.
; ------------------------------------------------------------------
; Turn off session upload progress tracking.
; Available since PHP 5.4; older versions ignore this line.
session.upload_progress.enabled = 0
; Limit how much request data PHP will parse.
; Use 32M / 30M instead if the site needs larger uploads.
post_max_size = 8M
; Must stay below post_max_size.
upload_max_filesize = 6M
; Avoid aborting on the memory limit while the request is parsed.
; Use ONLY if the PHP service has a memory cap set elsewhere
; (e.g. systemd MemoryMax= / MemoryLimit=), never ulimit -v.
memory_limit = -1

What are the CVE-2026-109618 and CVE-2026-109619 vulnerabilities?

As mentioned, they are both memory-safety false in the PHP engine with those that found the exploits giving them the name PHP2Shell. Both vulnerabilities come from the same weak spot - the execution that PHP follows once a request doesn’t make it all the way through, in most cases due to lack of sufficient memory.

In more basic terms, a PHP worker process can handle a huge number of requests in its lifetime with each one having its own private memory that needs to be wiped once the request ends. However, some worker-wide variables sometimes tend to live longer and because of that - can point to that request memory, which means that if PHP doesn’t reset them before the memory is discarded, then they become a vulnerable point of attack.

But what does that mean? An attacker can send a request built to crash PHP at a very particular moment, leaving a corrupted internal state behind. They can then shape what sits in memory and enforces PHP to act on it, meaning their code can run on your server.

A 20-year-old idea, finished by AI

This vulnerability is not new, AI just made it possible to be confirmed. In 2004, security researcher Stefan Esser published the first remote PHP bug that was related to the memory limit.

In 2020, PHP bug #78876 also showed that long multipart variables could push a request out of memory and in 2024, an external audit of PHP run by OSTIF (carried out by Quarkslab) identified the first signs of the OOM problem, leading into 2026 where AI was used to audit PHP and the vulnerability was finally found to be exploitable.

How the attacks work

Both vulnerabilities share the same things - PHP trusting memory it doesn’t need to. But here’s a more in-depth look at both.

CVE-2026-109618: OOM corruption

An attacker aborts PHP at the right moment, making it run out of memory at the right time.

A multipart upload with an empty filename (filename="") created no file but still built all six $_FILES entries and nested field names (files[a][b][c]...) multiplied that work. Hundreds of these records could go past the default 128 MiB memory limit while the HTTP body stayed under the 8 MiB post_max_size.

When PHP would then hit the limit in the middle of operating, it used an internal jump (longjmp()) to just bail out. In the vulnerable code, a hash-table entry is marked as "in use" before its key is fully allocated. If the allocation fails at that exact instant, cleanup walks over the table and treats the half-built entry as real, reading attacker-tailored bytes as a live structure.

Additionally, on Apache mod_php this cleanup would run even when startup fails, so the attack lands before any application code is able to be executed.

CVE-2026-109619: stale global state

The second vulnerability spans over 2 requests. In the first one, the PHP stores request-owned state in a worker-wide variable (like the session upload-progress handler, the unserializer's bookkeeping or a fatal-error backtrace). A fatal error, including OOM, would then interrupt the request before the matching reset could ever run. PHP then proceeds to free the request's memory, but the worker-wide variable still remains pointing at it.

Furthermore, the same worker proceeds to then handle a second request. Before PHP is able to reset that variable, an early operation (INI diagnostic or another upload-progress call) reads or frees the memory the variable still points to - a classic use-after-free situation. By controlling what gets written into that freed memory, the attacker can then turn the dangling pointer into memory corruption and unsafe code execution. On PHP 8.5 the confirmed path uses the fatal-error backtrace feature, which is on by default.

Who is affected

Given that the flaws live in the PHP engine rather than in any application, the actual exposure is huge..

• All PHP versions before the patched ones

• Server setups - all PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

• All applications like WordPress, Drupal, Joomla, Magento, Laravel, MediaWiki, phpMyAdmin, Nextcloud and the rest are all exposed

Researchers estimate that PHP powers about 70% of all websites and just one attack-surface scan counted over 22 million exposed instances.

How to update your PHP version

If you need to manually update your version, here’s how to do it. Start by checking which PHP version you’re running (and confirm the version used by your web server, PHP-FPM or Apache, as it can differ from the command line):

php -v

This tells you which branch you’re on (e.g. 8.3) and which update applies to you.

Next, make sure to update through your package manager or vendor, not by hand. Linux distributions received the patch in advance. If you use a control panel (cPanel, Plesk, DirectAdmin), update through the panel instead.

Debian/Ubuntu:

apt update && apt upgrade

RHEL/AlmaLinux/Rocky:

dnf update 'php*'

Alternatively, you can pull a patched container image and recreate your containers from it.

Next, restart the PHP workers. A vulnerable worker that is already running in memory stays vulnerable until it restarts, so make sure to restart PHP-FPM (Debian/Ubuntu allow for multiple PHP-FPM versions, so repeat it for each installed version):

Debian/Ubuntu (replace 8.3 with your version):

systemctl restart php8.3-fpm

RHEL/AlmaLinux/Rocky:

systemctl restart php-fpm

If you use Apache with mod_php, restart Apache instead:

Debian/Ubuntu:

systemctl restart apache2

RHEL/AlmaLinux/Rocky:

systemctl restart httpd

Finally, verify the fix by running php -v again. If it shows one of the patched versions listed above (e.g. 8.3.36), you’re done.

Distribution packages often keep the original version number (a patched Ubuntu 24.04 still shows “8.3.6”). If your version number didn’t change, check that your package changelog mentions the CVE:

Debian/Ubuntu:

zgrep CVE-2026-109618 /usr/share/doc/php*-common/changelog.Debian.gz

RHEL/AlmaLinux/Rocky:

rpm -q --changelog php-common | grep CVE-2026-109618

If the command prints a line, the fix is installed. No output means the server isn’t patched yet.

If you use a control panel (cPanel, Plesk, DirectAdmin), note that your server may run several PHP versions and php -v shows only the default one. Check every PHP version your sites use in the panel’s PHP settings, and confirm with your panel vendor’s security advisory that the update you installed includes the fix.