Faille PHP : Pourquoi le pire scénario semble moins probable

Internet vient d’éviter un scénario potentiellement catastrophique. Le 21 octobre 2026, les développeurs de PHP ont publié des correctifs d’urgence pour deux failles de sécurité critiques capables de permettre à un pirate d’exécuter du code à distance sur un serveur, sans même devoir se connecter. La bonne nouvelle, c’est que les premières analyses nuancent le risque d’une attaque massive et instantanée. La moins bonne, c’est que des millions de sites reposent encore sur des environnements PHP vulnérables.

Et non, il ne s’agit pas d’un problème réservé à quelques informaticiens barbus enfermés dans une cave. PHP fait tourner une partie considérable du Web, notamment WordPress, le système utilisé par une foule de blogs, de médias, de boutiques en ligne et de sites professionnels.

PHP, le moteur discret qui fait tourner votre site

Pour comprendre le problème, il faut savoir que PHP n’est pas un logiciel que l’on installe simplement sur son ordinateur. C’est un langage de programmation exécuté principalement sur les serveurs web. Lorsque vous consultez un article, par exemple, PHP peut récupérer son contenu dans une base de données, assembler la page et transmettre le résultat à votre navigateur.

WordPress dépend directement de ce mécanisme. Même si votre site utilise un thème récent, des extensions à jour et un mot de passe d’administrateur particulièrement compliqué, il reste dépendant de la sécurité de PHP sur le serveur qui l’héberge.

C’est précisément ce qui rend ces vulnérabilités préoccupantes : elles touchent le moteur lui-même, et pas seulement une extension douteuse téléchargée un soir de solitude numérique.

Deux failles critiques qui ouvrent une porte inattendue

Les deux vulnérabilités ont été identifiées sous les références CVE-2026-109618 et CVE-2026-109619. Elles ont reçu un score de gravité de 9,2 sur 10 selon l’échelle CVSS 4.0. Autrement dit, les spécialistes ne les ont pas classées dans la catégorie des petits désagréments que l’on peut remettre à lundi.

La première faille concerne la gestion de la mémoire lorsque PHP rencontre une erreur d’allocation. En simplifiant, le logiciel peut laisser des données dans un état incohérent avant de poursuivre certaines opérations de nettoyage. Un attaquant capable de provoquer les bonnes conditions pourrait exploiter ce comportement pour exécuter du code malveillant.

La seconde repose également sur un problème de gestion mémoire. Dans certaines circonstances, PHP peut conserver une référence vers une zone mémoire qui a déjà été libérée. Cette situation, connue sous le nom de « use-after-free », peut ouvrir la voie à une exécution de code arbitraire.

Pourquoi est-ce si grave ? Parce qu’une exécution de code à distance peut permettre à un pirate de dépasser les simples limites d’une page web. Selon les droits accordés au processus compromis et la configuration du serveur, il pourrait modifier des fichiers, installer des composants malveillants, tenter de récupérer des données ou rebondir vers d’autres ressources.

Il ne faut toutefois pas confondre possibilité technique et compromission automatique. Une faille critique ne signifie pas que tous les sites concernés ont déjà été piratés.

Pourquoi le pire scénario semble moins probable

Les premières alertes ont suscité de fortes inquiétudes, au point que plusieurs organisations ont préféré couper temporairement certains services accessibles depuis Internet. Des sites institutionnels ont notamment été mis hors ligne par précaution, le temps de déterminer comment appliquer les correctifs.

Les analyses publiées après la sortie des mises à jour apportent toutefois une nuance importante. Toutes les configurations PHP ne présentent pas le même niveau de risque pratique.

Les serveurs Apache utilisant l’ancien module intégré mod_php sont considérés comme particulièrement exposés : une exploitation complète a été démontrée dans cette configuration, avec des réglages par défaut.

