PHP : Deux failles corrigées, les sites web appelés à se mettre à jour

Le projet PHP demande aux administrateurs de mettre à jour leurs serveurs après la découverte de deux vulnérabilités capables de conduire à une exécution de code à distance. L’alerte concerne un langage très présent sur le Web, mais le chiffre de 70 % évoqué dans la presse ne correspond pas au nombre de sites effectivement vulnérables.

Deux failles peuvent conduire à une exécution de code

L’équipe de PHP a publié plusieurs mises à jour de sécurité ce 22 octobre. Son avertissement ne laisse guère de place au doute : « vulnérabilités critiques d’exécution de code à distance : mettez à jour maintenant ». Une exécution de code à distance, ou RCE, peut permettre à un hacker de lancer des commandes sur un serveur sans disposer d’un accès légitime.

Les deux principales failles touchent la gestion de la mémoire et de l’état interne de PHP. Leur exploitation dépend toutefois de conditions techniques précises. Il ne s’agit donc pas d’une attaque universelle qui compromettrait automatiquement chaque site construit avec ce langage.

Les deux vulnérabilités critiques reposent sur des mécanismes différents :

• La première, référencée GHSA-w8hw-w9fx-j79w, exploite une corruption de mémoire provoquée lorsque PHP manque de mémoire pendant certaines opérations. Le programme peut alors conserver des données incomplètes avant de les réutiliser au moment de l’arrêt du processus ;
• La seconde, identifiée sous la référence GHSA-6wmf-4rv5-p3rp, repose sur un état global devenu obsolète. Une première opération laisse une information en mémoire, puis une autre requête la réutilise comme si elle était encore valide.

Dans les deux cas, un hacker doit réussir à déclencher une succession particulière d’opérations. Les avis officiels évoquent néanmoins un risque d’exécution de code, ce qui explique le niveau d’urgence retenu par le projet PHP.

Les correctifs publiés couvrent aussi plusieurs failles moins critiques. Elles comprennent un contournement des restrictions d’accès de PHP-FPM avec certaines adresses IPv6, une erreur dans la vérification des certificats TLS et un dépassement de mémoire dans le composant OpenSSL. Des problèmes affectant les archives Phar, le protocole SOAP et le pilote MySQL natif ont également été corrigés.

Le chiffre de 70 % ne désigne pas les sites vulnérables

PHP équipe une part considérable des sites dont le langage serveur est connu. Il se trouve notamment derrière WordPress, Drupal, Joomla et de nombreuses applications conçues sur mesure. Cette diffusion explique pourquoi une faille critique dans son moteur suscite rapidement une forte inquiétude.

Affirmer que 70 % d’Internet est menacé reste pourtant imprécis. Ce pourcentage mesure l’utilisation générale de PHP, et non la proportion de serveurs qui exécutent une version vulnérable. Il ne tient pas non plus compte des systèmes déjà corrigés, des configurations différentes ou des conditions nécessaires à chaque attaque.

Un site peut utiliser WordPress sans être directement exposé à ces deux failles. Selon l’analyse on-chain, le risque dépend de la version de PHP installée par l’hébergeur, des extensions actives et de la manière dont les requêtes sont traitées. Plusieurs sites hébergés sur une même infrastructure peuvent également partager un moteur PHP déjà mis à jour.

La situation est plus préoccupante pour les serveurs qui utilisent une branche ancienne et non prise en charge. Ces installations ne reçoivent plus les correctifs officiels. Elles peuvent donc cumuler les nouvelles vulnérabilités avec des failles découvertes au cours des années précédentes.

Une mise à jour et un redémarrage restent indispensables

Les administrateurs doivent installer la dernière version de sécurité disponible pour leur branche PHP. Une simple modification des fichiers ne suffit pas toujours : les services PHP-FPM, Apache ou les autres processus concernés doivent être redémarrés pour charger le moteur corrigé.

Un inventaire doit aussi couvrir les interfaces en ligne de commande, les tâches planifiées et les conteneurs. Un serveur peut en effet utiliser plusieurs versions de PHP en parallèle. Corriger celle du site principal ne protège pas nécessairement un ancien outil interne ou une image de conteneur rarement actualisée.

Les clients d’un hébergement mutualisé peuvent vérifier la version active dans leur espace d’administration ou demander confirmation à leur fournisseur. Ils ne disposent généralement pas des droits nécessaires pour appliquer eux-mêmes le correctif au système.

Aucune exploitation massive de ces deux failles n’a été établie dans les avis officiels consultés. Cette absence ne réduit toutefois pas l’urgence. La publication des détails techniques facilite leur étude par les chercheurs, mais aussi par les hackers. La mesure la plus sûre reste donc une mise à jour rapide, accompagnée d’une vérification des journaux du serveur pour repérer d’éventuels comportements inhabituels.