Who Patches Your Server? What PHP2Shell Means for Non-Technical Founders

On October 21, 2026, the PHP project disclosed two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now collectively known as PHP2Shell. Both live in the PHP interpreter itself, not in a framework or plugin like WordPress or Laravel. An attacker needs no login; under the right conditions, HTTP requests alone can lead to remote code execution. PHP rates both 9.2 (CVSS v4, Critical). According to W3Techs, 69.3% of websites whose server-side language is known run PHP.

Here is how the week unfolded (UTC):

One detail in this table is worth dwelling on. Companies whose business is security were protecting their customers before the official fix existed: Cloudflare's rules went live hours before PHP's release, and Linux distributions received the patches in advance. A founder who maintains their own server finds out from the news, at the earliest. By then, exploitation attempts have long since begun.

TL;DR

All software contains vulnerabilities that haven't been found yet. Upgrading is first and foremost how you receive security patches, not how you get new features. If you deploy your own service, you have signed up to do that maintenance, indefinitely. If you lack the skill, the confidence or the time to do it, choose a platform that reliably keeps its infrastructure upgraded on your behalf.

Upgrades Are Not About New Features

Many non-technical founders reason about upgrades like this: new versions bring new features; I don't need new features; therefore I don't need to upgrade. The premise is wrong.

All software contains vulnerabilities that haven't been found yet. If the version you run today has no known vulnerabilities, that only means nobody has found them yet, not that there aren't any.

Two examples:

Anyone who deployed PHP 5.4 in 2012 was running a vulnerable version from day one. The vulnerability just took 14 years to be found.

And the gap is shrinking. AI has made reading and analyzing code dramatically cheaper, and finding vulnerabilities has become cheaper along with it. The cheaper it is to find vulnerabilities, the more of them get found, and the more patches there are to apply. That is good news for defenders, provided someone actually applies the patches.

It also helps to separate two kinds of upgrades:

1. Patch updates, e.g. 8.3.35 to 8.3.36. They fix vulnerabilities and change nothing else. When the next PHP2Shell arrives, this is what you need.

2. Major-version upgrades, e.g. PHP 8.1 to 8.2. These are unavoidable because once a version reaches end of life (EOL), it stops receiving patch updates.

The second point is the one most often missed. Even if you want zero new features, you cannot avoid major upgrades, because only a supported version keeps receiving patches. This time, the PHP project shipped official fixed releases only for 8.2 through 8.5, and 8.2 itself reaches end of life on December 31, 2026. "Still supported" today means unsupported in two months.

What Patching Actually Asks of You

For a non-technical founder running their own service, the risk comes from two things: not knowing that maintenance is needed, and having no way to do it once you do know. The three situations below are, in my view, equally dangerous.

Situation one: WordPress on a server someone set up years ago. A freelancer installed it, maybe with cPanel or Plesk, maybe on CentOS 7, and nobody has touched it since. CentOS 7 ships PHP 5.4.16 and reached end of life in June 2024. For PHP2Shell there is no free fix path on stock CentOS 7: the main third-party repository shipped no fixed build, and the remaining options are paid extended-support services (TuxCare, for instance, starts at roughly $5,000 a year) or unreviewed community patches. If the server runs cPanel, Plesk or DirectAdmin, fixed builds did ship within a day, but on many setups they install only when an admin runs the update, and on several the patched build keeps the old version number.

Situation two: an app you built with Cursor, Claude Code or Lovable, deployed to a VPS. The AI wrote the code and the Dockerfile, and the Dockerfile pins a base image. You may not know what's inside it. This time it was PHP; next time it might be Node.js, Python, or a dependency three levels down. AI can write the upgrade commands for you, but it won't tell you on the day a vulnerability goes public. DigitalOcean's advisory for Droplet users put it plainly: "PHP runs inside your instance, so updating it is your responsibility." And even on hosts that patch the runtime for you, your framework dependencies usually stay your job: Next.js alone shipped security releases in May, July, August and October of this year.

Situation three: a backend built by an agency. The project was delivered, the contract ended, and the server credentials are in an email somewhere. When a vulnerability drops, you don't know whom to call or what to check.

In any of these situations, this is what PHP2Shell week asked of you:

1. Know about it. Not a week after disclosure, but on the day. Exploitation attempts were seen before disclosure.

2. Separate fact from noise. In the first 48 hours, claims circulated that "a single request takes over 70% of the internet." In fact, nobody has demonstrated a single request that works against arbitrary servers, and the public exploits don't work against a default PHP installation. The 70% is PHP's share of websites, not the number of vulnerable ones. Depending on where you looked, the two CVEs were scored 9.2, 9.8, 8.1 or 10. You need to be able to tell which claims are true.

3. Find out which version you actually run. What php -v prints on the command line may not be what your web server loads. Worse, a patched PHP on Ubuntu 24.04 still reports version 8.3.6, because the distribution backports fixes without changing the version number. To know whether you're patched, check the package changelog for the two CVE IDs.

4. Upgrade. Your distribution, your control panel and your PHP branch determine where your patch comes from, and whether one exists at all.

5. Restart. After updating the package, you must restart PHP-FPM or the web server. Otherwise, the processes already in memory keep running the old code.

6. Deal with end-of-life versions. If you're on 8.1 or older, either migrate to 8.2 or later (and 8.2 itself goes EOL in two months), or confirm whether your distribution ships a backported fix. Disabling session.upload_progress mitigates only one of the two vulnerabilities, and it has to be set in php.ini or the FPM pool config, followed by a restart of every worker.

