Why PHP sites on a VPS or your own server are still at risk
Shared hosts patched PHP2Shell for you. On a VPS or your own server, you patch it yourself. How to tell which you have, three update traps, and stopgaps.
By Jeensuk Yang
PHPFree · Web security · Risk series 03
?Who this is for
- Your business website runs on a VPS, a cloud server or your own server
- Your web developer set up the server too, and you're not sure how it's built
- You need to update PHP yourself and want to know what to watch out for
!What you'll learn
- Who fixes PHP on shared hosting, and who fixes it on a VPS
- Three traps that make an update look finished when it isn't
- What you can do if you can't update today, and where that stops working
Same WordPress, different outcome.
Some sites were patched by October 22. Others are still exactly as they were. The difference comes down to one thing: whether the site lives on shared hosting or on a VPS. Let me explain how to tell which one you have, and what to do if it's a VPS.
Same WordPress, so why did the outcomes split?
Because a different person fixes PHP. On shared hosting, the hosting company does. On a VPS or your own server, you do. That was the picture as of October 25, 2026.
Hostinger rolled the fix out across its platform, and Kinsta patched PHP 7.4 through 8.5, with nothing for customers to do.1·2 But Hostinger's notice is explicit about VPS customers.1 Reclaim Hosting gave customers running their own PHP containers until October 27 to redeploy.3
If you manage PHP on your own server, update it and restart it now. — Hostinger, Oct 21, 2026
A house lets you build however you like. But when the foundation cracks, fixing it is on you.
| Shared hosting | VPS / your own server | |
|---|---|---|
| Who fixes PHP | The hosting company | You (or your developer) |
| This fix | Done by most hosts on Oct 21–22 | Not done until someone does it |
| Old PHP versions | Some hosts patched them too | You have to handle it |
Psychologists have a name for what can go wrong here: diffusion of responsibility. When several people could act, each assumes someone else will.4 The owner assumes the developer did it. The developer assumes the host did it.
Jeensuk's takeIf nobody decided who updates PHP on a VPS, there's a real chance nobody did.
How much old PHP is still out there?
More than you'd think. CybelAngel's analysis shows why "just update to the latest PHP" isn't simple for many sites.5
Those patches for 7.4, 8.0 and 8.1 are source code changes "to help people building from source." They aren't regular releases, so someone may have to build PHP by hand.6 On shared hosting, the host took care of that. On a house, it's your job, or the job of whoever you hire.
Jeensuk's takeWhat the building manager did for apartment residents, a homeowner has to do alone or pay someone to do.
You updated PHP, so why isn't it finished?
Because an update can look done when it isn't. There are three common traps.
Trap 1: Trusting the number from "php -v"
The version that php -v shows on the server is the command-line PHP, and it can differ from the PHP that actually serves your website. CybelAngel's advice: "Check the version the site reports while serving a request, not php -v."5 On WordPress, look under Tools → Site Health → Info → Server.7
Trap 2: Updating without restarting
After updating, the PHP workers that are already running keep using the old code until they restart. Restart PHP-FPM or the web server so the new version loads.5·1 If you run containers, rebuild with an updated PHP base image and redeploy, then confirm that what's serving requests is the patched version.8
Trap 3: Running a "fix script" you found online
Whenever a big vulnerability lands, code claiming to test or fix it appears on GitHub fast. Not all of it is safe. In one study of 20,433 proof-of-concept repositories for known vulnerabilities, about 2.5% were likely malicious.9 If you don't know who wrote it, don't run it on your server.
Jeensuk's takeCheck the number the website reports, restart, and never run code you don't recognize. Those three habits prevent most "we updated, but it didn't take" cases.
What can you do if you can't update today?
You can buy time with temporary settings, but only time.
PHP's advisory lists stopgaps, such as removing the PHP memory limit, setting a low post_max_size, and setting session.upload_progress.enabled=0 and restarting every worker. It also says plainly that these "reduce exposure" but "do not make an installation safe." The upload-progress setting has to go in php.ini or the server configuration, not ini_set() or a .user.ini file.6
Jeensuk's takeTemporary settings only buy time. On the same day, decide who will do the real update, and by when.
So what should a business on a VPS do?
You have three ways forward.
Update PHP to a fixed version while watching for the three traps, restart the workers, and confirm on the live site.
"Did you update to a fixed PHP version (or your OS vendor's patched package)?" "Did you restart PHP?" "What does Site Health show now?"
Move to a setup without PHP, and the foundation that needs fixing disappears.
Jeensuk's takeFor a ten-page company website, option C is worth a serious look. This kind of work comes back every time the next vulnerability is found.
Frequently asked questions about VPS hosting and PHP updates
Does my hosting company fix PHP on a VPS too?
Usually not. Hostinger, for example, patched its hosting plans but told VPS customers who manage PHP themselves to update and restart it.
If "php -v" shows the new version, am I done?
No. That's the command-line PHP. Check the version your website actually reports, and restart PHP-FPM or the web server.
If I turn on a WAF, am I safe?
No. A WAF reduces attacks but doesn't replace the fix. Updating PHP to a fixed version is the real solution.
SOURCES
- Hostinger, "Hostinger deploys protections against php2shell PHP vulnerabilities" (Oct 21, 2026; updated Oct 23) hostinger.com
- Kinsta, "PHP2Shell: How Kinsta protected WordPress sites" (Oct 23, 2026) kinsta.com
- Reclaim Hosting, "Reclaim Cloud and PHP2Shell" (Oct 22, 2026) reclaimhosting.com
- Wikipedia, "Diffusion of responsibility" (Darley & Latané 1968) wikipedia.org
- CybelAngel, "2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming: What We Know About php2shell" (Oct 21, 2026) cybelangel.com
- PHP Group, "Security advisory: Critical remote code execution vulnerabilities, update now" (Oct 21, 2026) php.net
- WordPress.org, "Site Health screen" (updated Jul 12, 2026) wordpress.org
- Vercel, "PHP security advisory: php2shell" vercel.com
- El Yadmani et al., "SecurePoC: A Helping Hand to Identify Malicious CVE Proof of Concept Exploits in GitHub" (USENIX WOOT '25, 2025) usenix.org
- Cloudflare, "Cloudflare deploys protections against php2shell vulnerability" (Oct 21, 2026; updated Oct 23) blog.cloudflare.com
- CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (Oct 21, 2026; last revised Oct 23) cisa.gov
Five articles on what PHP2Shell means for small business websites. More English editions are on the way.
- What is PHP2Shell? What it means for your business website
- Patched, but still not safe? Three cases (coming soon)
- Why PHP sites on a VPS or your own server are still at risk (this article)
- What if someone got in before the patch? Three signs (coming soon)
- PHP 8.2 support ends Dec 31: what to decide now (coming soon)
More articles on the ATATAKAI Digital blog.
If you own the house, have you decided who fixes the foundation?
Enter your site address and we'll tell you right away whether it runs on PHP and where your host stands. If you're not affected, we'll say so plainly: "No need to move right now."
Run the free 30-second checkWant to talk it through after you see the result? Contact ATATAKAI Digital
Updated Oct 26, 2026
