Kilho.net

Vulnérabilités PHP CVE-2026-109618 et CVE-2026-109619

Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, permettant l’exécution de code à distance (RCE) sans authentification ont été révélées dans le moteur principal de PHP, lors de la gestion des arrêts anormaux et de l’état des requêtes. Ce problème ne concerne pas des applications web comme WordPress ou GNUBoard, mais résulte de défauts de corruption de mémoire et de réutilisation après libération (Use-After-Free) dans le moteur d’exécution PHP lui-même. Pour corriger le problème, vous devez immédiatement mettre à niveau PHP vers une version intégrant les correctifs de sécurité, notamment PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrer les processus workers.

Une vulnérabilité du moteur PHP qui ne peut pas être bloquée par la seule mise à jour de l’application web

Le 21 octobre 2026 (UTC), l’équipe PHP a publié deux vulnérabilités de sécurité évaluées à 9,2 selon le niveau de risque CVSS v4.0. Un attaquant peut exécuter du code arbitraire sur le serveur en envoyant simplement une requête HTTP spécialement conçue, sans passer par une procédure de connexion.

Ces défauts se situent dans la couche principale de PHP, qui analyse les requêtes web et libère la mémoire. Par conséquent, même si le CMS ou les extensions du site sont maintenus à jour, un environnement d’exécution PHP obsolète reste exposé. En particulier, dans les environnements utilisant la configuration par défaut de mod_php avec Apache, il a été confirmé qu’une seule requête peut suffire à exécuter du code avant même l’exécution du code de l’application web.

En cas de réussite de l’attaque, l’intrus obtient les privilèges du compte système sous lequel le processus PHP s’exécute. Cela ne permet pas de prendre immédiatement le contrôle avec les privilèges root, mais l’attaquant peut créer un webshell dans le répertoire racine du site, ou consulter les informations de connexion à la base de données enregistrées dans les fichiers de configuration afin d’exfiltrer ou de modifier des données internes. Si plusieurs sites web partagent le même compte d’exécution PHP-FPM sur un serveur, la compromission d’un site peut également se propager aux autres sites du serveur.

Principe de la corruption de mémoire et de la réutilisation après libération lors d’un arrêt anormal

Les deux vulnérabilités sont dues à l’incapacité à libérer correctement la mémoire lorsqu’une situation exceptionnelle survient pendant le traitement d’une requête. Les conditions de déclenchement et le fonctionnement interne diffèrent toutefois.

CVE-2026-109618 (corruption de mémoire lors du traitement d’un dépassement de limite mémoire) : lorsque PHP dépasse la limite mémoire autorisée (Out-Of-Memory) pendant le traitement d’une requête, il appelle longjmp() afin d’interrompre immédiatement l’exécution. Si le traitement s’arrête alors que les structures de données internes de la requête ne sont pas encore complètement initialisées, cet état incomplet peut subsister sans être annulé. La routine de nettoyage (cleanup) de la requête qui s’exécute ensuite considère cette mémoire non initialisée comme des données valides et y accède, ce qui peut entraîner une corruption de mémoire puis l’exécution de code à distance.

CVE-2026-109619 (Use-After-Free faisant référence à la mémoire libérée d’une requête précédente) : certains états globaux internes de PHP ou certains états de traitement des erreurs pointent temporairement vers une zone mémoire appartenant à une seule requête. Lorsqu’une requête s’arrête anormalement à la suite d’une erreur fatale (fatal error) ou d’un manque de mémoire, la mémoire réelle peut être libérée alors que la référence de pointeur interne qui la désigne n’est pas réinitialisée. Dans les environnements qui réutilisent les processus workers, comme PHP-FPM ou mod_php, lorsque le même worker traite la requête HTTP suivante, il peut relire la zone mémoire déjà libérée (Use-After-Free), créant ainsi un chemin d’exécution de code.

L’avis de sécurité officiel cite comme chemins confirmés pour CVE-2026-109619 la fonctionnalité de progression des téléversements de session (session.upload_progress), les avertissements de configuration affichés avant l’initialisation de la requête et les backtraces d’erreurs fatales de PHP 8.5 (fatal_error_backtraces). Il précise toutefois que d’autres variantes restent possibles même si ces chemins sont bloqués.

État des correctifs par version de PHP et portée selon l’environnement d’exécution

Les versions PHP 8.2 à 8.5 antérieures aux versions corrigées sont concernées. Les versions 8.1 et antérieures, qui ne sont plus prises en charge, ne font pas partie des mises à jour officielles du projet PHP. Tous les modes d’exécution traitant des requêtes web sont concernés, notamment PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. L’avis officiel considère toutefois mod_php comme présentant le risque le plus élevé. Red Hat classe PHP-FPM comme conditionnellement vulnérable par l’intermédiaire de chemins au niveau de l’application.

