ShoppingPartnerLab — Blog

PHP2Shell is patched. The real work starts now.

2026-10-21 · ShoppingPartnerLab Redactie · Security

PHP2Shell is patched. The real work starts now.

*21 Oct 2026 · @LMC AI*

The patch is out, but the danger isn't over

On 21 October 2026, PHP released emergency updates for PHP2Shell: two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 score of 9.2. They allow code to be executed on a server without logging in.

The day before, the details leaked, ahead of the coordinated disclosure. In response, a large part of the Dutch internet went offline as a precaution: Tweakers, the Dutch House of Representatives, the NCSC, Security.NL, DigiD and MijnOverheid. Media sites of DPG Media and Roularta, as well as Magento web shops, also took their public-facing side down.

The patch is now available. Yet the problem is not over. In this article you'll read what went wrong technically, what you need to do now, why the risk actually increases after the patch, and why we at ShoppingPartnerLab think this is only the beginning.

What went wrong technically

According to the official advisory from the PHP security team, there are two separate flaws in the way PHP handles requests:

  • CVE-2026-109618: RCE via OOM corruption. If PHP runs out of memory during a request, processing can stop while internal request data is only half built. When the request is cleaned up, PHP then treats that half-built data as valid.
  • CVE-2026-109619: RCE via stale global state. Internal request data can persist after the associated memory has already been freed. A subsequent request handled by the same worker can use that stale data before it is reset.

In both cases, PHP uses memory that is not (or no longer) correct. Anyone who can control what ends up there can execute code as the user PHP runs under.

Three things make this so serious:

  • It sits below the application. The attack can happen before WooCommerce, Magento or Laravel executes a single line of code. A well-maintained shop with the latest plugins is therefore still vulnerable.
  • Every web setup is at risk. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all named. The PHP team rates the risk highest for mod_php, where a working attack has been demonstrated.
  • No login required. A single request from an anonymous visitor can be enough.

The official GitHub advisories contain the full technical details: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

Step 1: update now

Only an update truly fixes the problem. The patched versions are:

  • PHP 8.5 → 8.5.12
  • PHP 8.4 → 8.4.27
  • PHP 8.3 → 8.3.36
  • PHP 8.2 → 8.2.35 (note: 8.2 reaches end of life on 31 December 2026, so plan an upgrade as well)

Using the PHP packages from your Linux distribution? Those vendors received the patches in advance. Check with your distribution whether updated packages are available.

PHP 8.1 and older no longer receive official releases. Given the severity, the PHP team has published minimal source patches for 7.4, 8.0 and 8.1 for those who compile PHP themselves. Some distributions and LTS vendors also offer their own backports. For most web shops, upgrading to a supported version is the only sensible route.

After updating, check that the web server is really running the new version. The command line and PHP-FPM can use different versions:

```bash php -v php-fpm8.3 -v # adjust to your version ```

Then restart all PHP workers. An old worker that is still running still uses the vulnerable code.

On shared hosting or a managed web shop, this is your hosting provider's responsibility. Ask them today whether the update has been applied.

Can't update right away?

The PHP team lists a number of measures that close specific attack paths. They do not make an installation safe. See them as a delay of a few days, not a solution. If even that isn't possible, take the site offline temporarily.

Against CVE-2026-109619 (stale state)

Disable upload progress in php.ini, the FPM pool or the server configuration, then restart every worker:

```ini session.upload_progress.enabled = 0 ; PHP 8.5 only: fatal_error_backtraces = 0 ```

In a PHP-FPM pool:

```ini php_admin_value[session.upload_progress.enabled] = 0 ```

Do not rely on `ini_set()` or a `.user.ini` file for this. Those are only applied after PHP has already processed the request. Also clean up invalid or deprecated settings that raise a notice on every request, and fix fatal errors and timeouts that a visitor can trigger.

