php2shell: hosting provider status

What each hosting provider and control panel says, in its own words, and what you may need to do yourself.

Last checked Last changed

Not re-checked since the time above. Check the official source below.

A newer official update is being verified.

13 of 70 hosting providers say they have patched.

Global

Region: Global
ProviderStateWhat they saySource
SiteGround Mitigation only SiteGround says server-level protections are already active on all its servers and customers do not need to change anything. It does not name patched PHP builds in the post. Source
Hostinger Rolling out Hostinger says its own tests found its platform is not vulnerable to php2shell and that it added an extra layer of protection, but it is rolling out patched PHP versions. It first finished its Agency Hosting infrastructure, and later said all cPanel servers had been updated to a cPanel build that includes the PHP fix and the latest Alt-PHP version. It says no action is required from clients; it has not announced that the rollout is complete for all managed hosting. Source
Bluehost Rolling out Bluehost says it has patched the majority of servers and is completing updates on the remaining systems; mitigations stay in place as an extra layer, and they may limit upload file size. Source
GoDaddy Rolling out GoDaddy says it has patched all PHP versions on Managed Hosting for WordPress and customers need take no action. For Web Hosting and Windows Hosting it is waiting for its vendor to supply patched versions of its custom PHP packages, and has put mitigations in place in the meantime. VPS owners must update PHP themselves. It calls this an industry-wide issue. Source
HostGator Rolling out HostGator says it has patched the majority of servers and is completing updates on the remaining systems; mitigations stay in place as an extra layer, and they may limit upload file size. Source
DreamHost Rolling out DreamHost says protections and a WAF are active on all hosting platforms and it is rolling out PHP's official fix across all servers, expecting to be complete soon. Sites on PHP 8.1 and older are protected by the mitigations deployed early; security fixes for those versions under its PHP Extended Support program are being built and expected to roll out within the next day. No action is needed from customers. Source
A2 Hosting Unconfirmed A2 Hosting reports an ongoing 'PHP Update' incident: its latest update says patches from upstream vendors have been released and are being deployed across its fleet in rolling waves. The notices do not name the CVE or the fixed PHP versions. Source
Namecheap Rolling out Namecheap applied mitigations on all platforms and is installing the released PHP versions across its platform. It first said the patched versions were in the CloudLinux staging repositories and being deployed to a focus group of servers; later it said it was still working on deploying them to the servers. VPS and dedicated server owners must update PHP themselves. Source
InMotion Hosting Rolling out InMotion says PHP version upgrades have already been performed across its Shared and Dedicated servers and are now being performed on the VPS fleets, with no completion estimate yet. Earlier it had said shared hosting was waiting for an upstream CloudLinux patch for older PHP versions. It has also applied interim mitigations, and restricted access to CWP/CWP Admin ports while it awaits official CWP patches. Its latest update says the VPS upgrades are still in progress with no estimate. Source
IONOS Rolling out IONOS is installing the PHP security update across its systems and expects to finish within 24 hours; short slowdowns or interruptions are possible. Source
Kinsta Rolling out Kinsta says patches for PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 are all rolling out across its infrastructure, according to its latest update; earlier it had said only 8.3 and 8.5 were ready. Cloudflare firewall mitigations and local configuration changes stay in place for all sites regardless of patch status. It has not announced that the rollout is finished. Source
WP Engine Patched WP Engine says it has finished deploying the security patches for the two critical PHP vulnerabilities on its platform, that the patches are applied to each customer's PHP version, and that no action is needed. It names the updated PHP versions: a patched 7.4 build, 8.2.35, 8.4.27 and 8.5.12. Source
Cloudways Rolling out Cloudways says interim configuration-level mitigations recommended by the PHP Group are deployed across its fleet and the phased rollout of official security patches is in progress for all supported PHP versions including deprecated ones. It first completed patches for all customer applications on Autonomous; in a later update it said the rollout for applications on Flexible was still in progress and on schedule, with no customer action needed and interim protections staying until it completes. Source
Pantheon Rolling out Pantheon says patched PHP builds are deployed on all live environments (PHP 8.2 or later, and all LTS versions), all environments in SFTP mode, and all pre-production customer environments. Free/sandbox environments will be updated over the next 24-48 hours. Network-level mitigations stay in place, and Pantheon says no customer action is required. Source
WordPress.com Unconfirmed Automattic says WordPress.com sites are protected and it worked with the PHP security team; no customer action is stated. Source
Pressable Unconfirmed Pressable says every PHP version on its platform is already protected against both vulnerabilities (production, staging, sandbox); customers need no action. Source
Flywheel Patched Flywheel says WP Engine has finished deploying the PHP security patches on the Flywheel platform; the patch has been applied to your PHP version and no action is needed. Protective mitigations were also in place at the CDN and host layers. Source
Nexcess Mitigation only Nexcess (a Liquid Web brand) is applying mitigations and has not yet changed production PHP; it is still deciding its patching plan and maintenance windows. Source
Liquid Web Rolling out Liquid Web says its engineering teams are actively working to deploy patched PHP builds across its hosting infrastructure. It lists the current patched builds: cPanel PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 plus vendor backports for 8.1, 8.0 and 7.4; Plesk PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus end-of-life 8.1, 8.0 and 7.4 builds; and Windows Plesk PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It tells customers who are not patched yet to run a package update through their control panel. It does not say its own managed hosting is fully patched. Source
DigitalOcean App Platform Customer action needed DigitalOcean says the App Platform PHP buildpack has been patched; you must redeploy your app to pick up the latest buildpack and its patched PHP. If you deploy from your own Dockerfile or container image, update the PHP version in that image and redeploy. The post does not name buildpack PHP versions. Source
Heroku Customer action needed Heroku released PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on its PHP runtime; you must redeploy your app to pick them up. The PHP 8.1 build on Heroku-22 was rebuilt with the PHP project's backported fix. Source
Render No statement No statement about this PHP issue found on Render's official channels as of the check. Source
Platform.sh / Upsun Rolling out Upsun's latest update says the PHP security patch has finished deploying to all Dedicated clusters, after updated PHP images were deployed to all grid regions across its fleet. It strongly recommends customers running PHP versions older than 8.0 upgrade to 8.0 or later as soon as possible; they are protected by its edge-layer mitigations in the meantime. Earlier updates: the PHP 8.4, 8.3, 8.2 and 8.5 images were deployed one by one, and no update will be available for branches older than 7.4. Brief downtime is possible while containers are refreshed. Source
Laravel Cloud Patched Laravel Cloud says it has patched every running application with the PHP security release and deployments have resumed. Applications now run PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 depending on the version used, patched in place with no redeploy needed. All new deployments use updated base images that include the patched versions. Source
Laravel Forge Customer action needed Forge users must still update PHP on their own servers. Laravel's post says that if you use PHP 8.2, 8.3, 8.4 or 8.5 you go to your server in Forge and click 'Update PHP', once per server, or update over SSH if that fails. Servers running Ubuntu 20.04 LTS (focal) or older cannot be updated: create a new server on a supported Ubuntu and move your sites. For PHP 8.0 and 8.1 it says no patch is available. Forge's own advisory says its automatic security updates do not patch PHP and that PHP 8.1 and earlier get no official fix. Source
AWS Elastic Beanstalk (PHP) Rolling out AWS says its Elastic Beanstalk Amazon Linux 2023 PHP 8.5 and PHP 8.4 platform versions now ship PHP 8.5.12 and PHP 8.4.27, which address both CVEs. A subsequent release will include updates for the PHP 8.3 and PHP 8.2 platform branches; the platform history still lists PHP releases below the fixed ones on those branches. Environments with Managed Platform Updates enabled get the new platform version automatically in their next maintenance window; otherwise you must update the environment's platform version yourself. Our guidance: Update the environment to the platform version that ships the fix (or later) on PHP 8.5 or PHP 8.4 (or enable Managed Platform Updates). On PHP 8.3 and PHP 8.2, wait for AWS's follow-on platform release and check the platform history, or move to a patched branch. Source
Amazon Lightsail Customer action needed AWS documents how Lightsail owners update PHP themselves. On instances created from the Lightsail-packaged blueprints (WordPress, WordPress Multisite, LAMP and Nginx) PHP comes from the operating system package repositories and is updated with the package manager. Instances created from Bitnami blueprints keep their own copy of PHP that apt upgrade does not update, and AWS recommends moving to a Lightsail-packaged blueprint. AWS lists the fixed versions as 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Our guidance: Take a snapshot, run sudo apt update and sudo apt upgrade, restart the web server, then paste the apt policy or dpkg -l output into this site's Linux package checker (Lightsail's packaged PHP keeps Ubuntu or Debian version numbers, not the upstream ones). For Bitnami-blueprint instances follow AWS's Lightsail guide for moving to a Lightsail-packaged blueprint or replacing the Bitnami PHP. Source
Azure App Service (Linux, PHP) Rolling out Microsoft says the updated built-in PHP images are now rolled out to the Latest and Standard release channels for App Service on Linux (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12). The Extended channel gets the fix last, so it advises switching to Standard or Latest. WordPress apps from the official WordPress on App Service offering in Microsoft Marketplace have been updated to patched PHP, except apps still on the older Alpine-based images, which will not receive the patches. Custom containers must be rebuilt by you, and end-of-life PHP runtimes are not patched. Source
Google Cloud (App Engine, Cloud Run) Customer action needed Google Cloud says App Engine standard (PHP 8.2+) is patched automatically; other services need a redeploy or rebuild with fixed PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35). PHP 8.1 and older will not be patched. Source
cPanel & WHM (EasyApache 4) Patched The EasyApache 4 update for this fix ships fixed ea-php82 to ea-php85 and backported patches for the end-of-life ea-php74, ea-php80 and ea-php81. Install the EasyApache 4 update through the normal system update, then restart PHP (Apache, PHP-FPM or LSAPI) so the new build is loaded. cPanel also updated the PHP inside cPanel & WHM itself (it affects cPanel interfaces, including Roundcube webmail): updated cPanel & WHM builds on three release lines include PHP 8.4.27, and an updated build on one older release line includes backported fixes for PHP 8.1. On CloudLinux, CloudLinux's own ea-php builds carry the fix under lower version numbers (for example a 8.4 build numbered below 8.4.27), so check the package changelog for the CVE IDs rather than comparing with the numbers above. Source
CloudLinux (alt-php) Customer action needed CloudLinux says fixed alt-php packages are in its stable repositories and that the release is complete: on CloudLinux OS 7, 8 and 9 for alt-php in the 5.x, 7.x and 8.x series up to 8.5; on CloudLinux OS for Ubuntu 22.04 LTS (jammy) for the same series with fewer 5.x versions; and, on CloudLinux OS 10, for the oldest 5.x alt-php only (the other versions come from the ELS ALT PHP repository). A regular update now installs all of these, followed by a restart of PHP. The packages carry the fix as a backport and keep their own lower version numbers, so CloudLinux says to confirm the fix in the package changelog. CloudLinux 6 is not confirmed yet. Our guidance: On CloudLinux OS 7 run yum clean all && yum update "alt-php*"; on CloudLinux OS 8, 9 and 10 run dnf clean all && dnf upgrade "alt-php*"; on CloudLinux OS for Ubuntu run apt-get update && apt-get upgrade. Then restart Apache, PHP-FPM or LiteSpeed, and check the changelog, for example rpm -q --changelog alt-php74-common | grep -E "CVE-2026-(109618|109619)". Security-only updates (yum --security) do not list these packages yet. Source
Plesk Obsidian Customer action needed Plesk says fixed PHP builds are available: PHP 8.2 to 8.5 as 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on Plesk for Linux and Plesk for Windows. On Linux, the end-of-life PHP 7.4, 8.0 and 8.1 builds keep their version numbers, and the builds made on the PHP fix release day () include the fixes. Plesk's own interface engine (sw-engine) is fixed in updates to two Plesk Obsidian releases. Plesk's call to action is to update Plesk to the latest available version. Our guidance: Install the Plesk updates on your server (Plesk's own call to action is to update Plesk), then check the PHP version for each handler under Tools & Settings > PHP Settings. For PHP 7.4, 8.0 and 8.1 on Linux the version number does not change, so check the build date ( or later). If your site is on a host's shared server, ask the host whether it has installed the update. Source
DirectAdmin (CustomBuild) Customer action needed DirectAdmin released a build that bumps CustomBuild PHP 8.5, 8.4, 8.3 and 8.2 to the latest versions and adds patches for PHP 8.1, 8.0 and 7.4. A later build adds patches for the older PHP versions it still builds (five branches older than 7.4) and a small fix for the PHP 8.1 compilation. A further build for the legacy rhel7 and debian10 release channels comes with the latest PHP versions and all security patches. The PHP upgrade is not automatic: run 'da update' then 'da build php' (unless the CustomBuild cron is enabled). Staff earlier noted PHP 8.1 may not build cleanly on some systems. Source
Webuzo (Softaculous) Customer action needed Webuzo says it has released updated EMPS packages (the PHP stack Webuzo ships) that address CVE-2026-109618 and CVE-2026-109619, and that it launched PHP 7.4 to 8.5 with patches (its older EMPS line for a pre-7.4 PHP is updated to PHP 7.4 with the patches). It recommends all Webuzo users update EMPS and all PHP as soon as possible by running a command as root. A new stable Webuzo release includes the EMPS security fix and says EMPS will be updated automatically. Webuzo does not name PHP version numbers. Source
CyberPanel Customer action needed CyberPanel now says fixed LiteSpeed packages are available and that it updated PHP to 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on its own Ubuntu 26.04 LTS (resolute) test server, where the checks passed. Administrators must update every PHP runtime and its modules themselves, refresh CyberPanel's separate panel PHP copy, restart workers and verify. The result covers that test system only, and PHP 8.1 and older need a vendor backport or migration. Source
Virtualmin Mitigation only Virtualmin staff say Virtualmin does not provide PHP packages and that the operating system does (forum reply), so the PHP fix comes from your OS or PHP package source. An earlier pre-release staff post suggested turning off one PHP session setting in the PHP-FPM pool as a partial step. No Virtualmin list of patched packages was found. Source
ISPConfig Mitigation only ISPConfig says this is not an ISPConfig vulnerability and the real fix is an updated PHP from your distribution or PHP repository (Debian, Ubuntu, sury.org and others). As a temporary measure it published 'ispconfig-multipart-guard', which blocks multipart (file upload) requests in nginx or Apache; uploads on blocked sites stop working until you install the PHP update and switch the guard off. Source
aaPanel Customer action needed aaPanel staff (in an edited post) now say patches are available for PHP 7.4 to 8.5 only (update to 8.5.12, 8.4.27, 8.3.36, 8.2.35, or the 8.1, 8.0 and 7.4 builds the post names); an earlier staff reply says fixes were added for the 7.4, 8.0 and 8.1 updates. Update in the App Store: click 'Update App List', find the PHP version, click Update, and repeat for each installed PHP version; take a snapshot first. Users on PHP older than 7.4 are pointed to configuration mitigation only. Do not judge the 8.1, 8.0 and 7.4 builds by number alone: the post's numbers for those branches are not PHP project fixed releases (php.net uses the number the post gives for 8.0 for an older, unfixed release). Several users in the same thread report failed or very slow PHP builds in the panel. Source
Cloudflare WAF Mitigation only Cloudflare deployed managed WAF rules for php2shell that are on by default for Free and paid plans. It also released a new response-side managed rule (Cloudflare Managed Response Firewall Default, 'Default block for High confidence Signatures') on all plans including Free, which looks at the origin's response as well as the request. They are an extra layer only: Cloudflare says to patch PHP anyway, and traffic that reaches your server without passing through Cloudflare is not covered. Paid plans should check that the Managed Ruleset is deployed in block mode. Source
Sucuri Website Firewall Mitigation only Sucuri has deployed extra WAF rules for the two PHP CVEs on its Website Firewall (status: 'Monitoring'). A later Sucuri blog post adds that more refined virtual patching rules for known exploitation paths are now deployed across its WAF network, that the WAF only works for requests passing through the firewall (direct connections to the origin can bypass it), and that you must still update PHP. Sucuri stresses this does not replace patching PHP on the origin server: ask your host to update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a vendor-patched package. Source
Wordfence (WordPress) Customer action needed Wordfence published a post-release notice: PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix both vulnerabilities, WordPress automatic updates will not fix them, and PHP must be updated by your host or on your own server. A follow-up post says its Threat Intelligence team reviewed PHP's patches and tested the behaviour in lab environments, that its firewall protects the WordPress application layer only, and that updating and restarting PHP is essential. It does not announce a firewall rule for these CVEs. Source
Patchstack (WordPress) Customer action needed Patchstack's alert says to update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor's patched package) and to contact your vendor for a backport or upgrade if you run PHP 8.1 or older. It lists configuration measures as partial only and recommends against unofficial 'fix' plugins. The page does not mention a Patchstack virtual patch for this issue. Source
Imunify360 (CloudLinux) Mitigation only Imunify360's WAF rules are an interim mitigation, not a fix. Three ruleset updates are delivered automatically to servers with Imunify360 and its WAF enabled; on Apache, Nginx and Coraza they block the known exploit requests and the public exploit tool, and since the second of these rulesets LiteSpeed also blocks the tool and upload-progress requests that do not come from the site's own pages. Imunify360 also gives scanning IPs a CAPTCHA challenge. CloudLinux says the rules target only the upload-progress path of CVE-2026-109619 and that no rule blocks the out-of-memory path of CVE-2026-109618 yet; ImunifyAV and servers with the WAF disabled get no coverage. Updating PHP is still the action to take: CloudLinux's blog says fixed alt-php packages are now in stable. Source

