Faille critique PHP : deux RCE à corriger sans attendre
En bref. Le 21 octobre 2026, l’équipe PHP a publié des correctifs pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619. Elles peuvent permettre une exécution de code à distance sans authentification dans un runtime PHP exposé au web. La mesure complète est de mettre à jour PHP et de redémarrer les workers concernés.
Deux failles mémoire, deux chemins différents
Les deux avis de sécurité de PHP classent ces failles comme critiques et leur attribuent un score de 9,2 sur 10 en CVSS 4.0. Une exécution de code à distance (RCE) signifie qu’un attaquant peut faire exécuter du code par le serveur. Le code s’exécuterait avec les droits du processus PHP, qui ne sont pas nécessairement ceux de l’administrateur système.
Le risque concerne les versions vulnérables de PHP qui traitent des requêtes web, notamment Apache avec mod_php, PHP-FPM et php-cgi, avec un niveau d’exposition qui varie selon le SAPI. Pour la CVE-2026-109618, un exploit complet est confirmé sur mod_php ; l’analyse identifie aussi des chemins vulnérables dans FPM, sans exploit complet démontré pour ce SAPI. Pour la CVE-2026-109619, une exécution de code a été validée sur mod_php et FPM. Ce n’est pas une faille propre à WordPress ou à un framework : c’est le moteur PHP qu’il faut vérifier.
CVE-2026-109618 : une erreur mémoire pendant le traitement
PHP peut interrompre brutalement une requête quand une allocation échoue. Dans certains chemins, les données internes de la requête sont alors accessibles alors qu’elles ne sont pas encore complètement initialisées. Le nettoyage qui suit peut tenter d’utiliser cet état incomplet. Dans Apache mod_php, ce traitement peut arriver avant l’exécution du code de l’application ; l’avis PHP confirme une exécution de code à distance non authentifiée dans ce scénario.
Schéma 1 — Le chemin général de la CVE-2026-109618, du démarrage de la requête à la corruption mémoire. Les détails dépendent du runtime et de sa configuration.
L’avis décrit notamment des chemins d’épuisement mémoire pendant l’analyse des requêtes multipart. Le point essentiel est que l’erreur peut laisser PHP dans un état incohérent avant que le script du site ne commence.
CVE-2026-109619 : un état périmé entre deux requêtes
Un worker PHP traite plusieurs requêtes au fil du temps. Certains états globaux conservés par le worker peuvent pointer vers une mémoire qui appartient à une requête terminée. Si un chemin d’erreur empêche la remise à zéro, puis qu’une opération d’initialisation accède à cette référence avant de la remplacer, PHP lit ou manipule une zone déjà libérée : c’est une utilisation après libération (use-after-free).
Schéma 2 — La première requête laisse une référence en mémoire ; une requête suivante, traitée par le même worker, la rencontre avant la réinitialisation.
Cette seconde faille dépend donc d’un enchaînement entre deux requêtes servies par le même worker. Les avis de PHP confirment une exécution de code à distance et une divulgation mémoire dans les scénarios validés.
Quelles versions installer ?
Les versions correctives publiées par l’équipe PHP sont :
| Branche | Version corrigée |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Ces seuils correspondent aux correctifs amont annoncés le 21 octobre. Si votre hébergeur ou votre distribution maintient une autre branche, vérifiez son avis de sécurité : un correctif peut être rétroporté sans changer le numéro amont affiché.
Actions à mener
- Inventoriez chaque runtime web. Contrôlez les VM, conteneurs, pools PHP-FPM, serveurs Apache et environnements de préproduction. La version de la commande PHP en ligne de commande ne décrit pas toujours celle qui sert les requêtes.
- Mettez à jour vers une version corrigée ou installez le paquet rétroporté par votre fournisseur. Pour une image conteneur, reconstruisez puis redéployez l’image.
- Redémarrez tous les workers PHP et confirmez que chaque pool ou conteneur utilise bien le correctif. Un paquet installé sans redémarrage peut laisser d’anciens processus actifs.
- Vérifiez les journaux et l’activité des processus si un serveur vulnérable était accessible depuis Internet. L’absence d’erreur dans les journaux ne suffit pas à exclure une tentative ou une compromission.
Un réglage temporaire suffit-il ?
Non. L’équipe PHP indique que la mise à jour est la seule remédiation complète. Pour la CVE-2026-109618, l’avis décrit des réglages qui réduisent certains chemins d’épuisement mémoire, mais précise qu’ils ne constituent pas une protection complète et ne corrigent pas la seconde faille. Limiter les corps de requête et les traitements multipart au niveau du frontal peut réduire l’exposition en attendant le correctif ; cela ne remplace pas la mise à jour.
À retenir
Ces deux failles touchent la gestion mémoire interne de PHP et peuvent aboutir à une exécution de code avec les droits du worker web. Vérifiez les versions réellement utilisées pour servir le trafic, appliquez le correctif fournisseur correspondant et redémarrez les processus PHP. Les avis officiels détaillent les versions concernées et les mesures de remédiation :
Commentaires ()