Against CVE-2026-109618 (OOM corruption)

  • Set `memory_limit=-1` in a way applications cannot override, such as `php_admin_value` in the FPM pool. Then monitor memory at container level, with a limit that only stops the affected worker.
  • Lower `post_max_size`: 8M if you don't need uploads, 32M if you do. Keep `upload_max_filesize` below that.
  • At web server or proxy level, limit request size, the number of form fields, multipart parts and headers.

Do not use `RLIMIT_AS` or `RLIMIT_DATA` as a substitute. They can actually trigger the vulnerable memory error.

For Nginx, for example, you can limit the body size:

```nginx client_max_body_size 8m; ```

After the patch: why the risk is now rising

A patch closes the hole, but also tells attackers exactly where it was. Four reasons why the coming weeks are more dangerous than yesterday:

  1. The patch is a manual. Attackers compare the old and new source code and build a working attack from it. Security firm Sansec expected mass attacks within 15 minutes of the release.
  2. Patching is slow. Many web shops run on shared hosting or with a developer who'll do it "soon". After previous major vulnerabilities, servers stayed vulnerable for months.
  3. Old versions stay open. Anyone running PHP 8.1 or older who doesn't compile themselves has no ready-made fix.
  4. Hacked stays hacked. If a server was breached between the leak and the update, a web shell or backdoor may have been left behind. An update doesn't remove it.

Look for traces

Assume your server has been scanned and check actively. Adjust the paths to your own server.

Processes PHP shouldn't be starting:

```bash ps -ef --forest | grep -A3 php-fpm ```

A PHP process that starts sh, bash, curl, wget or nc is almost always a red flag.

New or modified PHP files, possibly web shells:

```bash find /var/www -type f -name "*.php" -newermt "2026-10-20" ```

Pay special attention to upload and cache folders, such as `wp-content/uploads` or `pub/media`.

Other signals:

  • Unexpected outbound traffic from the web server
  • New cron jobs, SSH keys or admin accounts
  • PHP workers crashing or logging an unusual number of memory errors
  • Unusually large or abnormal POST requests in your logs

Found something? Treat the server as compromised. Rotate passwords and API keys, restore from a clean backup from before 20 October and investigate whether customer data was accessed. In the event of a data breach, you must notify your data protection authority (in the Netherlands, the Autoriteit Persoonsgegevens) within 72 hours.

Limit the damage next time

This week, the first line of defence, up-to-date software, failed for everyone at once. Then the rest of your security determines how big the damage gets. The question isn't just "can an attacker get in?", but above all "what can they do once inside?"

  • No write access to your code. Let the PHP user only read the folder containing your code. Then an attacker can't drop a web shell there.
  • Uploads separate and non-executable. Put uploads and cache in a separate location where PHP files are not executed.
  • Shell functions off. With `disable_functions` (for example exec, system, shell_exec, proc_open, passthru), executing commands becomes harder. Note: with memory bugs like this one, an experienced attacker can sometimes bypass it. It's a hurdle, not a wall.
  • Restrict outbound traffic. A web server rarely needs to connect out on its own. Only allow traffic to your payment provider, mail server and update sources. Then a compromised server can't send data out or fetch malware.
  • Separate secrets. Store API keys in a secrets manager and use a dedicated database user with minimal privileges per application.
  • Containers and isolation. With a read-only file system and tight memory limits per worker, changes disappear on restart and a problem stays confined to one process.
  • Know what you run. Keep track of which servers run which PHP version and software, and agree a patch window with your host, for example critical vulnerabilities within 24 hours.

It doesn't stop here: the wave of AI-generated code

PHP2Shell is one vulnerability in one language, and there's now a patch. The bigger problem is creeping in. At ShoppingPartnerLab we scan web shops daily, and we see more and more code, integrations and configurations created with AI. Often that code works fine, but no one with security knowledge has ever looked at it.

Independent research confirms this picture:

  • Veracode tested more than 100 language models on 80 coding tasks. In 45% of cases, the AI code failed security tests against the OWASP Top 10.
  • IOActive analysed nearly 20,000 pieces of AI code. Almost a third (31.6%) was fully exploitable.
  • More than 75% of developers surveyed believed AI code is more secure than human-written code. At the same time, 56% admitted AI code often introduces security problems.

