Deux failles critiques dans PHP : les sites des entreprises doivent vérifier leur hébergement

Ce qui a été annoncé le 21 octobre

Le 21 octobre 2026, l’équipe du langage PHP a publié un avis de sécurité exceptionnel concernant deux vulnérabilités critiques, identifiées CVE-2026-109618 et CVE-2026-109619. Elles touchent le fonctionnement interne du moteur PHP, utilisé pour servir des pages et applications Web. Dans certaines configurations, elles peuvent permettre à une personne non authentifiée de provoquer des dysfonctionnements, de consulter des données en mémoire ou d’exécuter du code sur un serveur vulnérable. Il ne s’agit donc pas simplement d’un problème de thème ou d’extension de site.

Le projet PHP indique que toutes les installations de PHP servant des requêtes Web doivent être considérées comme concernées par l’évaluation du risque, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé particulièrement élevé pour certaines configurations Apache avec mod_php, où un scénario d’exploitation a été démontré avant même l’exécution du code de l’application. Cette gravité ne signifie pas que chaque site PHP a été compromis : la configuration, la version et les mesures déjà en place restent déterminantes.

Quels correctifs sont disponibles ?

Les versions corrigées publiées le 21 octobre sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les responsables techniques doivent identifier la branche réellement utilisée par le site, puis appliquer la version corrigée correspondante. PHP 8.1 et les branches plus anciennes ne reçoivent plus de mises à jour ordinaires du projet PHP. Certains éditeurs de distributions Linux et fournisseurs de support longue durée peuvent néanmoins intégrer des correctifs rétroportés : dans ce cas, le numéro de version seul ne suffit pas à conclure et il faut demander une preuve du correctif appliqué.

Le projet PHP précise qu’il n’existe pas de mesure d’atténuation complète autre que la mise à jour. Un pare-feu applicatif peut réduire l’exposition, mais ne remplace pas le correctif. Les équipes de Cloudflare déclarent avoir déployé des règles de protection par défaut sur les offres disposant de leur WAF, y compris Free, et avoir observé des tentatives d’attaque contre leur réseau. Cela ne permet pas d’affirmer que tous les sites exposés ont subi une intrusion ni qu’un pare-feu garantit leur sécurité.

Pour un artisan, un commerçant ou une PME, quel est le risque concret ?

Un site vitrine, une boutique en ligne ou un espace client reposant sur PHP peut être concerné même si son propriétaire n’a jamais installé lui-même le langage. C’est fréquemment l’hébergeur, l’agence Web ou le prestataire de maintenance qui gère ce composant. Le risque potentiel inclut l’indisponibilité du site, la compromission du serveur et l’exposition de données. L’impact réel dépend de l’architecture et des droits accordés au processus PHP.

À l’inverse, un site entièrement statique ou une application exécutée sans moteur PHP n’est pas touché par ces failles PHP en tant que telles. La présence d’un CMS connu ou d’un nom d’hébergeur ne prouve pas à elle seule la vulnérabilité. Pour un site géré par un prestataire, il faut obtenir une réponse vérifiable plutôt que supposer que « tout est automatique ». Cette distinction évite de payer une intervention inutile sur un site qui n’utilise pas PHP.

Les cinq vérifications à demander à son prestataire

• Identifier si le site et ses sous-domaines exécutent réellement PHP, et sur quel environnement : mutualisé, VPS, conteneur ou service managé.
• Relever la branche PHP et la preuve du correctif de sécurité installé, y compris les éventuels correctifs rétroportés par la distribution.
• Sauvegarder et prévoir un retour arrière avant l’intervention ; programmer une mise à jour rapide, puis redémarrer les processus concernés si nécessaire.
• Après intervention, tester les formulaires, l’espace d’administration, le paiement s’il existe, les emails transactionnels et les journaux d’erreur.
• Demander un compte rendu daté indiquant les composants mis à jour, les tests exécutés et les éléments qui restent à vérifier.

Ce qu’il ne faut pas faire

Ne pas croire qu’une mise à jour du thème, des extensions ou du contenu du site corrige automatiquement une faille du moteur PHP. Ne pas désactiver des protections de sécurité pour faire passer un test. Ne pas publier publiquement une page phpinfo contenant des détails de configuration, et ne pas lancer d’outils d’exploitation trouvés sur Internet pour « vérifier » un site client. La priorité est l’inventaire, l’application du correctif et la vérification du bon fonctionnement.

Si l’hébergeur administre entièrement la plateforme, une demande d’assistance ciblée suffit souvent : « Notre site utilise-t-il PHP et les correctifs des CVE-2026-109618 et CVE-2026-109619 sont-ils appliqués ? Pouvez-vous confirmer la date et la version ou le correctif fournisseur ? » Cette demande ne suppose ni accès administrateur au serveur ni manipulation risquée par le propriétaire du site.

Ce qui reste à établir pour chaque entreprise

Les sources officielles confirment la publication des correctifs et la gravité technique. Elles ne fournissent pas la liste des sites français touchés, ne prouvent pas que le site d’un lecteur est vulnérable et ne permettent pas de mesurer ici le nombre de compromissions réussies. Cloudflare rapporte du trafic d’attaque, ce qui est distinct d’une intrusion confirmée. AXDIA n’a pas testé les serveurs de ses lecteurs dans le cadre de cette veille.

Pour les petites entreprises, la conclusion opérationnelle est claire : faire confirmer rapidement la version PHP et la correction, sans céder à la panique ni considérer une protection réseau comme une réparation définitive. Le contrôle doit être réalisé par une personne autorisée à administrer le site et consigné avec une date et des résultats vérifiables.