// FRANDROID — GAMING
Préfectures, impôts, Orange, Nintendo, Wikipédia… Pourquoi des milliers de sites se sont mis hors ligne en urgence
Impossible de prendre un rendez-vous en préfecture ou de consulter la météo sur le site de Météo-France sans tomber sur une page « en maintenance ». Alors que ce type de message évoque d’ordinaire une panne ou un piratage, il s’agissait cette fois d’une décision volontaire prise par des milliers d’organisations. En cause : deux failles critiques de PHP, corrigées en urgence mercredi peu avant 16 h. Un réflexe de précaution qui s’est rapidement étendu, touchant notamment Orange aujourd’hui (ce qui n’a rien à voir avec la panne d’hier)
Pour aller plus loin
Failles critiques dans PHP : alerte maximale et mise à jour d’urgence ce mercredi à 16 h
En France, le ministère de l’Intérieur a placé l’ensemble de ses portails en maintenance préventive à la demande de l’ANSSI, impactant les préfectures, les services d’impots.gouv.fr, la CNIL ou encore la Ville de Paris.
La mesure a traversé les frontières : en Belgique, la police fédérale et le SPF Finances ont coupé l’accès à leurs plateformes, tandis que le centre national de cybersécurité a sommé les administrateurs de corriger ou de débrancher.
Aux Pays-Bas, en Finlande et en Allemagne, la même stratégie s’est imposée, tout comme sur Wikipédia, l’Internet Archive ou chez Nintendo.
Ces vulnérabilités permettaient ni plus ni moins de prendre le contrôle d’un serveur à distance, sans le moindre mot de passe, comme nous le détaillions dans notre point complet sur les correctifs.
Pour aller plus loin
Failles critiques dans PHP : la menace se précise, mais le pire scénario s’éloigne pour nos sites web
Pour comprendre l’ampleur de cette coupure massive, il faut se pencher sur la nature même de la faille. Selon les avis de sécurité, l’attaque se déclenche dès la lecture de la requête HTTP, avant même que le code du site ne s’exécute. Par conséquent, un mode maintenance classique propulsé par WordPress ou Drupal, des CMS eux-mêmes écrits en PHP, s’avère totalement inefficace. Tant que le serveur continue d’accepter les requêtes, la porte reste ouverte. Pour se protéger sans correctif immédiat, la seule option viable consistait donc à stopper net le trafic en aval ou à couper les serveurs.
Or, installer le correctif officiel ne relève pas de la simple formalité. Les grandes organisations doivent d’abord recenser l’intégralité de leurs serveurs PHP, y compris les intranets ou les sous-domaines oubliés, avant d’appliquer la mise à jour et de redémarrer chaque service. Sans ce redémarrage, l’ancien code vulnérable continue de tourner en mémoire vive. Pour les machines fonctionnant sous PHP 8.1 ou des versions plus anciennes, dépourvues de correctif direct de la part du projet, c’est une lourde migration qui s’est imposée.
Les équipes techniques ont également dû éplucher les journaux de connexion afin de s’assurer qu’aucune intrusion n’avait eu lieu avant 16 h, une précaution indispensable pour éliminer d’éventuelles portes dérobées, comme nous l’expliquions au sujet des boutiques en ligne et des données bancaires.