Deux failles critiques dans PHP : mettez à jour dès maintenant

Le 21 octobre 2026, l'équipe de sécurité de PHP a publié des correctifs pour deux vulnérabilités critiques du moteur lui-même : CVE-2026-109618 et CVE-2026-109619. Toutes deux ont reçu la cote CVSS v4 de 9,2 et peuvent mener à l'exécution de code à distance (RCE), sans authentification. Le problème ne vient pas d'une application ou d'une bibliothèque : il touche PHP, donc potentiellement tous vos sites.

L'essentiel en trente secondes

• Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les deux failles.
• Toute installation PHP qui répond à des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.
• Seule la mise à jour règle complètement le problème. Les mesures temporaires réduisent l'exposition, sans plus.

Ce que font les deux failles

CVE-2026-109618 est une corruption de mémoire déclenchée lorsque PHP manque de mémoire en pleine préparation d'une requête. Les données de la requête restent alors partiellement initialisées, et le nettoyage qui suit les traite comme si elles étaient valides. Des requêtes multipart conçues pour l'occasion peuvent épuiser la mémoire même dans les limites de taille configurées.

CVE-2026-109619 est un « use-after-free » : un état global laissé par une requête précédente pointe vers de la mémoire déjà libérée, et une requête suivante traitée par le même processus peut s'en servir. La divulgation de mémoire est un effet confirmé. Une erreur fatale ou un dépassement de délai, qui interrompt le nettoyage, suffit à créer les conditions du problème.

Dans les deux cas, le code de l'attaquant s'exécute avec les droits du processus web. Le projet PHP considère mod_php comme le scénario le plus risqué, puisque l'attaque peut survenir avant même que le code de votre application ne s'exécute.

Est-ce déjà exploité?

Au moment d'écrire ces lignes, les analyses publiées se contredisent légèrement, ce qui est normal pour une situation qui évolue vite. Amazon Threat Intelligence rapporte une tentative sur ses pièges dès le 17 octobre, soit quatre jours avant la divulgation, puis d'autres le 21. Cloudflare et watchTowr font aussi état de tentatives. Rapid7, de son côté, n'a pas observé d'exploitation confirmée, mais relève de nombreux signalements de tentatives.

Des codes d'exploitation circulent, mais aucun n'a été confirmé comme fiable et général : chacun semble fonctionner pour une combinaison précise de système, de version de PHP et de serveur web. Restez prudent : un « exploit » trouvé en ligne peut lui-même être malveillant. Le répit est court. Considérez-le comme une fenêtre pour corriger, pas comme une preuve que vous êtes à l'abri.

Quelles versions sont touchées?

• PHP 8.2 à 8.5 : corrigé dans 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• PHP 7.4, 8.0 et 8.1 : aucune version officielle, mais l'équipe a publié des correctifs minimaux à appliquer au code source.
• PHP 5.4 à 7.3 : fin de vie, aucun correctif. Le code fautif remonte au moins à PHP 5.4.0.

Si vous utilisez les paquets de votre distribution Linux, vérifiez l'avis de votre fournisseur : plusieurs ont reçu les correctifs à l'avance. Attention aux dépôts tiers qui n'ont pas suivi le même calendrier.

Vérifier votre version

En ligne de commande, php -v indique la version du binaire CLI, mais pas nécessairement celle qui sert vos pages. Créez plutôt une page temporaire qui affiche PHP_VERSION et PHP_SAPI, consultez-la, puis supprimez-la. Vérifiez aussi chaque environnement : production, préproduction, conteneurs et serveurs oubliés.

<?php echo PHP_VERSION, ' / ', PHP_SAPI;

Si vous ne pouvez pas mettre à jour tout de suite

Ces réglages sont des pansements, pas des correctifs :

• memory_limit = -1, appliqué de façon que les applications ne puissent pas le modifier. Sans plafond de mémoire, d'autres limites de ressources deviennent plus importantes, par exemple au niveau du conteneur.
• session.upload_progress.enabled = 0 pour la seconde faille.
• Sous PHP 8.5, fatal_error_backtraces = 0.
• Limiter la taille des requêtes et le nombre de champs au niveau du serveur frontal, et bloquer les requêtes multipart si votre site n'en utilise pas.

Redémarrez ensuite tous les processus PHP : un ini_set() dans le code arrive trop tard. Évitez aussi les limites système RLIMIT_AS et RLIMIT_DATA, qui peuvent provoquer exactement le chemin d'allocation défaillant visé par la première faille. Enfin, masquer les erreurs ne protège de rien, et l'absence de journaux ne prouve pas que vous n'avez pas été visé.

Et le pare-feu applicatif?

Cloudflare a déployé des règles contre les vecteurs connus, mais elles ne couvrent que le trafic qui passe par ce service, et elles servent de solution d'attente. Un pare-feu ne remplace pas le correctif : une autre variante de requête peut passer entre les mailles.

Un plan d'action simple

1. Inventoriez tous vos serveurs, conteneurs et hébergements mutualisés qui exécutent PHP.
2. Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou vers le paquet de votre distribution qui contient les deux correctifs.
3. Redémarrez PHP-FPM, Apache ou le serveur concerné, puis vérifiez la version réellement servie.
4. Appliquez les mesures temporaires partout où la mise à jour doit attendre.
5. Cherchez des traces suspectes : requêtes multipart inhabituelles, erreurs fatales en rafale, nouveaux fichiers dans les dossiers accessibles en écriture.
6. Planifiez la migration des versions en fin de vie, car aucune d'elles ne sera corrigée.

Si vous gérez des sites pour des clients, prévenez-les rapidement : un site WordPress, Drupal, Joomla ou Magento hébergé sur une version vulnérable de PHP est touché, même si le CMS est à jour. Des chercheurs ont d'ailleurs démontré des attaques sans authentification contre certaines versions de ces plateformes.

À retenir

Cette alerte rappelle qu'on ne met pas seulement à jour son code et ses dépendances Composer : le moteur PHP, le serveur web et le système sont aussi de la surface d'attaque. Utiliser une version prise en charge, savoir précisément ce qui tourne en production et pouvoir déployer un correctif en quelques heures valent mieux que n'importe quel réglage de dernière minute. Si votre site est sur un hébergement mutualisé, écrivez à votre hébergeur pour connaître son échéancier : vous ne contrôlez pas la version de PHP, mais vous avez le droit de savoir quand elle sera corrigée. Mettez à jour aujourd'hui.

Sources

• Tenable : questions fréquentes sur CVE-2026-109618 et CVE-2026-109619
• Rapid7 : exécution de code à distance non authentifiée dans PHP