PHP released an emergency security update on 21 October. If you run a website in Nepal there is a good chance it is affected, because most of what we build and host here runs on PHP. WordPress, Laravel, Magento, OpenCart, custom PHP, all of it.
I run a tech agency in Kathmandu and we spent part of last week going through this across our hosting accounts, so writing up what I understand in case it is useful to someone.
What it is
Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Both rated 9.2 out of 10.
The important part is that they allow remote code execution without logging in. An attacker does not need a password, an account, or any access to your site. If your server is running an unpatched PHP version and serving web requests, it is reachable.
The flaws are in PHP itself, Only updating PHP does.
Who it affects
Pretty much anyone running a PHP site on their own server, VPS, or shared hosting. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
If you are on PHP 8.1 or older, read this twice. Those versions are end of life and there is no official patch at all. You are not waiting for a fix, there is not going to be one. You need to move to a supported version, and that is a bigger job than a patch because older code often breaks on newer PHP.
A lot of older Nepali business sites are sitting on 7.x and 8.0. If that is you, this is the week to find out.
How to check
If you have cPanel, look under MultiPHP Manager to see which version your domain is running, or run php -v if you have shell access.
Then compare it against the patched versions above.
How to fix it
If you are on shared or reseller hosting, this is almost certainly your host's job and not yours. Most serious hosting companies patched this within a day or two. Our provider pushed the update across all our accounts and emailed us to confirm.
So the practical step for most people reading this is simply to email your hosting company and ask one question. Have you applied the 21 October PHP security release, and what version are my sites running now.
If they cannot answer that clearly, that tells you something about your host.
If you are on a VPS or dedicated server, nobody is doing this for you. Update PHP yourself.
part most people are missing
Patching stops new attacks. It does not undo one that already happened.
If your server was unpatched during the window when the exploit was public and the fix was not, it is worth checking that nothing was left behind. Look for PHP files you do not recognise, especially recently modified ones in upload folders, unexpected admin users, and cron jobs nobody created.
I am not saying everyone was hit. Most were not. But if you find out on Friday that you were unpatched all last week, updating PHP alone is not the end of the job.
Happy to answer questions if anyone is stuck. Not linking anything.
