Une nouvelle faille PHP deux jours après PHP2Shell : ce que les agences WordPress doivent savoir

Deux jours après avoir corrigé la faille PHP2Shell, l'équipe PHP a publié un nouvel avertissement concernant cette même partie de PHP. Cette fois-ci, le risque est bien moindre et aucun correctif d'urgence n'est nécessaire. Voici en quoi cela diffère, ce que cela implique pour les sites WordPress et les mesures à prendre.

Ce qu'a annoncé PHP

Le 21 octobre, l'équipe PHP a publié des mises à jour d'urgence concernant PHP2Shell, deux failles critiques affectant le cœur même de PHP. Si vous n'êtes pas au courant, notre guide sur PHP2Shell explique ce qui s'est passé et les mesures à prendre.

Le 23 octobre, PHP a publié une nouvelle alerte concernant la faille CVE-2026-115560. À l'instar de l'une des vulnérabilités PHP2Shell (CVE-2026-109619), celle-ci concerne l'affichage de la progression du téléchargement de session. Cette fonctionnalité de PHP permet à un site d'afficher une barre de progression pendant le téléchargement d'un fichier.

Cette nouvelle faille peut également permettre l'exécution de code à distance, ce qui signifie qu'un pirate pourrait exécuter ses propres commandes sur le serveur. La grande différence réside dans la difficulté à la déclencher.

Pourquoi celui-ci présente moins de risques

PHP2Shell pouvait être déclenché sur un serveur standard à partir d'une seule requête, avant même que le code du site web ne soit exécuté. La nouvelle vulnérabilité nécessite une combinaison très spécifique de paramètres et de code. Selon PHP, toutes ces conditions doivent être remplies simultanément :

1. Les paramètres PHP du serveur définissent la variable `session.serialize_handler` (qui détermine la manière dont PHP enregistre les données de session) sur `php_binary` ou `php_serialize`.
2. Le code du site modifie ce paramètre pour le faire passer en PHP pendant que le site est en cours d'exécution, à l'aide de la fonction `ini_set()`.
3. Cette opération est effectuée avant le lancement de la session via la fonction session_start().
4. La progression du téléchargement de la session est toujours activée.

Si un site ne modifie jamais la manière dont les données de session sont enregistrées pendant son fonctionnement, il n'est pas concerné par ce problème. C'est pourquoi PHP traite ce problème dans le cadre de son cycle de publication habituel, plutôt que par le biais d'une mise à jour d'urgence.

À l'heure où nous écrivons ces lignes, aucune attaque exploitant cette faille n'a été signalée. Les attaques observées depuis le 21 octobre visaient les vulnérabilités PHP2Shell.

Ce que cela signifie pour WordPress

Le cœur de WordPress n'utilise pas les sessions PHP ; il ne modifie donc jamais la manière dont les données de session sont enregistrées. Pour qu'un site WordPress soit exposé à un risque, il faudrait qu'un plugin, un thème ou un bout de code personnalisé utilise les sessions PHP et modifie les paramètres de session pendant le fonctionnement du site, exactement comme décrit ci-dessus. C'est rare.

« Rare » ne signifie toutefois pas « impossible », surtout sur les sites utilisant des plugins plus anciens ou du code personnalisé que vous n’avez pas écrit vous-même. C’est pourquoi il reste judicieux d’appliquer le paramètre recommandé par PHP.

Ce que les agences WordPress devraient faire

1. Commencez par effectuer vos vérifications PHP2Shell

PHP2Shell représente le risque le plus important, et des attaques ont déjà été signalées. Assurez-vous que chaque site utilise l'une des versions corrigées : PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou une version à laquelle votre hébergeur a appliqué un correctif.

2. Désactiver l'affichage de la progression du téléchargement de la session

PHP recommande de définir `session.upload_progress.enabled=0` jusqu'à la prochaine version régulière. Le cœur de WordPress n'utilise pas cette fonctionnalité ; sa désactivation pose donc rarement des problèmes. Si vous l'avez déjà fait pour PHP2Shell, conservez ce paramètre tel quel.

La manière dont vous l'appliquez a son importance. Selon l'avis publié par PHP le 21 octobre, ce paramètre doit être défini dans le fichier php.ini, dans le pool PHP-FPM ou dans la configuration du serveur, puis chaque processus PHP doit être redémarré. Il ne doit pas être défini depuis le code du site à l'aide de la fonction ini_set() ni dans un fichier .user.ini sur PHP-FPM, car ces modifications sont appliquées trop tardivement.

Avec la plupart des formules d'hébergement, vous devrez demander à votre hébergeur de s'en charger.

3. Vérifiez votre code personnalisé

Si votre équipe développe des plugins ou des thèmes personnalisés, recherchez-y du code qui modifie la variable `session.serialize_handler`, par exemple `ini_set('session.serialize_handler', …)`. Si vous en trouvez, cela signifie que ce site présente une partie de la configuration à risque ; assurez-vous donc que la fonctionnalité de suivi de la progression des téléchargements de session y est désactivée.

4. Planifiez vos mises à niveau vers PHP 8.2

PHP 8.2 a bénéficié du correctif PHP2Shell, mais PHP a confirmé que cette version arrivera en fin de vie le 31 décembre 2026. Après cette date, elle ne bénéficiera plus de correctifs de sécurité, y compris ceux destinés à résoudre des problèmes comme celui-ci. Si certains sites de clients fonctionnent encore sous PHP 8.2, c’est le moment idéal pour planifier leur migration vers PHP 8.3 ou une version ultérieure. WordPress.org répertorie les versions de PHP qu’il recommande.

5. Restez vigilant et surveillez les signes d'une attaque

Les attaques visant PHP2Shell pourraient se poursuivre pendant un certain temps, en particulier contre les serveurs qui n'ont pas encore été mis à jour. Surveillez l'apparition de nouveaux comptes administrateurs que vous n'avez pas créés et de fichiers PHP que vous ne reconnaissez pas.

Réflexions finales

Après une semaine comme celle-ci, on a tendance à considérer chaque nouvelle alerte PHP comme une nouvelle urgence. Ce n’est pourtant pas le cas ici. PHP a clairement expliqué qui est concerné, a proposé un paramètre simple pour bloquer ce problème et a décidé de le corriger selon le calendrier habituel.

Pour la plupart des agences WordPress, cet avis sert avant tout à rappeler qu'il faut mener à bien ce que PHP2Shell a commencé : vérifier que chaque site utilise une version corrigée de PHP, s'assurer que la fonctionnalité de téléchargement par session est désactivée et planifier la migration hors de PHP 8.2 avant la fin de l'année.