Histoire de PHP et faille PHP2Shell : pourquoi tant de sites sont concernés

En bref. PHP est né en 1994 comme un simple jeu d’outils pour afficher un CV en ligne. Plus de trente ans plus tard, il fait tourner environ sept sites sur dix dont on connaît le langage serveur. Fin octobre 2026, deux failles critiques baptisées « PHP2Shell » ont rappelé ce que cette omniprésence implique : une faille dans PHP, c’est une faille potentielle dans des millions de sites. La seule vraie protection est de mettre PHP à jour vers une version corrigée, ce que votre hébergeur ou votre prestataire doit pouvoir confirmer en quelques minutes.

Code source PHP et HTML affiché en couleurs sur un écran sombre, vu en perspective

1994-1998 : d’un CV en ligne à un vrai langage

Selon l’historique officiel de PHP, tout commence en 1994 avec Rasmus Lerdorf. Sa première version est un ensemble de programmes écrits en C, qu’il utilise pour suivre les visiteurs de son curriculum vitae en ligne. Il les appelle « Personal Home Page Tools », d’où le sigle PHP.

En juin 1995, il publie le code source : les développeurs peuvent l’utiliser et proposer des corrections. Une version réécrite, PHP/FI (pour « Forms Interpreter », l’interpréteur de formulaires), apparaît ensuite. Elle sait déjà lire des formulaires web, dialoguer avec des bases de données et s’insérer dans une page HTML. En mai 1998, d’après Netcraft cité par PHP, environ 60 000 domaines affichent un en-tête « PHP », soit à peu près 1 % des domaines d’Internet de l’époque.

En juin 1998, une équipe de développeurs annonce PHP 3, réécrit à partir de 1997 par Andi Gutmans et Zeev Suraski, avec Rasmus Lerdorf. Le langage prend alors son nom actuel, un acronyme récursif : « PHP: Hypertext Preprocessor ». Son atout : il est facile à étendre, avec un support de plus en plus large des bases de données, des protocoles et de la programmation orientée objet. Au plus fort de son succès, PHP 3 est installé sur environ 10 % des serveurs web d’Internet.

2000-2020 : le moteur Zend, puis la course à la performance

Pour tenir des applications plus complexes, Andi Gutmans et Zeev Suraski réécrivent le cœur du langage. Ce nouveau moteur, le Zend Engine (de leurs deux prénoms), est publié vers la mi-1999. PHP 4 s’appuie dessus et sort officiellement en mai 2000, avec de meilleures performances et la gestion des sessions HTTP. PHP 5 arrive en juillet 2004, avec un nouveau modèle objet.

La suite est plus discrète mais tout aussi importante. Un « PHP 6 », censé apporter une gestion approfondie de l’Unicode, est abandonné, et une partie de ses idées est reprise dans PHP 5.3 et 5.4. PHP 7.0, sorti en 2015, introduit un nouveau moteur et, selon la documentation officielle, des performances jusqu’à deux fois supérieures à PHP 5.6. PHP 8.0 suit en 2020 avec un compilateur JIT, des types plus stricts et une syntaxe modernisée. Le langage de 1994 n’a plus grand-chose à voir avec celui d’aujourd’hui.

Pourquoi PHP est partout en 2026

D’après W3Techs, au 31 octobre 2026, PHP est utilisé par 69,2 % des sites dont le langage serveur est connu. Parmi eux, on trouve des sites aussi différents que Facebook, Wikipédia ou WordPress.org. Cette présence s’explique par l’histoire : PHP est gratuit, facile à héberger, et de très nombreux logiciels de gestion de contenu et de boutiques en ligne sont écrits avec.

Autre chiffre à retenir, côté entreprises : toujours selon W3Techs, 26,4 % des sites PHP fonctionnent encore sous une version 7 et 7,6 % sous une version 5. Or le CERT-FR rappelle que l’éditeur n’assure plus le support des versions 5.x, 7.x, 8.0.x et 8.1.x. Autrement dit, au moins un site PHP sur trois tourne sur une version qui ne reçoit plus de correctifs de sécurité.

Octobre 2026 : les failles PHP2Shell

Le 20 octobre 2026, l’équipe de PHP annonce la publication imminente de deux correctifs pour des vulnérabilités critiques. Les correctifs sortent le 21 octobre. Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619, concernent la gestion de la mémoire du langage lui-même. Elles peuvent permettre à un attaquant d’exécuter du code sur un serveur, sans avoir de compte ni de mot de passe. Le CERT-EU leur attribue un score de gravité de 9,2 sur 10.

Le risque n’est pas théorique. Le CERT-FR constate des tentatives d’exploitation, et la CISA, l’agence américaine de cybersécurité, a ajouté les deux failles à son catalogue des vulnérabilités activement exploitées le 26 octobre. D’après la CISA, toutes les installations PHP qui servent des pages web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Faisceaux de câbles réseau bleus branchés sur des équipements de serveur dans l'obscurité

Comment corriger la faille, étape par étape

Bonne nouvelle : la solution existe et elle est connue. Voici les étapes, dans l’ordre.

