Faille critique PHP : 2 failles RCE corrigées, le guide complet et gratuit

Cette faille critique PHP n’est pas une alerte de plus à survoler. Deux vulnérabilités, publiées ensemble par le projet php-src, touchent toutes les branches maintenues de PHP (8.2, 8.3, 8.4 et 8.5) et peuvent mener à une exécution de code à distance (RCE) avec les droits du serveur web, sans compte ni interaction de l’utilisateur. Si tu héberges un site WordPress, Laravel ou n’importe quelle application PHP, tu es potentiellement concerné.

Dans cet article de veille, on reprend l’histoire dans l’ordre : la découverte, ce que fait concrètement chaque faille (sans entrer dans l’exploitation), puis la correction et ce que tu dois faire aujourd’hui.

Chronologie de la faille critique PHP

Le schéma est classique et c’est une bonne nouvelle : la faille a été divulguée de manière responsable. Le jour où le grand public en a entendu parler, la mise à jour existait déjà. Le risque principal concerne donc les serveurs qui ne seront pas mis à jour dans les jours qui viennent.

En bref : la faille critique PHP en chiffres

	CVE-2026-109618	CVE-2026-109619
Avis GitHub	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
Titre officiel	RCE via OOM corruption	RCE via stale global state
Gravité	Critique · CVSS v4 9.2	Critique · CVSS v4 9.2
Type	Use-after-free (CWE-416)	Use-after-free (CWE-416)
Authentification requise	Non	Non
Versions touchées	< 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12	idem
Versions corrigées	8.2.35 · 8.3.36 · 8.4.27 · 8.5.12	idem
Date de publication	21 octobre 2026	21 octobre 2026

Le score CVSS 9.2 est très élevé, mais le vecteur indique une complexité d’attaque élevée (AC:H) et des conditions préalables (AT:P) : l’attaque n’est pas triviale et sa fiabilité dépend du serveur. Ce n’est pas une raison pour attendre, car l’équipe PHP indique avoir validé une exécution de code à distance réelle.

Faille n°1 : la corruption mémoire lors d’un manque de mémoire (CVE-2026-109618)

Quand une requête dépasse la mémoire autorisée (memory_limit), PHP interrompt brutalement le traitement grâce à un mécanisme bas niveau appelé longjmp(). Le problème : à certains moments, une zone mémoire de la requête est déjà accessible alors qu’elle n’est pas encore complètement initialisée. Si le manque de mémoire tombe pile à cet instant, PHP laisse cette zone dans un état incohérent, puis la relit pendant le nettoyage de fin de requête.

Pour provoquer ce manque de mémoire, il suffit de requêtes multipart (les formulaires d’envoi de fichiers) bien choisies : en-têtes très nombreux dans une partie, champs fichiers vides qui ne comptent pas dans max_file_uploads, noms de champs imbriqués… Autant d’entrées qui consomment beaucoup plus de mémoire dans PHP qu’elles n’en occupent sur le réseau.

• Apache + mod_php : le plus exposé. Le code vulnérable s’exécute avant même ton application. L’équipe PHP a validé une RCE dans cette configuration, avec les limites par défaut.
• PHP-FPM (Nginx, la plupart des hébergeurs modernes) : exposition réduite, aucune exploitation complète démontrée, mais le même défaut reste atteignable.
• FrankenPHP et LiteSpeed (LSAPI) : probablement concernés d’après l’analyse du code, sans validation à ce jour.

Faille n°2 : l’état global « périmé » entre deux requêtes (CVE-2026-109619)

Un processus PHP traite plusieurs requêtes à la suite. Entre deux requêtes, il doit remettre à zéro son état global : erreurs en cours, session, objets, extensions. Or une erreur fatale (dépassement de mémoire, erreur de compilation, require qui échoue, délai d’exécution dépassé) ou un avertissement émis pendant l’arrêt peut empêcher cette remise à zéro.

La requête suivante, traitée par le même processus, peut alors lire de la mémoire qui appartenait à la requête précédente et qui a déjà été libérée : c’est un use-after-free. L’avis cite deux points de lecture confirmés, qui s’exécutent avant l’initialisation normale de la requête : certains avertissements liés aux réglages INI (y compris via .htaccess avec mod_php) et le suivi de progression des envois de session (session.upload_progress), validé à la fois sous mod_php et sous PHP-FPM.

Suis-je concerné par cette faille PHP ?

Commence par vérifier la version exacte de PHP qui exécute ton site. En ligne de commande :

php -v
# Exemple de sortie vulnérable :
# PHP 8.4.26 (cli) ...
# Version corrigée attendue : 8.4.27 ou plus

Attention : la version en ligne de commande n’est pas toujours celle utilisée par le serveur web. Pour être certain, crée temporairement un fichier, ouvre-le dans ton navigateur, puis supprime-le immédiatement :

<?php
// version.php : à supprimer juste après la vérification
echo PHP_VERSION . " — " . PHP_SAPI;