Avec PHP-FPM, un mécanisme fréquemment utilisé pour exécuter PHP séparément du serveur web, la situation est plus complexe. Frandroid souligne que certaines conditions particulières sont nécessaires et que les scénarios d’exploitation ne sont pas identiques selon l’architecture.

Mais attention à ne pas traduire cette nuance par « PHP-FPM est protégé ». Le projet PHP inclut explicitement PHP-FPM dans les environnements concernés. Des chercheurs de Datadog ont également reproduit une exploitation à distance sans authentification sur une version récente de PHP vulnérable.

En clair, la configuration du serveur peut influencer le niveau de risque, mais elle ne remplace pas l’installation du correctif.

Les correctifs sont disponibles, mais tous les sites ne sont pas sauvés

Le 21 octobre, l’équipe PHP a publié les versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les administrateurs utilisant ces branches doivent installer la mise à jour correspondante sans attendre.

Le piège se trouve du côté des installations anciennes. Les versions de PHP antérieures à 8.2 ne bénéficient plus du support officiel du projet principal. Elles ne reçoivent donc pas automatiquement les nouveaux correctifs publiés pour les branches maintenues.

Certains fournisseurs peuvent toutefois proposer des correctifs rétroportés pour des versions anciennes. Il faut alors obtenir une confirmation précise de l’hébergeur : le simple affichage d’un ancien numéro de version ne permet pas toujours de savoir si un correctif spécifique a été intégré.

Les recommandations des organismes de cybersécurité sont claires : identifier les installations concernées et appliquer les mises à jour dès que possible. Les mesures temporaires, comme désactiver certaines fonctions PHP, ne constituent pas une protection complète contre les deux vulnérabilités.

Pour un propriétaire de site WordPress, la première démarche consiste donc à contacter son hébergeur et à lui demander quelle version de PHP est réellement utilisée, si les correctifs ont été appliqués et quelle migration est recommandée.

Votre site WordPress est-il concerné ?

Si vous gérez votre propre hébergement, commencez par consulter la rubrique « Outils », puis « Santé du site » et « Informations » dans WordPress. La section consacrée au serveur indique généralement la version de PHP utilisée par le site.

Mais ne vous arrêtez pas à ce numéro. Si vous utilisez un hébergement mutualisé, un VPS ou une infrastructure administrée par un prestataire, demandez-lui de confirmer l’application du correctif sur l’environnement qui exécute réellement votre site.

Une mise à jour majeure de PHP doit aussi être préparée avec soin. Les thèmes et extensions anciens peuvent présenter des incompatibilités. Il est donc préférable de réaliser une sauvegarde complète, de vérifier les composants utilisés et, si possible, de tester la migration avant de la déployer sur un site important.

Enfin, une mise à jour ne permet pas de conclure qu’aucune intrusion n’a eu lieu auparavant. Si vous constatez des fichiers inconnus, des comptes administrateurs suspects ou des comportements inhabituels, une vérification de sécurité complémentaire est nécessaire.

Le Web n’est pas condamné, mais les retardataires sont prévenus

Ces deux failles rappellent une réalité peu spectaculaire, mais essentielle : la sécurité d’un site ne dépend pas uniquement de son mot de passe ou de son plugin de protection. Elle repose aussi sur des composants techniques invisibles, parfois oubliés pendant des années.

La complexité de l’exploitation peut éloigner le scénario d’un piratage massif instantané. Elle ne fait cependant pas disparaître le problème, surtout lorsque des sites restent exposés sur des versions qui ne reçoivent plus de correctifs officiels.

La bonne nouvelle, c’est que des mises à jour existent. La mauvaise, c’est que certains administrateurs découvriront peut-être leur version de PHP au moment précis où ils auraient préféré ne pas avoir de mauvaise surprise.

Si votre site tourne encore sur une vieille version de PHP, ce n’est donc pas le moment de croiser les doigts en espérant que les pirates aient autre chose à faire. Il est temps de vérifier, de corriger et de préparer la suite.