Europe

Region: Europe
ProviderStateWhat they saySource
OVHcloud Web Hosting Patched OVHcloud says all PHP releases from 7.4 to 8.5 have been patched on all Web Hosting clusters; it had earlier applied WAF rules on all clusters. It also says it is still working on the previous releases. This covers Web Hosting only, not VPS or Public Cloud. Source
Hetzner Patched Hetzner says it has deployed patches for PHP 7.4 and 8.0 to 8.5, and then for the two remaining older PHP versions it offers, on all Webhosting and Managed Servers. Dedicated and cloud server customers are being notified separately by email. Source
netcup Patched netcup says all Webhosting packages (including Reseller) and all Managed Servers have been patched and secured and are online, and that no unpatched PHP version is online on them. The Webhosting Control Panel is back online after Plesk provided an updated version. Root server, VPS and managed cloud cluster customers manage their own systems and must patch PHP themselves. Source
Hostnet Patched Hostnet says the PHP security update has been rolled out on all of its systems and the vulnerabilities are fixed, including older PHP versions via PHP Extended Support; its temporary measures have since been lifted. Source
Infomaniak Rolling out Infomaniak says updates for PHP 8.5, 8.4, 8.3, 8.2, 8.1, 8.0 and 7.4 are being deployed. Its last update says it is continuing the rollout of security updates at a regular pace and has temporarily paused migrating Web Hosting and Cloud Server to the latest infrastructure versions. The hosting incident was then marked ended without a statement that every update is done. It disabled session.upload_progress.enabled as a temporary mitigation and temporarily limited file uploads on several of its other services. Versions older than PHP 7.4 must be upgraded. Source
TransIP No statement No statement about this PHP issue found on TransIP's official website as of the check. TransIP's status page could not be reached. Source
o2switch No statement No statement about this PHP issue found on o2switch's official channels as of the check. Source
Gandi No statement No statement about this PHP issue found on Gandi's official channels as of the check. Source

