PHP2Shell: PHP vulnerabilities CVE-2026-109618 and 109619 — what to do

Updated: November 8, 2026, based on data from php.net, CVE.org, NVD and CISA. The first version of this article was published on October 21, 2026, before the fixed PHP release came out.

If your hosting provider sent you an email at the end of October about an urgent PHP update, and the news was full of “PHP2Shell,” it was all about one event: two critical vulnerabilities were found in PHP itself, not in a CMS or plugins. On October 21, 2026, PHP released fixes, and on October 26 the US agency CISA added both vulnerabilities to its catalog of vulnerabilities exploited in the wild. Below is what PHP and the CVE databases have officially confirmed, what remains unconfirmed and what a website owner should do: how to check whether the server has been updated, who should do it and what to do with a website on PHP 8.1 or an older version.

What happened: timeline for October 20–26

On October 20, the PHP security team published a pre-announcement on php.net: on October 21 at 14:00 UTC (17:00 Kyiv time), a release would come out to fix two critical vulnerabilities rated 9.2 on the CVSS v4.0 scale. CVSS is the widely used vulnerability severity scale from 0 to 10, and scores from 9.0 up are rated critical. Even before the release, details leaked online, and researchers named the event “PHP2Shell.” This name did not come from PHP.

On October 21, as scheduled, PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and published a security advisory. On the same day, the CVE-2026-109618 and CVE-2026-109619 records appeared in the CVE.org and NVD databases, and Ubuntu released fixed packages. Debian published updates for Debian 12 and 13 in its security repository.

On October 23, PHP added an informational notice about the session.upload_progress.enabled setting (more on it below). On October 26, CISA added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, with a remediation deadline of October 29 for US federal agencies. Inclusion in KEV means that CISA has confirmation of attacks using these vulnerabilities.

What has been officially confirmed

Sources for this section: php.net, PHP advisories on GitHub, CVE.org and NVD records, the CISA KEV catalog.

• Type of vulnerabilities. PHP describes both vulnerabilities as unauthenticated remote code execution (RCE): an attacker can run their own commands on the server without having an account. CVE-2026-109618 is “RCE via memory corruption under memory exhaustion,” CVE-2026-109619 is “RCE via stale global state”. Both are rated 9.2 on CVSS v4.0; NVD additionally rated them 9.8 and 8.1 on CVSS v3.1.
• Who is at risk. All PHP installations that serve web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP sees the highest risk for mod_php: an attack has been demonstrated there in which an unauthenticated request takes effect before the website code even runs.
• Fixed versions. 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All earlier releases of these branches are vulnerable, including 8.2.34, 8.3.35, 8.4.26 and 8.5.11 from September 24, 2026.
• Old branches. PHP 8.1 and older do not receive updates from the PHP project: support for 8.1 ended on December 31, 2025, and for 8.0 in November 2023. Because of the severity of the case, the PHP security team made an exception and published minimal source code fixes for 7.4, 8.0 and 8.1 on GitHub. These are not ready-made releases; they are intended for those who build PHP from source themselves. Linux distributions and extended support vendors received the fixes in advance. NVD lists the vulnerable ranges as starting from version 7.3.0 for CVE-2026-109618 and from version 5.4.0 for CVE-2026-109619.
• There is no full protection without an update. In every release announcement, PHP repeats: there are no complete workarounds, and updating is the only safe choice. Temporary settings reduce the risk only for specific attack paths.
• Attacks are underway. This is confirmed by CISA (the KEV catalog, “active” exploitation status in the NVD records). PHP itself has not mentioned observed attacks in its advisories.
• Support for 8.2 ends on December 31, 2026. PHP gave this reminder in the 8.2.35 release announcement.

What remains unconfirmed

• Scale of the attacks. In the first hours after the leak, the CTO of Cloudflare reported the first attacks, and CERT-EU expected mass exploitation in advisory 2026-018. CISA confirmed that attacks are taking place, but neither PHP nor CISA has published data on the number of affected websites or on the attack variants being used.
• “All versions since PHP 5 are vulnerable.” This wording came from social media, and CERT-EU referred to it. The PHP advisories list only branches 8.2–8.5, and PHP released code fixes for older branches for 7.4, 8.0 and 8.1. The NVD range for CVE-2026-109619 starts at 5.4.0, but this is NVD’s assessment, not a statement by PHP.
• Whether public “exploits” work. Reliable sources have not verified the code passed off in October as an attack tool. This article contains no links to such code and no description of how the attack works: they would not help a website owner.

