Logo Laravel France - Retour à l'accueil

PHP : deux failles critiques corrigées le 21 octobre, comment s’y préparer

Publié le 21 octobre 2026 par Mathieu De Gracia
Couverture de l'article PHP : deux failles critiques corrigées le 21 octobre, comment s’y préparer

L’équipe de sécurité de PHP a annoncé le mardi 20 octobre 2026 la publication d’une mise à jour de sécurité ce mercredi 21 octobre à 14h UTC, soit 16h heure de Paris.

Cette dernière corrigera deux vulnérabilités critiques toutes deux notées 9.2 selon la classification CVSS 4.

Le détail des failles, les versions touchées, ainsi que les versions corrigées ne seront publiés qu'avec le correctif.

PHP se réserve également le droit d'avancer la publication si les détails venaient à fuir davantage ou si une exploitation était constatée.

Voici ce que l'on sait à cette heure, et en attendant les versions corrigées, plusieurs vérifications peuvent déjà être faites sur vos serveurs.

Mise à jour · 21 octobre, 15h20
À titre d'information, ce dépôt GitHub rassemble plusieurs éléments intéressants : une tentative d'explication du mécanisme supposé, un use-after-free dans la gestion de session.upload_progress, une liste d'actions de prévention et des pistes pour surveiller les processus PHP suspects. Son contenu n'est pas validé par l'équipe de PHP, et nous vous déconseillons d'exécuter les scripts qu'il propose sur vos serveurs.
Mise à jour · 21 octobre, 14h25
Laravel a détaillé sur X les mesures prévues pour ses plateformes d'hébergement.
Laravel Cloud Correction automatique dès la sortie du correctif, sans action de votre part.
Forge Mise à jour manuelle de PHP depuis le tableau de bord du serveur. Laravel recommande d'éteindre les serveurs qui ne pourront pas être mis à jour.
Vapor Redéploiement automatique des applications sous PHP 8. Aucun correctif n'est prévu pour PHP 7 : migrez immédiatement vers PHP 8.

Ce que l'on sait

Les deux failles circulent sous les identifiants CVE-2026-109618 et CVE-2026-109619.

D'après les informations qui ont fuité, ces failles permettraient une exécution de code à distance sans authentification (une faille RCE).

Ces mêmes fuites affirment que toutes les versions depuis PHP 5 seraient touchées, ce que PHP n'a pas encore confirmé.

Ce matin, Patchstack, une société spécialisée dans la sécurité de l’écosystème PHP qui maintient une base de données de vulnérabilités et travaille avec de nombreux hébergeurs a fait état de plusieurs incidents d’exploitation.

Cette information n’a été ni détaillée ni confirmée par l’équipe de PHP et doit être prise avec prudence, elle suffit cependant à justifier de ne pas attendre 16h pour commencer à s’intéresser au problème.

Les versions qui seront mises à jour

PHP ne publie des correctifs de sécurité que pour ses versions encore maintenues : 8.2, 8.3, 8.4 et 8.5.

Les versions antérieures, de PHP 8.1 aux plus anciennes, ne devraient pas recevoir de correctif. Si l'une de vos applications tourne encore sur l'une d'elles, sa migration vers une branche maintenue devient urgente.

Si vos applications tournent dans des conteneurs le correctif ne s'appliquera pas tout seul : il faudra reconstruire vos images à partir d'une image de base à jour, puis redéployer.

💡

Laravel a part ailleurs prévenu les clients de Forge et de Cloud qu'un redéploiement pourrait être nécessaire pour profiter des images mises à jour.

La piste session.upload_progress

Depuis la nuit du 20 octobre, une mesure temporaire a commencé à circuler sur les réseaux consistant à désactiver la directive session.upload_progress.enabled de l'extension session activée par défaut.

Cette piste ne vient pas de PHP mais des analyses publiées à partir des fuites qui situent au moins l'une des deux failles dans la gestion de la progression des uploads.

L'exploit n'est à ce jour pas validé officiellement et l'auteur de l'analyse la plus détaillée reconnaît lui même que cette désactivation ne fermerait qu'un seul des deux chemins d'attaque suspectés.

Gina Peter Banyard, développeuse du cœur de PHP, rappelle de son côté que la seule protection reste la mise à jour.

Cette désactivation réduit donc le risque sans le supprimer, mais il y a de fortes chances que cela puisse être fait sur votre application Laravel sans conséquence.

Vérifier si la directive est active

Le vecteur d'attaque exploitant la RCE est une requête HTTP, il faut donc regarder la configuration de PHP-FPM (ou du module Apache) de votre application.

La configuration CLI n’étant pas exposée sur le web, elle ne devrait pas être sujette à l’attaque, vous pouvez néanmoins vérifier les deux :

1# Configuration CLI
2php -i | grep upload_progress
3 
4# Configuration FPM (Debian / Ubuntu) : php.ini, conf.d et pools
5grep -rn upload_progress /etc/php/*/fpm/
6 
7# Valeur effectivement chargée par FPM (adaptez la version)
8php-fpm8.4 -i | grep upload_progress

Attention à la lecture du résultat des commandes : dans un php.ini, la ligne ;session.upload_progress.enabled = On est commentée, vous pouvez le voir à la présence du point virgule en début de ligne.

Une ligne commentée ou absente signifie que la valeur par défaut s'applique ... et dans notre cas, cette valeur est malheureusement On.

Vérifier que votre code ne l'utilise pas

Avant de désactiver la directive, nous vous conseillons fortement de vérifier que votre application ne l'utilise pas :

1grep -rni "upload_progress\|PHP_SESSION_UPLOAD_PROGRESS" app/ config/ resources/ vendor/

Laravel gère ses sessions sans s'appuyer sur les sessions natives de PHP : sauf usage explicite dans votre code, désactiver cette directive ne devrait avoir aucun impact fonctionnel.

Désactiver la directive

Au démarrage, PHP lit son fichier php.ini principal, puis tous les fichiers .ini présents dans le dossier conf.d, par ordre alphabétique. Lorsqu’une même directive est définie plusieurs fois, c’est la dernière valeur lue qui l’emporte.

Plutôt que de modifier le php.ini de votre application, nous vous conseillons de créer un fichier dédié dans le dossier conf.d de FPM, plus facile à retirer une fois la mise à jour appliquée :

1; /etc/php/8.4/fpm/conf.d/99-upload-progress.ini
2session.upload_progress.enabled = Off

Rechargez ensuite PHP-FPM pour que la modification soit prise en compte, puis relancez les commandes de vérification :

1sudo systemctl reload php8.4-fpm

En attendant 16h

La seule protection reconnue par PHP reste la mise à jour : faites dès maintenant l'inventaire de ce qui embarque PHP (serveurs, images Docker, environnements Vapor, CI) et prévoyez une fenêtre de maintenance dès que possible.

Les nouvelles versions seront annoncées sur php.net et le détail des deux failles sera publié dans les avis de sécurité du dépôt php-src.

Mathieu De Gracia avatar

Écrit par

Mathieu De Gracia

Lead & Software Architect • nublar.dev

Aucun commentaire

Tu veux commenter ? Crée un compte ou connecte-toi.

A lire

Autres articles de la même catégorie