Deux failles critiques de PHP, baptisées PHP2Shell, permettent de prendre le contrôle d'un serveur web sans mot de passe. Le projet PHP a publié le 21 octobre 2026 à 16 h (heure de Paris) les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent cette faille PHP. En Suisse, l'Office fédéral de la cybersécurité (OFCS) recommande d'installer ces mises à jour immédiatement.

PHP est le langage de programmation qui fait tourner environ trois sites web sur quatre, dont tous les sites WordPress. La faille concerne donc aussi bien un site de commune qu'une boutique en ligne de PME. En France, plusieurs sites publics ont été mis hors ligne par précaution le même jour.

Que permet la faille PHP2Shell ?

Les deux failles permettent à un attaquant de lancer ses propres programmes sur le serveur, sans identifiant. Elles sont référencées CVE-2026-109618 et CVE-2026-109619 et notées 9,2 sur 10 sur l'échelle de gravité habituelle. L'attaquant envoie une requête piégée, et l'attaque se déclenche avant même que le site ne traite la demande.

L'avis de sécurité de php.net décrit deux mécanismes distincts :

  • CVE-2026-109618 : quand la mémoire vient à manquer, PHP peut s'interrompre alors que les données internes d'une requête ne sont qu'en partie prêtes. Le nettoyage qui suit peut alors traiter ces données invalides comme valides.
  • CVE-2026-109619 : un état interne lié à une requête peut survivre après la libération de sa mémoire. Une requête suivante, traitée par le même processus, peut réutiliser cet état périmé.

Toutes les façons courantes de servir PHP sont touchées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP juge le risque le plus élevé avec mod_php. Il dit disposer d'une attaque démontrée où une seule requête sans authentification suffit.

Quelle mise à jour PHP installer ?

La seule protection complète est la mise à jour PHP vers la version corrigée de sa branche. Le tableau résume la situation décrite par php.net et par Journal du Coin.

Branche installéeVersion à installerRemarque
PHP 8.58.5.12Branche soutenue
PHP 8.48.4.27Branche soutenue
PHP 8.38.3.36Branche soutenue
PHP 8.28.2.35Fin des mises à jour le 31 décembre
PHP 8.1, 8.0 et 7.4Pas de nouvelle version officielleCorrectifs minimaux publiés par l'équipe de sécurité de PHP, paquets des distributeurs ou migration

Les distributions Linux et les éditeurs de support à long terme ont reçu les correctifs à l'avance. Sur un serveur Linux, il suffit donc souvent d'installer le paquet mis à jour par son distributeur. Pour PHP 8.1 et les versions plus anciennes, le projet ne publie plus de mises à jour, mais il a fourni des correctifs minimaux pour ceux qui compilent PHP eux-mêmes.

Qui ne peut pas mettre à jour tout de suite dispose de mesures temporaires. Le projet PHP précise qu'elles réduisent l'exposition à certains chemins d'attaque, sans rendre une installation sûre :

  • désactiver le suivi des téléversements (session.upload_progress.enabled=0), puis redémarrer chaque processus PHP ;
  • abaisser la taille maximale des données envoyées (post_max_size) : 8M pour un site sans envoi de fichiers, 32M si des envois sont nécessaires ;
  • supprimer la limite de mémoire contrôlable par PHP (memory_limit=-1), dans une configuration que les applications ne peuvent pas modifier.

Pourquoi des sites publics ont-ils été coupés en France ?

En France, la coupure est une décision de précaution, pas la conséquence d'une intrusion. Le ministère de l'Intérieur a mis en maintenance « l'ensemble de ses sites internet exposés » à la demande de l'Agence nationale de la sécurité des systèmes d'information (ANSSI). Les sites de la préfecture de police et de plusieurs préfectures, du ministère de l'Économie, de Météo-France et des Echos affichaient un message de maintenance le 21 octobre 2026. Aucun de ces sites n'a signalé d'intrusion.