What to do if your server is not yet updated

Almost three weeks have passed since the fixes were released. If your hosting provider or administrator has still not confirmed the update, check it today.

How to check your PHP version

In WordPress, the version is shown under “Tools → Site Health,” the “Info” tab, “Server” block. On any other CMS, the version is shown in the hosting control panel (cPanel, Plesk, ISPmanager and similar) in the PHP version section. All methods, including checking background tasks (cron), are covered in the article PHP 8.1/8.2 without support: what a website owner should do.

Compare your number with the fixed ones: 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer. If your number is lower, the website is vulnerable, with one exception: Linux distribution packages (more on them below). If you have 8.1, 8.0 or 7.x, go to the section on old versions.

Who updates PHP

On regular (shared) hosting, only the hosting provider can update PHP on the server; you can only choose the branch in the control panel. If your provider has not written about the update, ask their support team directly: whether releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or fixed distribution packages have been installed.

On a VPS or dedicated server, PHP is updated by whoever administers the server: your system administrator, your contractor or you yourself. If the VPS is unmanaged, the provider does not log into the system and will not update PHP for you. After the update, check two things:

• After updating the packages, you need to restart PHP-FPM or the web server: running processes keep the old code in memory, and without a restart the website remains vulnerable. In its advisory, PHP requires restarting every worker process. The restart will cut off requests being processed at that moment, and visitors may see a 502 error for a few seconds. Also restart background PHP processes, such as queue workers.
• In Debian, Ubuntu, RHEL and other distributions, fixes are often backported into a package without changing the main PHP version. An example from this case: in Ubuntu 24.04 the fixed package is called php8.3 8.3.6-0ubuntu0.24.04.13, and php -v still shows 8.3.6. You need to check the package version and the distribution’s security notice (for Ubuntu, USN-8948-1), not just the PHP version number.

PHP is not only used by the main website. Check staging copies, CRM and accounting portals, Docker images (they need to be rebuilt on the fixed version) and server control panels that have their own PHP build.

Updating within a branch is safe

Moving from 8.3.35 to 8.3.36 and moving from 8.2 to 8.3 are operations with different levels of risk. Under PHP’s release rules, versions of the form x.y.z → x.y.z+1 contain only bug fixes and preserve backward compatibility. In the 8.2 and 8.3 branches, the October 21 releases contain exactly one change: the fix for the two vulnerabilities. Code that worked on 8.3.35 will also work on 8.3.36.

Changing the branch (8.2 → 8.3) is a different matter. Every new branch has a “backward incompatible changes” section and a list of deprecated functions, and old plugins and modules may break on it. A branch change is tested on a copy of the website, while a security fix within a branch is installed right away. Make a backup before the update in any case.

Websites on PHP 8.1 and older versions

There are no official releases for 8.1 and earlier branches, and there will be none: under PHP policy, a branch whose support period has ended does not receive fixes. The source code fixes for 7.4, 8.0 and 8.1 on GitHub are only useful to an administrator who builds PHP themselves.

For everyone else, the only option is distribution packages or an extended support vendor. Ubuntu 22.04 received a fixed php8.1 package, and for Ubuntu 20.04, 18.04 and 16.04 fixes were released in the paid ESM program (PHP 7.4, 7.2 and 7.0). If the website is on a VPS with an old operating system, ask your administrator whether a fix has been released for your PHP package. On regular hosting, ask your provider the same question.

If there is no fixed package for your version, the options are:

1. Move the website to a supported branch, preferably 8.3 or newer: support for 8.2 ends on December 31, 2026. The migration steps are described in the article on PHP 8.2 end of life.
2. Until the move is complete, take the website off the open internet or put it behind a filter (see the temporary measures below).
3. Turn off a website that brings in no money and is not needed until the move.

Now that attacks have been confirmed, we do not recommend leaving a website on PHP 8.1 without a fix. Unsupported branches will face further vulnerabilities in the future.

Temporary measures recommended by PHP

None of the measures below replaces an update: in PHP’s words, they reduce the risk for specific attack paths but do not make an installation safe. The list is taken from the PHP advisory of October 21. Before the release there were no official recommendations, and in the first version of this article the session.upload_progress.enabled setting was listed as unofficial.

Settings from the PHP advisory

For CVE-2026-109618, PHP advises setting memory_limit=-1 in a way that the application cannot override (via php_admin_value in the PHP-FPM pool or the Apache configuration) and checking that no pool, directory or website setting brings back a finite limit. The second measure is to limit the request size: post_max_size = 8M for websites without file uploads, post_max_size = 32M if uploads are needed; upload_max_filesize must be smaller than post_max_size. PHP also recommends setting limits on request size and content at the web server or proxy level.

