# PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what it is and how to tell if your website is affected

> PHP2Shell (CVE-2026-109618 and CVE-2026-109619): affected versions, how to check yours and what to do if you can't update PHP on an older website.

URL: https://webintacta.com/en/guides/php2shell-vulnerability
Language: English (Spanish version: see the hreflang alternate of the HTML page)
Last updated: 2026-10-24

**In short:** Your website is affected if it runs on PHP (WordPress, PrestaShop, WooCommerce, Joomla, Drupal or Magento) and its version is older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 depending on the branch, or if it is still on PHP 8.1 or earlier, which has no official fixed release. PHP2Shell is the name for two critical flaws published on October 21, 2026 (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) that allow code to be run on the server without a password. What to do now is update PHP from your hosting dashboard or ask your provider to; if your website doesn't work with a newer PHP, ask your host for a version with the patch (backport), apply the temporary server-side measures and plan the migration with dates.


By Jose Soriano (WebIntacta) · published 2026-10-24

On October 21, 2026 the PHP team published an advisory with an unusual headline: critical remote code execution vulnerabilities, update now. Since almost every small-business website and store I review runs on PHP, this guide gets straight to the point: whether it affects you, how to find out which version you have, what to update to and what to do if your website can't run on a newer PHP, which is very common with older PrestaShop stores. I don't explain how the flaw is exploited: you don't need that to protect yourself.

## What PHP2Shell is

It is the name given to two vulnerabilities in PHP itself, the language WordPress, PrestaShop and most content management systems run on: **CVE-2026-109618** (advisory GHSA-w8hw-w9fx-j79w) and **CVE-2026-109619** (advisory GHSA-6wmf-4rv5-p3rp). Both have a severity of **9.2 out of 10** (CVSS 4.0) and can be exploited **without a username or password**, just by sending requests to the website.

“Remote code execution” means that whoever pulls it off can run their own code on your server: install a backdoor, read the database with your customers or insert a script that copies cards at checkout. That is why the official advisory doesn't mince words: the only complete fix is to update PHP.

> At the time of publication, CISA (the US Cybersecurity and Infrastructure Security Agency) had not observed real attacks exploiting these flaws. That can change once so many websites are left unpatched, so it is not worth waiting, but there is no reason to panic either: for most websites it is a maintenance update, and for those that can't update there is a layered plan further down.

## Who is affected?

Any PHP installation that serves web requests, regardless of what you have installed on top of it:

- **WordPress and WooCommerce**, **PrestaShop**, **Joomla**, **Drupal** and **Magento**: they all run on PHP.
- **Custom PHP websites** (Laravel, Symfony, CodeIgniter or in-house code).
- **Every way of running PHP on the server**: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk is **Apache with mod_php**, because the flaw can trigger before your website's code even runs; with PHP-FPM or LiteSpeed the risk is lower, but you still need to update.

It doesn't affect you directly if your store is on a hosted platform such as **Shopify** or **Wix**: there you don't manage PHP and the server is the provider's job.

## Affected and fixed versions

| PHP branch | Fixed in | What to do |
| --- | --- | --- |
| 8.5 | 8.5.12 | Update to 8.5.12 or later |
| 8.4 | 8.4.27 | Update to 8.4.27 or later |
| 8.3 | 8.3.36 | Update to 8.3.36 or later |
| 8.2 | 8.2.35 | Update to 8.2.35 or later, and plan the branch change: 8.2 reaches end of support on December 31, 2026 |
| 8.1, 8.0 and 7.x | No official release | Move to a supported branch (8.3 or later). PHP has only published minimal source-code patches for 7.4, 8.0 and 8.1; some Linux distributions and extended-support vendors publish their own patches. If the website doesn't accept a newer PHP, follow the plan below |

Based on the php.net advisory of October 21, 2026 and the GHSA advisories in PHP's official repository.

> If your version has something appended, like `8.1.2-1ubuntu2.20` or `8.2.28-1~deb12u1`, it is a Linux distribution package. Those distributions sometimes fix the flaw without changing the main number, so the version is **probably** affected, but only your provider can confirm whether its patch has been applied. Ask for it in writing.

## How to find out which PHP version your website runs

