OVHcloud PHP2Shell status: what OVH said and how to confirm

OVHcloud says shared hosting gets PHP updated automatically, while VPS and Bare Metal customers must patch and restart PHP themselves. Its status notice reports PHP 7.4 to 8.5 patched on all clusters on 21 October at 17:53 UTC and PHP 5.3 to 7.3 completed on 23 October at 17:07 UTC, and the maintenance was marked completed on 26 October at 09:50 UTC (vendor-claimed). Your domain stays unknown. Ask OVH support, in writing, for the fixed build and the worker restart for your domain.

Which OVHcloud products are affected?

It depends on who runs the PHP. OVH's post, in French, splits its customers into two groups.

• WebCloud and shared hosting. OVH says these customers will benefit automatically from an updated PHP component. OVH runs the servers, so the fix is OVH's to deploy. OVH's dated status notice reports PHP 7.4 to 8.5 patched on all clusters on 21 October 2026 at 17:53 UTC, PHP 5.3 to 7.3 deployment completed on 23 October 2026 at 17:07 UTC, and the maintenance marked completed on 26 October 2026 at 09:50 UTC. That is a vendor-claimed rollout. It names clusters, not your domain, so it stays "unknown" for your domain until OVH confirms the build.
• VPS and Bare Metal (the post lists Kimsufi, So you Start, Rise, Advance, Scale and High Grade). You run the operating system and the PHP packages. OVH says it updates the OS images offered at install, warns customers whose instances look exposed, and does not act on your instances without your agreement.
• Public Cloud. The post does not mention it. We make no statement either way.

The PHP project is clear that all PHP installations serving web requests are in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Sites that run no PHP are not affected by this bug. More on the bug itself is on the PHP2Shell page.

What did OVH's status notice say, and when?

All entries are vendor-claimed, at our check on 26 October 2026. The notice lists clusters, not individual domains.

Does "my panel shows 8.3" mean my OVH site is patched?

Three things make a version number misleading on any host, OVH included.

1. Backports keep the old number. A distribution fix arrives as a new package build under the same PHP version. The package changelog, which names both CVE ids, is the evidence.
2. php -v is the command-line PHP. The binary that answers web requests can be a different one. OVH's post itself tells customers to check the version used by the web server or the admin panel, as well as in SSH.
3. A fixed package is not a restarted worker. OVH's post says that without a restart the old version keeps running in memory. This is the step people skip.

A hosting plan's PHP selector shows the branch you chose. It does not show whether the build behind it has the fixes. In the OVHcloud Control Panel the setting is under Web Cloud > Hosting plans > your plan > the Configuration box > Global PHP version, per OVH's hosting configuration guide (page dated 23 July 2026, at our check on 24 October 2026). Treat what you see there as the branch only; what a version check can and cannot prove is covered separately.

How do I fix it on OVHcloud?

What do I do on shared hosting or WebCloud?

You cannot patch it yourself. Ask OVH support, and keep the answer:

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, confirm that all PHP workers serving it have been restarted or replaced, and say whether I need to change a setting or the PHP version selected for my plan.

• Send the question for each domain on the plan, not once per account.
• Ask what you can see yourself that proves the build (a build date, a changelog entry).
• If your plan is pinned to PHP 8.1 or older, ask what OVH will do for that version, and plan a move to a supported branch.
• Until you have an answer, treat the state as unknown. See the host question guide in questions to put to a shared host.

What do I do on a VPS or Bare Metal?

• Take a snapshot (VPS) or back up configuration and data (Bare Metal) first. OVH recommends this in its post.
• Update PHP from your distribution's packages, or from rebuilt Docker images if you run containers. The changelog must list both CVE ids. Check your distribution's own advisory, for example Debian's tracker or Canonical's notice.
• Restart PHP-FPM, or Apache if you use mod_php.
• Check the PHP the web server uses, not only the command line.
• Check every virtual host if the server runs more than one PHP version.
• If you cannot update yet, OVH lists temporary measures in its post. These reduce exposure. They do not replace the update.
• Set session.upload_progress.enabled = 0 and keep it off after updating. OVH's post says PHP recommends leaving it disabled even after the update. PHP's 23 October notice suggests the same setting until the next regular bugfix release, for the separate CVE-2026-115560. php.net says this setting must be changed in php.ini or the FPM or server configuration, because ini_set() and .user.ini act too late.

Am I affected? A three-state self-test

Was anything exploited on OVHcloud?

We found no OVH statement about exploitation of customer servers, and no primary source naming any compromised OVH customer. In general, AWS reported exploit attempts against its honeypots from 17 October, before disclosure (vendor-claimed, see also the PHP2Shell page). Our write-up of what is known about exploitation carries the dated detail.

If your PHP was reachable and unpatched in the days around disclosure, look for unexpected PHP files in upload directories, new scheduled tasks, new admin accounts and odd outbound connections. Patching does not remove anything planted earlier.

Where do I follow the rest of this month's incidents?

PHP2Shell is one of several October 2026 incidents. The October 2026 security tracker lists each one with its dated primary source. Status pages for the other hosts are collected in one place, for example IONOS, HostGator's confirmation steps or what Microsoft says about Azure App Service.