DreamHost PHP2Shell status: what to confirm for your site

DreamHost says its PHP2Shell fix is installed. Its incident notice, resolved on 23 October 2026, says the fix is "now installed across all DreamHost servers, including Shared, Dedicated, VPS, and DreamPress". That is DreamHost's statement, not our finding. Ask DreamHost support for the build identifier and worker restart for your server, using the question below.

What did DreamHost say about PHP2Shell?

DreamHost's incident notice is titled "PHP Security Vulnerability: Protections Are In Place". Its 22 October, 11:12 PDT update says the official PHP security updates "have been applied across the entirety of our network". Its 23 October, 11:26 PDT resolution says the fix is "now installed across all DreamHost servers, including Shared, Dedicated, VPS, and DreamPress", and that sites on PHP 8.1 and older are covered under its PHP Extended Support program.

At our check on 26 October 2026 the notice was readable and showed that resolution. We repeat it as DreamHost's statement.

The status page front page was not all clear at the same check. It listed an open incident, "Investigating an incident affecting File Manager and Webmail", with status Identified. The File Manager Interface, Email Hosting and Webmail Interface showed Service Disruption, and DreamHost was resetting passwords for some email and FTP/SFTP users. That incident began on 23 October and is separate from PHP2Shell. Our statement about the PHP fix covers only the PHP incident notice, and we make no claim about the other incident beyond what DreamHost wrote. It does not name your site, your server, a build identifier or a restart time, so it is not owner evidence for your site. Treat your site as unknown until DreamHost gives you those for your server.

This page will change if DreamHost updates its notice. The other hosting status checks are collected in one place. Other hosts that did publish are covered in SiteGround and Kinsta's patch status, and the incident is explained in PHP2Shell: affected versions, fixes, and what to do now.

Who on DreamHost is affected?

The PHP project says all PHP installations serving web requests are in scope. That covers shared hosting sites running WordPress, WooCommerce or any PHP application, and any PHP running on a DreamHost VPS or dedicated server. A site that serves no PHP (static files only) is not affected by this bug.

The advisory for CVE-2026-109618 says updating is the only complete mitigation. Updating WordPress or plugins does not change the PHP engine underneath.

Is the PHP version in the DreamHost panel proof of a fix?

The panel path for shared hosting, from DreamHost's own help article at our check on 26 October 2026:

1. Open Manage Websites.
2. Click Manage for the domain.
3. Open the Settings tab.
4. In Website Settings, click Manage next to PHP.
5. Read the PHP Version section.

On a managed VPS running Nginx, DreamHost says PHP is managed at the server level on the Server & Users page. Its article does not cover DreamPress, so we give no panel path for it.

What you read there is the branch you selected. Two things make it weak evidence:

• php.net says some vendors provide backports for older branches, so a version number alone does not show whether a fix is present.
• The advisory for CVE-2026-109618 says to restart every PHP worker after updating. Only the host can say when that happened for your site.

Do not treat a version number, a build date or a changelog as proof of a fix on its own. Ask for the build identifier and the restart.

How do I get DreamHost to confirm my site is fixed?

What do I do on shared hosting or DreamPress?

Send DreamHost support this and keep the reply. The same question works with any provider, and what to ask a shared host is on its own page:

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 on the server this site is on, confirm that every PHP worker serving it has been restarted or replaced since, and say whether I need to redeploy or change a setting.

• Write down the PHP version shown in Manage Websites and the date you read it.
• Send the question above, with the domain.
• Ask which server the site is on, so the answer is about that server.
• Save the reply. It names the build and the restart, or it does not.
• If you pinned an end-of-life PHP version (8.1 or older), ask whether a vendor backport exists for it. php.net ships no release for those branches.

What do I do on a VPS or dedicated server that I manage myself?

DreamHost's incident notice lists Managed VPS and Dedicated Server Hosting, and its 22 October update says "No intervention is needed on your end." The steps below apply only where you run and update the PHP runtime yourself, for example PHP you installed from packages or built into a container image.

• Update PHP from your vendor's packages. The package changelog must name both CVE ids.
• Restart the PHP workers (PHP-FPM, or Apache if you use mod_php).
• Confirm the PHP that serves the web, not only php -v.
• Check each virtual host if the server runs more than one PHP version.
• Rebuild and redeploy any container image that bundles PHP.

Package status by distribution is in the fixed versions table.

Am I affected? A three-state self-test

Was anything exploited before the fix?

AWS reported an exploitation attempt dated 17 October against its own MadPot honeypots, before disclosure, and says it is unclear whether any of the attempts it saw would have succeeded on real systems. That is vendor telemetry. The advisory for CVE-2026-109618 says remote code execution was validated against mod_php and that no complete FPM exploit has been demonstrated for that bug. The advisory for CVE-2026-109619 says session-lifecycle remote code execution was validated against mod_php and FPM.

Neither advisory lists indicators of compromise. The advisory for CVE-2026-109619 suggests auditing logs for repeated warnings before target scripts run, fatal, parse or uncaught errors, and "Maximum execution time exceeded". It also says the absence of an error in logs is not proof of safety, and that historical logs may have excluded the relevant severities.

What is the bug, without the exploit?

Both CVEs are memory-safety flaws in the PHP engine. CVE-2026-109618 comes from out-of-memory handling that can leave request data half set up. CVE-2026-109619 lets request state outlive its memory, and a later request on the same worker can use it. We publish no exploit material, and you do not need any to fix your site.

On 23 October php.net also posted an informational advisory about a different issue, CVE-2026-115560, tied to session upload progress. It is separate from PHP2Shell.