Failles critiques de PHP : quelles versions installer ?

Si vous exploitez un site PHP, vérifiez que le moteur qui traite ses requêtes web a reçu les correctifs de sécurité d’octobre. Le 21 octobre, le projet PHP a annoncé des mises à jour pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre l’exécution de code à distance sans authentification. Toutes deux ont un score CVSS v4.0 de 9,2. L’avis de sécurité de PHP  (en anglais) recommande une mise à jour immédiate.

Les failles se trouvent dans PHP lui-même. Une validation, une authentification ou un échappement HTML correctement réalisés dans l’application ne corrigent pas le moteur sous-jacent.

Que s’est-il passé ?

CVE-2026-109618  (avis en anglais) concerne la gestion du manque de mémoire. Si une allocation échoue alors que les données d’une requête ne sont que partiellement initialisées, le nettoyage peut agir sur une mémoire invalide. PHP décrit une exploitation sans authentification démontrée avec Apache mod_php, notamment par un chemin exécuté avant le démarrage du code applicatif.

CVE-2026-109619  (avis en anglais) concerne un état interne périmé. Un processus peut conserver des références à une mémoire libérée après une requête, puis les utiliser au démarrage d’une autre. Les conditions exactes dépendent de l’état concerné, de la configuration et du chemin suivi par la requête.

L’avis de PHP cite PHP-FPM, Apache mod_php, PHP-CGI, FrankenPHP et LiteSpeed parmi les installations à examiner. Il désigne mod_php comme le déploiement présentant le risque le plus élevé. Les conditions d’exposition varient selon le mode d’exécution ; utiliser FPM ne justifie pas de repousser la mise à jour.

Quelles versions contiennent les correctifs ?

Voici les premières versions corrigées des branches maintenues, indiquées dans les avis de PHP :

Installez un paquet bénéficiant d’un suivi de sécurité qui contient ces correctifs, ou une version corrigée ultérieure. Les distributions peuvent rétroporter les correctifs tout en conservant un ancien numéro de version amont. Consultez donc l’avis de sécurité de votre système d’exploitation, dépôt de paquets ou hébergeur.

PHP 8.1 et les versions antérieures ne reçoivent plus de versions amont régulières. L’équipe PHP a néanmoins ajouté à son avis des liens vers des rétroportages minimaux du code source pour les versions 7.4, 8.0 et 8.1. Ces correctifs d’urgence ne rétablissent pas leur maintenance : utilisez une version corrigée prise en charge par un fournisseur ou prévoyez une migration vers une branche maintenue. Le suivi de sécurité amont de PHP 8.2 prend fin le 31 décembre 2026, selon le calendrier des versions prises en charge  (en anglais).

Comment l’incident s’est déroulé

Le récit de la PHP Foundation  (en anglais) apporte un contexte plus précis que la seule date d’une publication d’urgence :

• 2024 : des travaux consécutifs à un audit externe ont révélé les premiers signes du problème de manque de mémoire. La Foundation décrit des contraintes de compatibilité, des ressources limitées et un processus de décision bloqué qui ont retardé le correctif.
• Août 2026 : des signalements démontrant l’exécution de code à distance ont clarifié l’impact et fait de la correction la priorité principale.
• 20 octobre : l’équipe de sécurité PHP a annoncé à l’avance la publication critique.
• 21 octobre : PHP a annoncé les versions corrigées et publié les avis de sécurité.

Les annonces et le récit de la Foundation datent la publication du 21 octobre ; le journal des modifications de PHP 8.5.12  (en anglais) indique actuellement le 22 octobre. Cette chronologie suit les annonces.

Que vérifier sur vos serveurs ?

1. Identifiez le moteur qui sert chaque site. php -v identifie le PHP en ligne de commande, qui peut différer de celui d’un pool FPM, d’un module Apache, d’un conteneur ou du choix effectué dans le panneau d’hébergement. Incluez toutes les instances et images déployées.
2. Mettez à jour et redémarrez ou remplacez les processus. Confirmez que le moteur web en cours d’exécution utilise le paquet corrigé. Installer un paquet sans arrêter les anciens processus ne suffit pas.
3. Réduisez l’exposition en attendant la mise à jour. Restreignez les accès lorsque c’est possible et suivez l’avis de PHP ainsi que les recommandations de votre fournisseur. Les mesures de configuration temporaires de PHP visent certains chemins d’attaque ; elles ne remplacent pas complètement les correctifs.
4. Examinez les signes de compromission. Analysez les fichiers, processus, requêtes et défaillances inhabituels avec votre équipe de sécurité ou votre hébergeur. Une mise à jour réussie ne prouve pas l’absence de compromission antérieure.
5. Testez ensuite le comportement de l’application. Vérifiez les connexions, sessions, formulaires, envois de fichiers, tâches planifiées et points d’accès API sur le moteur mis à jour.

Pour répéter les vérifications fonctionnelles, utilisez le générateur de commandes cURL. Le guide des commandes cURL présente les options de requête ; l’article JSON, données de formulaire ou multipart aide à reproduire le format réellement reçu par votre application. Le guide d’inspection des requêtes réseau du navigateur peut aider à examiner un formulaire ou une connexion dont le comportement a changé après le déploiement.

Il s’agit de vérifications fonctionnelles. Les réponses HTTP ne prouvent pas, à elles seules, qu’un interpréteur PHP est corrigé ou qu’un serveur n’a pas été compromis.

Situation au 23 octobre 2026

Les versions corrigées sont disponibles et les avis décrivent des démonstrations d’exploitation. Ces éléments établissent l’urgence, pas un nombre de sites compromis. Cet article n’estime pas l’ampleur de l’exploitation et ne détermine pas l’état d’un serveur particulier.

Pour un administrateur, l’étape utile est de vérifier le moteur corrigé sur chaque instance qui traite des requêtes web, puis d’effectuer les vérifications applicatives et les investigations adaptées à cet environnement.