Failles PHP critiques : vérifier et patcher votre serveur dédié en 15 minutes

Si PHP tourne sur votre serveur Kimsufi, mettez-le à jour vers PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, puis redémarrez PHP-FPM ou Apache. C'est tout, et ça prend une quinzaine de minutes. Le redémarrage est l'étape que tout le monde oublie : sans lui, l'ancienne version reste en mémoire et votre serveur reste exposé. La suite détaille chaque commande, et ce qu'il faut faire si votre version de PHP n'a pas de correctif.

Publié le 22 octobre 2026 · Par Louise Boderé · Relu par Denis Hamon · Article mis à jour si de nouvelles informations sont publiées

Ce qui s'est passé le 21 octobre

Le projet PHP a publié mercredi 21 octobre des correctifs pour deux failles critiques, CVE-2026-109618 et CVE-2026-109619. Les deux ont reçu la note de 9,2 sur 10 sur l'échelle CVSS v4.

Dans la foulée, de nombreux sites ont été mis en maintenance par précaution : ceux des préfectures, de la CNIL, de titres de presse, selon Le Monde. Le ministère de l'Intérieur a mis hors ligne ses sites exposés à la demande de l'ANSSI. Le CERT-EU, le NCSC britannique et l'ACSC australien ont conseillé de couper les sites qui ne pouvaient pas être patchés. Le directeur technique de Cloudflare a signalé les premières attaques le jour même.

L'échelle s'explique : PHP fait tourner 69,3 % des sites web dont le langage serveur est connu (W3Techs, 22 octobre 2026). WordPress, Drupal, Joomla, Magento, les panneaux d'administration : tout ce qui repose dessus est concerné.

Les deux failles, en clair

Le problème n'est pas dans votre application. Il est dans la façon dont PHP gère sa mémoire entre deux requêtes.

Dans les deux cas, l'attaquant obtient les droits de votre serveur web. Une connexion HTTP à votre site lui suffit.

Votre serveur est-il exposé ? Vérifiez en 2 minutes

Vous êtes concerné dès que PHP répond à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed. Le projet PHP juge le risque le plus élevé avec mod_php.

Connectez-vous en SSH et lancez :

php -v                                              # version en ligne de commande
systemctl list-units --type=service | grep -i fpm   # services PHP-FPM actifs
apache2ctl -M 2>/dev/null | grep -i php             # mod_php chargé dans Apache ?

Attention : la version en ligne de commande peut différer de celle qui sert votre site, surtout si plusieurs versions de PHP sont installées. Vérifiez chaque pool FPM et votre panneau d'administration si vous en utilisez un (Plesk, cPanel…).

Comparez ensuite avec ce tableau :

Le même tableau, à garder sous la main ou à partager avec votre équipe :

Bon à savoir : avec les paquets Debian ou Ubuntu, le numéro de version peut ne pas changer. Les distributions intègrent souvent le correctif sans modifier la version, seul le suffixe du paquet bouge. Dans ce cas, cherchez le numéro de CVE dans le journal du paquet :

apt changelog php8.2-common | grep -m1 CVE-2026-109618   # adaptez à votre version

Si la ligne s'affiche, le correctif est là.

Patcher en 4 étapes

Comptez une quinzaine de minutes par serveur. Commencez par les machines exposées sur Internet.

1. Sauvegardez. Au minimum vos fichiers de configuration et vos données. Notre guide de sauvegarde de serveur dédié détaille les options.

1. Mettez à jour PHP avec le gestionnaire de votre système :

bash sudo apt update && sudo apt upgrade # Debian, Ubuntu sudo dnf upgrade # AlmaLinux, Rocky Linux

PHP compilé depuis les sources : récupérez la version corrigée sur php.net. En conteneur : reconstruisez vos images sur une image PHP à jour, puis redéployez.

1. Redémarrez vos services PHP. C'est l'étape la plus souvent oubliée.

bash sudo systemctl restart php8.4-fpm # remplacez 8.4 par votre version sudo systemctl restart apache2 # httpd sur AlmaLinux et Rocky Linux

