Urgent : deux failles critiques dans PHP, les correctifs arrivent aujourd'hui à 16h

L'équipe de sécurité de PHP a publié une alerte hier soir (mardi 20 octobre) : une mise à jour de sécurité sortira ce mercredi 21 octobre à 14h UTC, soit 16h heure de Paris, pour corriger deux vulnérabilités critiques.

Les deux failles sont notées 9,2 sur 10 selon le CVSS v4.0, l'échelle standard qui mesure la gravité d'une vulnérabilité (on est dans la catégorie critique, la plus haute).

Et c'est à peu près tout ce que l'on sait officiellement : ni leur nature, ni les versions touchées, ni les numéros des versions corrigées. Tout sera publié avec le correctif.

En attendant, le message adressé aux développeurs et aux admins tient en un mot : préparez-vous.

Un embargo qui prend l'eau

Cette annonce n'arrive pas par hasard. Hier soir, une heure environ avant l'alerte de PHP, la boîte de sécurité watchTowr a confirmé sur X que des informations avaient fuité sur deux failles d'exécution de code à distance dans PHP, encore sous embargo, et qu'elles étaient bien réelles.

Une faille d'exécution de code à distance (RCE, pour Remote Code Execution), c'est le pire scénario pour un serveur web : un attaquant parvient à faire tourner son propre code sur votre machine, depuis Internet.

Ici, c'est PHP lui-même qui est touché : tout ce qui repose dessus, CMS comme frameworks, serait donc exposé.

Les messages qui ont fuité évoquaient une annonce de sécurité prévue jeudi, sans dire qui devait la faire. PHP a publié son avertissement dans la foulée, avec une sortie fixée à aujourd'hui, mercredi 21 octobre.

De PHP 5 à PHP 8, tout le monde y passe ?

Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Un rapport non vérifié, relayé par watchTowr, affirme qu'elles touchent toutes les versions de PHP depuis la 5, ce que PHP n'a pas confirmé.

L'entreprise singapourienne pense être parvenue à reproduire la première. Et elle donne aux deux failles la note maximale de 10, quand l'annonce officielle de PHP s'en tient à 9,2.

Une vidéo circule également : elle montre un outil baptisé PHP2Shell qui exécuterait du code sur des serveurs WordPress, Drupal, Magento, Joomla, phpBB ou Laravel. Elle serait tirée de ce même rapport, qui n'a pas été authentifié.

La situation s'est tendue pendant la nuit : plusieurs pages qui surfent sur l'inquiétude et prétendent publier un exploit fonctionnel sont apparues en ligne. PHP ne les a pas authentifiées, et aucune attaque réelle n'a été signalée à ce stade.

Si l'un de ces exploits se révélait authentique, ou si des attaques étaient repérées, PHP pourrait publier ses correctifs avant 16h, comme il s'en est réservé le droit. Pour l'instant, l'horaire officiel ne bouge pas.

Quand on sait que PHP fait tourner près de 70 % des sites web, l'agitation se comprend. Une faille sans détail dans une brique installée partout n'est d'ailleurs pas sans rappeler quelques mauvais souvenirs de Log4j.

Comment se préparer d'ici 16h

Le plus utile, c'est de faire l'inventaire : serveurs, conteneurs, images de CI, machines de dev, tout ce qui embarque PHP, avec sa version (un php -v suffit). Sur WordPress, la version s'affiche dans Outils, Santé du site, onglet Infos, rubrique Serveur.

Depuis cette nuit, une parade circule aussi sur les réseaux : désactiver un réglage dans le php.ini.

Gina Peter Banyard, développeuse du cœur de PHP, a rapidement douché les espoirs : selon elle, la seule protection reste la mise à jour de PHP.

Elle ajoute que couper le serveur une journée est sans doute le plus raisonnable pour celles et ceux qui peuvent se le permettre, tout en reconnaissant que c'est beaucoup demander à la plupart des gens.

Le CERT-EU, l'équipe qui veille sur la cybersécurité des institutions et des agences de l'Union européenne, ne prend pas de gants non plus.

Il recommande de se tenir prêt à patcher immédiatement et, pour ceux qui ne pourront pas le faire tout de suite, d'envisager de couper les applications exposées sur Internet en attendant.

Si vous êtes sur un hébergement mutualisé, c'est votre hébergeur qui met PHP à jour : demandez-lui quand il compte déployer le correctif. Sur vos propres serveurs, prévoyez une fenêtre de maintenance en fin d'après-midi.

Si vos applis tournent dans des conteneurs Docker, le correctif ne s'installera pas tout seul : il faudra reconstruire vos images à partir d'une image de base à jour, puis redéployer.

Laravel a déjà prévenu les clients de Forge et de Laravel Cloud que leurs images de base seraient mises à jour, mais qu'un redéploiement pourrait être nécessaire pour en profiter.

Et pour corser l'après-midi, Node.js publie aussi ses correctifs de sécurité ce mercredi. Les équipes ops vont adorer.

PHP 5.6, le grand oublié

Les correctifs de sécurité de PHP ne concernent normalement que les versions encore maintenues, à savoir 8.2, 8.3, 8.4 et 8.5.

Tout ce qui tourne en dessous, de PHP 8.1 jusqu'aux antiquités 👀, ne devrait donc pas être couvert par ces correctifs.

Et ce n'est pas une population négligeable : 5 % des sites web tourneraient encore aujourd'hui en PHP 5, et plus de la moitié d'entre eux en PHP 5.6, sorti en 2014 et dont la maintenance a pris fin en décembre 2018.

Quelque part, un vieux serveur que personne n'a touché depuis 2014 vient de sentir un frisson lui parcourir l'échine.

Les nouvelles versions correctives seront annoncées dès leur sortie sur la page d'accueil de php.net, et le détail des deux failles sera publié dans les avis de sécurité du dépôt GitHub de PHP.