# PHP2Shell and the Next.js Flaws of October 2026: Is Your Store Safe?

**October 2026 brought two sets of critical web flaws, and attackers went after the PHP ones before the fix was even public.** PHP2Shell (CVE-2026-109618 and CVE-2026-109619) can let someone who is not logged in run code on a server that runs PHP. PHP fixed it on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A week earlier, on 14 October, Next.js fixed two critical remote code execution flaws and one denial of service flaw in versions 16.4.1 and 15.5.28. CISA, the US cybersecurity agency, put both PHP flaws on its list of actively exploited vulnerabilities on 26 October and gave US federal agencies until 29 October to patch.

If your store runs on WordPress with WooCommerce, PrestaShop, Magento, OpenCart, Laravel or any other PHP software on hosting you manage, this concerns you, and updating your plugins will not fix it. The PHP version under the store has to change. This guide explains what each flaw does, what an attacker can take from a cash on delivery store, how to check your versions and which release fixes what. Every date and version below comes from vendor advisories and security firms' reports, read on 29 October 2026.

<!-- -->

![October 2026 PHP and Next.js vulnerabilities: a laptop showing an online store behind a warning shield, with a padlock being repaired](/assets/images/en-cover-a5d990f703ad46eb6cc6ebd82b9c1928.webp)

## The October 2026 flaws at a glance

| Flaw                                                    | Identifier                          | Severity                                   | Who is exposed                                                        | Fixed in                                 | Exploited                      |
| ------------------------------------------------------- | ----------------------------------- | ------------------------------------------ | --------------------------------------------------------------------- | ---------------------------------------- | ------------------------------ |
| PHP memory corruption when a request runs out of memory | CVE-2026-109618                     | Critical, 9.2 (CVSS 4.0, rated by PHP)     | Every PHP site that serves web requests                               | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35       | Yes, CISA catalog since 26 Oct |
| PHP stale state reused by the next request              | CVE-2026-109619                     | Critical, 9.2 (CVSS 4.0, rated by PHP)     | Every PHP site that serves web requests                               | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35       | Yes, CISA catalog since 26 Oct |
| PHP session upload progress                             | CVE-2026-115560                     | No score published                         | Only apps that switch `session.serialize_handler` to `php` at runtime | Not fixed yet, workaround available      | No report                      |
| Next.js `use cache` code execution                      | GHSA-673q-mjm6-r5xr (no CVE)        | Critical, 9.5 (CVSS 4.0, rated by Next.js) | App Router with Cache Components, 16.0.0 to 16.4.0                    | Next.js 16.4.1                           | Not in the CISA catalog        |
| Next.js image optimization with SVG                     | CVE-2026-96889, GHSA-2464-fhr4-w9xw | Critical, 9.5 (CVSS 4.0, rated by Next.js) | Next.js on glibc Linux, from 10.0.0                                   | Next.js 16.4.1, 15.5.28 and sharp 0.35.5 | Not in the CISA catalog        |
| Next.js Server Actions denial of service                | CVE-2026-94482, GHSA-p3m5-59mp-jv5r | High, 8.2 (CVSS 4.0, rated by Next.js)     | App Router with at least one Server Action, from 13.0.0               | Next.js 16.4.1, 15.5.28                  | Not in the CISA catalog        |

The Exploited column refers to the Known Exploited Vulnerabilities catalog as published on 29 October 2026. Scores differ between scorers: NVD gives CVE-2026-109618 a 9.8 and CVE-2026-109619 an 8.1 on the older CVSS 3.1 scale.

## What PHP2Shell is and why it is serious

PHP2Shell is two separate bugs in the PHP engine itself, the program that runs WordPress, WooCommerce, PrestaShop, Magento and most of the web's stores. PHP describes them this way in its advisory:

* **CVE-2026-109618:** when a request runs out of memory, PHP can be interrupted while its internal request data is only partly set up. The cleanup step then treats that broken data as valid. An attacker can push a request into that state with a crafted file upload request, even within the server's normal size limits.
* **CVE-2026-109619:** internal state that belongs to one request can survive after its memory has been freed, and the next request handled by the same PHP worker can use it. PHP confirmed code execution through the session upload progress feature, which is on by default, and through the error backtrace path of PHP 8.5.

