PHP équipe 70 % du Web, deux failles donnent accès aux serveurs sans mot de passe

Une faille PHP capable de contourner l’authentification suffit à transformer un serveur web en point d’entrée direct pour un attaquant. L’alerte publiée le 21 octobre 2026 prend une dimension particulière : des administrations et services publics ont déjà coupé certains sites, tandis que l’IA a contribué à démontrer la manière dont les vulnérabilités pouvaient être exploitées.

Deux failles critiques dans un langage omniprésent

Le PHP Foundation et le FBI ont alerté sur deux vulnérabilités critiques affectant PHP, le langage utilisé par environ 70 % des sites web dans le monde. Cette proportion inclut aussi bien des sites développés sur mesure que des plateformes très répandues, notamment celles qui s’appuient sur des systèmes de gestion de contenu.

Le risque décrit dépasse celui d’une simple fuite d’informations. Exploitées dans certaines conditions, les failles pourraient permettre à un attaquant d’accéder à un serveur sans fournir de mot de passe ni franchir le mécanisme d’authentification prévu. Une fois à l’intérieur, il pourrait consulter ou modifier des données, installer des outils malveillants, désactiver des protections ou utiliser la machine comme relais vers d’autres systèmes.

Cette dernière possibilité est particulièrement préoccupante pour les organisations publiques et les entreprises interconnectées. Un serveur web compromis ne contient pas nécessairement les informations les plus sensibles, mais il peut disposer d’identifiants techniques, de connexions à des bases de données ou d’un accès au réseau interne. La faille peut alors devenir le premier maillon d’une attaque plus large.

La présence de PHP ne signifie toutefois pas que 70 % des sites web sont automatiquement vulnérables. L’exposition dépend de la version utilisée, de la configuration du serveur, des extensions installées et des mesures de protection en place. Le chiffre illustre surtout l’ampleur potentielle du correctif à déployer.

L’IA a servi à tester le scénario d’attaque

Selon les informations rapportées par l’Associated Press, OpenAI et la société de cybersécurité Wiz ont utilisé des outils d’intelligence artificielle pour analyser les vulnérabilités et déterminer comment elles pouvaient être exploitées. L’IA a également servi à tester les correctifs proposés, afin de vérifier qu’ils bloquaient bien les chemins d’attaque identifiés.

Cette intervention ne signifie pas que l’IA a découvert seule les failles dans le code de PHP. La fondation indique que le problème était connu depuis au moins 2024. L’apport des modèles consiste plutôt à accélérer certaines étapes particulièrement longues de la recherche en sécurité : parcourir de grandes quantités de code, repérer des interactions inhabituelles entre composants, formuler des scénarios d’exploitation et multiplier les tests sur des versions corrigées.

La nuance est importante. Une vulnérabilité peut être repérée sans que sa gravité ou son exploitabilité soient immédiatement établies. Entre un comportement suspect et une attaque fonctionnelle, les chercheurs doivent comprendre les conditions nécessaires, construire une preuve de concept et vérifier que le correctif ne laisse pas subsister une variante exploitable.

Les modèles d’IA peuvent réduire ce délai, mais leurs résultats doivent encore être validés par des spécialistes. Une suggestion de code ou un scénario d’attaque erroné peut conduire à une fausse alerte. À l’inverse, une analyse automatisée suffisamment précise peut révéler un enchaînement que des tests classiques n’auraient pas couvert.

Une vulnérabilité ancienne, une exposition actuelle

Le fait que le problème soit connu depuis 2024 souligne la difficulté de la gestion des failles dans un projet largement déployé. L’identification d’un défaut n’entraîne pas immédiatement une correction publique : il faut confirmer le problème, mesurer les versions concernées, préparer un correctif, coordonner les avis de sécurité et laisser aux utilisateurs le temps de mettre à jour leurs installations.

Cette période de coordination limite le risque de divulgation prématurée, mais elle crée aussi une fenêtre durant laquelle de nombreux systèmes restent exposés. Plus le logiciel est répandu, plus la publication du correctif déclenche une course entre les administrateurs qui cherchent à protéger leurs serveurs et les attaquants qui tentent d’industrialiser l’exploitation.

Des sites publics mis hors ligne pour limiter le risque

Des organismes situés au Royaume-Uni, en Finlande et au Japon ont mis certains sites hors ligne pendant l’application des correctifs. Cette décision traduit une approche prudente : lorsqu’un service public ne peut pas être sécurisé rapidement, son retrait temporaire d’Internet réduit la surface d’attaque.

La mesure a toutefois un coût concret. Elle peut empêcher l’accès à des démarches administratives, perturber la consultation de documents ou interrompre des services destinés aux citoyens et aux entreprises. Dans certains cas, une page statique ou un canal de secours peut être maintenu ; dans d’autres, la mise hors ligne devient le seul moyen de limiter une compromission en cours.

La situation rappelle aussi que la sécurité d’un site dépend rarement d’un seul acteur. Un organisme peut administrer son contenu tout en externalisant l’hébergement, la maintenance ou certains composants logiciels. La correction de PHP doit alors être coordonnée avec plusieurs prestataires, parfois sur des infrastructures qui ne peuvent pas être redémarrées immédiatement.

Le correctif ne se résume pas à une mise à jour

Les administrateurs concernés doivent d’abord identifier les versions de PHP utilisées, y compris celles installées sur des serveurs secondaires, des environnements de test ou des applications oubliées. La mise à jour vers une version corrigée constitue l’étape prioritaire, mais elle doit être accompagnée d’une vérification des journaux et des accès.

Si un serveur a pu être exposé, installer le correctif ne suffit pas à effacer les traces d’une intrusion antérieure. Il faut rechercher des connexions inhabituelles, des fichiers récemment modifiés, des comptes créés sans justification et des échanges anormaux avec d’autres systèmes. La rotation des mots de passe et des clés d’accès peut également s’imposer, notamment si le serveur détenait des identifiants réutilisables ailleurs.

Les organisations qui ne peuvent pas corriger immédiatement leurs installations devront réduire l’exposition : filtrage réseau, désactivation temporaire de composants non indispensables, restriction des accès d’administration et surveillance renforcée. Ces mesures ne remplacent pas le correctif, mais peuvent limiter le risque pendant la période de transition.

Le prochain indicateur sera le rythme des mises à jour

La gravité réelle de l’alerte se mesurera dans les prochaines semaines à travers trois indicateurs : l’existence éventuelle d’un exploit public, le nombre de serveurs encore exposés et la capacité des hébergeurs à appliquer les versions corrigées à grande échelle. La mise hors ligne de sites au Royaume-Uni, en Finlande et au Japon montre déjà que la vulnérabilité a des conséquences opérationnelles, pas seulement théoriques.

Pour les responsables informatiques, le prochain jalon est immédiat : inventaire des versions, déploiement des correctifs et analyse des journaux depuis 2024 si une exposition est plausible. Pour l’écosystème PHP, l’épisode fournira aussi un test grandeur nature de l’usage de l’IA en sécurité : non pas comme substitut aux chercheurs, mais comme accélérateur de l’analyse et de la validation des défenses.