Faille PHP : Monaco a coupé ses sites

Le mercredi 21 octobre 2026 en soirée, quiconque tentait d'ouvrir le site du Gouvernement Princier, celui du Palais, celui de l'Agence Monégasque de Sécurité Numérique (AMSN) ou celui de la Mairie de Monaco tombait sur une page de maintenance. Personne n'avait été piraté, du moins personne ne l'a affirmé. La Direction des Systèmes d'Information et des Infrastructures (DISI), en accord avec l'AMSN, avait choisi de couper volontairement l'accès externe, parce que deux failles critiques venaient d'être révélées dans PHP, le langage qui fait tourner une très grande partie des sites web dans le monde.

Si le site de votre entreprise repose sur WordPress, WooCommerce, PrestaShop, Magento, Drupal, Laravel ou du code PHP sur mesure, cette histoire vous concerne autant que la Principauté. Voici ce qui s'est passé, en quoi consistent ces failles en termes simples, et les quelques gestes à faire avant la fin de la semaine.

Ce qui s'est passé à Monaco

La suspension était préventive. Le Gouvernement a indiqué que ses sites resteraient inaccessibles de l'extérieur jusqu'à la fin des vérifications de sécurité et des mises à jour, tout en restant consultables depuis les postes internes de l'administration. La Mairie a confirmé le même jour la coupure de ses propres sites, ce qui a aussi rendu indisponibles ceux du Jardin Exotique, de l'Académie Rainier III, de l'Espace Léo Ferré et du magazine en ligne Monaco Vivre Ma Ville. Elle a rassuré les usagers : les rendez-vous déjà pris auprès de l'État Civil restaient valables et les demandes de documents déposées avant la coupure étaient bien enregistrées.

Monaco n'était pas un cas isolé. Le ministère de l'Intérieur français a placé les sites des préfectures en maintenance préventive, l'aéroport Nice Côte d'Azur et la ville d'Antibes ont fermé leurs services en ligne, et les Pays-Bas, la Finlande et l'Allemagne ont également débranché des sites publics. Le CERT-FR a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre et l'a mise à jour le lendemain pour signaler qu'il avait connaissance de preuves de concept fonctionnelles.

Le 24 octobre, lors de notre vérification, les principaux sites du Gouvernement et de la Mairie se chargeaient à nouveau, sans que nous ayons trouvé de communiqué confirmant un rétablissement complet. Prenez cela comme un signal encourageant, pas comme la fin de l'épisode.

Ce qu'est vraiment PHP2Shell

Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619 et ont été surnommées « PHP2Shell ». Toutes deux sont notées 9,2 sur 10 sur l'échelle CVSS 4.0 et permettent une exécution de code à distance sans authentification. Concrètement, un attaquant capable d'envoyer des requêtes web à un serveur vulnérable peut potentiellement y exécuter son propre code, lire ce qu'il contient et s'en servir comme point d'appui.

Trois points comptent pour un chef d'entreprise :

• La faille se trouve dans PHP lui-même, pas dans une extension ou un thème. Mettre à jour WordPress, un plugin ou un thème ne sert à rien si le PHP sous-jacent est resté ancien. Toutes les versions depuis PHP 5.4 sont signalées comme touchées.
• Des correctifs existent, mais seulement pour les branches maintenues. PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles : les sites concernés dépendent d'un rétroportage de leur fournisseur ou doivent migrer vers une branche actuelle.
• La faille est exploitée. La société Patchstack a signalé des incidents d'exploitation active remontés par des hébergeurs dès le jour de la divulgation, et le réseau de leurres d'Amazon a enregistré une tentative quatre jours avant l'annonce publique. Ce n'est pas théorique.

Ces failles ont été découvertes grâce à des outils de recherche assistés par IA, ce qui explique en partie la rapidité de la divulgation. PHP a depuis signalé un problème supplémentaire, de gravité moindre, encore sans correctif à l'heure où nous écrivons : attendez-vous à d'autres mises à jour dans les semaines à venir.

Pourquoi cela dépasse largement le Gouvernement

Les plateformes hébergées comme Shopify, Squarespace ou Wix corrigent leur propre infrastructure, et leurs clients n'ont rien à installer. Presque tout le reste est différent. Un site vitrine WordPress pour un cabinet d'avocats monégasque, une boutique WooCommerce du Carré d'Or, une boutique PrestaShop, le portail d'annonces d'une agence immobilière, le moteur de réservation d'un hôtel, un intranet, un mini-site oublié d'un événement de 2022, une copie de préproduction laissée en ligne : tous font tourner PHP quelque part, et chacun est une installation distincte à vérifier.