Neither bug needs a login, and on mod\_php the first one fires before your store's own code even starts. PHP lists the exposed setups as PHP-FPM, Apache with mod\_php, php-cgi, FrankenPHP and LiteSpeed, and considers the risk highest for mod\_php. Researchers at Calif confirmed code execution before login on WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, Magento 2.4.9, phpMyAdmin 5.2.3, Laravel 13.11 and Symfony 8.1, among others.

The affected range is wide. NVD's records start at PHP 7.3.0 for the first bug and PHP 5.4.0 for the second. Supported fixes exist for 8.2 and newer. For PHP 7.4, 8.0 and 8.1, which reached end of life, the PHP security team published minimal source patches, and PHP 7.3 and older received nothing from PHP.

### How the disclosure unfolded

Calif reported a remote code execution to PHP on 11 August 2026, and Wiz sent its own report on 24 August. OpenAI's Codex Security team found parts of the problem too. The fix was planned for 22 October, but the two CVE numbers started circulating on forums around 15:00 UTC on 20 October, so PHP moved the release to 21 October at 14:00 UTC. On the evening of 20 October, Calif also published a proof of concept video by mistake.

Amazon's honeypot network had already logged an exploitation attempt on 17 October, four days before disclosure. On 24 October a researcher reported successful exploitation of three honeypot servers running PHP 8.4.26, and on 26 October Trail of Bits confirmed working exploits against unpatched PHP 8.2 through 8.5. A public sensor network run by Delft researchers counted more than 73,900 exploitation requests from 676 IP addresses in 73 countries between 21 and 29 October.

Some experts expect fewer mass attacks than the headlines suggest. Sansec, which specializes in store security, wrote that an attack needs specific knowledge of the target server, and Red Hat calls code execution on its standard PHP-FPM setup difficult in practice. Neither says a store can skip the update.

## What an attacker can do on a hacked store

Remote code execution means the attacker's code runs with the same rights as your store's code. On a typical PHP store, that gives access to the configuration file holding the database password, and from there to every table. For a store that sells cash on delivery in Algeria, the database is the business: the name, phone number, wilaya, commune and full address of every buyer, plus their order history.

The same access reaches the API keys saved in your settings: courier accounts, SMS or WhatsApp senders, Facebook and TikTok pixel tokens. An attacker can also change the checkout page, swap the phone number buyers call, or plant a hidden file that lets them come back after you patch.

What attackers did in October is documented. The Delft sensors recorded droppers that fetch Mirai-derived bots, which use the hacked server to flood other sites, and a backdoor written in Nim that poses as a program called "sysmon". On 28 October CISA added a Linux kernel flaw, CVE-2026-46300, noting that it can be chained with PHP2Shell to plant PHP webshells and run commands as root, the highest level of control over the machine.

As of 29 October no public report names a store breached through PHP2Shell, and no source reports card skimmers delivered through it. A backdoor planted during the window before you patched can stay after the update, so the checks in the next sections matter even on a server that is already up to date.

## Is my PHP site affected?

Any PHP build without the October fixes is affected. Where you stand depends on who runs PHP for you.