La deuxième valeur t’indique le mode d’exécution : apache2handler correspond à mod_php (le cas le plus exposé), fpm-fcgi à PHP-FPM et litespeed à LiteSpeed.

• WampServer ou XAMPP en local : risque faible tant que ton serveur n’est pas accessible depuis Internet, mais mets à jour quand même (et si ton port 80 pose problème, notre guide port 80 déjà utilisé avec WampServer t’aidera).
• Hébergement mutualisé (Hostinger, OVH, o2switch…) : vérifie la version dans ton panneau et la date de mise à jour de l’hébergeur.
• VPS ou serveur dédié : c’est à toi de mettre à jour, aujourd’hui.

Comment corriger la faille : mettre à jour PHP

Debian / Ubuntu (dépôt ondrej/php ou paquets de la distribution)

sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm php8.4-cli
php -v
# Redémarre le service concerné :
sudo systemctl restart php8.4-fpm   # ou : sudo systemctl restart apache2

RHEL / AlmaLinux / Rocky (dépôt Remi)

sudo dnf upgrade "php*"
php -v
sudo systemctl restart php-fpm httpd

Docker

# Dans ton Dockerfile, épingle une version corrigée :
FROM php:8.4.27-fpm

# Puis reconstruis sans cache :
docker build --pull --no-cache -t mon-app .

Windows, WampServer et XAMPP

Télécharge la nouvelle version sur windows.php.net (ou l’addon PHP correspondant pour WampServer), ajoute-la, sélectionne-la dans le menu, puis redémarre les services.

Hébergement mutualisé

Dans ton panneau d’hébergement, sélectionne la dernière version de ta branche PHP. Si la version corrigée n’apparaît pas encore, contacte le support en citant CVE-2026-109618 et CVE-2026-109619.

Pas de mise à jour possible tout de suite ? Les mesures temporaires

L’équipe PHP est claire : aucune configuration ne remplace la mise à jour. En attendant, ces réglages réduisent la surface d’attaque :

• Désactiver le suivi de progression des envois si tu ne t’en sers pas : session.upload_progress.enabled = 0.
• Sur PHP 8.5 : fatal_error_backtraces = 0.
• Garder des limites prudentes : post_max_size, max_input_vars, max_input_nesting_level, max_file_uploads, et limiter la taille des requêtes au niveau du serveur web ou du pare-feu.
• Bloquer les requêtes multipart au niveau du serveur frontal si ton application n’accepte aucun envoi de fichier.
• Sous PHP-FPM, pm.max_requests = 1 si les performances le permettent (un processus neuf par requête).

; php.ini : mesures temporaires en attendant la mise à jour
session.upload_progress.enabled = 0
post_max_size = 8M
max_input_vars = 1000
max_input_nesting_level = 32

Ce que la correction change dans PHP

Pour la première faille, PHP n’interrompt plus brutalement la requête au moment exact du manque de mémoire. Il déclenche un arrêt « en douceur » au prochain point sûr de l’exécution, et ne coupe net (avec _exit()) qu’au-delà d’un seuil plus élevé. Le nettoyage de fin de requête ne voit donc plus jamais de mémoire à moitié initialisée. Pour la seconde, l’état global est désormais réinitialisé de façon fiable, même après une erreur fatale. Les notes de version résument le tout par « Avoid state corruption via bailout ».

Ces versions contiennent aussi d’autres corrections de robustesse, dont un dépassement de tampon dans le moteur HTML Lexbor et plusieurs corrections dans OPcache : une raison de plus pour ne pas rester sur une version antérieure.

Comprendre un use-after-free en 2 minutes

Les deux failles appartiennent à la même famille : le use-after-free, littéralement « utilisation après libération ». C’est la catégorie de bug derrière une bonne partie des failles critiques des navigateurs et des moteurs de langages, et cette faille critique PHP ne fait pas exception.

Imagine un casier de consigne. Tu y déposes ton sac, on te donne un ticket. Tu récupères ton sac et le casier est libéré, mais tu gardes le ticket. Si quelqu’un d’autre dépose ses affaires dans ce casier et que tu utilises ensuite ton vieux ticket, tu ouvres le casier… et tu tombes sur le contenu de quelqu’un d’autre. En mémoire, c’est exactement ça : un programme garde un « pointeur » vers une zone libérée, la zone est réutilisée, et le programme lit ou écrit dedans comme si rien n’avait changé.

Pour un attaquant, l’intérêt est de choisir ce qui sera placé dans le casier. En envoyant des requêtes bien calibrées, il peut influencer le contenu de la mémoire réutilisée et, dans le pire des cas, détourner le flux d’exécution du programme. C’est pour ça qu’un simple « bug de mémoire » peut devenir une exécution de code à distance.

Checklist complète après la faille critique PHP

Une fois PHP mis à jour, prends dix minutes pour faire le tour de ton serveur. Cette checklist s’applique à n’importe quelle alerte de sécurité, mais elle est particulièrement utile après une faille critique PHP exploitable à distance.