Famille de versions PHP Plage de versions vulnérables Version corrigée État de la prise en charge et remarques
PHP 8.5 8.5.0 ~ 8.5.11 8.5.12 Mise à jour de sécurité officielle publiée
PHP 8.4 8.4.0 ~ 8.4.26 8.4.27 Mise à jour de sécurité officielle publiée
PHP 8.3 8.3.0 ~ 8.3.35 8.3.36 Mise à jour de sécurité officielle publiée
PHP 8.2 8.2.0 ~ 8.2.34 8.2.35 Mise à jour de sécurité officielle publiée
PHP 8.1 et antérieures Ne font pas l’objet de mises à jour officielles Aucune version officielle publiée Fin de prise en charge (EOL). Pour 7.4, 8.0 et 8.1, seuls des rétroportages minimaux destinés à la compilation depuis les sources sont fournis ; vérifiez les paquets proposés par votre distribution ou votre fournisseur LTS

Environnement vérifié : au 22 octobre 2026, dans un environnement de serveur Linux utilisant le dépôt Remi, nous avons mis à niveau PHP 8.4.26 vers 8.4.27, puis vérifié le redémarrage des workers PHP-FPM et la prise en compte par les requêtes web.

Procédure de mise à jour des paquets et d’application de la configuration d’atténuation PHP-FPM

L’équipe PHP indique qu’une modification de configuration seule ne permet pas de bloquer tous les chemins d’attaque et que la mise à jour vers une version corrigée constitue l’unique solution complète. Après la mise à jour, vous pouvez également désactiver les fonctionnalités inutiles afin de réduire la surface d’attaque.

  1. Installer la mise à jour des paquets PHP
    Mettez à niveau les paquets vers la version corrigée de la branche PHP utilisée, par exemple 8.4.27 pour la branche 8.4, à l’aide du gestionnaire de paquets du système d’exploitation. Après l’installation, vérifiez d’abord la version de l’interface de ligne de commande dans le terminal.

    php -v

    L’exécution de la commande affiche à l’écran le numéro de version mis à jour et la date de compilation, par exemple PHP 8.4.27 (cli). Toutefois, la version de l’interface de ligne de commande peut différer de celle du processus PHP réellement utilisé par le serveur web ; vous devez donc impérativement effectuer l’étape suivante.

  2. Ajuster la configuration PHP-FPM pour réduire la surface d’attaque (facultatif et temporaire)
    Si l’application immédiate de la mise à jour est difficile ou si vous souhaitez ajouter une couche de défense, sauvegardez le fichier php.ini ou le fichier de configuration du pool PHP-FPM (par exemple /etc/php-fpm.d/www.conf), puis modifiez les paramètres suivants.

    php_admin_value[session.upload_progress.enabled] = Off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

    La désactivation de session.upload_progress.enabled permet de bloquer le chemin d’attaque confirmé fondé sur les sessions. La réduction de post_max_size — à 8M dans un environnement sans téléversement de fichiers, ou à 32M dans un environnement qui en a besoin, par exemple — rend plus difficiles les tentatives visant à provoquer un épuisement de la mémoire au moyen de requêtes volumineuses. Tenez compte de la taille des en-têtes supplémentaires multipart et définissez upload_max_filesize à une valeur légèrement inférieure à post_max_size. Dans un environnement PHP 8.5, appliquez également le paramètre fatal_error_backtraces = 0.

  3. Vérifier la syntaxe de la configuration PHP-FPM et redémarrer les processus
    Après avoir enregistré la configuration, vérifiez l’absence d’erreur de syntaxe, puis redémarrez le service PHP-FPM.

    php-fpm -t
systemctl restart php-fpm

    Si la configuration est correcte lors de l’exécution de php-fpm -t, le message NOTICE: configuration file ... test is successful s’affiche à l’écran. Le redémarrage des processus workers est nécessaire pour arrêter les anciens workers obsolètes encore résidents en mémoire et appliquer la nouvelle version corrigée ainsi que la configuration.

  4. Vérifier la version réellement appliquée au moyen d’une requête web
    Appelez l’onglet d’informations « État du site (Site Health) » de WordPress ou une page de diagnostic de l’intégration au serveur web afin de vérifier que le worker PHP-FPM traitant les requêtes web répond avec une version corrigée telle que 8.4.27. Si vous avez créé temporairement un fichier PHP de diagnostic, supprimez-le immédiatement après la vérification afin d’éviter d’exposer des informations système à l’extérieur.

Que faire en cas de retard de mise à jour ou d’effets indésirables liés à une modification de configuration

Lorsque la mise à jour d’un paquet n’est pas disponible en raison du retard de synchronisation d’un dépôt tiers (Remi, etc.)