Le point gênant, c'est que beaucoup de dirigeants ignorent la version de PHP de leur site, et qui est chargé de la mettre à jour. En hébergement mutualisé, c'est généralement l'hébergeur. Sur un VPS, un serveur dédié ou un conteneur, c'est vous ou votre développeur. En hébergement WordPress managé, cela dépend du contrat. Si vous ne pouvez pas répondre en une phrase, c'est la première chose à régler.

Cinq gestes à faire cette semaine

1. Identifiez votre version de PHP. Dans WordPress : Outils, puis Santé du site, onglet Informations, section Serveur. Ailleurs, demandez par écrit à votre hébergeur ou à votre développeur. Toute version inférieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 est exposée.
2. Mettez à jour, puis redémarrez. Passez à la version corrigée de votre branche et redémarrez PHP-FPM ou le serveur web pour que la nouvelle version soit réellement utilisée. Sauvegardez avant, testez après.
3. Si vous ne pouvez pas mettre à jour aujourd'hui, réduisez l'exposition. Le CERT-FR cite deux mesures provisoires : désactiver la fonction upload-progress dans php.ini (session.upload_progress.enabled = Off), qui ne couvre qu'une des deux failles, et bloquer ou surveiller étroitement les requêtes multipart au niveau du pare-feu. Ou faites comme Monaco : passez le site en maintenance jusqu'au correctif.
4. Abandonnez PHP 8.1 et antérieurs. Si votre hébergeur ne propose aucun rétroportage, migrer vers une branche maintenue est la seule voie fiable. Pour un vieux WordPress ou PrestaShop, cela suppose d'abord un contrôle de compatibilité.
5. Partez du principe qu'un intrus a peut-être déjà pénétré. Le correctif n'expulse pas quelqu'un entré avant lui. Examinez les journaux d'accès, cherchez des fichiers ou des administrateurs inconnus, et changez les mots de passe, clés API et jetons détenus par le serveur.

Un bon contrat de maintenance de site web aurait dû traiter les points un et deux pour vous les 21 ou 22 octobre, sans que vous ayez à le demander. Si ce n'est pas le cas, posez la question.

Ce que la décision de Monaco enseigne aux PME

Couper volontairement son propre site ressemble à un échec. Ce n'en est pas un. Le Gouvernement a mis en balance le coût de quelques jours d'indisponibilité et celui d'une compromission de systèmes contenant des données de résidents, et il a choisi la page de maintenance. Une entreprise monégasque qui conserve des dossiers clients, des données de paiement ou des échanges confidentiels derrière une application PHP doit être capable de prendre la même décision, vite, et savoir qui a le droit de la prendre.

Cela suppose trois choses en place avant l'urgence : un inventaire de tous les sites et applications que vous exploitez ; une page de maintenance et un message d'un paragraphe expliquant à vos clients comment vous joindre par téléphone ou par e-mail en attendant ; et une personne désignée, interne ou externe, qui a l'autorité et les accès pour tout couper et tout remettre en route.

N'oubliez pas le volet protection des données. En vertu de la loi n° 1.565, une violation de données personnelles peut imposer une notification à l'APDP, qui a récemment rappelé que les notifications tardives se multiplient. Si vos journaux laissent penser à une intrusion, consultez le jour même votre conseil en conformité APDP plutôt que d'attendre d'être certain.

La leçon de fond

PHP2Shell finira par être corrigé partout, puis la faille suivante arrivera. Les entreprises qui traversent ces semaines sereinement sont celles qui considèrent leur site comme une infrastructure, et non comme un projet terminé le jour de sa mise en ligne : une branche PHP maintenue, des mises à jour de sécurité automatiques quand c'est possible, un hébergeur qui communique, un code moderne porté par une équipe qui répond encore au téléphone. Si votre site a été construit il y a des années et que personne n'a touché au serveur depuis, c'est le bon moment pour parler de durcissement WordPress ou d'une nouvelle base de développement web.

Si vous ne savez pas sur quoi tourne votre site, ni si quelqu'un l'a corrigé depuis mercredi, contactez-nous : nous le vérifierons avec vous.