Failles PHP : le casse-tête qui menace l’Internet mondial
La semaine dernière, un client m’appelle en panique. Son site de vente en ligne affiche une page blanche depuis deux heures. Je me connecte, je jette un œil aux logs, et là je vois exactement ce que je redoutais : une salve de requêtes bizarre sur un vieux script PHP planqué dans un sous-dossier que personne n’avait touché depuis 2019. Les failles PHP, encore elles. Sauf que cette fois, ce n’est pas juste mon client dans le pétrin : c’est potentiellement une bonne partie d’Internet qui tremble. Et pour être honnête, ça ne me surprend qu’à moitié.
PHP2Shell : la faille PHP qui rend les experts marteaux
D’après ce que j’ai lu sur 01net, une nouvelle famille de failles baptisée PHP2Shell sème la pagaille un peu partout. Le problème, mine de rien, ce n’est pas tant la faille elle-même que son invisibilité. PHP est partout. Il est dans ton blog, dans ton intranet, dans le site de la mairie, dans la page de suivi de colis de ton transporteur préféré, et même dans des trucs que tu ne soupçonnes pas, comme le panneau d’affichage numérique de ta boulangerie qui tourne sous un vieux CMS à moitié abandonné.
Autant dire que cartographier l’ensemble des installations PHP vulnérables sur la planète, c’est comme essayer de compter les miettes dans un sac de chips. Techniquement possible. En pratique, tu abandonnes au bout de trois minutes. Les experts eux-mêmes le disent : ils n’arrivent pas à déterminer où PHP se cache réellement. Et c’est précisément là que le bât blesse, parce qu’on ne peut pas patcher ce qu’on ne voit pas.
Résultat : des sites publics se mettent carrément hors ligne par mesure de précaution. Je comprends le réflexe, hein. Mieux vaut couper le service que se faire trouer la boutique. Mais avouons-le, c’est un peu comme éteindre le disjoncteur général parce qu’une ampoule grésille. Ça règle le symptôme, pas la cause.
Pourquoi ces failles PHP sont un vrai casse-tête pour tout le monde
Je vais être franc : je ne suis pas certain à 100% que PHP2Shell soit la catastrophe annoncée. J’ai vu tellement d’alertes sensationnalistes ces quinze dernières années que j’ai appris à me méfier. Mais d’après mon expérience en atelier, quand une faille touche PHP, elle touche tout le monde, du petit artisan au géant du e-commerce. Et ça, personne ne peut le nier.
Le vrai casse-tête, il est triple. D’abord, PHP est souvent installé par-dessus, oublié, empilé. Un serveur qui héberge trois applications, chacune avec sa version de PHP, c’est mon quotidien. Ensuite, les dépendances : les bibliothèques tierces, les plugins, les thèmes, tout ce petit monde communique et propage la faille sans que personne ne s’en rende compte. Enfin, il y a le facteur humain. Le stagiaire qui a déployé un site en 2018 et qui est parti depuis, le prestataire qui a disparu dans la nature, l’hébergeur qui ne répond plus.
Bref, on se retrouve avec un patch à appliquer sur des systèmes dont on ne connaît même pas l’inventaire complet. Autant dire que la gestion de crise ressemble davantage à une partie de cache-cache qu’à une intervention chirurgicale.
- Des serveurs qui font tourner plusieurs versions de PHP en parallèle, sans documentation.
- Des CMS abandonnés qui continuent de servir des pages en production.
- Des hébergeurs mutualisés incapables de dire précisément quelle version tourne sur quel compte.
- Des scripts oubliés dans des sous-dossiers que même Google a oubliés.
Mon coup de gueule sur la gestion des mises à jour
Là où je décroche avec les experts, c’est quand ils pointent du doigt la complexité technique. Pour moi, le vrai problème c’est la culture de la procrastination. J’ai vu des dizaines de fois des boîtes repousser une mise à jour PHP « parce que ça marche comme ça, ne touche à rien ». Sauf que ça ne marche plus très bien quand une faille sort. Et évidemment, la semaine où ça pète, tout le monde appelle le technicien indépendant en urgence. Devine qui.
Mine de rien, la mise à jour de la semaine dernière sur Windows n’a rien arrangé. Un serveur qui héberge les deux, un client qui redémarre sa machine au mauvais moment, et hop, la petite couche de chaos en plus. Merci Microsoft. C’est pas comme si on manquait déjà de pain sur la planche.
Ce que je fais concrètement en atelier face aux failles PHP
Quand un client m’appelle pour un site suspect, je ne commence pas par paniquer. Je commence par l’inventaire. Je liste toutes les versions de PHP installées, tous les scripts qui traînent, toutes les dépendances. C’est long, c’est chiant, mais c’est la seule façon de savoir où on met les pieds. Ensuite, je patche. Et là, deuxième étape désagréable : je patche encore, parce qu’il y a toujours un truc qu’on a loupé.
Mon conseil numéro un, celui que je répète à chaque intervention : ne jamais laisser une version de PHP en fin de vie tourner en production. PHP 7.4 est mort depuis un moment, et pourtant je croise encore des serveurs qui tournent dessus en 2025. Ça me fait grincer des dents à chaque fois.
- Inventorier tous les environnements PHP avant de toucher quoi que ce soit.
- Mettre à jour PHP en priorité, avant même les plugins.
- Supprimer les scripts et dossiers oubliés qui ne servent plus.
- Surveiller les logs d’accès pour repérer les scans ciblés.
- Tester en local avant de déployer, évidemment, mais tester quand même.
Pour être honnête, la meilleure défense reste la veille. Je surveille les annonces de failles PHP comme d’autres lisent le journal le matin. Un site qui n’est pas mis à jour, c’est une porte ouverte avec un panneau « entrez, c’est gratuit ».
L’anecdote du serveur oublié
Il y a deux ans, j’ai récupéré un client dont le site tournait sur PHP 5.6. Oui, 5.6. Une relique. Personne ne savait qui l’avait installé, ni pourquoi. Le site fonctionnait, donc personne ne touchait. Sauf qu’un jour, il a commencé à envoyer des mails de spam à tout le carnet d’adresses. La faille PHP avait été exploitée pendant des semaines sans que personne ne remarque rien. On a tout reconstruit à neuf. Histoire de repartir sur des bases saines. Depuis, ce client me paie une bière chaque année à la date anniversaire du dépôt de bilan évité. C’est ma petite fierté.
Faut-il couper son site par précaution ?
La question mérite d’être posée, parce que certains sites publics ont choisi cette option radicale. Mettre hors ligne par précaution, c’est un choix qui se défend quand on héberge des données sensibles ou quand on n’a aucune visibilité sur son infrastructure. Mais pour un site vitrine qui ne stocke rien, franchement, c’est disproportionné.
Mon avis tranché : la coupure doit être le dernier recours, pas le premier réflexe. Un site hors ligne, c’est du chiffre d’affaires perdu et une image de marque écornée. Mieux vaut investir deux heures à faire un audit sérieux que de tout couper pendant une semaine en espérant que le problème passe. Mine de rien, les attaquants ne prennent pas de vacances pendant que ta vitrine est fermée.
Ceci dit, je reconnais que pour les collectivités et les grosses structures, la prudence est compréhensible. La responsabilité juridique n’est pas la même. Chacun son combat.
Failles PHP : ce que j’en retiens vraiment
Au final, cette histoire de PHP2Shell me conforte dans une conviction : le problème n’est pas PHP. Le problème, c’est la façon dont on l’installe, l’oublie et le laisse tourner pendant des années sans surveillance. PHP est un outil formidable, omniprésent et gratuit, mais il ne se patche pas tout seul. C’est notre boulot, à nous les techniciens, de faire le ménage régulièrement.
Si vous hébergez un site, une seule action à faire aujourd’hui : vérifier votre version de PHP. C’est gratuit, ça prend cinq minutes, et ça peut vous éviter une nuit blanche. Et si vous ne savez pas où regarder, appelez quelqu’un qui sait. De préférence avant la catastrophe, pas pendant.
La source de cet article, c’est le papier de 01net sur les failles PHP : Failles PHP, pourquoi c’est un vrai casse-tête pour l’Internet mondial. Une lecture que je recommande à tous mes clients, ne serait-ce que pour leur faire peur un peu. Des fois, la peur, c’est le meilleur argument pour mettre à jour.
Source : article original