La raison tient à la chronologie. Cloudflare, qui filtre le trafic d'une grande partie du web, bloquait des tentatives d'attaque dès 5 h 02 (heure de Paris), soit neuf heures avant la publication officielle. L'entreprise a aussi vu les attaquants modifier leurs méthodes pour contourner ses règles. L'embargo prévu pour le jeudi avait sauté le lundi 19 octobre 2026, après un message sur le forum Hacker News.

D'autres pays européens ont réagi de la même façon, selon un relevé de l'agence Reuters cité par Journal du Coin. L'agence fédérale allemande ITZBund a désactivé plusieurs sites, la Finlande a coupé les services web de l'État et, aux Pays-Bas, le port de Rotterdam et le portail Overheid.nl étaient hors ligne.

Que recommande l'Office fédéral de la cybersécurité ?

L'OFCS a publié un avertissement le 21 octobre 2026. Il y décrit deux vulnérabilités critiques qui pourraient permettre d'exécuter du code malveillant sur les serveurs concernés, sans authentification. L'office recommande de mettre à jour immédiatement les systèmes touchés.

L'OFCS ajoute un point souvent oublié : au-delà des serveurs web, il faut vérifier les applications et les appareils qui utilisent PHP comme composant intégré. L'office reçoit par ailleurs les annonces volontaires de cyberincidents de la population, des entreprises et des autorités. Les exploitants d'infrastructures critiques sont, eux, tenus de lui signaler leurs cyberincidents depuis le 1er avril 2025.

Ce qu'une PME ou une commune doit vérifier auprès de son hébergeur

Pour la plupart des sites hébergés, c'est l'hébergeur qui gère PHP et qui doit appliquer la mise à jour. Une question suffit pour commencer : « Avez-vous appliqué le correctif PHP2Shell ? » La sécurité du site web passe ensuite par quelques vérifications concrètes, tirées des recommandations de l'OFCS et de php.net :

  • dresser la liste de toutes les installations PHP, y compris celles cachées dans un logiciel tiers : outil de statistiques, forum ou vieux site oublié ;
  • demander la version installée et vérifier qu'il s'agit de 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ;
  • pour un site encore en PHP 8.1 ou plus ancien, appliquer les mesures temporaires et planifier une migration ;
  • passer en revue les applications et les appareils qui embarquent PHP, comme le demande l'OFCS ;
  • surveiller les signes d'attaque : envois de fichiers suivis d'erreurs 500 en série, cookies PHPSESSID anormalement gros, processus PHP qui redémarrent sans raison.

Un site protégé par Cloudflare bénéficie des règles de blocage, actives sur tous ses abonnements, y compris gratuits. Ce filtre ne remplace pas la mise à jour, puisque les attaquants adaptent déjà leurs requêtes. Ces gestes rejoignent des mesures simples de cybersécurité : inventaire, mises à jour et surveillance.

Comment une intelligence artificielle a trouvé la faille

Les bugs dormaient dans le moteur de PHP depuis plus de dix ans, selon Wiz Research, l'entreprise de cybersécurité à l'origine de la découverte. Son équipe a trouvé la première faille le 19 août avec son outil Wiz Atlas et deux modèles d'IA, Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI. Le rapport a été transmis au projet PHP le 24 août et l'accusé de réception est arrivé le 21 septembre.

Wiz affirme qu'« un seul chercheur a accompli en une semaine » le travail de plusieurs mois d'une équipe de haut niveau. Raluca Ada Popa, responsable de la sécurité de Gemini chez Google DeepMind, nuance : l'IA a aussi servi à valider le correctif et à construire les outils de détection.

Ce qu'on ne sait pas encore

  • Aucune des sources consultées ne fait état d'une exploitation réussie en Suisse, ni d'un site suisse mis hors ligne.
  • Le nombre de sites suisses encore vulnérables n'est pas connu.
  • L'ampleur des attaques reste floue : Huntress n'avait vu aucune exploitation réelle le soir du 19 octobre 2026, alors que Cloudflare en observe depuis le matin du 21 octobre.
  • Le délai de retour des sites coupés dépend du nombre de serveurs à traiter : quelques heures, parfois des jours quand des applications métier doivent être testées.

Sources