Nouvelle faille PHP CVE-2026-115560 : la solution à appliquer

Une nouvelle faille PHP vient d’être signalée, deux jours seulement après les correctifs d’urgence contre PHP2Shell. Elle porte le numéro CVE-2026-115560 et ouvre une autre voie pour exécuter du code à distance sur un serveur web. Bonne nouvelle : elle est bien moins dangereuse que les précédentes, et la parade tient en une seule ligne de configuration que beaucoup d’administrateurs ont déjà appliquée.

On fait le point : qui est vraiment concerné, pourquoi PHP ne publie pas de correctif en urgence et comment se protéger tout de suite.

Une nouvelle faille PHP indépendante de PHP2Shell

Le 21 octobre, PHP corrigeait en urgence deux failles critiques baptisées PHP2Shell, les CVE-2026-109618 et CVE-2026-109619, dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le 23 octobre, l’équipe a publié un avis signalant un troisième problème, la CVE-2026-115560. Il est distinct des deux premiers et n’est pas corrigé par ces versions. Un serveur déjà mis à jour reste donc exposé à cette nouvelle voie, même s’il est protégé contre PHP2Shell.

Comme pour PHP2Shell, le problème passe par la gestion des sessions et la fonction de suivi de progression des envois de fichiers. Mais cette fois, PHP juge le risque faible et aucune attaque n’a été repérée. Les attaques en cours continuent de viser les deux failles PHP2Shell.

Qui est concerné par la CVE-2026-115560

La faille ne touche qu’une configuration très particulière. Pour être vulnérable, une application doit réunir toutes ces conditions en même temps. Elle règle l’option session.serialize_handler sur php_binary ou php_serialize dans sa configuration. Elle change ensuite cette option pour php en cours d’exécution, avec un appel à ini_set(). Et elle fait ce changement avant d’ouvrir la session avec session_start(). Le suivi de progression des envois doit aussi rester actif.

Autant dire que ce cas est rare. PHP le qualifie lui-même de peu probable. Côté sécurité WordPress, la bonne nouvelle est qu’une installation standard ne fait pas ce genre de manipulation et n’est pas exposée par cette voie. C’est la raison pour laquelle l’équipe de PHP ne publie pas de correctif d’urgence et traitera le problème dans sa prochaine mise à jour de maintenance habituelle.

La solution en une ligne

La parade est la même que celle déjà recommandée le 21 octobre contre l’une des failles PHP2Shell : désactiver le suivi de progression des envois de fichiers. Si vous l’aviez appliquée et laissée en place, vous êtes déjà protégé et vous n’avez rien à faire de plus.

Avant tout, repérez votre version de PHP avec php -v, ou listez les versions installées sur votre serveur :

ls /etc/php/

Dans les commandes qui suivent, remplacez partout 8.2 par votre numéro de version. Si plusieurs versions sont installées et actives, appliquez le réglage à chacune. Créez ensuite un petit fichier de configuration :

echo "session.upload_progress.enabled = 0" | tee /etc/php/8.2/fpm/conf.d/99-disable-upload-progress.ini systemctl reload php8.2-fpm

Vérifiez ensuite que le réglage est bien actif :

php-fpm8.2 -i | grep session.upload_progress.enabled

La commande doit afficher Off. Ce réglage ne casse rien sur un site WordPress classique, puisque le suivi de progression n’est quasiment jamais utilisé, et vous pouvez le laisser en place définitivement.

Ce que PHP n’a pas encore précisé

L’avis du 23 octobre reste court. PHP n’a pas indiqué les versions touchées, la version qui apportera le correctif ni une note de gravité. L’équipe n’a pas non plus dit si cette nouvelle faille partage la même cause que la CVE-2026-109619. Un avis complet accompagnera la prochaine mise à jour de maintenance. En attendant, le réglage ci-dessus suffit à fermer la porte.

Si vous n’avez pas encore appliqué les correctifs PHP2Shell du 21 octobre, c’est la priorité absolue : eux sont activement exploités. Vérifiez votre version avec php -v et installez PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre branche.

Plus de détails dans l’avis publié sur php.net.