La version de sécurité publiée le 21 octobre 2026 corrige les problèmes dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les branches précédentes ne bénéficient d’aucune nouvelle version officielle en amont. Des backports minimaux du code source existent pour PHP 7.4, 8.0 et 8.1. Certains fournisseurs peuvent proposer des paquets corrigés pour les anciennes branches. Ces solutions réduisent le risque à court terme, mais ne remplacent pas un runtime pris en charge.

composer why-not php 8.4
composer audit
vendor/bin/rector process --dry-run
vendor/bin/rector process

CVE-2026–109618 concerne le gestionnaire mémoire de Zend. Si un manque de mémoire interrompt l’initialisation de structures internes, le nettoyage peut ensuite interpréter une structure incomplète comme une donnée valide. Le traitement de multipart/form-data constitue une surface importante, car il peut provoquer de fortes allocations avant l’exécution du code applicatif. Une exécution de code à distance non authentifiée a été démontrée avec Apache mod_php. Avec PHP-FPM, l’échec du démarrage d’une requête provoque généralement l’arrêt du worker concerné. Une saturation mémoire après le démarrage peut toutefois créer des conditions dangereuses. L’avis officiel considère donc FPM comme exposé, sans présenter d’exploit FPM complet pour cette CVE.

PHP 8.5.12 remplace le chemin immédiat de zend_bailout() présent dans PHP 8.5.11 par une gestion différée des erreurs de mémoire. Le runtime enregistre un état en attente dans EG(delayed_oom).state et demande une prise en charge via EG(vm_interrupt) à un point plus sûr de la machine virtuelle. Une limite mémoire distincte peut terminer le processus avec _exit(137) lorsque continuer risquerait de corrompre l’état interne. Le correctif modifie donc l’architecture de gestion des erreurs, au-delà d’un simple contrôle d’entrée.

CVE-2026–109619 touche un état appartenant à une requête, mais dont la référence reste présente après la libération de la mémoire. Une requête suivante traitée par le même worker Apache ou PHP-FPM peut alors accéder à un pointeur obsolète. Les mécanismes concernés comprennent la gestion des erreurs, les backtraces d’erreurs fatales, la progression des téléversements de session et les diagnostics de configuration. La progression des téléversements peut intervenir pendant le traitement du corps de la requête, avant l’initialisation normale de la session. L’application n’a donc pas nécessairement besoin d’appeler session_start() pour exposer cette surface. L’avis décrit un chemin d’exploitation FPM validé, qui dépend d’une opération applicative adaptée après le démarrage de la requête.

Le correctif élargit le nettoyage effectué à la fin d’une requête. zend_shutdown_executor_values() efface notamment EG(last_fatal_error_backtrace), remet EG(num_errors) à zéro et affecte NULL à EG(errors) ainsi qu’à EG(exception). L’objectif est d’empêcher qu’un état appartenant à une requête reste accessible au cycle suivant après une exécution anormale.

Les deux failles ont obtenu un score CVSS v4.0 de 9.2. Ce score décrit la gravité potentielle, pas l’exposition exacte de chaque installation. La première CVE possède un chemin confirmé avant le code applicatif avec mod_php. Pour la seconde, des chemins confirmés existent avec mod_php et PHP-FPM, avec des prérequis liés à l’application et à la configuration dans le cas de FPM. Les équipes doivent vérifier la version du runtime, la SAPI, les chemins accessibles, la configuration, le cycle de vie des workers et les conditions d’exploitation connues. Une modification temporaire de configuration peut limiter certains chemins. La correction complète reste l’installation d’un runtime corrigé.

Sur une branche prise en charge, l’intervention peut rester limitée, par exemple en passant de PHP 8.4.26 à PHP 8.4.27. Une migration majeure ne devrait pas être ajoutée à la réponse urgente sans raison opérationnelle précise. Il faut vérifier le paquet ou l’image réellement utilisés, exécuter les tests automatisés et contrôler les parcours métier critiques. Dans un environnement conteneurisé, php:8.4-fpm est un tag mutable. Les caches, les miroirs internes, les délais de publication et les digests épinglés peuvent laisser une ancienne version dans l’image. Un contrôle de version pendant le build et un digest immuable rendent l’artefact vérifiable. Mettre PHP à jour sur l’hôte ne modifie pas l’interpréteur du conteneur.

Les tests doivent couvrir les téléversements, les imports, les traitements longs, les exceptions, les sessions et les intégrations. Après le déploiement, il faut surveiller les requêtes en échec, les crashes de workers, la pression mémoire, les redémarrages et les erreurs métier. Un déploiement progressif réduit le risque lorsque l’infrastructure le permet. Le rollback doit conserver un artefact connu. Revenir durablement à un runtime vulnérable n’est pas une réponse de sécurité acceptable.

La situation est plus complexe pour PHP 8.1 et les versions précédentes. PHP 8.1 est arrivé en fin de vie le 31 décembre 2025, et les branches plus anciennes avaient déjà perdu leur support amont. Un backport fourni par un éditeur et vérifiable peut réduire le risque immédiat. La cible stratégique doit rester une branche supportée. PHP 8.2 arrivera en fin de vie le 31 décembre 2026. PHP 8.4 ou PHP 8.5 constituent donc des cibles plus durables lorsque le framework et les dépendances sont compatibles.

L’évaluation doit examiner les contraintes Composer, les extensions non supportées, les fonctionnalités supprimées, les comportements dépréciés, les exigences du framework et les dépendances d’infrastructure. composer why-not php 8.4 aide à repérer les blocages de dépendances. composer audit recherche les avis de sécurité connus pour les paquets. Ces commandes ne garantissent pas la compatibilité à l’exécution. RectorPHP applique des transformations AST pour de nombreuses évolutions du langage. Une configuration peut utiliser RectorConfig::configure(), withPaths(), withPhpSets() ou des niveaux progressifs avec withPhpLevel(). Les dry-runs et les petits lots facilitent la revue. Rector ne met pas à jour l’interpréteur, ne résout pas tous les conflits de dépendances et ne remplace pas les tests de non-régression. Les outils de migration assistés par IA ont les mêmes limites et doivent être vérifiés.

Une mise à niveau importante doit être menée comme un programme d’ingénierie. Les transformations du code, les dépendances et les tests doivent être séparés du basculement en production. La préproduction doit reproduire les extensions pertinentes, les réglages du runtime, le comportement de l’infrastructure et les données représentatives. Les chemins d’erreur et la reprise doivent être testés. Le déploiement peut ensuite progresser par étapes, avec un suivi technique et métier.

L’analyse rappelle que la PHP Foundation a reconnu l’existence de premiers signaux concernant le problème de mémoire dès 2024. Aucun chemin d’exploitation concret n’était alors établi. Elle a attribué une partie du retard à des limites organisationnelles et de ressources, puis décrit des changements dans ses processus de sécurité. Les correctifs et la documentation publiques constituent des avancées, mais ils ne suppriment pas la responsabilité de maintenance des utilisateurs. Le risque métier ne se limite pas à une compromission. Une organisation qui ne peut pas appliquer un correctif sans lancer une modernisation d’urgence reste également exposée.