Failles critiques PHP (CVE-2026-109618 et CVE-2026-109619) : comment protéger vos serveurs Bare Metal et VPS

Le projet PHP a publié le 21 octobre 2026 des correctifs d’importance pour deux failles critiques. Si PHP tourne sur l’un de vos serveurs dédiés Bare Metal ou VPS, voici comment vérifier votre exposition et vous protéger, étape par étape.

Ce billet de blog s’adresse à nos clients de serveurs dédiés/VPS. Les clients WebCloud et ceux avec un hébergement mutualisé bénéficieront automatiquement d’un composant PHP mis à jour.

L’essentiel en un coup d’œil

Ce qui se passe, expliqué simplement

Les deux failles touchent le cœur de PHP, et non un CMS ou un framework en particulier. Elles concernent la façon dont PHP gère sa mémoire entre deux requêtes :

• CVE-2026-109618 : une requête volontairement trop lourde (un envoi de formulaire, par exemple) pousse PHP à épuiser sa mémoire et à laisser des données dans un état incohérent.
• CVE-2026-109619 : des informations d’une requête précédente restent en mémoire alors qu’elles devraient être effacées, et sont réutilisées par la requête suivante.

Dans les deux cas, un attaquant peut exécuter son propre code sur votre serveur, avec les droits de votre serveur web. Il n’a besoin ni de compte, ni de mot de passe : une connexion à votre site suffit. L’exploitation a été démontrée par les chercheurs, notamment avec Apache (mod_php) et PHP-FPM, les deux configurations les plus courantes.

Êtes-vous concerné ? Vérifiez en deux minutes

Vous êtes notamment concerné si PHP sert un site ou une application sur l’un de vos serveurs Bare Metal (Kimsufi, So you Start, Rise, Advance, Scale, High Grade) ou sur un VPS OVHcloud.

Connectez-vous en SSH et tapez :

php -v

Comparez le résultat avec ce tableau :

Bon à savoir : la version affichée en ligne de commande peut différer de celle utilisée par votre site, surtout si plusieurs versions de PHP sont installées. En cas de doute, vérifiez aussi la version dans la configuration de votre serveur web ou de votre panneau d’administration (Plesk, cPanel…).

Mettre à jour pas à pas

La mise à jour ne devrait pas prendre plus d’une quinzaine de minutes par serveur. Nous vous conseillons de traiter en premier les serveurs accessibles depuis Internet.

Faites une sauvegarde. Sur un VPS, un snapshot depuis l’espace client OVHcloud suffit. Sur un serveur Bare Metal, sauvegardez au minimum vos fichiers de configuration et vos données.

Mettez à jour les paquets PHP avec le gestionnaire de votre distribution :

• Debian / Ubuntu : sudo apt update && sudo apt upgrade
• AlmaLinux / Rocky Linux : sudo dnf upgrade
• PHP compilé depuis les sources : téléchargez la version corrigée sur php.net
• Conteneurs Docker : reconstruisez vos images sur une image PHP à jour, puis redéployez

Redémarrez vos services PHP. C’est l’étape la plus souvent oubliée : sans redémarrage, l’ancienne version continue de tourner en mémoire.

• PHP-FPM : sudo systemctl restart php8.x-fpm (Debian/Ubuntu, en remplaçant x par votre version) ou sudo systemctl restart php-fpm
• Apache : sudo systemctl restart apache2 ou sudo systemctl restart httpd

Vérifiez avec php -v que la version corrigée est bien en place, et que votre site fonctionne normalement.

Si votre distribution ne propose pas encore la version corrigée, revenez vérifier régulièrement : certains dépôts publient les mises à jour avec quelques heures de décalage. En attendant, appliquez les mesures temporaires ci-dessous.

Vous ne pouvez pas mettre à jour tout de suite ?

Le projet PHP est clair : seule la mise à jour protège complètement votre serveur. Les réglages suivants, issus des avis officiels, réduisent le risque en attendant. Ils se placent dans votre php.ini, puis demandent un redémarrage de PHP-FPM ou d’Apache.

• Désactivez le suivi de progression des envois de fichiers : session.upload_progress.enabled = 0. Cette fonction est rarement utilisée, et PHP recommande de la laisser désactivée même après la mise à jour.
• Sur PHP 8.5 uniquement : fatal_error_backtraces = 0.
• Si votre application n’utilise pas d’envoi de formulaires avec fichiers, bloquez ce type de requêtes (multipart) au niveau de votre serveur web ou de votre proxy.

PHP évoque aussi la suppression de la limite mémoire (memory_limit = -1). Nous vous invitons à la manier avec prudence : une seule requête pourrait alors consommer toute la mémoire de votre serveur.

Vous êtes encore en PHP 8.1 ou antérieur ? Ces versions ne recevront pas de correctif. Appliquez ces mesures dès aujourd’hui, et planifiez au plus vite une migration vers PHP 8.4 ou 8.5.

Nous sommes là pour vous aider

Sur un serveur Bare Metal ou un VPS, vous gardez totalement la main sur votre système : nous n’intervenons en aucune manière sur vos instances sans votre accord. C’est pour cela que nous tenons à vous donner toutes les clés pour agir rapidement et sereinement.

De notre côté, nous mettons à jour les images d’OS disponibles à l’installation et prévenons les clients dont les instances semblent exposées. Nous compléterons cet article si de nouvelles informations sont publiées.

Une question, un doute sur votre configuration ? Nos équipes support sont à votre écoute, et nos partenaires peuvent vous accompagner pour la mise à jour ou la migration de vos versions de PHP.

Pour aller plus loin

• Annonce officielle PHP et téléchargement des versions corrigées
• Avis de sécurité CVE-2026-109618
• Avis de sécurité CVE-2026-109619
• Versions de PHP maintenues