Connaître sa version de PHP. Demandez-la à votre hébergeur ou à votre prestataire, ou consultez-la dans le panneau d’administration de votre hébergement. Sans cette information, impossible de savoir si vous êtes concerné.
Mettre à jour vers une version corrigée. Les versions qui corrigent les deux failles sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Il faut viser la version de la même branche que celle que vous utilisez. Sur un serveur géré par un hébergeur, ce sont des paquets mis à jour par ses soins : PHP précise que les distributions Linux avaient reçu les correctifs à l’avance.
Appliquer réellement la mise à jour. Une mise à jour n’est effective que lorsque les processus PHP ont été relancés. Demandez à votre hébergeur de vous le confirmer.
Si votre PHP est en fin de vie (8.1 et antérieurs), migrer. Ces versions ne recevront pas de correctif. Le CERT-FR recommande d’isoler les équipements concernés en attendant la migration, et la CISA va plus loin : mettre hors ligne ce qui ne peut pas être mis à jour.
En attendant, appliquer les mesures provisoires officielles. PHP et le CERT-FR en listent plusieurs (limiter la mémoire et la taille des envois de formulaires, désactiver le suivi de progression des envois de fichiers). Ce ne sont que des palliatifs : le CERT-FR précise que seule la mise à jour protège vraiment.
Surveiller. La CISA conseille de repérer les signes d’activité suspecte, comme des processus PHP qui lancent des commandes système ou téléchargent des outils. Un pare-feu applicatif (WAF) peut réduire le risque, sans remplacer la mise à jour.

Cinq questions à poser à votre hébergeur ou à votre prestataire

Quelle version de PHP fait tourner mon site, et à quelle date a-t-elle été mise à jour ?
Est-ce une version corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou plus récente) ?
Les processus PHP ont-ils bien été redémarrés après la mise à jour ?
Mon site utilise-t-il une version en fin de vie, et quel est le plan de migration ?
Qui surveille les journaux du serveur et me prévient en cas d’activité suspecte ?

Une troisième faille à surveiller

Le 23 octobre, PHP a publié un avis sur une troisième vulnérabilité, CVE-2026-115560, que les correctifs du 21 octobre ne corrigent pas. D’après la dernière annonce de PHP consultée le 1er novembre 2026, elle ne peut se produire que dans une combinaison de configuration et de code applicatif jugée peu probable. Un correctif est prévu dans la prochaine version régulière, et PHP suggère en attendant de désactiver l’option session.upload_progress.enabled. Demandez à votre prestataire de suivre ce point.

Pourquoi la cybersécurité devient un sujet de direction

Cette affaire illustre plusieurs tendances qui concernent tous les dirigeants, pas seulement les informaticiens.

Tout va plus vite. Le CERT-FR avait connaissance de preuves de concept dès le lendemain de la publication, et la CISA classait les failles comme exploitées cinq jours après. Le temps dont dispose une entreprise pour réagir se compte en jours.
L’IA entre dans la boucle. D’après l’Usine Digitale, ces deux failles ont été découvertes à l’aide de l’intelligence artificielle. Les outils qui aident les défenseurs à trouver des failles peuvent aussi aider les attaquants. Nous revenons sur ce sujet dans notre article sur l’IA et la vitesse des projets informatiques.
Une brique, des millions de conséquences. Le CERT-FR rappelle que PHP est utilisé dans de nombreux produits, et que beaucoup sont potentiellement concernés. Le NCSC néerlandais publie une liste de logiciels qui embarquent PHP. Même sans « avoir du PHP » en propre, votre entreprise peut en dépendre via un logiciel acheté.
Les institutions elles-mêmes ont réagi. Selon l’Usine Digitale, plusieurs sites publics ont basculé en maintenance préventive le 21 octobre pour appliquer le correctif.

Pour un dirigeant de PME, la leçon n’est pas technique. Elle tient en cinq réflexes de gouvernance : tenir l’inventaire de ses sites et applications, désigner un responsable pour chacun, planifier les mises à jour plutôt que les subir, tester ses sauvegardes et disposer d’un contrat de maintenance clair. Le calendrier de support de PHP aide à anticiper : selon la page officielle des versions supportées, le support de sécurité de la branche 8.2 s’arrête le 31 décembre 2026, celui de la 8.3 le 31 décembre 2027.

Questions fréquentes

Mon site WordPress est-il concerné ?

WordPress fonctionne avec PHP : ce qui compte est donc la version de PHP installée sur le serveur qui héberge votre site. Si elle est antérieure aux versions corrigées, le site est exposé, même si WordPress et ses extensions sont à jour. C’est l’hébergeur ou le prestataire qui doit agir sur PHP.

Un plugin de sécurité suffit-il ?

Non. Selon le CERT-FR, seule l’application de la mise à jour protège réellement. Un pare-feu applicatif peut offrir une protection partielle en attendant, d’après la CISA, mais il ne remplace pas la mise à jour.

Faut-il mettre son site hors ligne ?

Si vous ne pouvez pas mettre à jour rapidement, ou si votre PHP est en fin de vie, la CISA recommande de mettre les systèmes PHP hors ligne jusqu’à leur correction. À vous de mesurer l’impact sur votre activité, avec votre prestataire.

Faut-il abandonner PHP ?

Pas nécessairement. Aucun langage n’est à l’abri de failles : la question est de savoir si le logiciel est maintenu et mis à jour à temps. Un site sur une version supportée et suivie de près est mieux protégé qu’un site récent jamais mis à jour.

Un site à mettre à jour ou à sécuriser ?

Décrivez votre besoin en quelques questions rapides : nous revenons vers vous sous 24 h, sans engagement.

Parlons de votre site →

Pour aller plus loin, découvrez notre accompagnement en maintenance et infogérance web, notre page sur la conformité et la protection des données et notre offre de développement web et logiciel sur mesure.