PHP2Shell: Patch Today, or Upgrade First?

On Oct 20, details of two remote code execution flaws in PHP leaked before a fix existed. PHP's security team rated both 9.2 on CVSS v4.0 and shipped fixed releases on Oct 21 at 14:00 UTC (10:00 a.m. Eastern). By that morning, Cloudflare was already reporting early attacks on PHP sites.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and security researchers call them PHP2Shell. They sit in the PHP interpreter, not in WordPress, Laravel or a plugin. Clean application code does not protect you.

For most teams, today's work is short: install the patch and restart. For some, there is no official release to install. Which group you are in depends on one number: your PHP version.

What we know so far

• Impact: unauthenticated remote code execution. A single request from someone on the internet can run their code on your server before your application code even starts.

• Cause: two memory bugs in how PHP handles a request. One comes from out-of-memory handling that leaves request data half set up. The other lets state from an earlier request on the same worker be reused after its memory is freed.

• Who is exposed: PHP says every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php (the highest risk), php-cgi, FrankenPHP and LiteSpeed. It does not matter which framework you use.

• Proof: researchers at watchTowr reproduced one of the two flaws before the release.

• Fix: PHP says updating is the only complete fix. It lists settings that reduce exposure, such as turning off session.upload_progress.enabled in php.ini, but none of them make a server safe.

Sansec, which tracks attacks on online stores, expected mass attacks to start within minutes of the release, once the technical details were public. A server patched tomorrow will have spent a night exposed.

Which PHP versions get a fix

PHP ships releases only for supported branches. Today those are 8.2, 8.3, 8.4 and 8.5.

The versions come from PHP's Oct 21 announcement. For 8.1, 8.0 and 7.4, PHP also published minimal source patches on GitHub for people who build PHP themselves, and some Linux distributions and paid support vendors ship backported builds. Those close today's hole. They do not make the version supported again.

Check the version your web server actually runs. On one server, the command-line PHP and PHP-FPM can be different builds, so check both.

Patch, plan or upgrade

flowchart LR
  A[Check PHP version] --> B{8.3 or newer?}
  B -- Yes --> P[Patch and restart]
  B -- No --> C{8.2?}
  C -- Yes --> Q[Patch, then plan upgrade]
  C -- No --> U[No release: upgrade]
  U --> I[Isolate it meanwhile]

The 8.2 row is the one teams misread. You get a patch today, and in 10 weeks you stop getting patches at all. If the next PHP flaw lands in January, you are in the bottom rows.

What to do today on a supported version

1. List every server, container and CI image that runs PHP, with its version. Include staging and the old admin panel nobody remembers.

2. Install the patched build from the same source you installed PHP from. Linux distributions received the fix in advance, but some repositories lag. Remi's repository, used on many RHEL-family servers, had no update on Oct 21, and PHP suggests switching to distribution packages or building from source.

3. Rebuild Docker images from the updated base image and recreate the containers. A running container does not update itself.

4. Restart every PHP process: PHP-FPM, queue workers, and Apache with a full restart (not a graceful reload) if it runs mod_php. The old code stays in memory until the process restarts.

5. Confirm the new version on the web server itself, not only on the command line.

6. Look for PHP files that appeared since Oct 20 in upload, cache and temp folders, and for unusual requests in the access logs.

7. Ask your host for their patch time if you are on shared or managed hosting. You cannot patch it yourself there.

If you are on PHP 8.1 or older

There is no official release for your version. These are the options, from cheapest to most work:

• Isolate the app until it is upgraded. If only staff use it, put it behind a VPN or an IP allowlist. If nobody needs it, turn it off. The UK's NCSC advises taking offline any system that cannot be patched right away.

• Apply a backported fix. Use your distribution's or support vendor's patched build, or PHP's source patch if you compile PHP yourself. It closes these two flaws only. The next one starts the same scramble.

• Move to a newer PHP on the same framework. This can be quick when the framework already allows it. Laravel 10 runs on PHP 8.1 to 8.3, so moving a Laravel 10 app from 8.1 to 8.3 can be a server change plus a full test run.

• Upgrade the framework and PHP together. Laravel 9 stops at PHP 8.2 and Laravel 8 at PHP 8.1, so those apps need the framework moved first. This is the project that grows every month you wait.

The cost of an upgrade depends on the version gap, how much of the app has automated tests, and how many packages are pinned to old versions. We cover each in what a Laravel upgrade costs, and the step-by-step route in modernizing a legacy Laravel app without a rewrite. Our Laravel upgrades start from $5k.

We are not always the right call. If your site is a WordPress install on managed hosting, your host patches PHP for you, and the fastest fix is an email to their support.

Why staying current makes today a short day

Marafiq, the training platform we built and maintain, runs Laravel 13, which requires PHP 8.3 or newer. PHP 8.3 has security support until the end of 2027. For an app like that, today means a new image and a restart, and its ≈940 automated tests show within minutes whether the new build broke anything. Read the Marafiq case study.

That is how Oct 21 went for us: we moved every platform and server we maintain to the patched PHP release the same day, within hours of the fix being published.

The opposite case is common: for example, a customer portal on Laravel 8 and PHP 7.4, with no tests, untouched for three years. Today it has no official release, and the upgrade that would have taken a few days two years ago is now a project.

Keeping PHP and the framework current is maintenance, not a project. A support plan should name the PHP version the app runs and its end-of-life date, as we describe in what happens after your software launches.

Next step

Not sure which PHP version your app runs, or what moving it would take? Send us your composer.lock and we will do a free upgrade check: your PHP and Laravel versions, what blocks the upgrade, and a fixed quote. Book a short intro call.