Faille critique PHP du 21 octobre 2026 : ce que les propriétaires de sites doivent faire

Le 21 octobre 2026, l'équipe PHP a publié une mise à jour de sécurité critique : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux failles, CVE-2026-109618 et CVE-2026-109619, qui permettent dans certaines conditions à un attaquant sans aucun compte d'exécuter du code sur le serveur. Si votre site, votre boutique ou votre application tourne sur PHP (WordPress, Laravel, Symfony, PrestaShop, Magento, Drupal, un développement maison), cet article explique ce qui s'est passé, qui est concerné et ce qu'il faut faire aujourd'hui, pas la semaine prochaine.

Ce qui a été publié le 21 octobre 2026

Quatre versions corrigées sont disponibles sur php.net : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les deux vulnérabilités sont classées critiques avec un score CVSS 4.0 de 9,2 sur 10. Des chercheurs les ont surnommées « php2shell », parce qu'elles transforment une simple requête HTTP en accès au serveur.

• CVE-2026-109618, corruption mémoire lors d'un dépassement de `memory_limit` : si PHP manque de mémoire au mauvais moment, des données internes partiellement initialisées sont traitées comme valides, ce qui corrompt la mémoire. Sur Apache avec mod_php, une requête non authentifiée peut déclencher le problème avant même que le code de votre site s'exécute.
• CVE-2026-109619, état interne périmé : une erreur fatale au mauvais endroit laisse des structures internes pointer vers de la mémoire libérée. Une requête suivante traitée par le même processus peut réutiliser cet état et, dans les conditions démontrées par le rapporteur, exécuter du code.

Ces défauts ne datent pas d'hier : ils sont présents dans le moteur PHP depuis de nombreuses années. Ce qui change aujourd'hui, c'est qu'ils sont connus publiquement.

Pourquoi l'urgence est réelle

Plusieurs éléments rendent cette publication plus pressante qu'une mise à jour de sécurité habituelle. Les identifiants CVE ont fuité le 20 octobre, la veille de la publication, ce qui a obligé l'équipe PHP à avancer la sortie. Un cabinet de recherche a publié par erreur une vidéo montrant sa preuve de concept, vidéo copiée et diffusée depuis. Et une image de conteneur contenant le correctif a été publiée quelques heures avant l'annonce coordonnée, ce qui permet de comparer le code corrigé et le code vulnérable. Autrement dit, les attaquants ont de quoi travailler.

Au moment de la publication, ni l'équipe PHP ni la CISA (l'agence américaine de cybersécurité, qui a publié une alerte le jour même) n'avaient observé d'exploitation en conditions réelles. C'est rassurant pour les prochaines heures, pas pour les prochaines semaines : les campagnes automatisées qui scannent Internet à la recherche de serveurs non corrigés arrivent en général vite après ce type d'annonce.

Qui est concerné

Selon l'annonce officielle, toutes les installations PHP qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé sur Apache avec mod_php, où l'exploitation a été démontrée avec les réglages par défaut. PHP-FPM, la configuration la plus répandue avec Nginx, est également concerné via des chemins qui passent par le code de l'application.

Concrètement, si vous avez l'un de ces éléments, vous êtes concerné :

• Un site WordPress, WooCommerce, PrestaShop, Magento, Drupal ou Joomla.
• Une application Laravel, Symfony ou CodeIgniter, interne ou publique.
• Un intranet, un CRM ou un outil métier développé en PHP, même accessible uniquement depuis vos bureaux.
• Un hébergement mutualisé ou un VPS avec un panneau cPanel ou Plesk.
• Un logiciel tiers qui embarque PHP (certains outils de supervision, de ticketing ou de facturation).

Les versions qui ne recevront pas de correctif

PHP 8.1 et les versions antérieures (8.0, 7.4, 7.3 et plus anciennes) ne sont plus maintenues par le projet PHP et ne reçoivent pas de correctif officiel. Des rétroportages minimaux ont été mis à disposition pour ceux qui compilent PHP eux-mêmes, et certaines distributions Linux ou fournisseurs de support étendu appliquent la correction dans leurs paquets. Mais pour la plupart des sites, la réponse est claire : il faut migrer vers une version supportée. La CISA va plus loin et recommande de mettre hors ligne les systèmes qui ne peuvent pas être corrigés. Nous détaillons la marche à suivre dans PHP 8.1, 8.0 ou 7.4 : comment migrer.