Japan

Region: Japan
ProviderStateWhat they saySource
さくらのレンタルサーバ / さくらのマネージドサーバ (Sakura Internet) Patched Sakura Internet says it has completed the fix for the PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619) for every PHP version that can be selected in the control panel, for Rental Server and Managed Server. It says phpMyAdmin used by some services is still being handled; it later added that the webmail work is complete. Its emergency maintenance 'PHP version upgrade' is marked completed. Our guidance: Sakura says no urgent action is needed from customers. It also suggests moving to the newest PHP version still in its support period; if you do, check that your app works on it and take a backup first. Source
エックスサーバー (Xserver) Rolling out Xserver Inc. says fix patches have been applied on all target servers for PHP 8.2 to 8.5 (in a notice) and then for PHP 7.4 to 8.1 (in a later official X post). For PHP older than 7.4 it says it is still applying fixes in sequence. Mitigations were applied earlier. Account screens and many functions have resumed; the service sites are still suspended and are planned to return the same day. Our guidance: The notice does not ask customers to do anything now. It says it may ask for extra steps after the control panel is fully back, so check the host's notice (site and X @xserverjp) and act only if it asks. If you run PHP older than 7.4, check with the host before relying on it. Source
Xserverビジネス (Xserver Business) Rolling out Xserver Inc.'s company-wide notice (also shown on this product's own site) says fix patches have been applied on all target servers for PHP 8.2 to 8.5, and its official X account later says the same for PHP 7.4 to 8.1. For PHP older than 7.4 it says it is still applying fixes in sequence. The notice does not name this product. Account screen, server panel and sign-up for Xserver Business are listed as available. The service sites are still suspended. Our guidance: The notice does not ask customers to do anything now. It says it may ask for extra steps after the control panel is fully back, so check the host's notice (site and X @xserverjp) and act only if it asks. If you run PHP older than 7.4, check with the host before relying on it. Source
シンレンタルサーバー (Shin Rental Server) Rolling out Xserver Inc.'s company-wide notice (also shown on this product's own site) says fix patches have been applied on all target servers for PHP 8.2 to 8.5, and its official X account later says the same for PHP 7.4 to 8.1. For PHP older than 7.4 it says it is still applying fixes in sequence. The notice does not name this product. In a later update it says the Shin Cloud services have resumed their account screen and features (some still under maintenance); the login, server panel and sign-up links for Shin Rental Server are available again, and only Shin Domain is listed as 'preparing to resume'. The service sites are still suspended. Our guidance: The notice does not ask customers to do anything now. It says it may ask for extra steps after the control panel is fully back, so check the host's notice (site and X @xserverjp) and act only if it asks. If you run PHP older than 7.4, check with the host before relying on it. Source
スターレンタルサーバー / スターサーバー (Star Server) Rolling out Xserver Inc.'s company-wide notice (also shown on this product's own site) says fix patches have been applied on all target servers for PHP 8.2 to 8.5, and its official X account later says the same for PHP 7.4 to 8.1. For PHP older than 7.4 it says it is still applying fixes in sequence. The notice does not name this product. Account screen, server panel and sign-up for Star Rental Server are listed as available. The service sites are still suspended. Our guidance: The notice does not ask customers to do anything now. It says it may ask for extra steps after the control panel is fully back, so check the host's notice (site and X @xserverjp) and act only if it asks. If you run PHP older than 7.4, check with the host before relying on it. Source
ロリポップ!レンタルサーバー (GMO Pepabo) Patched GMO Pepabo says on its official X account that it applied the fixed version and restored customers' sites, and that it also applied its own fixes to older PHP versions that have no official fix. It says the service site, apart from some parts, is to resume shortly. Our guidance: The posts do not ask customers to do anything. Check Lolipop's X @lolipopjp and notices for when the service site is fully back. Source
ヘテムル (heteml, GMO Pepabo) Patched GMO Pepabo says that for PHP 8.0 and later and PHP 7.4 it applied the official fixed versions, and that for all other versions it made its own fix based on the official fix. It says some functions (such as session.upload_progress) are now disabled on PHP 8.1 and below. As of its latest addendum, customer sites, the service site, the control panel, heteml FTP, hetemail and phpMyAdmin are back; only the 'Osaipo!' auto-update was still stopped (recovery in progress). Our guidance: Check that your own site still works: the host says some functions are disabled on PHP 8.1 and below. It also suggests moving to a newer PHP version. The 'Osaipo!' auto-update was still stopped at the last check. Source
レンタルサーバーCPI Rolling out CPI says, in its latest update, it is urgently working on the PHP versions for which the latest official patch exists, and will update on versions without a patch. Customer servers keep running; the service site and control panel stay suspended (Roundcube webmail has resumed), restart time undecided. It states no unauthorized access or attack has been observed. Our guidance: No customer action is requested. Sites and mail keep working. Watch CPI's page for updates. Source
KAGOYA レンタルサーバー (カゴヤ・ジャパン) Planned KAGOYA's notice naming CVE-2026-109618 / CVE-2026-109619 has been updated. For Rental Server plans on PHP 8.2/8.3/8.4/8.5 it says it is coordinating the response by upgrading to the fixed versions. For Managed Dedicated, Shared Server and WordPress-dedicated plans it says the permanent response is still being decided, and as an interim risk reduction it asks owners to consider taking the site offline (switching to a maintenance screen) or restricting access. Our guidance: KAGOYA suggests interim steps for Managed Dedicated, Shared Server and WordPress-dedicated plans, such as taking the site offline or restricting access. On the Rental Server plan with PHP 8.2 to 8.5, wait for KAGOYA's update. Watch the same notice page for follow-up. Source
ConoHa WING (GMO Internet) Rolling out ConoHa says that the ongoing emergency maintenance of ConoHa WING and the temporary suspension of File Manager and Webmail are both part of its response to the fixed version of PHP released on . It says it is applying security patches to the servers in sequence while keeping each customer's current PHP version. Website display and mail sending and receiving work as usual. Our guidance: ConoHa says you do not need to change your PHP version yourself. File Manager and Webmail are suspended as a precaution; check the host's notices for progress. Source
お名前.com レンタルサーバー (GMO Internet) Rolling out GMO Internet says its ongoing emergency server maintenance and the temporary suspension of File Manager and Webmail are part of its response to the fixed version of PHP released on . It says it is applying security patches to servers in sequence while keeping each customer's current PHP version. Customers basically do not need to change their PHP version, but it says a change may be needed for some customers on PHP 5.x or 7.x. Website display and mail work as usual. Our guidance: Basically no PHP version change is needed. If you are on PHP 5.x or 7.x, check the host's notices, because a change may be needed. File Manager and Webmail are suspended as a precaution. Source
カラフルボックス / カラフルビジネス (ColorfulBox) Patched ColorfulBox says that protective measures and the security-fix update work on all its servers (shared server, ColorfulBusiness, Tada Server, dedicated server) were all completed. It says the servers were updated to fixed builds while keeping each customer's PHP version, so customers do not need to change or switch PHP versions. It says older versions such as PHP 7.4 and PHP 8.0/8.1 are also covered by security fixes and protective measures on the server side, in addition to the latest fixed releases of PHP 8.2 to 8.5. Our guidance: ColorfulBox says no action is needed and that you do not need to change your PHP version. Source
mixhost (ミックスホスト) Patched mixhost says it has finished applying the PHP fix packages on all servers of mixhost Rental Server, mixhost Adult Rental Server and mixhost Overseas Rental Server, for CVE-2026-109618 and CVE-2026-109619. It says the scope is PHP versions from the 5.x series up to 8.5, including versions that upstream no longer fixes, through CloudLinux's own fix packages. The fix does not change the PHP version number shown (for example a 8.4 build numbered below 8.4.27 keeps its number). It says no customer action is needed and recommends PHP 8.2 or later for customers on older versions. Our guidance: mixhost says no customer action is needed. The PHP version number shown in WordPress Site Health or phpinfo does not change after the fix. If you are on PHP below 8.2, it recommends moving to 8.2 or later. Source
CORESERVER V1 / V2 (コアサーバー, Value Domain) Rolling out Value Domain's status page names CVE-2026-109618 / CVE-2026-109619 and marks both CORESERVER maintenances completed. For CORESERVER V2 (all servers, completed) it says the fix is complete for every PHP version it offers. For CORESERVER V1 (all servers, completed) it says the fix is complete for PHP 7.4 and later (7.4, 8.0 to 8.5) and does not mention older versions. Our guidance: On the versions the host lists as fixed, no PHP version change is needed. On CORESERVER V1 with PHP older than 7.4, the notice says nothing; ask the host or move to a supported PHP version. Source
XREA (エクスリア, Value Domain) Rolling out Value Domain's status page names CVE-2026-109618 / CVE-2026-109619 and marks the XREA maintenance (all servers) completed. It says the fix is complete for PHP 7.4 and later and that customers on those versions do not need to change their PHP version. Older PHP versions are not mentioned. Our guidance: No PHP version change is needed on PHP 7.4 or later. For older PHP versions the notice says nothing; ask the host or move to a supported PHP version. Source
VALUESERVER (バリューサーバー, Value Domain) Rolling out Value Domain's status page names CVE-2026-109618 / CVE-2026-109619 and marks the VALUESERVER maintenance (all servers) completed. It says the fix is complete for PHP 7.4 and later and that customers on those versions do not need to change their PHP version. Older PHP versions are not mentioned. Our guidance: No PHP version change is needed on PHP 7.4 or later. For older PHP versions the notice says nothing; ask the host or move to a supported PHP version. Source
Oneレンタルサーバー (Value Domain / GMO DigiRock) Rolling out Value Domain's status page names CVE-2026-109618 / CVE-2026-109619 and marks the One Rental Server (Oneレンタルサーバー) maintenance (all servers) completed. It says the fix is complete for PHP 8.0 and later and that customers on those versions do not need to change their PHP version. Older PHP versions are not mentioned. Our guidance: No PHP version change is needed on PHP 8.0 or later. For older PHP versions the notice says nothing; ask the host or move to a supported PHP version. Source
WebARENA (NTTPC) Mitigation only NTTPC Communications published a notice for WebARENA SuiteX (shared hosting) naming CVE-2026-109618 and CVE-2026-109619. It says it has restricted web access from outside Japan and disabled one PHP function (the file-upload progress feature), both completed, and that other mitigations, next steps and customer requests will be posted on the same page. The notice does not say a PHP fix has been applied. Our guidance: The notice does not ask customers to do anything yet. Watch the same notice page for follow-up. Source
ABLENET (旧ケイアンドケイコーポレーション) No statement No PHP-specific statement found. The latest security item is about a Linux kernel vulnerability for VPS, a different issue. Our guidance: No instruction. If you run PHP yourself, update the OS package and check the version. Source