Internet : le cauchemar PHP est-il vraiment terminé ? Ce qu'il faut savoir

Un jour après que deux bugs dans PHP ont poussé des gouvernements à se précipiter pour débrancher leurs sites web, le correctif est disponible, les attaquants frappent sans relâche, et beaucoup de gens se posent la même question : puis-je utiliser Internet sans m'inquiéter, ou dois-je me cacher sous le lit jusqu'à la semaine prochaine ?

La réponse courte est qu'Internet n'a pas cessé de fonctionner, et que pour la plupart des gens, le risque concerne les sites web qu'ils visitent, pas leurs propres téléphones ou ordinateurs portables. La réponse longue comporte quelques réserves qu'il vaut la peine de connaître.

Rappel rapide : PHP est le logiciel qui fonctionne en arrière-plan sur environ 70 % des sites web dont le langage côté serveur est connu, et les deux failles, surnommées PHP2Shell, permettent à un inconnu de prendre le contrôle d'un serveur vulnérable sans se connecter.

Est-ce corrigé ?

Alors, l'exploit est-il corrigé ? Oui, en grande partie. PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 mercredi, selon ses notes de version. « Il n'existe pas de mesures d'atténuation complètes, la mise à jour est le seul choix sûr. » Jeudi, PHP n'avait publié aucun correctif de suivi.

Un correctif n'aide toutefois qu'une fois qu'il est installé. PHP ne se met pas à jour tout seul, donc chaque société d'hébergement, service informatique et propriétaire de site web individuel doit l'appliquer sur ses propres serveurs, puis redémarrer le logiciel pour qu'il prenne effet.

En d'autres termes, le correctif existe, mais cela ne signifie pas que les sites que vous visitez sont nécessairement sûrs.

PHP 8.1 et les versions antérieures ne reçoivent plus de versions officielles, ce qui fait des serveurs plus anciens le point faible, bien que l'équipe de sécurité de PHP ait publié des correctifs minimaux pour 7.4, 8.0 et 8.1 à l'intention des personnes qui compilent le logiciel elles-mêmes.

Quelqu'un a-t-il réellement été piraté ?

Les attaquants ont certainement essayé : le PDG de Cloudflare, Matthew Prince, a déclaré que son réseau avait observé des milliers de tentatives d'exploitation dans les 10 heures précédant l'annonce, des dizaines de milliers dans les 45 minutes qui ont suivi, des centaines de milliers en deux heures, et des millions depuis.

Amazon est allé plus loin, déclarant que ses serveurs leurres ont enregistré une tentative le 17 octobre, quatre jours avant que les failles ne soient rendues publiques. « Il reste difficile de déterminer comment l'acteur a obtenu des informations sur l'exploit avant la divulgation », a écrit CJ Moses, RSSI d'Amazon, ajoutant que PHP2Shell est « désormais largement exploité dans la nature ».

Les gouvernements, en revanche, ne semblent pas avoir encore subi de quelconque intrusion réussie. Thomas Caspers, vice-président de l'agence fédérale allemande de cybersécurité BSI, a déclaré que l'agence avait observé des attaques mais aucune utilisation réussie des failles, ajoutant : « Cela semble un peu plus compliqué que prévu à exploiter. » Le secrétaire général du Cabinet japonais, Minoru Kihara, a également déclaré qu'aucune attaque exploitant les failles n'avait été confirmée.

Une tentative, c'est quelqu'un qui secoue la poignée de porte ; une intrusion, c'est quelqu'un qui entre à l'intérieur, donc les deux affirmations peuvent être vraies en même temps. Des millions de poignées de porte secouées et zéro effraction confirmée, c'est une bonne nouvelle, mais les effractions ont tendance à être découvertes plus tard, pas en temps réel.

Pourquoi cela n'a-t-il pas été détecté plus tôt ?

En quelque sorte, cela l'a été. Dans un article de blog publié mercredi, la Fondation PHP a déclaré que son travail de sécurité en 2024 « a trouvé les premiers signes du problème OOM derrière CVE-2026-109618 », c'est-à-dire le bug de mémoire insuffisante au cœur de l'une des deux failles.

L'équipe a proposé « plusieurs approches concurrentes » pour le corriger, mais « a eu du mal à choisir entre elles et craignait les répercussions de livrer le mauvais choix », selon la fondation. « Sans le financement de la Fondation, il aurait été impossible que plusieurs personnes travaillent à plein temps sur ce problème », a-t-elle ajouté.

