You run a WordPress site. Maybe it's a clinic, a coaching centre, a shop. You pay for hosting every year and you have never once logged in to a server. Then you read that PHP has two critical flaws, and the first question is a reasonable one: do I update WordPress, or what?
Updating WordPress won't fix it. That is the whole difficulty with PHP2Shell on WordPress and shared hosting, and it is why this one is annoying for small business owners in India.
Why a WordPress update doesn't help
WordPress is a program written in PHP. PHP is the engine that runs it, and that engine is installed on the server, by whoever manages the server. The flaws (CVE-2026-109618 and CVE-2026-109619) are in the engine. A fully updated WordPress, with every plugin current, still sits on top of whichever PHP build your host installed.
The same goes for Laravel, CodeIgniter, Magento, a custom PHP app someone built in 2019. The application is not the thing to patch.
Shared hosting: you probably can't fix this yourself
On shared hosting, the provider controls the PHP runtime for hundreds of customers on the same machine. You can usually pick a PHP version from a dropdown in cPanel, but the dropdown only chooses which version the host has installed. If their 8.3 build is older than 8.3.36, picking 8.3 does nothing for you.
The honest answer to “am I safe?” on shared hosting is: whatever your host says, in writing.
So ask. Send your host a short, specific message:
- Has the PHP build on my plan been updated to include the fixes for CVE-2026-109618 and CVE-2026-109619?
- If you backport fixes without changing the version number, can you point me to the changelog entry?
- Which PHP version and handler (mod_php, PHP-FPM, LiteSpeed) is my site running on?
That third question matters because the PHP project considers Apache with mod_php the highest risk setup. Distros and hosts often patch without bumping the visible version string, which is why the changelog question is not pedantic. The fixed upstream releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, but a distribution package can carry the fix under an older looking number.
If you manage your own VPS
Then it is yours to update. On a Debian or Ubuntu server that usually means updating your PHP packages from whichever repository you installed them from, then restarting PHP-FPM or Apache so the old workers stop running. People forget the restart. An updated package with old workers still running is not a patched server.
Check what is actually running after you update. Run php -v for the command line, but remember the web server can use a different PHP than the terminal does. Drop a temporary page that prints the version, check it, delete it.
What to do if your host is slow or silent
Some small hosts will take weeks. You have a few options, and none of them is free.
- Ask for a move to a plan or server that already has the fixed PHP.
- Put the site behind a CDN or firewall that filters hostile requests. That reduces exposure, though PHP's own advice is that only updating fully protects you.
- Move the site to a host that publishes its patch status. This is the slowest option and sometimes the right one.
Also do the ordinary things you were meant to do already: keep a recent backup somewhere that is not the same server, and change admin passwords if you see anything strange in your logs after the patch.
If your site is old enough that it only runs on PHP 7 or early PHP 8, the real conversation is bigger than this one patch. We covered what a rebuild versus a rescue looks like in our post on when template versus custom actually matters.
If you would like someone to check what your site is running and handle the update, our web development team in Delhi NCR does this regularly. You can also read about our custom web development or send us your hosting details. We will tell you what is exposed and what is not.