CVE-2026-109619 : exécution de code à distance dans PHP par état global obsolète

Ce qui se passe mal, au niveau des informations de l’éditeur

Selon la PHP Foundation, une erreur fatale au mauvais endroit peut laisser un état interne pointant vers la mémoire d’une requête précédente. Une requête ultérieure sur le même worker peut alors utiliser cette mémoire libérée. La Foundation indique que le use-after-free et un plantage du worker sont confirmés, et que la personne ayant signalé la faille a démontré une exécution de code à distance contre une application réelle sur Apache avec mod_php. La description du NCSC britannique correspond à la phrase de php.net.

L’avis de l’Université de Toronto cite la progression d’envoi de session, activée par défaut, comme un chemin confirmé. Selon la recommandation provisoire de PHP, session.upload_progress.enabled=0 bloque les chemins de session confirmés, mais pas les autres variantes. La désactiver est une atténuation, pas une correction. Nous ne décrivons pas comment une requête atteint la fenêtre de l’erreur fatale.

mod_php et PHP-FPM

Expel indique, citant PHP, que PHP a démontré cette CVE contre PHP-FPM lorsque le code applicatif lui-même peut être poussé vers une erreur fatale. L’exposition de FPM dépend de l’application et de la configuration ; PHP considère néanmoins les installations FPM comme exposées. mod_php reste la configuration que le projet PHP classe au risque le plus élevé. Le Centre canadien pour la cybersécurité le répète : un exploit démontré sur mod_php permet à une requête non authentifiée de déclencher la faille avant le code applicatif.

Correction

Il n’existe pas de correctif séparé. Installez les versions du 21 octobre et redémarrez chaque worker. Pour PHP 8.5, le projet cite en plus fatal_error_backtraces=0 comme mesure provisoire, qui ne bloque que le chemin confirmé via les backtraces d’erreurs fatales. Masquer les diagnostics avec error_reporting, display_errors ou l’opérateur @ n’aide pas, selon php.net. Google Cloud cite pour la paire 5.4 à 8.5.11 comme vulnérables ; la correspondance avec les branches réellement corrigées figure sur la page des versions.

Pourquoi la faille exige deux requêtes sur le même worker

L’avis complet de PHP décrit la faille comme une paire. D’abord, une opération laisse un pointeur vers la mémoire d’une requête dans un état global du worker (erreurs, session, objets ou extensions) et est interrompue avant de l’effacer, par exemple par une erreur fatale, un require raté, un dépassement de temps ou un manque de mémoire. Ensuite le worker libère cette mémoire, prend la requête suivante, et un traitement exécuté avant le démarrage normal utilise l’ancien pointeur. Les deux moitiés doivent tomber sur le même worker ; plus de workers et le recyclage ralentissent une attaque sans l’empêcher.

D’où viennent les réglages précoces, selon le SAPI

Un déclencheur confirmé est un avertissement ou une dépréciation émis pendant que PHP applique des réglages par requête avant le démarrage, même si le message n’est jamais affiché ni journalisé. Masquer les erreurs ne sert donc à rien. L’existence de ce chemin dépend de la façon dont les réglages arrivent à PHP :

• Apache mod_php : .htaccess et php_value / php_flag / php_admin_* sont appliqués tôt ; une directive erronée ou obsolète à cet endroit compte. Le php.ini normal est lu une fois au démarrage et n’en fait pas partie.
• PHP-FPM : exposé de cette façon seulement si nginx, mod_proxy_fcgi ou un autre frontal transmet un PHP_VALUE ou PHP_ADMIN_VALUE qui déclenche un avertissement. Les réglages de pool et .user.ini non, car ils s’appliquent au lancement du worker ou après le démarrage.
• LiteSpeed LSAPI : ses réglages d’environnement précoces en font un candidat conditionnel. FrankenPHP : pas de chemin précoce équivalent dans sa configuration par défaut, ce qui selon PHP ne le rend pas immunisé.

Mesures supplémentaires de l’avis si vous ne pouvez pas encore corriger

• Retirer les directives obsolètes ou invalides de tout ce qui s’applique par requête, et préférer php.ini, la config de pool ou du serveur.
• Corriger les erreurs fatales et dépassements de temps accessibles aux visiteurs, y compris dans l’upload, l’import, les pages d’erreur, les destructeurs, la sérialisation et les plugins.
• Si le débit le permet, pm.max_requests=1 fait servir une seule requête par worker FPM. PHP le présente comme optionnel ; c’est coûteux.
• Désactiver session.upload_progress.enabled là où il ne sert pas, même après correction : PHP le décrit comme peu utilisé et peu testé.
• Pour un audit limité dans le temps, tout journaliser (log_errors=On, un error_log fonctionnel, error_reporting=E_ALL) et chercher les avertissements répétés avant les scripts, les erreurs au nettoyage, les erreurs fatales et les dépassements de temps. Un journal propre ne prouve rien.