Short answer
On shared hosting, the PHP that runs your site is installed and updated by your hosting provider, not by you. So for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), you have three jobs:
Check your site's PHP version (step 1 below).
Message your host's support and ask them to confirm PHP is at a release that includes the fix: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package that carries the patch (php.net). The message is ready to copy in step 2.
Read the reply carefully. "We've handled it" doesn't always mean patched. Step 3 lists common replies and what to ask back.
Indonesia's national cyber agency BSSN has asked site owners and operators to act: check the PHP version, update to a patched release, make sure the whole PHP runtime is updated and the service restarted, and limit access or temporarily isolate the service if needed (BSSN on X, 24 Oct; Kompas Tekno). On shared hosting, most of those steps are your host's to do. This page helps you ask for them clearly.
Step 1: note your site's PHP version
Before you contact your host, note two things: the full PHP version (for example 8.3.36, not just "8.3") and the Server API (for example LiteSpeed or FPM/FastCGI). How to find them in cPanel, the Select PHP Version menu, WordPress Site Health or phpinfo is on Am I affected by PHP2Shell?.
Then paste the version into the PHP version checker. It compares your version with the patched releases. The check runs in your browser, and the version you paste isn't sent anywhere.
If the result is below the patched release, or you can't see the full version number, go on to step 2.
Step 2: send this message to your host's support
Use a support ticket rather than live chat, so the answer is in writing and you can keep it. Replace the parts in square brackets.
Hello support team,
I own the account [account name / domain]. About PHP2Shell (CVE-2026-109618 and CVE-2026-109619), please confirm the following in writing:
The exact PHP version now serving [domain]. phpinfo shows version [version] with Server API [SAPI]. Does this version include the fixes for both CVEs (upstream releases 8.5.12, 8.4.27, 8.3.36 or 8.2.35)?
If the version number is lower than that but the fix comes from a vendor package, please give the package name and version, and confirm whether its changelog lists CVE-2026-109618 and CVE-2026-109619.
Are all the other PHP versions I can choose in the panel (Select PHP Version / MultiPHP Manager) patched too? If any aren't, which ones?
Were all PHP processes (LiteSpeed/lsphp, PHP-FPM or Apache) restarted after the update?
Is
session.upload_progress.enabledturned off at server level, as the PHP team suggests until the next release?If it isn't patched yet: what date is the patch scheduled for, and what interim measures are in place until then?
Thank you.
Why each point is in the message:
Point 1: what matters is the full release number, such as 8.3.36, not just 8.3 (php.net). The PHP menu in your panel may show only "8.3", so ask for the full number.
Point 2: the PHP team says Linux distributions and LTS vendors received the patches in advance, and tells users to check their vendor for updated packages (php.net). Such a package can keep an old version number and still be patched. For example, Ubuntu 24.04 lists php8.3 version 8.3.6-0ubuntu0.24.04.13 as fixed (Ubuntu). The package changelog is how to tell: Google Cloud advises searching the PHP package changelog for both CVE numbers (Google Cloud).
Point 3: on shared hosting you can switch versions in the panel. The version you use now may be patched while others in the list aren't.
Point 4: updating the package on disk isn't enough. Running PHP processes keep the old code until they're restarted (Google Cloud). BSSN also says to restart the service after updating (Kompas Tekno).
Point 5: the PHP team suggests keeping this setting off until the next release, because of a rare related flaw, CVE-2026-115560, that the 21 October releases don't fix (php.net, 23 Oct). It has to be set in the server config, not through
.user.ini(php.net), so on shared hosting usually only your host can set it.Point 6: "we're working on it" without a date isn't something you can hold them to.
Step 3: reading your host's reply
| Host's reply | What it means | What you do |
|---|---|---|
| "It's on 8.3.36" (or 8.5.12, 8.4.27, 8.2.35, or later) | That release includes the fix (php.net). | Check for yourself: open phpinfo again and paste the version into the PHP version checker. Then go to "Once it's patched". |
| "The version is an older 8.3.x, but it's patched by the vendor" | Can be true (see the Ubuntu example above). | Ask for the package name, its version, and the changelog line naming both CVEs. |
| "Our servers are protected by a WAF / firewall" | A WAF is an extra layer. Google Cloud calls WAF rules such as Cloud Armor a compensating control, and upgrading PHP is still required to close the flaws (Google Cloud). | Ask for the date PHP gets updated. |
| "We've turned off upload progress" | That's a mitigation for one attack path. The PHP team says only an update fully closes these flaws (php.net). | Good as an extra. Still ask for the version and update date. |
| "It's been updated", with no mention of a restart | Old processes may still be running (Google Cloud). | Ask whether every PHP process was restarted, then re-check phpinfo. |
| "We don't update PHP 8.1 / 7.4 any more" | The PHP project doesn't ship updates for 8.1 and older (php.net). | Switch to 8.3 or newer in the panel's PHP menu, if your site supports it and your host has patched that version. 8.2 only gets fixes until 31 December 2026 (php.net). Test your site after switching: old plugins or themes can break after an upgrade. |
| No reply, or "in progress" with no date | Status unknown. | See the next section. |
If your host can't (or won't) patch
Switch to a patched PHP version in the panel, if your host has patched another version in the list (point 3 of your message). Pick 8.3 or newer if your site supports it, because 8.2 only gets fixes until 31 December 2026 (php.net). Test the site after switching.
Limit access or take the site down for now. BSSN advises limiting network access to affected systems or isolating internet-facing services when you can't update yet (Kompas Tekno). The UK NCSC and the Canadian Centre for Cyber Security also say to consider taking systems off the internet until they can be fixed (NCSC, Canadian Cyber Centre). On shared hosting, that means asking your host to restrict access to your site, or turning on maintenance mode until PHP is patched.
Consider moving hosts to a provider that can show you a patched PHP version in writing.
Keep your host's written replies. If something goes wrong later, you have a record of when PHP was patched.
Once it's patched: check whether anyone got in
A patch closes the hole. It doesn't remove anything that got in before. Amazon found an exploitation attempt dating to 17 October 2026, before public disclosure, so check from at least that date (AWS). What you can check yourself on shared hosting, and what to ask your host for, is in the "On shared hosting" section of the compromise check page.
Has anyone actually been hit?
It isn't clear. Amazon (21 October) reports broad exploitation attempts, but says it's unclear whether any would have succeeded against real systems (AWS). The Canadian Centre for Cyber Security (updated 23 October) says a proof of concept is available and no active exploitation had been identified at that time, while warning this can change quickly (Canadian Cyber Centre). Don't wait for certainty: asking your host to confirm the patch takes one ticket.
Want us to deal with your host?
We've checked and patched PHP hosts we run for clients (WordPress, WooCommerce and Moodle sites). For your site, we check the PHP version and SAPI it actually uses, not just the number in the panel, and look for signs of compromise. On shared hosting, we switch the PHP version where the hosting panel allows it. Where it doesn't, the server's PHP belongs to your host, and we send your host the exact request. You get a written findings report the same day you request it. For servers we patch ourselves, we report the final status as it is: checked and patched.