7. Check whether you were already compromised. Look for unfamiliar PHP files in the web root, PHP processes spawning curl or wget, and unexpected outbound connections.

Why not just upgrade? Step 6 is where most self-hosted sites stall, because moving off an old PHP version is rarely a button. Often the operating system has to go first: cPanel's last release for CentOS 7 was version 110, and its extended security updates for that combination ended on January 1, 2026. Getting off CentOS 7 means either an in-place conversion that takes hours and several reboots, or a new server and a migration of every site, database and mailbox. Then the code breaks. PHP 7.0 removed the mysql_* functions that a lot of old code uses for every database query. PHP 7.2 removed mcrypt, so data encrypted with it has to be migrated, not just the code. PHP 8.0 turned many warnings into fatal errors and changed how strings compare to numbers, which alters logic without raising any error at all. Commercial scripts protected with Zend Guard can't run on PHP 7 or later, and ionCube-encoded files generally need their vendor to re-encode them for PHP 8. Old plugins, themes and framework versions often cap the PHP version as well. None of this work adds a feature, and none of it is optional if you want patches. It is also why control panels that let each site keep its own PHP version end up keeping so many sites on end-of-life versions.

This is not an edge case. Counting by the version number each service advertises, Shodan data from October 21 shows 2.6 million internet-facing services reporting a PHP version, 73.5% of them on 8.1 or older: end-of-life versions for which the PHP project no longer ships fixed releases. In the US, the share is 71%.

What to Ask When Choosing a Platform

If any of those seven steps is beyond you, you shouldn't be running your own server. But "choose a managed platform" is not enough on its own. A managed platform that itself sits on end-of-life components is, from your point of view, no different from self-hosting; the server that gets breached just has someone else's name on it.

So when choosing a platform, I suggest asking six questions:

1. Can you find out which versions of language, framework and database it runs? If they can't or won't answer, that is a signal in itself.

2. Are all of those components within their vendor support windows?

3. Has it actually performed major-version migrations? Not just minor patches. Ask for concrete examples with dates.

4. How fast does it respond to public critical vulnerabilities? For example, on what day did it handle Log4Shell in 2021?

5. Do patches take effect without you doing anything? If every fix requires you to "just republish," you're back to needing to know about it.

6. If the platform stops being maintained, can you take your data with you?

Question 5 deserves a concrete example, and Laravel's own response to PHP2Shell provides one. For applications on Laravel Cloud, its managed platform: "We applied the patches in place, so your applications stayed online, and no redeploy was needed." For servers managed through Laravel Forge: "go to your server in Forge and click 'Update PHP.' Do this for each server." And for Forge servers on Ubuntu 20.04 or older: "you will not be able to update PHP. Create a new server." Same company, same week, same vulnerability; the difference is who owns the server.

These questions apply to any platform, Momen included.

How We Do It at Momen

From day one, the point of Momen has been to take infrastructure off non-technical founders' hands: servers, databases, runtimes, security patches. The things that would otherwise need a backend team to maintain indefinitely, we maintain, so that founders can focus on their product and their users.

There is no PHP in Momen's stack, so PHP2Shell itself doesn't affect us. Incidentally, apps hosted on Momen answer any request for a .php path with a 403; those requests come almost exclusively from scanners.

The underlying problem PHP2Shell illustrates, though, is one we have been working on all along. Backend and database upgrades are carried out by us, centrally; project owners don't need to do anything. Since 2020, around twenty engineers have shipped more than seventy stack upgrades to the platform. Four of them:

None of these four upgrades gave users a single new feature. That is exactly the point made above: their purpose was to keep the platform on versions that still receive patches.

Both database upgrades followed the same procedure: logical replication, a deployment lock during migration, and rollback scripts prepared in advance. The 2026 migration runbook explicitly compares itself against the 2023 run. In other words, this isn't a one-off rescue; it's a repeatable process.

The Spring Boot upgrade deserves one more sentence. Nearly 900 changed files, and not one new feature; the only goal was to move the backend framework back onto a version its maintainers support. If you maintain your own Java backend, that is the amount of work waiting for you some day. With PHP, Node.js or Python, the scale differs; the nature of the work doesn't.

What You Give Up

A managed platform isn't free of trade-offs, and I don't want to pretend otherwise.

• You depend on the platform. When its maintenance is good, you benefit; when it isn't, you suffer with it. That's why the six questions above are worth actually asking.

• You give up some control. You can't choose the runtime versions yourself or install arbitrary software on the server.

• Switching has a cost. Before you commit, find out whether your data can be exported, and in what format.

Who should self-host? Teams with a technical co-founder, or with someone who can work through the seven steps above within 48 hours of a disclosure. For them, the control that comes with self-hosting is worth it.

For non-technical founders without such a person, my advice is this: hand security maintenance to people who do it for a living, and then check that they actually do.

Conclusion

PHP2Shell won't be the last of its kind. Finding vulnerabilities is getting cheaper, so more of them will be found, and there will be more patches to apply. Self-hosting means every one of those patches is your job. Choosing a managed platform means the platform does it, provided it really does, and provided you've checked.

We have been doing this at Momen since 2020, for almost seven years now: following public vulnerabilities, continuously upgrading our databases and backend services, and turning migrations into a repeatable process. We will keep doing it. That is why Momen exists: so that non-technical founders can have infrastructure that is always being maintained, without building a technical team of their own.

Learn more about Momen: https://momen.app