1. **In your hosting dashboard.** Look for “PHP version”, “Select PHP version” or “MultiPHP Manager” (cPanel), or “PHP Settings” (Plesk). There you see the branch and sometimes the full version.
2. **From your website.** In WordPress: **Tools → Site Health → Info → Server**. In PrestaShop: **Advanced Parameters → Information**. In Joomla: **System → System Information**. In Drupal: **Reports → Status report**.
3. **With the free scan.** If your server announces its PHP version in its headers, the [free scan](https://webintacta.com/en/free-website-security-scan) reads it and tells you whether it is affected. If it is hidden (which is recommended), it will tell you it can't be checked from outside.
4. **With the read-only connector.** The [WebIntacta connector](https://webintacta.com/en/read-only-connector) reads the exact version from the inside, without relying on what the server announces, and also how PHP is run (mod_php or FPM).

Some people upload a `phpinfo()` file to see it. It works, but it shows a lot of internal information about the server: if you do it, delete it as soon as you have checked the version.

## What to do now

1. **Update PHP** to the fixed version of your branch or to a newer branch. On many hosts you choose the branch in the dashboard and the provider installs the fixes within each branch; if you can't see the exact version, ask whether they already have 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
2. **Check the version afterwards**, by any of the methods above. If the dashboard changed it but the server is still running old processes, the version doesn't change until they are restarted.
3. **Test the website** the way a customer would: home page, forms and, if it is a store, a full purchase through to payment.
4. **If your website can't run on a newer PHP** (or your host doesn't offer one), follow the layered plan in the next section and set a date to update.

## October 23 update: CVE-2026-115560

Two days later, PHP published another advisory: CVE-2026-115560, a flaw in session upload progress tracking (`session.upload_progress`). It is very different from PHP2Shell: PHP considers it unlikely, because it only affects applications that change `session.serialize_handler` to `php` while running, which is uncommon. It has no fixed release yet and **the PHP2Shell updates don't fix it**.

What to do: **keep `session.upload_progress.enabled = 0` in the server configuration, even if you have already updated PHP**. It is the same measure as in the next section, so if you have already applied it there is nothing more to do; just don't remove it when you update. I will update this guide when the release that fixes it comes out.

## If you can't update PHP (old PrestaShop, incompatible modules or plugins…)

It is the situation of many stores and websites I review: a PrestaShop 1.6 or 1.7 with modules or a theme that don't work with a newer PHP, a WordPress site with old plugins, custom code or a host that doesn't offer another version. Updating is still the only complete fix, and for PHP 8.1 and earlier there is no official fixed release. But between “update now” and “do nothing” there is a layered plan that reduces the risk while you prepare the migration. In this order:

> Everything in this section is **temporary and not a complete fix**. It buys time with the risk contained, not a way to stay like this.

### 1. Ask your host whether its PHP already includes the patch

php.net mentions minimal source-code patches for PHP 7.4, 8.0 and 8.1, and that some Linux distributions and extended-support vendors publish their own patches (what is called a “backport”): the same PHP version with the fix applied. Since the version number doesn't change, you can't see it from outside: you have to ask.

- **What to ask:** whether your website's PHP includes the patch for CVE-2026-109618 and CVE-2026-109619, in which package and exact version, and where you can see it.
- **How they should confirm it:** with the package changelog or the security advisory of the distribution or vendor, listing both CVEs. A bare “we're protected” is not enough.
- **Where the patch usually comes from:** the distribution's security updates (Debian, Ubuntu or the Red Hat family), the extended-support PHP vendors many hosts use or, on your own VPS, compiling PHP with the patches php.net mentions. Ask whether that is your case: I don't assume any provider has already done it.

### 2. Temporary measures in the server configuration

php.net and the advisory in PHP's official repository publish them for installations that can't update. They go in the PHP-FPM pool, the Apache configuration or the main `php.ini`, never in your website:

- Set `memory_limit=-1` with `php_admin_value`, so no application can change it. It is the main measure, but it has a cost: a runaway script can eat the server's memory, so it has to go together with a memory limit on the service or container (cgroup) and request size limits in the web server.
- Lower `post_max_size` to `8M` if the website doesn't receive file uploads, or to `32M` if it does, with `upload_max_filesize` below it, and also limit request size in nginx or Apache.
- Lower `max_input_nesting_level` and cap `max_input_vars` and `max_file_uploads`.
- Disable `session.upload_progress.enabled` (set it to `0`). On PHP 8.5, also `fatal_error_backtraces=0`.
- If the website doesn't use forms with file uploads, block those requests in the web server before they reach PHP. Careful: the PrestaShop and WordPress admin panels do upload images this way; test it first.
- **Restart every PHP process** and check, pool by pool, that no setting puts a limit back on `memory_limit`. The advisory advises against using `RLIMIT_AS` or `RLIMIT_DATA` as a substitute.

```
; In the website's PHP-FPM pool (never in .user.ini)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 16M
php_admin_flag[session.upload_progress.enabled] = off
```

On shared hosting you can't touch that configuration: you have to ask your provider for it. On a VPS or your own server, whoever administers it does it. The report's remediation pack includes the email for your host, the configuration for PHP-FPM, Apache and nginx, and how to check it has been applied.

### 3. A firewall in front

A WAF or a CDN with a firewall in front of the website filters some of the anomalous requests. CISA considers it **only partial protection**: it adds a layer, it doesn't replace the patch.

### 4. Daily monitoring so you find out early

If something gets through, the sooner you see it, the less damage it does. CISA recommends watching for PHP processes that launch system commands or download tools; your host sees that in its logs. On your side:

- A daily check for file changes, with an alert if something new appears: that is what the [read-only connector](https://webintacta.com/en/read-only-connector) and the [website maintenance plans](https://webintacta.com/en/website-maintenance) do.
- Watch for new `.php` files in upload or image folders, admins nobody created and new scheduled tasks.
- A daily backup stored off the server.

### 5. A migration plan with dates

The measures above buy time; the way out is being able to use a supported PHP. Put a date on each step (test on a copy, update the website, switch PHP and verify), because your website's version sets the pace:

- **PrestaShop 1.7** runs on PHP 7.4 at most, and **PrestaShop 8** up to PHP 8.1. To use a supported PHP you have to move to **PrestaShop 9**, which runs on PHP 8.1 to 8.4 (8.5 from 9.1). I explain it in [upgrade PrestaShop](https://webintacta.com/en/guides/upgrade-prestashop) and in [is PrestaShop 1.7 still safe?](https://webintacta.com/en/guides/is-prestashop-1-7-still-safe). If you pass through PHP 8.1 for that jump, make it a test step of a few hours, not the destination.
- **WordPress** runs on PHP 8.3 from version 6.4 and on 8.4 from 6.7. The core usually works fine; what breaks are **old plugins and themes** nobody has updated in years.
- **Custom websites** and very old modules may use functions PHP has removed: test them on a copy before switching.

The effort varies a lot: on a WordPress site with up-to-date plugins it can be a few hours; on a PrestaShop 1.6 or 1.7 with a custom theme and modules, days or weeks. CISA recommends that, if a website on PHP 8.1 or earlier can't be patched, you consider taking it offline until it is updated. For a store that sells every day that isn't always viable, so the dates in the plan have to be short.

This is exactly the kind of work I do: I check your version, ask your host for the patch, apply the temporary server measures or handle them with your host, set up daily monitoring and prepare the migration plan with dates.

## What isn't enough

- **A .user.ini or an ini_set() in the code.** The measures have to be set by the server, with the processes restarted; per folder or from the application they don't work.
- **A WordPress security plugin or a PrestaShop module.** The flaw is in PHP, underneath your website; with mod_php it can trigger before the plugin even runs.
- **A web application firewall (WAF).** CISA considers it only partial protection: it helps, but it doesn't replace the update.
- **Changing passwords.** Always a good idea, but this flaw doesn't need any.

## What if I have already been attacked?

Updating PHP closes the door, but it doesn't throw out anyone who already got in. Check for these signs, especially if your website ran an affected version for days:

- `.php` files you don't recognize, in the root or in upload and image folders.
- Admins or employees nobody created.
- New scheduled tasks in the hosting dashboard.
- Connections from the server to unknown domains, or PHP processes launching system commands (CISA recommends watching exactly that; your host can see it in its logs).

The full list is in [how to tell if your website is hacked](https://webintacta.com/en/guides/how-to-tell-if-website-is-hacked). If you find something, don't update on top of it or delete blindly: the steps are in [recover a hacked website](https://webintacta.com/en/guides/recover-hacked-website).

## How I can help

Start with the [free scan](https://webintacta.com/en/free-website-security-scan): in a few minutes you will know whether your server announces an affected version. If you want me to sort it out, [Report + hardening](https://webintacta.com/en/pricing#packs) (€299 for a business website; stores, on the pricing page) includes the full security report with the connector, the fix of the urgent findings (up to 3 hours: updating PHP or, if the website doesn't allow it, asking your host for the patch and applying or arranging the temporary measures with them, and checking compatibility) and a new scan to confirm it. If the website needs a PrestaShop or WordPress version jump before PHP can be raised, I leave you the migration plan with dates and quote it separately, at a fixed price. Prices excluding VAT.

## Sources

- [php.net](https://www.php.net/): advisory of October 21, 2026 “Critical remote code execution vulnerabilities, update now” (fixed versions, branches without an official release, source-code patches and temporary measures).
- [GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) and [GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), advisories in PHP's official repository (including the measures for installations that can't update).
- [NVD: CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) and [NVD: CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619).
- PHP advisory of October 23, 2026 on CVE-2026-115560 (session upload progress), reported by [The Hacker News](https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html) and [Security Affairs](https://securityaffairs.com/201595/security/php-warns-of-new-code-execution-flaw-days-after-php2shell-patches.html).
- [CISA: Critical Vulnerabilities in PHP Require Immediate Patching](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) (October 21, 2026).

## Frequently asked questions

### Does my shared hosting update it automatically?

It depends on the provider. On many, you choose the PHP branch (8.2, 8.3…) and the host installs the fixes within each branch, but not always on the same day, and it never moves you to another branch without warning. Check it yourself with the exact version or ask them in writing.

### What if my hosting is with IONOS, Hostinger or another big company?

The size of the provider doesn't change what you have to do: check your website's exact PHP version and, if it is older than the fixed release of its branch, update it from the dashboard or ask support. Each provider rolls out updates at its own pace; I don't assume the status of any of them.

### How do I know if I have already been attacked?

Look for PHP files you don't recognize, new admins, strange scheduled tasks and connections from the server to unknown domains. The [free scan](https://webintacta.com/en/free-website-security-scan) checks what is visible from outside and the [read-only connector](https://webintacta.com/en/read-only-connector) checks files and admins from the inside.

### My PrestaShop doesn't work with PHP 8.2. What do I do?

It is the usual case: PrestaShop 1.7 runs on PHP 7.4 at most and PrestaShop 8 up to 8.1, and to use a supported PHP you have to move to PrestaShop 9. While you prepare that jump, ask your host to confirm in writing whether its PHP includes the patch (backport) for CVE-2026-109618 and CVE-2026-109619 and to apply the temporary measures in the server configuration, monitor the files daily and put a date on the migration. It is the plan in the “If you can't update PHP” section.

### Do settings in .user.ini or a security plugin help?

No. The temporary measures have to be set in the server configuration (php.ini, PHP-FPM pool or Apache) with the PHP processes restarted; a .user.ini or an ini_set() is not enough. And a WordPress security plugin or a PrestaShop module runs on top of PHP: with mod_php, the flaw can trigger before it even runs.

### Does my host's firewall protect me?

Only partly. CISA considers a WAF partial protection: it is one more layer, alongside the host's patch and the server measures, but what fixes the flaw is updating PHP or using a PHP with the patch applied.

## About the author

[Jose Soriano](https://webintacta.com/en/about): Full-stack developer specialized in PrestaShop, WordPress and WooCommerce, who has passed the official PrestaShop course and exam. He has been building online stores and modules since 2023 and is the founder of WebIntacta, the website security service through which he scans, cleans and maintains small-business websites and online stores himself, remotely from Ibi (Alicante, Spain). WebIntacta facts: https://webintacta.com/en/about#datos