Aller au contenu

Failles critiques PHP CVE-2026-109618 et 619: patches urgents

PHP corrige deux failles critiques permettant une exécution de code à distance sans authentification. Versions corrigées, serveurs exposés et vérifications…

6 min de lecture Comment nous travaillons

Le projet PHP a publié le 21 octobre 2026 des mises à jour pour deux vulnérabilités critiques permettant l'exécution de code à distance sans authentification. Pour tous ceux qui administrent des sites ou des applications fondés sur PHP, la priorité est de mettre à jour le moteur utilisé par le serveur et de vérifier que les processus actifs ont bien chargé la version corrigée. Mettre à jour uniquement le CMS ne suffit pas: une faille dans le langage sous-jacent reste ouverte.

Les deux failles sont répertoriées sous les identifiants CVE-2026-109618 et CVE-2026-109619, toutes deux avec une gravité de 9,2 sur 10 selon l'échelle CVSS v4.0. Cloudflare indique avoir observé du trafic d'attaque ciblant ses clients, tandis que CloudLinux signale des tentatives correspondant aux modèles d'exploitation connus. Ce sont des indices d'activité hostile: ils ne prouvent pas que chaque installation vulnérable a été compromise.

Deux problèmes dans la gestion de la mémoire

La CVE-2026-109618 concerne le comportement de PHP lorsqu'une opération épuise la mémoire disponible. L'interruption peut laisser des données internes partiellement initialisées; lors de la fermeture de la requête, le processus peut les traiter comme valides. L'advisory officiel documente un impact pouvant aller jusqu'à l'exécution de code sans identifiants, avec les privilèges du compte qui exécute le processus web.

PHP: News Archive - 2026
PHP is a popular general-purpose scripting language that powers everything from your blog to the most popular websites in the world.

La CVE-2026-109619 concerne quant à elle un état interne qui reste accessible après la libération de la mémoire à laquelle il faisait référence. Une requête ultérieure, traitée par le même processus, peut utiliser ces références désormais invalides. Là encore, la possibilité d'exécuter du code à distance a été démontrée. Cela ne signifie pas automatiquement obtenir les privilèges administrateur du système: l'impact initial dépend des permissions du processus concerné.

Quels serveurs sont exposés

L'avis PHP couvre les installations qui traitent des requêtes web via PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet considère le risque le plus élevé pour Apache avec mod_php, où une attaque démontrée peut se déclencher avant même que le code de l'application commence à s'exécuter. Un contrôle placé dans le CMS ne peut donc pas être considéré comme une protection suffisante pour ce chemin d'exécution.

Le risque n'est pas identique dans toutes les configurations. Les advisories distinguent les chemins d'attaque démontrés et les conditions qui dépendent du mode d'exécution, des extensions et de l'application. Pour la seconde vulnérabilité, l'exécution distante a été validée également sous PHP-FPM, via le cycle de gestion des sessions. Utiliser PHP-FPM seul ne permet donc pas de considérer le serveur comme exempt de risque.

Les trois points à retenir

  • Gravité: deux vulnérabilités critiques, toutes deux à 9,2 sur l'échelle CVSS v4.0.
  • Correction: mettre à jour PHP et s'assurer que les processus servant le site chargent bien le code corrigé.
  • Vérification: contrôler le moteur effectivement utilisé par le serveur web, et non seulement la commande disponible dans le terminal.

Les versions corrigées et le cas des paquets avec backports

Le projet PHP indique les premières versions corrigées pour les quatre branches maintenues. Le tableau ci-dessous se réfère aux versions distribuées par le projet: pour les paquets des distributions Linux et des fournisseurs de support, il convient de consulter également leur bulletin de sécurité propre.

Les numéros de versions précis sont indiqués dans les advisories officiels des deux vulnérabilités.

PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour de la part du projet PHP, mais certains fournisseurs maintiennent des paquets avec des correctifs reportés sur des versions plus anciennes, les backports. Pour ces paquets, le seul numéro de version d'origine ne suffit pas à établir si le correctif est présent: il faut vérifier la révision distribuée et les indications du fournisseur. Par ailleurs, le support de sécurité officiel de PHP 8.2 prend fin le 31 décembre 2026: appliquer ce patch et planifier la migration vers une branche plus récente sont deux démarches distinctes.

Comment mettre à jour et vérifier le résultat

La mise à jour doit concerner toutes les installations PHP utilisées sur le serveur. Un même système peut héberger plusieurs versions, plusieurs sites et des processus séparés. Les notes de cPanel distinguent, par exemple, le PHP interne du panneau des paquets EasyApache destinés aux sites. Plesk et CloudLinux publient également des indications pour des composants et des plateformes spécifiques: la disponibilité est à vérifier pour l'environnement réellement utilisé.

Cloudflare deploys protections against php2shell vulnerability
Cloudflare has deployed default web application firewall (WAF) protections for newly disclosed PHP vulnerabilities before public disclosure. The rules use request and response signals to stop exploit attempts and prevent exposed data from reaching attackers.

La commande php -v identifie le programme exécuté par le shell, qui peut différer du moteur configuré pour le site. Une vérification dans le panneau de contrôle ou via une page de diagnostic exécutée par le serveur web permet de contrôler le contexte réel. Si vous utilisez phpinfo(), l'accès doit être restreint et la page supprimée après le contrôle: elle peut exposer des chemins, des configurations, des en-têtes et des variables d'environnement. La procédure à convenir avec son administrateur ou son hébergeur est la suivante:

  1. Préparer une sauvegarde ou un snapshot, avec une procédure de restauration disponible.
  2. Identifier les versions et les composants en cours d'utilisation, y compris les moteurs assignés aux différents sites et ceux utilisés par les panneaux de contrôle.
  3. Installer les paquets corrects via le gestionnaire de la distribution ou les outils officiels du fournisseur.
  4. Redémarrer les services et les processus concernés, en suivant les indications pour PHP-FPM, Apache ou l'environnement utilisé: les anciens processus ne doivent pas continuer à traiter des requêtes.
  5. Vérifier le résultat depuis le terminal et depuis le site, en contrôlant la version, la révision du paquet et le bon fonctionnement des applications.

WAF et mesures temporaires ne remplacent pas le patch

Cloudflare et CloudLinux ont annoncé des règles pour intercepter certains schémas d'attaque. Il s'agit d'un niveau de protection supplémentaire, pas de la suppression de la faille au niveau du serveur. Cloudflare elle-même recommande d'appliquer les mises à jour PHP même en présence des protections WAF.

Les modifications de configuration indiquées dans les advisories officiels couvrent des chemins spécifiques et ne constituent pas une solution générale. Elles doivent être évaluées par rapport à l'application et appliquées au bon endroit dans la configuration. La protection complète contre ces deux failles nécessite le code corrigé, distribué par le projet PHP ou via un paquet fournisseur incluant les patches.

Analyse globale

Le contrôle décisif porte sur ce que le serveur exécute réellement. La présence d'un paquet mis à jour ou d'un panneau à la dernière version ne démontre pas, à elle seule, que chaque site a abandonné l'ancien moteur. La vérification doit descendre jusqu'au processus qui reçoit et traite les requêtes.

Pour les administrateurs, l'intervention se conclut donc par trois résultats vérifiables: correctifs installés, processus mis à jour et contrôle des applications exposées. Cette séquence évite de confondre la disponibilité du patch avec son application effective.

Sources

Contenu promotionnel