Faille PHP : pourquoi des sites ont été coupés en urgence et ce que les entreprises doivent faire ?

Le 21 octobre 2026, deux failles critiques dans PHP ont rendu inaccessibles ou instables des sites de préfectures, des impôts, de banques et de services privés. Une faille PHP de cette gravité concerne aussi votre site, votre boutique en ligne ou votre extranet. Voici ce qui s’est passé, comment réagir, et pourquoi la montée de version échappe souvent à la maintenance.

Que s’est-il passé avec la faille PHP du 21 octobre ?

Deux failles critiques dans le cœur de PHP

PHP2Shell désigne deux vulnérabilités du moteur de PHP, référencées CVE-2026-109618 et CVE-2026-109619. D’après le bulletin de sécurité de PHP, la première vient d’une mémoire saturée qui laisse des données de requête à moitié initialisées, la seconde d’un état interne qui survit à la libération de sa mémoire et peut être réutilisé par la requête suivante.

Les deux sont notées 9,2 sur 10 (CVSS v4.0) par l’équipe sécurité de PHP. Elles peuvent permettre d’exécuter du code sur le serveur sans authentification, donc de lire des données, de modifier le site ou d’installer un logiciel malveillant.

Le risque est le plus élevé avec mod_php : PHP dispose d’une démonstration d’exploit où une requête non authentifiée déclenche l’attaque avant même l’exécution du code de l’application.

Le problème se situe sous les CMS, pas dedans. WordPress, Drupal, Magento, Symfony ou une application sur mesure reposent tous sur PHP : un CMS parfaitement à jour peut tourner sur un PHP vulnérable. Selon le Wall Street Journal, repris par Actu17, PHP fait tourner jusqu’à 70 % des sites. Tous ne sont pas vulnérables, mais la faille PHP touche le socle, pas une extension.

Une publication annoncée la veille

Le 20 octobre, l’équipe sécurité de PHP annonce une publication critique pour le 21 à 14 h UTC (16 h à Paris), en se réservant le droit de publier plus tôt si des détails devenaient publics. Le CERT-EU recommande déjà d’isoler les applications PHP exposées à Internet. Selon la presse, des détails ont fuité avant la date d’embargo.

Les correctifs sortent le 21 octobre dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, mod_php, php-cgi, FrankenPHP ou LiteSpeed.

Selon le CERT-FR de l’ANSSI, sont concernées toutes les versions 5.x, 7.x, 8.0 et 8.1 (en fin de support), ainsi que les 8.2 antérieures à 8.2.35, les 8.3 antérieures à 8.3.36, les 8.4 antérieures à 8.4.27 et les 8.5 antérieures à 8.5.12.

Le projet PHP ne publie plus de mises à jour pour la 8.1 et les versions plus anciennes. Il a fourni des correctifs minimaux à compiler soi-même pour les branches 7.4, 8.0 et 8.1, et certains distributeurs proposent des correctifs rétroportés.

Sur l’exploitation, les sources divergent. Cloudflare a signalé de premières attaques. Le CERT-FR indique, dans sa mise à jour du 22 octobre, disposer de preuves de concept pour certains déploiements spécifiques, sans citer d’exploitation constatée, et le Centre canadien pour la cybersécurité fait un constat proche. Considérez le risque comme réel.

Pourquoi tant de sites ont-ils été mis hors ligne ?

Une faille exposée à tous, un correctif qui ne s’installe pas en une heure

Entre la fuite des détails et l’installation du correctif, un site reste exposé à une faille que n’importe quel scanner automatique peut tester. Face à une faille PHP qui donne la main sur le serveur sans authentification, cette fenêtre est trop risquée. Un site hors ligne est indisponible, mais intact.

Les administrations ont ouvert la voie : le ministère de l’Intérieur a procédé à une mise en maintenance préventive de ses sites à la demande de l’ANSSI, d’après la presse. Le CERT-FR recommande d’isoler les équipements concernés, et le CERT-EU, le NCSC britannique et l’ACSC australien vont dans le même sens : si vous ne pouvez pas corriger vite, coupez.

Sites touchés : ce qu’une compromission ferait à votre entreprise

Un attaquant qui exécute du code sur votre serveur ne s’arrête pas au site. Cybermalveillance.gouv.fr cite la prise de contrôle à distance, le déni de service, le vol ou la destruction de données confidentielles, et l’accès au système d’information interne.

Pour une entreprise, cela se traduit par des pertes concrètes : un site indisponible, des données clients exposées (avec les obligations RGPD qui suivent), une perte de confiance, et le temps passé à restaurer puis à prouver que l’environnement est sain. Chacune pèse en général plus lourd qu’une coupure planifiée de quelques heures.

