Failles critiques PHP (CVE-2026-109618 et CVE-2026-109619) : protégez vos serveurs cloud dès aujourd'hui

Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques qui permettent de prendre le contrôle d'un serveur à distance, sans identifiant. Si PHP tourne sur l'un de vos VPS CloudStore, serveurs dédiés ou machines virtuelles Cloud public, voici comment vérifier votre exposition et vous protéger, étape par étape.

L'essentiel en un coup d'œil



Ce qui se passe, en clair

Les deux failles touchent le cœur de PHP, pas un CMS ou un cadriciel en particulier. Elles portent sur la façon dont PHP gère sa mémoire d'une requête à l'autre.

• CVE-2026-109618 : une requête volontairement surdimensionnée, comme un envoi de formulaire, épuise la mémoire de PHP et laisse des données dans un état incohérent.

• CVE-2026-109619 : des informations d'une requête précédente ne sont pas effacées et sont réutilisées par la suivante.

Dans les deux cas, un attaquant peut exécuter son propre code avec les droits de votre serveur web. Une simple connexion à votre site suffit. Les chercheurs ont démontré l'attaque sur les deux configurations les plus répandues : Apache avec mod_php, et PHP-FPM.

PHP a annoncé ces failles le 20 octobre 2026 et publié les correctifs le 21 octobre à 14h00 UTC (15h00 à Douala).

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

Vous êtes concerné si PHP sert un site ou une application sur un VPS CloudStore, un serveur dédié ou une machine virtuelle de votre cloud privé ST Digital. Connectez-vous en SSH et tapez :

php -v



Attention : la version affichée en ligne de commande peut différer de celle utilisée par votre site, notamment si plusieurs versions de PHP cohabitent. En cas de doute, vérifiez aussi la configuration de votre serveur web ou de votre panneau d'administration (Plesk, cPanel…).

Mettre à jour pas à pas

Comptez environ quinze minutes par serveur. Traitez en priorité les serveurs exposés sur Internet.

1. 1

   Sauvegardez. Sur un VPS, prenez un instantané depuis votre espace client. Sur un serveur dédié, sauvegardez au minimum vos fichiers de configuration et vos données.

2. 2

   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 : récupérez la version corrigée sur php.net

   • Conteneurs : reconstruisez vos images sur une image PHP à jour, puis redéployez

3. 3

   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, x = votre version) ou sudo systemctl restart php-fpm

   • Apache : sudo systemctl restart apache2 ou sudo systemctl restart httpd

4. 4

   Vérifiez avec php -v que la version corrigée est active et que votre site répond normalement.

Si votre distribution ne propose pas encore la version corrigée, revérifiez dans quelques heures : certains dépôts publient avec un léger décalage. En attendant, appliquez les mesures ci-dessous.

Vous ne pouvez pas mettre à jour tout de suite ?

Seule la mise à jour, ou la migration vers une version maintenue, protège complètement votre serveur.

En attendant, voici une suggestion de  deux mesures provisoires.

1. Désactiver le suivi de progression des envois de fichiers. Dans votre php.ini :

session.upload_progress.enabled = Off

Si vous utilisez PHP-FPM, forcez aussi ce réglage dans la configuration du pool :

php_admin_flag[session.upload_progress.enabled] = off

Redémarrez ensuite PHP-FPM ou Apache. Cette fonction est rarement utilisée. Attention : cette mesure ne réduit la surface d'attaque que pour l'une des deux failles.

2. Bloquer les requêtes multipart. Si votre application n'envoie pas de fichiers par formulaire, bloquez toute requête HTTP dont l'en-tête Content-Type vaut multipart. Si ce blocage est impossible, placez ce type de requêtes sous supervision renforcée. Ces deux actions peuvent être réalisées sur un pare-feu applicatif web ; nos équipes peuvent vous accompagner pour les mettre en place.

Encore en PHP 8.1 ou antérieur ? Les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x ne sont plus maintenues et ne recevront aucun correctif. Le CERT-FR recommande de les isoler, puis de migrer vers une version maintenue et à jour. Appliquez les mesures provisoires dès aujourd'hui et planifiez la migration vers PHP 8.4 ou 8.5.

ST Digital à vos côtés

Sur un VPS ou un serveur dédié, vous gardez la main sur votre système : nous n'intervenons jamais sur vos instances sans votre accord. C'est pourquoi nous vous donnons toutes les clés pour agir vite.

De notre côté, nous mettons à jour les images système proposées à l'installation et nous alertons les clients dont les instances semblent exposées. Cet article sera complété si de nouvelles informations sont publiées.

Un doute sur votre configuration ? Nos équipes support répondent depuis nos datacenters africains, au plus près de vos serveurs . Elles peuvent aussi prendre en charge la mise à jour ou la migration de vos versions PHP.

Pour aller plus loin

• Communication PHP du 20 octobre 2026 et bulletins de sécurité PHP du 21 octobre 2026

• Téléchargement des versions corrigées

• Avis de sécurité GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp

• Fiches CVE-2026-109618 et CVE-2026-109619

• Versions de PHP maintenues