Faille critique PHP : votre site a-t-il bien reçu la mise à jour ?Faille critique PHP : votre site a-t-il bien reçu la mise à jour ?

Le projet PHP a publié le 21 octobre 2026 quatre versions qui corrigent deux failles critiques et demande une mise à jour immédiate. PHP est un langage de programmation qui fait tourner des sites : le message ci-dessous sert justement à demander à votre hébergeur si le vôtre l'utilise et s'il a reçu les corrections.

• Toutes les installations PHP qui servent des pages web sont concernées.
• Sur mod_php, le projet a démontré une attaque sans connexion à un compte.
• Demandez une confirmation écrite de la mise à jour.

Les versions publiées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles d'« exécution de code à distance » : un attaquant peut faire exécuter ses instructions sur le serveur sans s'identifier. Le projet signale un risque particulièrement élevé avec mod_php, une façon de faire fonctionner PHP sur un serveur. Dans l'attaque démontrée, une requête sans authentification déclenche le problème avant même le démarrage du code de l'application.

Voici un message à adapter, puis à envoyer aujourd'hui. Ajoutez le nom du site concerné, ou la liste de vos sites. Deux réponses peuvent confirmer la correction : une version publiée par PHP ou une référence de mise à jour fournie par le prestataire. Dans les deux cas, demandez que la confirmation couvre les deux failles.

« Bonjour, le projet PHP a publié le 21 octobre des correctifs pour deux failles critiques. Pouvez-vous confirmer si notre site utilise PHP et si les deux failles sont corrigées sur l'installation qui le fait fonctionner ? Merci de préciser la version utilisée ou la référence du correctif fourni par l'hébergeur. Si l'intervention reste à faire, pouvez-vous nous indiquer quand elle est prévue et nous confirmer sa réalisation ? »

Écrivez à la personne qui gère l'hébergement. Si vous ne savez pas qui c'est, partez de votre contact habituel pour le site et demandez-lui de prendre le relais. Si votre contrat passe par une agence, adressez-lui la demande et laissez-la coordonner la réponse avec l'hébergeur.

Pour votre entreprise, la bonne question n'est pas de savoir réciter ces numéros. C'est de faire confirmer que votre installation a reçu les corrections. Une publication chez PHP et une installation chez votre hébergeur, ce sont deux étapes différentes.

PHP vise toutes les installations qui répondent aux demandes du web. Vous pouvez laisser les noms des configurations à votre prestataire : le message lui donne déjà la question à traiter. Inutile de passer un examen de serveur pour demander une intervention.

Les failles peuvent être exploitées sans connexion à un compte. Pour cet échange, cherchez donc une réponse sur la mise à jour de PHP. C'est ce point précis que votre interlocuteur doit confirmer pour votre site.

Ce message demande un résultat, pas un cours d'informatique. Vous cherchez à obtenir une confirmation d'installation, ou une intervention programmée avec un responsable identifié. Un « on s'en occupe » peut ouvrir l'échange ; demandez ensuite la date prévue et la confirmation une fois le travail terminé.

Si la réponse reste vague, reprenez simplement la question centrale : les deux failles sont-elles corrigées sur l'installation qui fait fonctionner votre site ? Les explications qui suivent vous aideront à comprendre les réponses sur les paquets, les réglages provisoires ou les anciennes versions.

Les correctifs avaient été transmis en amont aux distributions Linux et aux fournisseurs qui assurent un support de longue durée. PHP recommande de demander à son fournisseur s'il propose des paquets actualisés. Un paquet, ici, c'est la version préparée pour son environnement. Votre interlocuteur peut donc vous répondre avec sa référence de mise à jour.

Et si la réponse parle seulement de réglages temporaires ? Demandez la date d'installation du correctif. PHP explique qu'aucun contournement ne protège complètement l'installation : ces ajustements limitent certaines attaques possibles, mais laissent des possibilités d'exploitation. La solution sûre reste la mise à jour.

Vous avez ainsi une suite concrète à donner à chaque réponse. Un paquet corrigé appelle une confirmation d'installation. Des réglages d'attente appellent une date pour appliquer la correction.

Le projet PHP a arrêté le suivi des branches 8.1 et antérieures. Face à ces failles, son équipe de sécurité a tout de même préparé des corrections minimales pour PHP 7.4, 8.0 et 8.1. Elles sont destinées aux équipes qui compilent PHP elles-mêmes, c'est-à-dire qui fabriquent leur installation à partir du code source.

Pour les autres installations, PHP indique qu'il faut rejoindre une version encore suivie. Demandez à votre prestataire de distinguer la correction de cette alerte et le changement de version à organiser. Vous saurez ainsi ce qui est traité tout de suite et ce qui doit être programmé.

PHP 8.2 a aussi une date de sortie du suivi : le 31 décembre 2026. Après cette date, le projet ne lui fournira plus de correctifs de sécurité. Si votre site utilise cette branche, faites programmer la suite dès maintenant. Le calendrier mérite sa place dans la réponse.

Une fois la correction confirmée, profitez de cet échange pour fixer une règle simple avec votre prestataire. Qui reçoit les annonces de sécurité ? Qui décide et applique les mises à jour ? Comment êtes-vous informé qu'une intervention est terminée ?

Conservez la confirmation avec les informations de maintenance du site et demandez quand son prochain changement de version sera préparé. Vous aurez un point de départ clair lors du prochain échange. Le bénéfice pour vous : un responsable identifié et une prochaine échéance connue.

Pour votre prestataire, les références sont l'avis de sécurité du projet PHP et les deux avis techniques publiés sur son dépôt GitHub. Ils correspondent à CVE-2026-109618, référence GHSA-w8hw-w9fx-j79w, et à CVE-2026-109619, référence GHSA-6wmf-4rv5-p3rp. De votre côté, le geste tient dans le message et son suivi.

• PHP: Hypertext Preprocessor — Security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)
• GHSA-w8hw-w9fx-j79w · php/php-src
• GHSA-6wmf-4rv5-p3rp · php/php-src