What OVHcloud did on October 21
On the evening of October 21, OVHcloud announced on its status page that application firewall rules had been deployed across its shared hosting clusters, along with an ongoing maintenance campaign, according to Clubic’s report at 6:25 PM. This is a temporary protection: it filters some malicious requests but does not fix PHP. A message from the OVHcloud community also noted a site still running PHP 8.5.7 when 8.5.12 was available. In other words, server updates happen in waves, and you’ll only know it’s been done by checking the version number of your own hosting.
Where to check your OVH hosting’s PHP version
In the OVHcloud customer portal, open Web Cloud, then Hosting, and select your hosting plan. In the General Informationtab, the line Global PHP Version indicates the version selected for the entire hosting account.
Two important details. First, this ‘global’ version can be overridden folder by folder by placing a `.ovhconfig` file in a subfolder: if your site is in a subdirectory, the version in that file applies. Second, the displayed number is a branch, such as 8.1 or 8.3, not the exact patch number. On WordPress, the exact number can be found in Tools, then Site Health, tab Info, section Server.
Change the version from the client area
Still in General Information, locate the Configuration. To the right of Global PHP Version, click the …, then on Edit Configuration. Select Modify the current configuration, select the desired version, click on Next, then on Confirm. The change will propagate in a few minutes.
If the Modify the configuration button is grayed out, a version check is being performed on their end. This is the case during maintenance campaigns like the one on October 21: wait a few minutes and try again—no need to reload ten times.
Changing the version with the .ovhconfig file
For those who prefer FTP: the `.ovhconfig` file is present by default at the root of your hosting storage space. The line `app.engine.version=8.1` sets the PHP version, provided that `app.engine=php` is present. For PHP 7.4 and all higher versions, the environment must be `container.image=stable64`. Replace the number with 8.3 or 8.4, save, and the result will be the same as changing it from the client space. Be cautious with older hostings that have accumulated multiple `.ovhconfig` files in subfolders: conflicting files can cause unpredictable behavior, and that’s the first thing I check when a client tells me that ‘nothing is changing.’
Which version to choose
PHP 8.3 or 8.4: the best choice for a WordPress, WooCommerce, or a modern tool. The patched versions are 8.3.36 and 8.4.27, and these branches will receive security patches until 2027 and 2028. OVH offers both in the Stable64 environment, along with 8.5.
PHP 8.2: also patched, up to 8.2.35, but the branch ends on December 31, 2026. You’ll have to repeat the process in two months.
PHP 8.1, 8.0, 7.4: no officially patched versions available. If your site is still on these, switching branches is no longer an option—it’s the security update itself. Before upgrading, check that your CMS supports the target version: WordPress works from 7.4 to 8.5, with 8.3 recommended, PrestaShop depends on its own version, and it’s often an old extension or theme causing the issue, not the CMS itself.
Verify that the patch is properly installed
Switching branches isn’t enough: the full number must match the patched level. The numbers to appear are 8.2.35, 8.3.36, 8.4.27, or 8.5.12. If your hosting shows 8.3 but the phpinfo page or WordPress Site Health indicates 8.3.35, OVH’s campaign hasn’t yet reached your server. Restart the verification tool the next day, or check the X-Powered-By header when it is displayed. And an old number does not prove the vulnerability on its own: in case of doubt, ask OVH in writing whether the patch has been applied to your cluster.
If the site breaks after the change
It happens, especially when moving from 7.4 or 8.0 to 8.3: an extension using a deprecated function, a theme that hasn’t been updated in years. The reflex: revert to the previous version via the same menu, long enough to update the faulty extension or theme, then go back up. Better yet: first test on a site copy, and make a backup outside the server before touching anything. A blank page after the change can be read in the hosting error logs, in the customer portal.
And if you don’t want to handle it yourself
This is the kind of remote intervention I perform in one hour for a simple site, half a day for a shop with many modules: backup, testing on a copy, version change, patch verification, testing of the homepage, admin panel, and a payment, then a written report. Write to me with your site’s link, I’ll reply within 24 hours. The same guides exist for o2switch and IONOS.
Sources: OVHcloud guide « Web hosting: environment, PHP version, .ovhconfig », hosting provider overview by Clubic on October 21 at 6:25 PM, fixed versions on php.net.