Type de site	Ce qui est exposé	Conséquence métier possible
Boutique en ligne	Commandes, comptes clients, connecteurs de paiement	Ventes interrompues, données clients exposées, obligations RGPD
Extranet ou espace client	Comptes, documents, échanges contractuels	Fuite de documents confidentiels, perte de confiance des clients
Application métier	Données internes, connexions à l’ERP ou au CRM	Rebond vers le système d’information, arrêt d’activité
Site vitrine	Contenu, formulaires de contact	Défiguration, pages frauduleuses, image dégradée

Un site compromis peut aussi servir de relais : pages de phishing hébergées, courriels frauduleux envoyés, rebond vers vos autres systèmes. Votre entreprise en porte alors l’image, sans que le visiteur voie la différence.

Un arbitrage que votre direction doit pouvoir faire

Pour une entreprise, couper un site est un arbitrage : quelques heures d’indisponibilité (ventes perdues, support débordé) contre le risque d’une compromission (données clients, image, obligations RGPD).

Le calcul diffère selon le site. Un site vitrine peut attendre, une boutique en ligne ou un extranet client a un coût d’arrêt à mesurer d’avance. Cybermalveillance.gouv.fr juge ces failles particulièrement critiques pour les sites transactionnels et prévient que des attaques massives pourraient survenir très prochainement.

Cet arbitrage se prépare à froid : qui décide, sur quels critères, avec quel message aux clients ? Sans décision préparée, la coupure se prend dans la panique, ou ne se prend pas.

Un langage ne se corrige pas comme un plugin

Mettre à jour PHP touche l’infrastructure, pas seulement l’application. Il faut déployer le correctif sur chaque serveur et chaque environnement, puis vérifier que le site fonctionne toujours : extensions, bibliothèques, comportements modifiés. Une entreprise qui a plusieurs sites chez plusieurs prestataires ne peut pas le garantir en quelques heures.

Les protections de remplacement ne suffisent pas. Un pare-feu applicatif (WAF) filtre les requêtes dangereuses connues, mais Cloudflare le présente lui-même comme une mesure d’attente. Les mises à jour automatiques de WordPress ne corrigent pas non plus PHP, comme l’a rappelé Wordfence : le langage se met à jour côté serveur, à la main.

Pour savoir où vous en êtes, notre audit de site fait le point sur la version de PHP, les dépendances et l’hébergement.

Comment réagir face à une faille PHP critique ?

Face à une faille PHP critique, il faut d’abord savoir ce que vous possédez, puis corriger ou isoler, puis vérifier que personne n’est entré avant vous. L’ordre des gestes compte plus que la vitesse brute.

Moment	Geste	Pourquoi
Premières heures	Identifier la version de PHP de chaque site, y compris en préproduction et les sites oubliés	On ne corrige pas ce qu’on ne connaît pas
Premières heures	Appliquer le correctif si votre branche en reçoit un (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récent)	C’est la seule solution durable
Premières heures	Sinon, appliquer les contournements ci-dessous et isoler ou couper le site	Le risque diminue, il ne disparaît pas
Jours suivants	Chercher des traces de compromission : fichiers inconnus, requêtes POST inhabituelles, comptes créés	Le site a pu être attaqué avant le correctif
Jours suivants	Changer les secrets en cas de doute : base de données, clés d’API, jetons	Un code exécuté sur le serveur voit tout ce que le serveur connaît
Jours suivants	Notifier la CNIL sous 72 heures si des données personnelles sont touchées	Obligation prévue par le RGPD

Pour connaître votre version de PHP, plusieurs chemins existent. Dans WordPress, elle s’affiche dans Outils, Santé du site, onglet Infos, rubrique Serveur. En ligne de commande, php -v l’indique, mais cette version peut différer de celle du serveur web : en cas de doute, demandez à votre hébergeur.

Si vous ne pouvez pas mettre à jour tout de suite, des contournements existent, mais PHP est clair : aucun n’est complet, seule la mise à jour est sûre. Le CERT-FR suggère de bloquer au niveau du WAF les requêtes dont le Content-Type est « multipart », ou au minimum de les superviser.

PHP recommande de désactiver session.upload_progress.enabled et de limiter post_max_size, dans php.ini, le pool FPM ou la configuration serveur, pas via ini_set(). Le 23 octobre, PHP a ajouté un avis : gardez le premier réglage désactivé jusqu’à la prochaine version corrective, qui accompagnera l’avis complet sur un vecteur peu probable (CVE-2026-115560).

N’attendez pas d’y voir plus clair : les attaquants automatisent très vite. Ne vous croyez pas protégé par un WAF ou par un CMS à jour, et ne laissez pas tourner une version de PHP en fin de vie en espérant que cela passe.