The risks we encounter most often:

  • No input validation. SQL injection, unsafe uploads and missing authorisation checks: the classics, now at scale.
  • Secrets in the code. API keys for payment providers, feeds or marketing tools hard-coded in scripts.
  • Invented or outdated packages. AI sometimes names libraries that don't exist. Attackers register those names and fill them with malware.
  • Prompt injection. An AI chatbot or AI agent with access to customer or order data can receive instructions via a product review, a manipulated product feed or a chat message. The agent simply carries them out.

That last one is the new attack surface. With PHP2Shell, an attacker had to find a memory bug in the core of PHP. With a poorly secured AI agent, one well-crafted sentence is sometimes enough.

Companies and governments are being hit by this more and more often. The faster AI code and AI agents go live without review, the bigger the pile of invisible vulnerabilities grows. Those who do nothing now won't soon face one hole you close with an update, but hundreds of small flaws spread throughout the entire stack. That becomes impossible to oversee.

Think differently: like a data engineer

The classic web shop question is: "does it work?" The question you need to ask now is: "what data flows where, and who or what is allowed to do something with it?" That's how a data engineer thinks. That mindset protects against vulnerabilities like PHP2Shell and against flaws in AI code.

Five principles we recommend to every web shop:

  1. All input is untrusted, including AI output. Treat what a language model generates as input from an unknown visitor. Code from a prompt only goes live after review and an automated security scan. An AI agent's response is checked before any action follows.
  2. Know your data flows. Map which systems receive, store and forward customer data, orders and payment data. You can't close a gap you can't see.
  3. Validate at every boundary. Use fixed schemas and data contracts between systems. A product feed, API integration or chatbot only accepts data in a pre-agreed form.
  4. Grant minimal privileges. An AI agent answering product questions doesn't need access to order history or payment details. The same rule as for your web server: only what's strictly necessary.
  5. Make everything observable. Log what systems and AI agents do and what data they request, and monitor for anomalies.

That last point is where AI adds real value. Models that recognise abnormal behaviour in large volumes of log data often spot an attack sooner than a human. A model that knows PHP normally never starts a shell raises the alarm, even for a vulnerability that isn't yet known.

But AI doesn't make a system unbreakable. It doesn't fix a memory bug in PHP and doesn't make bad code secure. It's a detection layer watching 24 hours a day, alongside good baseline security, not instead of it.

Action plan

Today

  • Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart all PHP workers
  • If that's not possible: apply emergency measures or take the site offline temporarily
  • Check processes, files and logs for signs of abuse

This month

  • Create an overview of all servers, PHP versions and software
  • Replace PHP 8.1 and older, and plan the 8.2 upgrade before 31 December
  • Implement damage limitation: no write access to code, restricted outbound traffic, separated secrets
  • Agree a fixed patch window with your host or developer

Structurally

  • No AI-generated code goes live without review and a security scan
  • AI agents and chatbots only get access to the data they truly need
  • Document data flows and validate at every boundary
  • Behavioural monitoring on web servers and AI applications
  • Test backups and set up an incident plan: who does what when things go wrong?

Finally

The shops that stayed calm this week didn't have magic technology. They knew what their shop runs on, who maintains it and what they'll do when things go wrong.

The next crisis probably won't come from one big vulnerability, but from thousands of small flaws in code nobody has really read. AI makes building faster than ever. That's a huge opportunity, as long as security grows just as fast. Start on that today.

Sources

  • PHP.net – Security advisory and releases 21 October 2026
  • GitHub – GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
  • GitHub – GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
  • Sansec – Critical PHP RCE: PHP2Shell
  • SecurityWeek – PHP2Shell: Mass Exploitation Looms
  • Patchstack – PHP vulnerable to critical RCE
  • Brussels Times – Major websites go offline
  • Cloud Security Alliance – Vibe Coding Security Debt
  • IOActive – The Security Gap in AI-Generated Code