Juste après la publication d’un correctif de sécurité urgent, une forte concentration du trafic ou un retard de synchronisation peut empêcher l’affichage immédiat des paquets dans un dépôt tiers, tel que rpms.remirepo.net, ou ralentir leur téléchargement. L’avis officiel indique que les mises à jour ne sont pas nécessairement disponibles le jour de leur publication dans ce dépôt géré par des bénévoles, et recommande de passer aux paquets de la distribution ou à une compilation depuis les sources.

Dans ce cas, vous pouvez définir directement, dans la configuration du dépôt, l’adresse d’un serveur miroir correctement synchronisé et offrant un débit normal, puis effectuer la mise à jour. Même après un changement manuel de miroir, vous devez maintenir la vérification des signatures GPG (gpgcheck=1) activée afin d’empêcher la falsification des paquets. Si l’utilisation d’un miroir est impossible, utilisez les paquets officiellement rétroportés par la distribution du système d’exploitation ou compilez directement le code source.

Lorsque la configuration d’atténuation fait craindre un manque de mémoire (OOM) ou le refus de téléversements

L’avis officiel propose memory_limit = -1 (illimité) comme mesure d’atténuation pour CVE-2026-109618 lorsqu’une mise à jour immédiate est impossible, et recommande de définir simultanément une limite mémoire au niveau du conteneur ou du cgroup. Toutefois, sur un serveur disposant de peu de mémoire physique, la suppression de cette limite peut permettre à une seule requête de consommer toute la mémoire du serveur et provoquer un incident au cours duquel l’OOM Killer du système d’exploitation force l’arrêt de services essentiels. Ce paramètre est une mesure temporaire à appliquer jusqu’à la mise à jour ; après l’installation d’une version corrigée, il est plus sûr de rétablir la limite mémoire initiale.

De même, avant de réduire post_max_size par rapport à sa valeur actuelle, par exemple 64 Mo, vous devez vérifier le mode de transfert des fichiers utilisé par le site. Un site permettant de téléverser directement de gros fichiers de sauvegarde ou des extensions depuis une page d’administration peut voir ces requêtes bloquées. En revanche, si les fichiers volumineux sont transférés avec SFTP ou rsync, ou si la limite propre à l’application est déjà fixée à 30 Mo ou moins, réduire la limite de téléversement PHP à 32 Mo n’aura aucun impact sur le service.

Par ailleurs, si les workers PHP-FPM s’arrêtent occasionnellement de manière anormale après une mise à niveau de PHP, vous pouvez vérifier la configuration de compilation JIT (Just-In-Time) d’OPcache. La fonctionnalité JIT, par exemple opcache.jit=1255, n’est pas directement liée à la présente vulnérabilité de sécurité, mais si elle a déjà provoqué des problèmes de stabilité lors d’un changement de version, vous pouvez la désactiver avec opcache.jit=off dans le fichier de configuration afin de prévenir les conflits.

Questions fréquentes

La mise à jour de WordPress ou des extensions vers la dernière version suffit-elle à résoudre le problème ?

Non. Cette vulnérabilité se produit dans le moteur principal de PHP, avant l’exécution de WordPress ou des extensions de sécurité. Un pare-feu applicatif web, comme Cloudflare ou AWS WAF, peut bloquer temporairement les schémas d’attaque connus, mais la résolution fondamentale consiste à mettre à jour la version de PHP du serveur par l’intermédiaire de votre hébergeur ou de votre administrateur système.

Est-il possible de rester en sécurité sans effectuer la mise à jour en désactivant session.upload_progress.enabled ?

Non. L’avis officiel précise que ce paramètre bloque uniquement le chemin de session confirmé et ne protège pas contre d’autres variantes. En outre, le paramètre doit être défini dans un emplacement appliqué avant l’analyse de la requête, comme php.ini, la configuration du pool FPM ou celle du serveur, et non avec ini_set() ou dans le .user.ini de FPM. Tous les workers doivent ensuite être redémarrés. Seule l’installation du correctif apporte une résolution complète.

Une fois le correctif installé, puis-je reprendre immédiatement l’exploitation sans vérification supplémentaire ?

La mise à jour bloque les attaques futures, mais n’indique pas si le serveur a déjà été compromis. Après la mise à jour, il est recommandé de rechercher séparément les signes d’une compromission antérieure. Vérifiez la présence de fichiers PHP récemment créés ou modifiés de manière anormale dans les répertoires web, notamment des webshells, et examinez les journaux d’accès du serveur web ainsi que les journaux d’erreurs PHP à la recherche de requêtes POST volumineuses inhabituelles ou d’erreurs mémoire répétées.

Comment réagir dans un environnement utilisant des conteneurs ou des images cloud ?

La mise à jour des paquets du serveur hôte ne modifie pas automatiquement l’environnement d’exécution PHP inclus dans les conteneurs. Vous devez donc reconstruire et redéployer les images de conteneurs à partir d’une image de base intégrant une version corrigée, à savoir 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Sources