Désignez dès le départ la personne qui décide (direction, DSI ou prestataire), et prévenez en parallèle le délégué à la protection des données et le support client.

Après l’incident, une surveillance après mise en production permet de repérer plus vite les comportements anormaux : pics de requêtes, fichiers modifiés, erreurs serveur.

Pourquoi la montée de version PHP n’est-elle pas dans votre maintenance ?

Ce que couvre une maintenance corrective

Une maintenance corrective garde le site sain : correction des anomalies, sauvegardes testées, mises à jour de sécurité. Chez Ylly, elle inclut les mises à jour de sécurité du CMS, des extensions et du serveur. Passer de PHP 8.3.35 à 8.3.36 en fait partie : c’est une mise à jour mineure, rapide et peu risquée.

Les évolutions se contractualisent à part, en TMA (tierce maintenance applicative). C’est une frontière courante dans les contrats de maintenance, et elle explique la suite.

Pourquoi une montée de version est un projet à part

Passer de PHP 7.4 à 8.3, ou de 8.0 à 8.4, n’est pas une mise à jour : c’est un chantier. Chaque version majeure retire des fonctions, change des comportements et durcit le typage. Du code qui tournait depuis dix ans peut cesser de fonctionner.

Critère	Mise à jour mineure	Montée de version majeure
Exemple	8.3.35 vers 8.3.36	7.4 vers 8.3
Risque de casse	Faible	Élevé : code, thème, extensions
Tests	Vérification rapide	Non-régression de tous les parcours
Effort	Prévisible	Dépend de l’état du code
Cadre contractuel	Maintenance corrective	Projet chiffré

Le coût d’une montée de version se connaît après l’audit, jamais avant.

L’effort est surtout imprévisible. Il dépend de l’âge du code, de la dette technique et des dépendances : thème, extensions, bibliothèques, connecteurs de paiement ou d’ERP. Certains composants ne seront jamais compatibles parce qu’abandonnés, comme sur les sites restés sur Drupal 7, dont la fin de vie a imposé une migration.

Un forfait mensuel est dimensionné pour l’entretien courant. Il ne peut pas absorber un chantier de plusieurs jours dont le coût n’est connu qu’après audit, et la décision engage un budget et une recette que seul le client peut arbitrer. Une montée de version majeure se cadre donc comme un projet, avec un chiffrage détaillé.

À quoi ressemble un chantier de 7.4 vers 8.3

Un chantier de migration suit le même fil quelle que soit la taille du site. Voici les étapes d’un passage de PHP 7.4 vers 8.3, sans durée annoncée : elle dépend de l’état du code.

1. Inventorier le code, le thème, les extensions et les bibliothèques Composer, avec la compatibilité annoncée de chacun.
2. Analyser le code avec des outils de compatibilité (PHPCompatibility, PHPStan ou Rector) pour repérer les fonctions retirées et les comportements modifiés.
3. Monter un environnement de recette identique à la production, en PHP 8.3.
4. Corriger le code et remplacer les composants abandonnés.
5. Mettre à jour le CMS et les extensions vers des versions compatibles.
6. Dérouler les tests de non-régression sur tous les parcours : formulaires, panier, paiement, exports, tâches planifiées.
7. Planifier la bascule avec une sauvegarde testée et un plan de retour arrière.
8. Surveiller le site après la mise en production.

Les étapes 2 et 4 concentrent l’incertitude : on ne sait ce qu’elles coûtent qu’une fois l’analyse faite. C’est ce qui justifie un audit préalable et un chiffrage détaillé plutôt qu’un forfait.

Le piège de la fin de vie

Le piège apparaît quand une branche de PHP arrive en fin de vie : plus aucun correctif officiel n’est publié. Si une faille PHP critique tombe à ce moment-là, il n’existe rien à installer. Il reste la coupure, le filtrage ou la migration en urgence, la plus coûteuse des trois.

Comment planifier vos montées de version avant la prochaine alerte ?

Budgéter une migration tous les deux à trois ans

Il faut budgéter une migration tous les deux à trois ans, comme un investissement, au lieu de la subir en urgence. Le cycle de support de PHP est public : chaque branche est supportée quatre ans, dont deux ans de support actif puis deux ans de correctifs de sécurité seuls. Les dates figurent sur php.net.

Le calendrier est serré. Au 26 octobre 2026, les branches 8.0 et 8.1 sont déjà en fin de vie, et la 8.2 n’est plus que dans sa période de correctifs de sécurité seuls : elle prend fin le 31 décembre 2026. Si votre site tourne sur l’une d’elles, la migration se prépare maintenant.

Les questions à poser à votre prestataire

Avant de signer ou de renouveler un contrat, posez ces questions à votre prestataire :

