CVE-2026-109618 et CVE-2026-109619 : deux failles critiques dans PHP
Deux failles critiques permettent d’attaquer des serveurs PHP sans authentification. Découvrez les versions touchées, les correctifs et l’aide de XemmeX.
Deux vulnérabilités critiques découvertes dans le cœur de PHP peuvent permettre à un attaquant non authentifié d’exécuter du code à distance sur un serveur Web. Identifiées sous les références CVE-2026-109618 et CVE-2026-109619, elles ont reçu chacune une cote de 9,2 sur 10 selon CVSS 4.0.
Le projet PHP a publié des correctifs d’urgence le 21 octobre 2026 et recommande une mise à jour immédiate. Son avis officiel est sans ambiguïté : aucune mesure de contournement ne protège complètement un système vulnérable. La mise à jour de PHP demeure la seule solution complète.
Pourquoi ces failles sont particulièrement graves
Une vulnérabilité d’exécution de code à distance, ou RCE, peut permettre à un attaquant de faire exécuter ses propres instructions par le processus PHP. L’accès obtenu correspond d’abord aux privilèges du compte utilisé par le serveur Web, mais il peut suffire pour consulter ou modifier des fichiers, voler des identifiants, injecter une porte dérobée, détourner un site, expédier du pourriel ou installer un cryptomineur.
L’attaque ne requiert ni compte utilisateur ni accès préalable au panneau d’administration. Le risque concerne les installations PHP qui traitent des requêtes Web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP considère actuellement le risque comme particulièrement élevé avec mod_php, pour lequel une exploitation a été démontrée avant même l’exécution du code de l’application.
CVE-2026-109618 : corruption lors d’un manque de mémoire
PHP utilise un mécanisme appelé longjmp() pour interrompre certains traitements lorsque la mémoire disponible pour une requête est épuisée. Dans certaines circonstances, cette interruption peut survenir alors que des données internes ne sont que partiellement initialisées. La procédure de fermeture de la requête peut ensuite traiter cette mémoire invalide comme si elle était légitime.
Selon l’avis technique officiel, des requêtes multipart spécialement construites peuvent provoquer cet état. Plusieurs techniques permettent de faire consommer beaucoup plus de mémoire à PHP que ne le laisse croire la taille apparente de la requête, notamment au moyen d’un grand nombre d’en-têtes, de champs imbriqués ou de métadonnées de téléversement.
Les chercheurs ont validé une exécution de code à distance sans authentification contre Apache mod_php. PHP-FPM réduit certains chemins d’attaque parce qu’un processus enfant peut être interrompu après un échec de démarrage, mais il n’est pas déclaré immunisé : des scénarios liés à l’application demeurent possibles.
CVE-2026-109619 : un état interne réutilisé entre deux requêtes
La seconde faille concerne des données internes qui peuvent survivre à la requête qui les a créées, même après la libération de la mémoire correspondante. Si le même processus PHP traite ensuite une autre requête, il peut réutiliser ce pointeur périmé avant que son état normal soit correctement réinitialisé. Il s’agit d’une forme d’utilisation de mémoire après libération, communément appelée use-after-free.
L’avis de sécurité de PHP décrit notamment des chemins impliquant le suivi de progression des téléversements de session, des erreurs fatales et certains diagnostics de configuration. Une exploitation complète exige plusieurs conditions et peut dépendre de la version, des extensions et de la configuration. Cela ne rend toutefois pas la faille théorique : des chaînes d’exploitation ont été démontrées sur des applications courantes.
Quelles versions doivent être corrigées?
Les versions corrigées publiées par le projet PHP sont les suivantes :
| Branche PHP | Version corrigée minimale |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 et versions antérieures | Aucune nouvelle version officielle de la branche; migration ou correctif rétroporté du fournisseur requis |
Les versions touchées confirmées vont de PHP 5.4 à PHP 8.5.11. Certaines distributions Linux, dont AlmaLinux, Red Hat, Debian et Ubuntu, peuvent intégrer le correctif à leurs propres paquets sans adopter le même numéro de version que PHP.net. Dans ce cas, php -v ne suffit pas toujours : il faut aussi vérifier la version du paquet, son journal de modifications et l’avis de sécurité du fournisseur.
Les branches PHP 8.1 et antérieures sont arrivées en fin de vie auprès du projet PHP. Certains distributeurs offrent exceptionnellement un correctif rétroporté, mais cela ne transforme pas une ancienne branche en solution durable. Une migration vers une version encore soutenue doit être planifiée.
Mettre à jour le CMS ne corrige pas PHP
WordPress, Drupal, Joomla, Laravel, Symfony, Magento et les applications sur mesure reposent sur PHP, mais ne le remplacent pas. Mettre à jour le site, ses extensions ou ses dépendances Composer ne met généralement pas à jour l’interpréteur installé sur le serveur.
L’intervention doit couvrir toutes les versions présentes. Un serveur cPanel ou WHM peut héberger plusieurs branches PHP en parallèle; la commande exécutée dans le terminal peut donc afficher une version différente de celle utilisée par un domaine. Les processus PHP-FPM, Apache ou LiteSpeed doivent aussi être redémarrés après l’installation des correctifs afin qu’aucun ancien processus vulnérable ne demeure en mémoire.
Le correctif doit être suivi d’une vérification de compromission
Installer la mise à jour ferme la faille, mais n’efface pas les actions qui auraient pu être réalisées auparavant. Lorsque le serveur était exposé, il est prudent d’examiner les journaux Web et PHP, les erreurs de mémoire répétées, les réponses HTTP 500 inhabituelles, les téléversements multipart suspects, les nouveaux fichiers exécutables, les tâches planifiées, les comptes créés et les processus inconnus.
La présence d’une requête suspecte ne prouve pas automatiquement une compromission. À l’inverse, une absence d’alerte dans le journal de l’application ne suffit pas à conclure que le système est sain, puisque les vulnérabilités agissent dans le moteur PHP et parfois avant le démarrage normal de l’application.
Comment XemmeX Technologies peut vous aider
XemmeX Technologies peut effectuer l’intervention directement dans votre environnement, qu’il s’agisse d’un serveur interne, d’un hébergement cPanel/WHM, d’un serveur VPS chez OVHcloud ou d’une infrastructure hébergée auprès d’un autre fournisseur.
L’intervention peut comprendre :
- l’inventaire des versions de PHP réellement utilisées par chaque site et service;
- la vérification du système d’exploitation, des dépôts et des paquets rétroportés;
- la sauvegarde préalable et l’évaluation de la compatibilité des applications;
- l’installation des versions corrigées ou la migration d’une branche arrivée en fin de vie;
- le redémarrage contrôlé de PHP-FPM, Apache ou LiteSpeed;
- la validation de chaque site après l’intervention;
- l’examen des journaux et des indicateurs pouvant révéler une tentative d’exploitation ou une compromission;
- le renforcement de la configuration et la remise d’un compte rendu technique.
Pour faire vérifier ou corriger votre serveur :
- Courriel : support@xemmex.ca
- Téléphone : 418 208-7616
- Demande de devis : Obtenir une évaluation de XemmeX Technologies
Conclusion
CVE-2026-109618 et CVE-2026-109619 touchent la couche qui exécute l’ensemble de l’application Web. Leur gravité, l’absence d’authentification nécessaire et la disponibilité publique de renseignements techniques imposent une réaction rapide.
La bonne démarche consiste à inventorier toutes les instances PHP, appliquer les correctifs du fournisseur, redémarrer les services, valider les applications et vérifier qu’aucune compromission antérieure n’est passée inaperçue.