Failles critiques dans PHP : deux RCE corrigées dans 8.5.12, 8.4.27, 8.3.36 et 8.2.35

PHP a publié le 21 octobre 2026 quatre versions correctives : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles jugées critiques (CVSS 4.0 : 9.2) par l'équipe PHP, qui titre son annonce « Critical remote code execution vulnerabilities, update now ». Les deux peuvent mener à une exécution de code à distance sans authentification, et elles sont liées : il faut appliquer la mise à jour pour les deux.

1. RCE via une corruption mémoire en cas de manque de mémoire (CVE-2026-109618)#

• Avis : GHSA-w8hw-w9fx-j79w, « RCE via OOM corruption »
• Gravité : critique, CVSS 4.0 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H)

Le problème. Quand une requête dépasse memory_limit, PHP quitte le contexte en cours avec longjmp(). Si ça arrive au moment où de la mémoire de la requête est accessible mais pas encore complètement initialisée, elle reste dans un état invalide, que la phase d'arrêt de la requête va ensuite lire.

Comment l'atteindre. L'avis décrit plusieurs moyens de provoquer ce manque de mémoire en restant dans les limites apparentes de PHP, surtout en jouant sur le parsing des requêtes multipart : un corps sans longueur exploitable, une partie avec un nombre illimité d'en-têtes, ou des champs fichier vides (qui ne comptent pas dans max_file_uploads) avec des noms imbriqués.

Impact.

• Apache mod_php : RCE complète démontrée par HTTP avec les limites par défaut, avant même l'exécution du code de l'application.
• PHP-FPM : vulnérable d'après l'analyse du code, mais aucun exploit complet n'a été démontré.
• FrankenPHP : probablement vulnérable, comme mod_php. LSAPI : probablement exploitable selon l'application, mais pas validé.

Corrigé dans 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (toutes les versions antérieures de ces branches sont touchées). Le correctif supprime le longjmp() en cas de manque de mémoire : PHP arrête désormais la requête proprement au prochain point sûr, et la coupe immédiatement si elle dépasse un second seuil plus élevé.

2. RCE via un état global périmé entre deux requêtes (CVE-2026-109619)#

• Avis : GHSA-6wmf-4rv5-p3rp, « RCE via stale global state »
• Gravité : critique, CVSS 4.0 9.2 (même vecteur), use-after-free (CWE-416)

Le problème. Un worker PHP garde des états globaux (erreurs, session, objets, extensions) qui peuvent pointer vers la mémoire d'une requête. Si une erreur fatale (manque de mémoire, erreur de parsing, require qui échoue, Maximum execution time exceeded…) interrompt une opération avant qu'elle remette cet état à zéro, la mémoire est libérée alors que le worker y fait encore référence. La requête suivante traitée par le même worker peut alors lire cette mémoire libérée avant que PHP ait fini de l'initialiser.

Les deux cas confirmés.

• Backtraces d'erreurs fatales (PHP 8.5) : avec fatal_error_backtraces activé, l'état n'est jamais remis à zéro. Un simple avertissement de configuration (.htaccess, php_value, ou PHP_VALUE envoyé à FPM par nginx) suffit ensuite à le lire. C'est la base de la RCE démontrée sur mod_php. Masquer les erreurs (@, display_errors=Off, error_reporting) ne protège pas.
• Suivi de progression des uploads de session (session.upload_progress, actif par défaut, même sans session_start()) : RCE validée sur mod_php et FPM (pool dynamique normal, à condition que l'application ait une opération adaptée).

Impact. Use-after-free sans authentification, fuite de mémoire et exécution de code avec les droits du worker web. Le nombre de workers et leur recyclage réduisent les chances de réussite à chaque requête, mais n'empêchent pas l'attaque.

Corrigé dans 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

Que faire ?#

1. Vérifier ta version.

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'

Attention, PHP-FPM et le module Apache peuvent tourner avec une autre version que la CLI : vérifie avec phpinfo() ou php-fpm -v.

2. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Selon l'avis, c'est la seule protection complète.

# Debian/Ubuntu (dépôt de ta distribution ou de Sury)
sudo apt update && sudo apt install --only-upgrade 'php8.*'
# RHEL/Fedora (Remi)
sudo dnf upgrade 'php*'
# Docker : reconstruire depuis l'image à jour
docker pull php:8.4-fpm   # puis rebuild/redeploy

Ensuite, redémarre tous les workers (systemctl restart php8.4-fpm, apache2, FrankenPHP…). Sur les distributions qui rétroportent les correctifs, regarde le bulletin de sécurité de ta distribution plutôt que le numéro de version. La branche 8.1 n'apparaît pas dans les avis.

3. Si tu ne peux pas mettre à jour tout de suite (mesures partielles, à appliquer au niveau admin puis redémarrer les workers) :

• session.upload_progress.enabled=0, à garder même après la mise à jour si tu ne t'en sers pas ;
• en PHP 8.5, fatal_error_backtraces=0 ;
• garder un post_max_size bas, limiter la taille des corps de requête côté reverse proxy, réduire max_input_nesting_level et max_input_vars, et bloquer le multipart si l'application ne s'en sert pas ;
• supprimer les directives INI obsolètes ou invalides passées par requête (.htaccess, php_value, PHP_VALUE) ;
• pm.max_requests=1 en FPM si les performances le permettent ;
• memory_limit=-1 est cité comme principale mesure contre la première faille, mais il ne la corrige pas complètement et peut exposer à un déni de service. Ne pas utiliser RLIMIT_AS/RLIMIT_DATA, qui déclenchent justement le chemin vulnérable.

Sources#

• Annonce PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, php.net, 21/10/2026
• ChangeLog PHP 8, php.net, 21/10/2026
• GHSA-w8hw-w9fx-j79w / CVE-2026-109618, php-src, publié le 21/10/2026
• GHSA-6wmf-4rv5-p3rp / CVE-2026-109619, php-src, publié le 21/10/2026

Failles signalées par lcfr-hax, sagitzadik-wiz, tomash-areion et amyb-oai, et corrigées par arnaud-lb, iluuu1994, bukka et ndossche (pseudos GitHub d'après les avis).

Crédits images#

• Miniature : logo PHP, Colin Viebrock, domaine public, via Wikimedia Commons.