• Quelle version de PHP tourne aujourd’hui, et jusqu’à quelle date est-elle supportée ?
• Sous quel délai les correctifs de sécurité sont-ils appliqués ?
• Qui décide de couper le site en cas d’alerte critique, et à quelles conditions ?
• Une montée de version majeure est-elle chiffrée à part, et sur quelle base ?

Les questions à poser à votre hébergeur

Si votre site est hébergé chez un tiers, c’est lui qui installe PHP : ces questions lui reviennent.

Question	Pourquoi elle compte
Quelle version de PHP tourne sur chacun de mes sites ?	Un même compte peut mélanger plusieurs versions
Quand le correctif du 21 octobre est-il appliqué ?	Ce délai fixe la durée d’exposition
Pouvez-vous bloquer les requêtes multipart ou désactiver session.upload_progress.enabled en attendant ?	Ce sont les contournements proposés par le CERT-FR et PHP
Puis-je choisir la version de PHP site par site ?	Sans cela, un site ancien bloque la montée des autres
Comment êtes-vous informé de la fin de vie d’une version ?	Sans veille, la fin de vie arrive sans préavis
Que prévoyez-vous si ma version n’est plus supportée ?	Correctif rétroporté, migration ou coupure : mieux vaut le savoir avant

Un contrat de maintenance qui nomme la montée de version

La prochaine faille PHP tombera sans prévenir. Un contrat clair indique ce que la maintenance inclut et ce qui se chiffre à part. Ylly, agence digitale parisienne forte de 17 ans d’expertise, assure la maintenance de votre site web : sécurité du CMS, des extensions et du serveur, sauvegardes testées et évolutions en TMA. Parlez-en à nos équipes avant qu’une alerte ne vous force la main.

Questions fréquentes

Mon site est-il concerné par la faille PHP2Shell ?

Oui si votre serveur exécute une version de PHP antérieure à la version corrigée de sa branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12), quel que soit le CMS. Demandez à votre hébergeur ou à votre prestataire la version de PHP de chaque site, y compris en préproduction. Toutes les versions 5.x, 7.x, 8.0 et 8.1 sont concernées et doivent migrer vers une branche maintenue, sauf correctif rétroporté par votre distributeur. Sur un hébergement mutualisé ou managé, c’est l’hébergeur qui met PHP à jour : demandez-lui sa date de déploiement.

Faut-il mettre son site hors ligne ?

Seulement si vous ne pouvez pas corriger rapidement et que le site est exposé ou sensible. Le CERT-EU et le NCSC britannique recommandent de couper un système qui ne peut pas être corrigé tout de suite. Si votre branche reçoit un correctif, appliquez-le dès que possible plutôt que de couper. Si vous coupez, affichez une page de maintenance claire plutôt qu’une erreur, et prévenez votre support client.

Un pare-feu applicatif (WAF) suffit-il ?

Non, c’est une protection provisoire. Un WAF filtre des schémas d’attaque connus, mais il peut être contourné. Cloudflare le présente lui-même comme une mesure d’attente, et PHP indique qu’aucun contournement n’est complet : seul le correctif traite la cause. Les réglages de configuration demandent en outre de redémarrer les processus PHP pour s’appliquer.

Pourquoi la montée de version PHP n’est-elle pas incluse dans la maintenance ?

Parce qu’une montée de version majeure est un projet, pas un entretien. Son coût dépend de l’état du code et des dépendances, il ne se connaît qu’après audit, et il demande des tests et une recette. Les mises à jour mineures de sécurité, elles, relèvent de la maintenance corrective. Prévoyez donc un audit, puis un chiffrage détaillé, avant de décider.

Que faire si ma version de PHP n’est plus supportée ?

Planifiez une migration vers une branche maintenue, et limitez l’exposition d’ici là : règles WAF, blocage en amont des requêtes multipart si l’application n’en a pas besoin, désactivation de session.upload_progress.enabled, mise hors ligne si le site est sensible. Un site WordPress repose par exemple sur PHP : sa sécurité dépend de la version du serveur.

Vers quelle version de PHP migrer ?

Visez une branche en support actif. Au 26 octobre 2026, ce sont les branches 8.4 (jusqu’au 31 décembre 2026) et 8.5 (jusqu’au 31 décembre 2027), la 8.3 ne recevant plus que des correctifs de sécurité. Vérifiez les dates sur php.net et la compatibilité de vos extensions avant de choisir.

Faut-il prévenir la CNIL après une faille PHP ?

Seulement si une violation de données personnelles est constatée, pas pour la simple présence d’une faille sur votre serveur. Dans ce cas, la notification se fait dans les 72 heures après en avoir pris connaissance, sauf si la violation est peu susceptible d’engendrer un risque pour les personnes. En cas de doute, consultez votre délégué à la protection des données.