1. Vérifiez. Relancez php -v ou la commande apt changelog ci-dessus, puis ouvrez votre site pour contrôler qu'il répond normalement.

Pourquoi le redémarrage compte : après apt upgrade, la version corrigée est sur le disque, mais le processus PHP déjà lancé tourne toujours avec l'ancienne.

Votre distribution ne propose pas encore le correctif ? Certains dépôts le publient avec quelques heures de retard. Revenez vérifier, et appliquez les mesures suivantes en attendant.

Pas de correctif tout de suite ? Les mesures temporaires

Le projet PHP est clair : seule la mise à jour protège complètement. Ces réglages, tirés de l'annonce officielle, réduisent le risque en attendant. Placez-les dans votre php.ini ou votre pool FPM, pas dans ini_set() ni dans un .user.ini, puis redémarrez tous vos workers PHP.

• session.upload_progress.enabled = 0 : bloque les chemins d'attaque confirmés de la seconde faille. Cette option sert rarement, PHP conseille de la laisser désactivée même après la mise à jour.
• Sur PHP 8.5 uniquement : fatal_error_backtraces = 0.
• post_max_size = 8M si votre site n'accepte pas d'envoi de fichiers, 32M sinon, avec upload_max_filesize en dessous.
• Si votre application n'a pas besoin d'envois de formulaires avec fichiers, bloquez ces requêtes (multipart) au niveau du serveur web ou du proxy.

PHP évoque aussi memory_limit = -1. Sur un serveur avec peu de RAM, prudence : une seule requête pourrait alors occuper toute la mémoire. Si vous l'appliquez, posez une limite au niveau du conteneur ou du cgroup, comme le recommande PHP.

Rien de tout ça n'est possible ce soir ? Faites comme la CNIL : coupez l'accès web le temps de patcher. Si vous avez configuré UFW comme dans notre guide du firewall, ces deux commandes ferment HTTP et HTTPS sans toucher à SSH :

sudo ufw delete allow 80/tcp
sudo ufw delete allow 443/tcp

Une fois le correctif en place, sudo ufw allow 80/tcp et sudo ufw allow 443/tcp rouvrent votre site.

Ce que fait OVHcloud, ce que vous faites

Sur un serveur Kimsufi, vous avez la main sur tout le système. OVHcloud n'intervient pas sur votre machine sans votre accord : la mise à jour vous revient.

De son côté, OVHcloud met à jour les images d'OS proposées à l'installation et prévient les clients dont les serveurs semblent exposés. Le détail est dans l'article d'OVHcloud sur ces failles, mis à jour au fil des informations.

Après l'urgence : la version de PHP compte aussi

Cette crise rappelle une règle simple : une version de PHP en fin de vie ne reçoit plus de correctif. PHP 8.2 n'a plus que deux mois de support de sécurité.

Source : versions de PHP maintenues. Profitez de la mise à jour pour viser PHP 8.4 ou 8.5. Et pour ne plus découvrir les failles dans la presse, notre guide de maintenance de serveur dédié explique comment automatiser les mises à jour de sécurité.

Questions fréquentes

Mon site WordPress est-il concerné ?

Oui, si PHP est en dessous des versions corrigées. La faille n'est pas dans WordPress mais dans PHP, qui le fait tourner. Mettre à jour WordPress ou ses extensions ne suffit pas.

Faut-il redémarrer tout le serveur ?

Non. Redémarrer PHP-FPM ou Apache suffit. Redémarrer la machine fonctionne aussi, mais coupe tous vos services plus longtemps.

Mon serveur n'utilise PHP qu'en ligne de commande, sans site web. Suis-je exposé ?

Le projet PHP cible les installations qui servent des requêtes web. Un PHP lancé seulement par des scripts locaux est moins exposé. Mettez-le quand même à jour : c'est la même commande.

Sources

• Avis de sécurité CVE-2026-109618
• Avis de sécurité CVE-2026-109619
• Versions de PHP maintenues
• W3Techs : part des sites web utilisant PHP
• OVHcloud : comment protéger vos serveurs Bare Metal et VPS