**Hosted store platform.** The platform runs PHP for you, so the platform has to patch it. Ask them if they have not said anything (DZBuild's answer is at the end of this guide).

**Shared hosting with cPanel or Plesk.** The panel shows the PHP version, but distributions often keep the old number on a fixed build. cPanel shipped the fix in EasyApache 4 release 25.91 on 21 October for ea-php74 through ea-php85. Plesk says its end-of-life 7.4, 8.0 and 8.1 builds keep the same version number, and the fix is identified by a build date of 21 October 2026 or later.

**Your own server (VPS).** The `php -v` command shows the command line PHP, which can differ from the PHP that serves your web pages. Check the package changelog instead:

```
php -v

# Debian and Ubuntu: replace 8.3 with your PHP branch

zgrep CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz

# Red Hat, AlmaLinux, Rocky Linux

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

A line mentioning the CVE means your package contains the fix. Hiding the `X-Powered-By` header with `expose_php = Off` does not protect you; VirusTotal's analysis puts it simply: it hides the header, not the vulnerability.

## How to fix PHP2Shell

**On shared hosting**, write to your host and ask these precise questions: which PHP build serves my site, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619? Were the PHP workers restarted after the update? A good answer names 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution build that lists both CVEs, and confirms the restart.

**On a Debian or Ubuntu server**, install the updates and restart PHP. Installing a package does not patch PHP processes that are already running, so the restart is part of the fix:

```
sudo apt update

sudo apt upgrade

# replace 8.3 with your branch

sudo systemctl restart php8.3-fpm

# if your site uses Apache with mod_php

sudo systemctl restart apache2
```

The fixed packages are 8.2.35-1~~deb12u1 on Debian 12, 8.4.27-1~~deb13u1 on Debian 13 and 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04. To confirm that the running PHP-FPM uses the new binary, run `sudo ls -l /proc/$(pgrep -o php-fpm)/exe`: the word `(deleted)` at the end means the old program is still in memory and the restart did not happen.

**With Docker**, pull a fixed official image such as `php:8.5.12-fpm`, `php:8.4.27-apache` or `php:8.3.36-fpm-alpine`, rebuild your image and redeploy it. The official PHP image received no fix for 8.1 or older.

**On PHP 8.1 or older**, move to a supported branch. PHP 8.2 reaches end of life on 31 December 2026, so 8.4 or 8.5 buys more time. Backported builds exist from Ondřej Surý's repository, Remi, Ubuntu Pro, Freexian and TuxCare if you need a few more weeks.

**If you cannot update today**, PHP lists partial measures: set `memory_limit=-1` in a way applications cannot override, cap `post_max_size` at 8M without uploads or 32M with uploads, set `session.upload_progress.enabled=0` and, on PHP 8.5, `fatal_error_backtraces=0`, then restart every worker. PHP says these block only some attack paths, and watchTowr considers configuration changes ineffective. Cloudflare has blocked known attack patterns for its free and paid WAF customers since 21 October at 03:02 UTC. None of this replaces the update.

**After patching**, look for traces: PHP files you did not upload, especially in upload folders, cron jobs you did not create, new administrator accounts, and POST requests containing `PHP_SESSION_UPLOAD_PROGRESS` in your logs. If you find any of them, clean the server, then change the database password and every API key stored on it.

## The third PHP flaw: CVE-2026-115560

On 23 October PHP published an informational advisory about a separate, "unlikely" code execution path in session upload progress. It also affects fully patched PHP, 8.5.12 included. It only applies when an application sets `session.serialize_handler` to `php_binary` or `php_serialize` in its configuration, then switches it to `php` with `ini_set()` before starting the session.

PHP will fix it in its next regular release, which has no date yet, and publish the full advisory then. Until that release the workaround is the same setting as above, `session.upload_progress.enabled=0`. On 29 October the flaw had no CVSS score and no NVD record, and no exploitation had been reported.

## The Next.js security update of 14 October 2026

Next.js announced the release on 8 October and published it on 14 October. Two of its three fixes had been held back from the 30 September security release while upstream projects coordinated. All three are in 16.4.1 and 15.5.28.

**The `use cache` flaw (GHSA-673q-mjm6-r5xr).** In apps that use the App Router with Cache Components, a `use cache` function that returns several typed arrays can lead to code execution without login. It affects 16.0.0 to 16.4.0. Next.js says there is no workaround and asks everyone on 16.x to upgrade even without such a function. The matching React fix shipped the same day in `react-server-dom-webpack`, `-turbopack` and `-parcel` 19.0.9, 19.1.10, 19.2.9 and 19.3.1. No CVE number had been assigned on 29 October.

**The image optimization flaw (CVE-2026-96889, GHSA-2464-fhr4-w9xw).** Next.js resizes images through the sharp library, which uses librsvg to read SVG files. A use-after-free bug in librsvg, triggered by a crafted SVG, can lead to code execution when Next.js runs on glibc-based Linux. The fix is sharp 0.35.5, released on 27 September with librsvg 2.63.2. Next.js 16.4.1 and 15.5.28 raise their sharp requirement, and every Next.js from 10.0.0 up to those releases is affected. The advisory does not limit the risk to sites that turned on the `dangerouslyAllowSVG` option, and a third-party repository published on 16 October claims a lab exploit that works with the default configuration. We have not tested that claim.

**The Server Actions flaw (CVE-2026-94482, GHSA-p3m5-59mp-jv5r).** Crafted requests to an App Router app with at least one Server Action can max out the CPU and block every other request in the same process, which can take the store offline. Apps on the Pages Router or without Server Actions are not exposed. It affects 13.0.0 and later, and there is no workaround.

None of the three was in CISA's exploited catalog on 29 October, and the Cloud Security Alliance found no reports of active exploitation as of 15 October. Next.js has a recent history here: React2Shell (CVE-2025-55182), a 10.0 (CVSS 3.1) flaw in React Server Components disclosed in December 2025, entered the CISA catalog two days after its disclosure.

**Next.js 13 and 14 got no patch.** Both are unsupported. The last releases were 14.2.35 in December 2025 and 13.5.11 in March 2025, yet both versions fall inside the affected ranges of the image and Server Actions flaws. The only way out is 15.5.28 or 16.4.1. Next.js 15 keeps receiving security releases until 31 January 2027.

## How to check and update a Next.js store

Run these in your project folder:

```
npx next --version

npm ls next sharp

node -e "console.log(require('sharp').versions)"
```

You want Next.js 16.4.1 or 15.5.28 (or later), sharp 0.35.5 or later, and an `rsvg` value of 2.63.2 or later in the last output. The `next info` command does not show sharp, so check it separately. To update:

```
npm install next@16.4.1    # on Next.js 16

npm install next@15.5.28   # on Next.js 15

npm install sharp@^0.35.5
```

There is a trap on Next.js 15: version 15.5.28 still accepts sharp 0.34.x, which never got a fix, so a lockfile that pins an old sharp keeps you exposed after the Next.js upgrade. Install sharp explicitly as shown above. If you deploy with `output: 'standalone'` in Docker, the image carries the `node_modules` it was built with: rebuild and redeploy it. On Netlify, old deploy previews and branch deploys can stay exposed until they are deleted. We found no statement from Vercel that apps on its platform were protected automatically against these three flaws, so upgrade and redeploy there too.

Node.js itself had a security release on 21 October with 10 CVEs, including a Brotli decoder flaw (CVE-2026-111497) that can lead to remote code execution. The fixed versions are 22.23.4, 24.22.1 and 26.12.1. Node.js 20 reached end of life on 30 April 2026 and gets no fix.

## Other October 2026 flaws that hit online stores

* **Drupal Commerce Core (CVE-2026-118539):** an access bypass rated "Highly critical", published on 28 October and exploited in the wild. Fixed in 3.3.13 and 8.x-2.41. Drupal asks sites to audit their orders for inconsistencies.
* **Magento and Adobe Commerce BlockStrap (CVE-2026-103849):** code execution without login, rated CVSS 10.0, fixed on 13 October in APSB26-153 with manual patches for Magento Open Source 2.4.7-p10, 2.4.8-p5 and 2.4.9. Sansec had seen no attacks on live stores yet.
* **Adobe Commerce PolyShell (CVE-2026-48356):** a file upload flaw known since March 2026, added to CISA's exploited catalog on 27 October.
* **Malicious npm packages:** GitHub's advisory database published 948 npm malware advisories between 1 and 29 October 2026. Check any package you add to a JavaScript store before installing it.

## A checklist for store owners who host their own site

1. Find out which PHP version serves your store, from your host or with the commands above.
2. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution build that lists both CVEs.
3. Restart PHP-FPM or Apache so the running program is the new one.
4. Leave PHP 8.1 and older for a supported branch.
5. If your store uses Next.js, move to 16.4.1 or 15.5.28 and sharp 0.35.5, then rebuild and redeploy.
6. Look for unknown PHP files, cron jobs and administrator accounts.
7. If anything looks wrong, change the database password and every API key after cleaning the server.

## DZBuild stores: nothing to do

DZBuild merchants do not manage servers, so none of the steps above apply to them. The PHP security releases of 21 October 2026 were running on DZBuild's servers on 22 October, the day after PHP published them. DZBuild storefronts do not use Next.js, so the 14 October flaws do not reach them. The third PHP flaw needs a session setting that DZBuild never changes. There is nothing to update, no host to write to and no server to restart.

If you run a self-hosted WooCommerce or PrestaShop store and would rather sell than spend a week on security updates, [create a DZBuild store for free](https://dzbuild.com/register). Cash on delivery, the wilaya and commune lists and the courier connections are built in.

## Frequently asked questions

**What is PHP2Shell?** PHP2Shell is the name given to two flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, published on 21 October 2026. Both can let an attacker who is not logged in run code on a web server that runs PHP. PHP rates both 9.2 out of 10 (CVSS 4.0, Critical).

**Which PHP versions fix PHP2Shell?** PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Linux distributions ship the fix under their own version numbers, for example 8.2.35-1\~deb12u1 on Debian 12 and 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04. From the PHP project, PHP 7.4, 8.0 and 8.1 only received source patches, and PHP 7.3 and older received no fix.

**Will updating WordPress, WooCommerce or PrestaShop fix PHP2Shell?** No. The flaws are in the PHP engine, not in the store software. Only a PHP update fixes them. PrestaShop said it plainly: updating PrestaShop or its modules will not fix this and there is no PrestaShop patch to install.

**Is PHP2Shell being exploited?** Yes. Amazon saw a first attempt on 17 October 2026, four days before the fix was public, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026. By 29 October one public sensor network had logged more than 73,900 exploitation requests from 676 IP addresses in 73 countries.

**How do I know if my store was hacked through PHP2Shell?** Look for PHP files you did not upload, especially in upload folders, cron jobs you did not create, new administrator accounts, and POST requests containing PHP\_SESSION\_UPLOAD\_PROGRESS in your server logs. If you find any of them, treat the server as compromised and change the database password and every API key stored on it after cleaning it.

**Which Next.js versions fix the October 2026 flaws?** Next.js 16.4.1 and 15.5.28, released on 14 October 2026. Also check that the sharp image library is 0.35.5 or later, because Next.js 15.5.28 still accepts an older sharp that stays vulnerable to CVE-2026-96889.

**Is Next.js 14 still safe to use?** No. Next.js 13 and 14 are unsupported and received no patch in October 2026, although they fall inside the affected ranges of the image optimization flaw and the Server Actions denial of service. The only fixed versions are 15.5.28 and 16.4.1.

**Do DZBuild merchants need to do anything?** No. The PHP security releases of 21 October 2026 were running on DZBuild's servers on 22 October, DZBuild storefronts do not use Next.js, and the third PHP flaw needs a session setting that DZBuild never changes. Merchants have nothing to update.

## Sources

* PHP, security release announcement and advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, 21 October 2026: [php.net](https://www.php.net/archive/2026.php)
* PHP Foundation, account of the release and the leak, 21 October 2026: [thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/)
* CISA, Known Exploited Vulnerabilities catalog, version of 29 October 2026: [cisa.gov](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
* Amazon Threat Intelligence, exploitation before disclosure: [aws.amazon.com](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)
* Delft live exploitation telemetry, updated 29 October 2026: [php2shell.delftintellab.com](https://php2shell.delftintellab.com/)
* Sansec, PHP2Shell and online stores, 21 October 2026: [sansec.io](https://sansec.io/research/php2shell)
* Calif, affected applications: [calif.io](https://calif.io/php2shell/)
* Next.js, security update of 14 October 2026: [nextjs.org](https://nextjs.org/blog/nextjs-security-update-october-14-2026)
* sharp advisory GHSA-wq5f-xc86-pv6w: [github.com](https://github.com/lovell/sharp/security/advisories/GHSA-wq5f-xc86-pv6w)
* Node.js, October 2026 security releases: [nodejs.org](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)
* Drupal, SA-CONTRIB-2026-254: [drupal.org](https://www.drupal.org/sa-contrib-2026-254)

## Related reading

* [The real cost of a WordPress store in Algeria](https://dzbuild.com/blog/wordpress-store-real-cost-algeria.md)
* [WooCommerce cash on delivery in Algeria](https://dzbuild.com/blog/woocommerce-cash-on-delivery-algeria.md)
* [Trust and security in Algerian e-commerce](https://dzbuild.com/blog/trust-security-algerian-ecommerce-reviews-fraud-prevention.md)