For CVE-2026-109619, PHP advises turning off session.upload_progress.enabled and restarting all worker processes. On PHP 8.5, additionally set fatal_error_backtraces=0, also with a restart. PHP also asks you to remove invalid and deprecated parameters from the website settings that produce warnings at startup and to fix errors in the code that an attacker can trigger with a request. Hiding warnings through error_reporting, display_errors or @ is pointless.

Disabling session.upload_progress.enabled

According to the php.net manual, session.upload_progress.enabled enables tracking of file upload progress through the session and is on by default (value 1). The setting is needed only by upload progress indicators that use a separate request to ask the server for progress from the PHP session. These are rare: a regular upload bar calculated by the browser does not depend on this setting. File uploads themselves keep working as before once it is turned off. The English version of the manual advises turning the setting off wherever progress indicators are not used, regardless of these vulnerabilities.

Where to change it. The setting’s mode is INI_PERDIR, which means it is formally accepted by php.ini, .htaccess (if PHP runs as an Apache module), httpd.conf and .user.ini. But in its advisory PHP requires setting it where the value applies before the request is parsed: in php.ini, the PHP-FPM pool or the server configuration. You cannot rely on ini_set() or on .user.ini with PHP-FPM. In php.ini, the line is:

session.upload_progress.enabled = Off

In httpd.conf (PHP as an Apache module):

php_admin_flag session.upload_progress.enabled off

Unlike php_flag, php_admin_flag cannot be overridden through .htaccess. In the PHP-FPM pool on a VPS, use php_admin_flag[session.upload_progress.enabled] = off, then restart PHP-FPM.

On regular hosting, the setting is changed in the control panel (the PHP settings section) if the provider has made it available there. If there is no such option, ask your hosting provider’s support team to change the setting at the server level: PHP considers a .user.ini file in the website root unreliable for this measure. Then check the result: in the phpinfo() output (your administrator or support team can show it to you), session.upload_progress.enabled should be set to Off.

Whether to keep the setting off after the update. On October 23, PHP published an informational notice: until the next scheduled release, PHP suggests keeping session.upload_progress.enabled=0 to close one more unlikely attack path (CVE-2026-115560). The problem arises only with an unusual combination of settings and application code, so PHP is fixing it in its regular release cycle. If you turned the setting off in October, leave it off; if you do not need upload progress indicators, it makes sense to turn it off on an updated server as well.

WAF

A WAF (Web Application Firewall) is a request filter in front of the website. Cloudflare has released rules for known attack variants, and they are available on the free plan as well; Cloudflare itself calls them a temporary measure. The filter only covers traffic that passes through it: if the server address is known, an attacker will bypass the WAF and go to the server directly. A WAF makes sense only together with a rule that the server accepts requests only from the WAF, and even then the rules catch only known attack variants.

Isolation

CERT-EU advised that where an immediate update is not possible, internet-facing applications should be taken off the public network until fixes are installed. For a business, this means putting internal systems, admin panels, CRM and accounting portals on PHP behind a VPN or restricting access to office IP addresses. A public website cannot be hidden this way; for it, the options are a WAF or temporarily taking it offline.

Signs of a hacked website

The fixes were released on October 21, and attacks have been confirmed. If your server was updated several days late, check it for the following signs:

• unfamiliar PHP files have appeared on the server, especially in upload folders;
• users that no one created have appeared in the admin panel;
• the hosting provider reports a sharp increase in load or spam being sent, or blocks the account;
• search engines or the browser show a warning about a dangerous website, and visitors are redirected to other people’s pages;
• unknown jobs have appeared in the task scheduler (cron);
• for the server administrator: PHP-FPM or web server processes launch a command shell, curl or wget.

A PHP update closes the vulnerability but does not remove what an attacker has already left on the server. If there is even one sign, an update alone is not enough: you need to find and remove malicious code and change passwords and keys. The steps are described on the hacked website recovery page.

How RIVERIT can help

We respond to clients on technical support within one hour during business hours, and we fix incidents outside business hours too, if your plan includes this. For VPS and dedicated servers, we offer server administration: firewall, isolating websites from each other, log analysis, and during attacks we set up DDoS protection. If there are already signs of hacking, we take on website recovery. For those who need a server together with maintenance, we offer secure hosting on servers in Europe with daily backups to separate storage.