Namecheap PHP2Shell status: what it says and how to confirm

At our check on 26 October 2026, Namecheap's status page says the PHP2Shell fixes (CVE-2026-109618 and CVE-2026-109619) are installed on all Shared Hosting servers and its maintenance has finished. If you manage your own VPS or dedicated server, updating PHP is your job, and the page gives no separate status for servers Namecheap manages. Ask support to confirm your server's build and worker restart, because a version number alone cannot prove a fix.

What does Namecheap actually say, and when?

The timeline on Namecheap's page is the only Namecheap source we rely on. Times below are as Namecheap stamped them.

• 21 October, 9:31 AM EDT: Namecheap announced the issue and said mitigations were in place.
• 21 October, 9:40 AM EDT: php.net released fixed versions and Namecheap began installing them. customers who manage their own VPS or dedicated server were told to update PHP themselves.
• 21 October, 4:40 PM EDT: Namecheap says patched versions were in CloudLinux staging repositories and going to a focus group of servers.
• 22 October, 6:00 AM to 12:00 PM EDT: the list of servers still in progress shrank from 17 servers (3 reseller, 14 regular) at 6:00 AM to regular servers 71, 105 and 312.
• 22 October, 12:50 PM EDT: Namecheap says the maintenance finished.
• Final Shared Hosting update, stamped 7:00 PM EDT, 00:00 UTC, with no calendar date: Namecheap says it installed the fixes on all Shared Hosting servers, that all PHP versions offered there are patched, and that PHP 8.2 to 8.5 now show the official numbers 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

Our earlier host matrix showed servers 71, 105 and 312 still open as of 16:00 UTC on 22 October. Namecheap's later updates supersede that. A server list that shrinks is a status page talking, not a test of your account.

Why does my PHP version still look old?

This is the trap on Namecheap shared hosting. Namecheap says the first CloudLinux packages did not update the version numbers, so some versions looked unpatched when the fixes were in place. CloudLinux confirms its first ea-php and alt-php packages carried the fix as a backport under a lower number, for example an 8.4.26 build in place of 8.4.27, and published builds with php.net numbers afterwards (alt-php on 23 October, ea-php later that day).

Namecheap also says PHP 5.2 to 8.1 keep their old numbers on shared hosting, with the fixes applied. The PHP project says 8.1 and older no longer receive project releases and some vendors backport instead. So for those branches the number can never confirm the fix, and sites stuck on PHP 8.1 or older need their own plan.

A fixed package and a restarted worker are two separate facts. Neither is visible from outside.

Who is affected on Namecheap?

The PHP project says every installation serving web requests is in scope. Who acts depends on your product:

How do I fix it or confirm it?

How do I confirm it on Namecheap shared or reseller hosting?

Per Namecheap's guide, log in to cPanel and open Select PHP Version under Software or Exclusive for Namecheap Customers. The current version shows above the extensions list. On Stellar Business, Exclusive for Namecheap Customers then PHP Tweaks shows the version per domain. The selector article does not say where to find your server number, so ask support for it. If you run your own panel, the cPanel steps for updating PHP cover that side.

Send 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 server number, the fixed package, build or backport identifier for the PHP version my domain uses, confirm that the PHP workers serving it were restarted or replaced after the fix, and say whether I need to change a setting.

• Note the PHP version selected for the domain in cPanel
• Ask support the question above and save the reply with its date
• Keep WordPress, themes and plugins updated, as Namecheap advises, but do not count that as the fix
• Run the free scan to see what version your site exposes from outside

How do I fix it on a VPS or dedicated server I manage?

• Update PHP from your operating system or panel vendor. Check the installed package version against your vendor's notice. CloudLinux says some fixed native PHP packages name no CVE ids in the changelog.
• Restart PHP-FPM, or Apache if you use mod_php, then confirm the web runtime, not just php -v
• Rebuild and redeploy any container image that bundles PHP
• Check each virtual host if more than one PHP version runs

Our full write-up of the bug has the distribution status table.

Am I affected? A three-state self-test

Was anything exploited before the fix?

Attempts started before disclosure. AWS reported attempts against its honeypots from 17 October and says it is unclear whether the early ones would have worked on real systems. We have no primary source naming a compromised Namecheap customer, and we do not claim one. If your PHP sat unpatched on a VPS between 17 October and your update, look for unexpected PHP files in upload directories, new cron entries, new admin accounts and odd outbound connections. Patching does not remove anything planted earlier. Whether PHP2Shell is being exploited at scale is tracked on its own page.

What is the bug, in one paragraph?

Two memory-safety flaws in PHP core, reachable by an unauthenticated web request: CVE-2026-109618 (remote code execution via out-of-memory corruption) and CVE-2026-109619 (remote code execution via stale global state). The PHP notice says updating is the only complete fix. For the full picture see PHP2Shell, the checker limits, SiteGround's status and the October 2026 tracker. Other host statuses are in the hosting guides.