« Nous ne prétendrons pas le contraire : le retard était un échec structurel, causé à la fois par le processus décisionnel de l'équipe de sécurité et par son manque de ressources », a écrit la fondation, ajoutant que son équipe de sécurité, qui devait auparavant fonctionner par consensus, décidera désormais à la majorité. Pour le logiciel qui fait tourner la majeure partie du web, ce travail de sécurité « dépend encore d'un petit groupe de développeurs financés par la fondation et d'un peu d'aide bénévole », selon l'article.

Pourquoi certains sites web sont-ils encore hors ligne ?

Parce que le correctif prend du temps, et « hors ligne » était le conseil officiel pour quiconque ne pouvait pas corriger immédiatement. Le Centre national de cybersécurité du Royaume-Uni a conseillé aux organisations d'envisager de « mettre le système hors ligne jusqu'à ce qu'il puisse être entièrement atténué ».

La liste des sites qui sont tombés mercredi s'est allongée rapidement. Selon TechRadar, elle comprenait les services Wikimedia, les sites et applications Orange dans des dizaines de pays, 32 services gouvernementaux britanniques, des hôpitaux néerlandais et le fournisseur informatique fédéral allemand, ITZBund.

L'Office for Budget Responsibility du Royaume-Uni et le site du conseil municipal d'Édimbourg étaient de retour jeudi. D'autres, comme le site néerlandais de signalement anonyme de crimes Meld Misdaad Anoniem, étaient encore hors ligne jeudi matin, selon DutchNews.

Dois-je changer mes mots de passe ?

Pas à cause de cela, du moins pas encore. Aucune violation de données confirmée n'a été liée à PHP2Shell jusqu'à présent, et changer tous les mots de passe aujourd'hui ne servira à rien si le serveur d'un site n'est toujours pas corrigé.

Ce qui aide, c'est le côté ennuyeux : des mots de passe uniques pour chaque compte, l'authentification à deux facteurs activée, et être attentif si une entreprise vous envoie un courriel au sujet d'une violation dans les semaines à venir. Si cela se produit, changez ce mot de passe, ainsi que tout compte où vous l'avez réutilisé.

Les propriétaires de sites web ont plus de travail, car le correctif ferme la porte mais ne vous dit pas si quelqu'un est entré auparavant. La société de sécurité Tag1 conseille de rechercher les fichiers PHP que vous n'avez pas téléversés, les nouvelles tâches planifiées et les nouveaux comptes, et de renouveler les mots de passe de base de données et les clés API sur tout serveur exposé à Internet qui exécutait une version vulnérable.

Et pour la crypto ?

Le fondateur de Binance, Changpeng Zhao, a donné un bref conseil sur X : « Traitez-moi de paranoïaque, mais soyez extrêmement prudent en visitant N'IMPORTE QUEL site web dans les prochains jours. »

Un serveur web piraté peut vous montrer une fausse version d'un site réel, et dans la crypto, cela signifie généralement une page qui vous demande de connecter votre portefeuille et d'approuver une transaction qui le vide. Un réseau blockchain lui-même peut très bien aller ; les sites web qui le précèdent, peut-être pas.

Pendant les prochains jours, vérifiez trois fois ce que vous signez, mettez en favori les sites que vous utilisez au lieu de cliquer sur des liens, et utilisez un portefeuille matériel si vous en avez un. Jusqu'à présent, aucun exchange crypto n'a signalé publiquement une violation liée à PHP2Shell.

Alors, est-ce sûr ?

Naviguer sur le web aujourd'hui est à peu près aussi sûr que la semaine dernière, c'est-à-dire pas parfaitement. La véritable exposition se trouve sur les serveurs qui n'ont pas été corrigés, et la société de sécurité Mallory a compté environ 884 000 hôtes exposés à Internet exécutant des versions de PHP qui ne reçoivent aucun correctif officiel.

Le conseil d'Amazon aux défenseurs est essentiellement que ce n'est pas terminé. « Les défenseurs ne doivent pas supposer que la date de divulgation publique est la première date d'exploitation. » Tout serveur ayant exécuté une version vulnérable depuis au moins le 17 octobre devrait être vérifié, pas seulement corrigé.