Bluehost PHP2Shell status: is your server patched?

At our check on 26 October 2026, Bluehost's own status page said most of its servers were patched for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) and that the rest were still being updated. It does not list which are left. The one action is to ask Bluehost support whether your server is patched and its workers restarted.

What does Bluehost's status page say?

The page is titled "PHP Updates". Its entries are dated, so here is the sequence as written on the page, with its own EST labels.

The page also lists patched package versions per product: cPanel EasyApache 4, Plesk, CloudLinux, TuxCare alt-php, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, Ubuntu and Debian. It says it will email customers directly where action is needed. The page does not name a completion time, and we do not know what "majority" covers. So the honest status for your account is Unknown until support tells you. If you run sites on more than one provider, the other host-by-host PHP2Shell status pages, such as the ones for HostGator and IONOS, are written the same way.

Who needs to act on Bluehost?

It depends on the plan, as Bluehost's page describes it.

• Shared hosting. Bluehost applies the patches. If your domain is pinned to a PHP version in MultiPHP Manager, say so when you ask support.
• VPS and dedicated servers. Bluehost says that if you manage your own VPS or dedicated server, you should run the package update through your control panel and watch for its emails. If you manage the server yourself, the update and the restart afterwards are your job; if Bluehost manages it, ask support.
• Any plan. PHP's own notice says all installations serving web requests are in scope. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. See PHP2Shell: affected versions, fixes, and what to do now for the bug itself.

Does the PHP version on screen tell me if I am patched?

Bluehost's page says that if the version in a phpinfo file matches or is newer than its listed versions, the site is patched. That is a fair first check on the upstream branches. It breaks down on backports. In the same list, the CloudLinux EasyApache 4 package for PHP 8.5 is shown as ea-php85 8.5.11-2, a fixed build whose number sits below 8.5.12. CloudLinux's update note explains why: its ea-php and alt-php packages carry the fix applied to the PHP version they already shipped, a backport, so the number is lower than upstream's. A plain comparison against upstream numbers would misread it.

Two more traps:

• MultiPHP Manager shows the branch. It tells you the domain uses, say, 8.3. It does not show whether that package has the fix (the cPanel side of changing versions is in updating PHP from cPanel), or whether the workers restarted after it was installed.
• The command line is not the web. PHP's manual describes the CLI as a separate SAPI from the web ones, and says php -v tells you whether the binary is CLI or CGI. So php -v over SSH describes the command-line binary, and does not show what answers web requests.

The fixed upstream versions by branch are in the fixed versions table. What an outside check can and cannot show is in what a PHP2Shell checker can confirm.

How do I confirm my Bluehost PHP is patched?

What do I do on Bluehost shared hosting?

Find the version your domain uses. Per Bluehost's MultiPHP help, at our check on 26 October 2026:

1. Log in to the Bluehost Portal.
2. Open Hosting, then My Plans.
3. Click the cPanel button.
4. Under Software, open MultiPHP Manager.
5. Find your domain. The version it uses is shown, and Inherited means the system default.

Then send Bluehost support this, and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier for my server, confirm that all PHP-FPM, CGI or Apache workers serving it have been restarted or replaced, and say whether I need to change a setting. Was my server among the systems still being updated on your status page?

• Note the PHP version MultiPHP Manager shows for each domain on the account.
• Send the question above and save the reply with its date.
• If any domain is pinned to an older version, ask about that version by name.
• If the reply gives only a version number, ask again for the package or build identifier and the restart time.

What do I do on a Bluehost VPS or dedicated server?

• Run the package update through your control panel, as Bluehost says, and read the package changelog for both CVE ids.
• Restart the PHP workers (PHP-FPM, or Apache if you use mod_php) and note the time.
• Confirm the PHP that serves web requests, not only the command line.
• Rebuild and redeploy any container image that bundles PHP.

Package sources are listed in CloudLinux's update note and in the PHP project's advisory for CVE-2026-109618.

Am I affected? A three-state self-test

Was anything exploited before Bluehost patched?

Attempts, yes. AWS reported an attempt against its MadPot honeypot on 17 October, four days before disclosure, and more once public proof-of-concept code appeared on 21 October. AWS says it is unclear whether any of those attempts would have worked on real systems, and its post names no victims. If your domain ran an unpatched PHP between 17 October and the fix, look for PHP files you did not upload, cron jobs you did not create, new administrator accounts and unexpected outbound connections. A patch does not remove anything planted before it; the signs that a site was hit are on their own page. The wider picture is on the October 2026 tracker.

What is the bug, without the exploit?

Per PHP's 21 October notice, both CVEs allow unauthenticated remote code execution. CVE-2026-109618 is code execution via out-of-memory corruption. CVE-2026-109619 is code execution via stale global state. The PHP project says only an update is a complete solution and that its listed measures reduce exposure to specific attack paths but do not make an installation safe. We do not reproduce exploit code here; the two flaws explained in plain terms is the longer read.

On 23 October php.net also posted an informational notice for a separate issue, CVE-2026-115560, and says it will publish a full advisory with the next release. It is not one of the two PHP2Shell CVEs.