Ce qu'il faut faire aujourd'hui

1. Inventoriez tout ce qui tourne sur PHP : sites, applications, outils internes, logiciels tiers. Les sites oubliés (un ancien blog, une landing page de 2019) sont les plus dangereux, car personne ne les surveille.
2. Identifiez la version de chaque installation : php -v en ligne de commande, la rubrique Santé du site sur WordPress, ou le gestionnaire PHP de votre panneau d'hébergement.
3. Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, en commençant par les sites exposés sur Internet. Le guide mettre à jour PHP sur votre serveur couvre chaque type d'hébergement.
4. Redémarrez PHP-FPM ou Apache après la mise à jour, puis les processus PHP de longue durée (files d'attente, workers), qui gardent sinon l'ancienne version en mémoire.
5. Vérifiez que la version affichée est bien la version corrigée. Attention : certaines distributions Linux appliquent le correctif sans changer le numéro de version ; dans ce cas, le journal des modifications du paquet fait foi.
6. Si vous ne pouvez pas mettre à jour tout de suite, appliquez les mesures temporaires ci-dessous et planifiez la mise à jour dans la journée.

Mesures temporaires si la mise à jour doit attendre

L'équipe PHP est explicite : seule la mise à jour est une solution complète. Les réglages suivants réduisent l'exposition à certains chemins d'attaque, sans rendre l'installation sûre.

• `session.upload_progress.enabled = 0`, dans php.ini ou dans la configuration du pool FPM, puis redémarrage de tous les workers. Ce réglage bloque les chemins confirmés de la CVE-2026-109619, pas les variantes. Ne comptez pas sur ini_set() ni sur un fichier .user.ini.
• `memory_limit = -1` appliqué au niveau serveur (php_admin_value), combiné à un post_max_size bas (8 Mo sans envoi de fichiers, 32 Mo avec) et à une limite mémoire au niveau du conteneur ou du cgroup. Cela réduit la surface de la CVE-2026-109618 sans la fermer. N'utilisez pas RLIMIT_AS ou RLIMIT_DATA, qui provoquent justement l'échec d'allocation vulnérable.
• Sur PHP 8.5 uniquement, fatal_error_backtraces = 0 bloque le chemin confirmé via les traces d'erreur fatale.
• Un pare-feu applicatif (WAF) peut filtrer une partie des requêtes malveillantes connues. C'est une couche, pas une correction.

Masquer les erreurs avec error_reporting, display_errors ou l'opérateur @ ne protège pas. Sur un hébergement mutualisé ou infogéré, ne modifiez pas ces réglages vous-même : demandez à votre hébergeur s'il a appliqué la mise à jour du 21 octobre.

Ce que fait la PHP Foundation

Dans son billet du 21 octobre, la PHP Foundation détaille comment elle renforce la sécurité du langage : une équipe dédiée à la sécurité de l'écosystème créée en mai 2026, des recrutements pour le traitement des signalements et le durcissement du moteur, des audits externes en cours (après celui de Quarkslab en 2024), des analyses automatisées et des programmes de recherche financés par des acteurs de l'industrie. Depuis le 1er juillet, l'équipe a publié 15 CVE et trié plus d'une centaine de signalements invalides ou en double. La Foundation appelle les entreprises qui vivent de PHP, les hébergeurs et les plateformes cloud à financer ce travail dans la durée.

Pour les propriétaires de sites, la conclusion est simple : la sécurité de PHP s'améliore, et le rythme des publications de sécurité va probablement rester soutenu. Un site sans processus de mise à jour accumulera du retard à chaque annonce.

Comment nous gérons cette alerte pour nos clients

Pour les sites et applications sous maintenance et accompagnement, l'inventaire existe déjà, les versions sont connues et les mises à jour PHP passent par un environnement de test avant la production. Ce type d'alerte se traite dans la journée, avec vérification de chaque site après coup. Si votre site n'est suivi par personne et que vous ne savez pas quelle version de PHP il utilise, contactez-nous : nous vérifions et mettons à jour en priorité les sites exposés.