• Vérifie toutes tes versions : en ligne de commande, via le serveur web et dans chaque conteneur Docker. Un serveur peut faire tourner plusieurs versions de PHP en parallèle (une par site).
• Redémarre les services : PHP-FPM, Apache, LiteSpeed. Sans redémarrage, l’ancien binaire vulnérable reste en mémoire.
• Reconstruis tes images Docker avec --pull pour récupérer la nouvelle image de base, puis redéploie.
• Relis tes journaux : un pic d’erreurs « Allowed memory size exhausted » ou de requêtes multipart anormalement grosses avant la mise à jour mérite un coup d’œil.
• Supprime les fichiers de test comme version.php ou phpinfo.php : ils donnent des informations précieuses à un attaquant.
• Planifie la suite : abonne-toi aux annonces de php.net ou suis notre rubrique Veille sécurité pour ne pas découvrir la prochaine faille trop tard.

# Voir les versions de PHP installées sur un serveur Debian/Ubuntu
ls /etc/php/

# Vérifier quelle version utilise chaque pool PHP-FPM
systemctl list-units --type=service | grep php

# Chercher des erreurs de mémoire récentes dans les journaux
sudo grep -i "memory size" /var/log/php*-fpm.log | tail -n 20

Faille critique PHP : les erreurs à éviter

Après chaque grosse alerte, on retrouve les mêmes réflexes qui donnent un faux sentiment de sécurité. Voici ceux à éviter face à cette faille critique PHP.

• Mettre à jour WordPress au lieu de PHP : WordPress, ses thèmes et ses extensions n’y sont pour rien. C’est le moteur PHP qu’il faut mettre à jour.
• Se contenter d’un pare-feu applicatif : un WAF peut filtrer certaines requêtes multipart suspectes, mais il ne corrige pas le défaut et ne couvre pas tous les chemins décrits dans les avis.
• Croire qu’un petit site n’intéresse personne : les attaques sur ce type de faille sont automatisées. Les robots scannent tout Internet, sans distinction de taille.
• Oublier les environnements secondaires : préproduction, ancien sous-domaine, serveur de démo… Ce sont souvent eux qui restent vulnérables le plus longtemps.

FAQ

Mon site WordPress est-il touché par cette faille critique PHP ?

Oui s’il tourne sur une version de PHP antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. La faille est dans PHP lui-même, pas dans WordPress : mettre à jour WordPress ou tes extensions ne suffit pas.

Et PHP 8.1 ou 7.4 ?

Ces branches ne sont plus maintenues et ne sont pas listées dans les avis. Elles ne recevront aucun correctif : il faut migrer vers une version supportée.

La faille est-elle exploitée activement ?

Les avis officiels ne mentionnent pas d’exploitation dans la nature, mais confirment une exécution de code réussie en laboratoire. Une fois les détails publics, il faut considérer que le risque augmente chaque jour.

Mon hébergeur s’en occupe-t-il ?

Sur un mutualisé, en général oui, mais avec un délai. Vérifie ta version exacte avec la méthode ci-dessus plutôt que de supposer qu’elle est à jour.

Faille critique PHP : le résumé à retenir

• La faille critique PHP CVE-2026-109618 vient d’une mauvaise gestion du manque de mémoire : une zone mémoire à moitié initialisée est relue en fin de requête.
• La faille critique PHP CVE-2026-109619 vient d’un état global non remis à zéro entre deux requêtes traitées par le même processus.
• Les deux mènent à une exécution de code à distance sans authentification, validée en laboratoire sous mod_php et, pour la seconde, sous PHP-FPM.
• La faille critique PHP touche les branches 8.2, 8.3, 8.4 et 8.5, et elle est corrigée dans 8.2.35, 8.3.36, 8.4.27 et 8.5.12, toutes publiées le 21 octobre 2026.
• Aucun réglage ne remplace la mise à jour : les mesures de configuration ne font que réduire la surface d’attaque de la faille critique PHP.

Si tu ne retiens qu’une chose de cette faille critique PHP, c’est celle-ci : une mise à jour de PHP n’est pas une tâche de maintenance à repousser, c’est un geste de sécurité. Traite la faille critique PHP aujourd’hui, puis profite-en pour mettre en place une routine de vérification mensuelle de tes versions.

Conclusion

Cette faille critique PHP rappelle une règle simple : la version de PHP fait partie de la sécurité de ton site, au même titre que tes mots de passe ou tes extensions. Prends cinq minutes aujourd’hui pour vérifier ta version et mettre à jour. Si tu veux surveiller l’état de ta machine pendant tes tests en local, jette un œil à notre moniteur système en PHP, et si tu viens de PHP pour découvrir d’autres langages, notre guide Java pour développeur PHP t’attend.

Sources officielles

• Avis GHSA-w8hw-w9fx-j79w (php-src)
• Avis GHSA-6wmf-4rv5-p3rp (php-src)
• Journal des modifications PHP 8
• NVD : CVE-2026-109618
• NVD : CVE-2026-109619