Faille de sécurité PHP : qui doit patcher votre site, et quand ?

Mercredi 21 octobre, vers 16 h (heure de Paris), le projet PHP a publié en urgence un correctif pour deux vulnérabilités jugées critiques. Dans les heures qui ont suivi, le gouvernement finlandais, l'agence néerlandaise de cybersécurité et la fondation Wikimedia ont coupé tout ou partie de leurs services en ligne. Une faille de sécurité PHP de ce niveau ne reste pas cantonnée aux grandes institutions : le langage fait tourner WordPress, Joomla, Magento et une bonne partie des outils métier développés pour les PME.

Le chiffre de 70 % d'Internet circule partout. Il provient d'une estimation de la société Wiz, que la BBC indique ne pas pouvoir vérifier. Pour un dirigeant, la question utile est plus étroite et plus urgente : sur vos propres serveurs, qui sait précisément où tourne PHP, et qui a les accès pour le mettre à jour aujourd'hui ?

Exécution de code à distance, sans compte : ce que cela ouvre

Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619 et baptisées PHP2Shell, permettent une exécution de code à distance sans authentification. Elles reçoivent toutes les deux une note CVSS v4.0 de 9,2 sur 10. Le CERT-EU, l'équipe de réponse aux incidents des institutions européennes, a alerté dans le même sens.

Concrètement, un attaquant envoie une requête à votre serveur et celui-ci exécute le code qu'il a choisi. Pas besoin de mot de passe, ni d'un employé qui clique sur un lien piégé. L'équipe de sécurité de PHP précise que, dans certaines configurations, l'attaque se déclenche avant même que le code de votre application ne s'exécute : la qualité de votre site ne vous protège donc pas. La faille est dans PHP, pas dans WordPress ou Symfony.

Les agences de cybersécurité ont été explicites : ces vulnérabilités offrent souvent « un accès direct au système de fichiers ou à la base de données du serveur ». Pour une PME, cela se traduit par des éléments très concrets :

• le fichier clients, les devis et les factures stockés en base de données ;
• les fichiers de configuration, comme le wp-config.php de WordPress, qui contiennent les identifiants de connexion à cette base ;
• des fragments de mémoire du serveur, qui peuvent contenir des mots de passe ou des clés d'API ;
• la possibilité d'installer un logiciel malveillant ou de défigurer le site.

Si des données personnelles fuient, le RGPD impose de notifier la CNIL dans les 72 heures lorsque la violation présente un risque pour les personnes concernées. Le problème technique devient alors un dossier juridique.

Le périmètre est désormais connu, et il est large : les failles touchent presque toutes les versions de PHP depuis la 5.4, sortie en 2012. Sont concernées toutes les installations qui servent des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP juge le risque le plus élevé pour mod_php. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Dix ans d'invisibilité, quelques semaines pour l'IA

Le code fautif était présent dans PHP depuis plus de dix ans. Un audit mené en 2024 par la société Quarkslab en avait repéré les premiers signes, sans qu'un correctif soit proposé : personne n'avait alors démontré qu'on pouvait réellement l'exploiter. C'est ce pas que l'IA a permis de franchir. Le 1er août, des chercheurs de la société Calif identifient plusieurs chemins d'exécution de code ; le 24 août, Wiz signale à son tour les vulnérabilités à PHP. Tous deux s'appuyaient sur des modèles d'intelligence artificielle avancés.

Calif travaillait dans le cadre de Patch the Planet, un programme lancé par OpenAI qui donne accès à ses outils les plus puissants pour trouver et corriger des failles dans les briques du web. L'équipe Codex Security d'OpenAI est d'ailleurs créditée parmi les découvreurs, aux côtés de Calif et de Wiz.

Le détail qui doit retenir l'attention d'un dirigeant vient de Wiz. Selon la société, ces modèles lui ont permis de développer et d'adapter des attaques fonctionnelles sur plusieurs applications en quelques heures. Ses chercheurs résument le changement d'échelle : un seul chercheur a accompli en une semaine ce qui aurait demandé des mois à une équipe de haut niveau.

Le calendrier prévu a d'ailleurs déraillé. La divulgation coordonnée devait laisser le temps de préparer le correctif. Mais mardi soir, Calif a publié par erreur une vidéo de son exploit fonctionnel, et des détails ont circulé sur les réseaux sociaux. Le projet PHP a annoncé les failles le jour même et publié le correctif le lendemain après-midi. Le CTO de Cloudflare, Dane Knecht, signalait déjà les premières tentatives d'attaque.

J'en tire une conviction : le délai entre la publication d'une faille et son exploitation se compte désormais en heures, et les outils d'IA qui servent aux défenseurs servent aussi aux attaquants. C'est le scénario décrit par l'alerte de 100 géants de la tech sur les cyberattaques par IA, qui se vérifie ici sur un cas réel. Une mise à jour repoussée à la semaine suivante n'est plus une option raisonnable.

Mon site internet est-il touché ? Le PHP se cache là où on ne le cherche pas

Pour Don Smith, expert de l'unité de recherche sur les menaces de Sophos, la difficulté n'est pas d'installer le correctif. Elle consiste à retrouver chaque endroit où PHP tourne, y compris là où l'entreprise ne le soupçonne pas.

La société Huntress le rappelle : PHP fait fonctionner WordPress, Drupal, Joomla, Magento, les hébergements mutualisés, les panneaux d'administration des hébergeurs et quantité de logiciels qui ne disent pas qu'ils l'utilisent. Dans une PME, l'inventaire ressemble souvent à ceci :

• le site vitrine sous WordPress, parfois accompagné d'un ancien site jamais supprimé ;
• la boutique en ligne sous PrestaShop ou Magento ;
• l'extranet client ou le portail fournisseur ;
• le CRM ou l'outil de devis développé sur mesure avec Symfony ou Laravel ;
• le panneau d'administration de l'hébergement, comme cPanel ou Plesk ;
• les logiciels et équipements tiers qui embarquent PHP, un point que le NCSC britannique souligne explicitement.

Pour chaque outil, notez trois informations : qui l'héberge, qui le met à jour, quelle version de PHP il utilise. La version s'affiche en général dans l'espace client de l'hébergeur. Sur un serveur, la commande php -v la donne en une seconde. Comparez-la ensuite aux versions corrigées : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche.

L'en-tête HTTP X-Powered-By révèle parfois la version, mais il est souvent masqué, justement pour des raisons de sécurité. Son absence ne prouve donc rien.

Les outils métier sont les plus souvent oubliés : ils ne sont pas publics, alors on les croit à l'abri. Une application interne accessible depuis Internet reste exposée. J'ai détaillé cette logique dans un article sur la nécessité d'auditer et sécuriser le code source de vos outils métiers.

Faille de sécurité PHP : qui applique le correctif chez vous ?

La réponse dépend entièrement de votre type d'hébergement. C'est précisément ce flou qui fait perdre des heures.

• Hébergement mutualisé (OVHcloud, o2switch, Ionos) : l'hébergeur met à jour les binaires PHP. Vérifiez quand même dans votre espace client que vous n'êtes pas bloqué sur une ancienne branche que vous avez choisie vous-même il y a des années. En cas de doute, demandez-lui une confirmation écrite.
• Serveur VPS ou dédié : la mise à jour revient à vous ou à votre prestataire. Sur Debian ou Ubuntu, les correctifs arrivent par les paquets de la distribution, qui reportent souvent la correction sans changer le numéro de version affiché. Fiez-vous au bulletin de sécurité de la distribution, pas au seul numéro de version. Et après la mise à jour, redémarrez PHP-FPM ou Apache : tant que les anciens processus tournent, c'est l'ancien code qui répond.
• Conteneurs Docker : l'image doit être reconstruite à partir d'une image de base corrigée, puis redéployée. Un simple redémarrage ne suffit pas.
• Logiciels tiers et SaaS : seul l'éditeur peut corriger. Exigez une réponse écrite et datée.

Reste la question de la dernière version de PHP. Le projet PHP ne publie plus de correctifs de sécurité pour les branches arrivées en fin de vie. Ici, seules les versions 8.2 et suivantes reçoivent un patch officiel. PHP 8.1, 8.0, 7.4 et toutes les versions plus anciennes restent vulnérables : un site qui tourne encore dessus n'a pas de correctif officiel à installer. Seule exception : certaines distributions maintiennent leurs propres paquets pour d'anciennes branches (Ubuntu 22.04 livre par exemple PHP 8.1). Dans ce cas, c'est le bulletin de la distribution qui fait foi. Consultez php.net pour l'avis officiel et suivez les avis du CERT-FR, la référence française en la matière.

La limite est réelle : passer de PHP 7.4 ou 8.1 à une version récente casse fréquemment de vieilles extensions WordPress ou du code écrit il y a dix ans. Ce n'est pas une opération de dix minutes. Mon conseil est de traiter les deux sujets séparément : sécuriser d'abord, puis planifier la migration avec des tests.

Pour sécuriser en attendant, l'équipe PHP a publié des mesures d'atténuation partielles, à appliquer dans la configuration PHP :

• passer session.upload_progress.enabled à 0 ;
• sur PHP 8.5, passer fatal_error_backtraces à 0 ;
• redémarrer ensuite tous les processus PHP pour que le changement soit pris en compte.

Ces réglages ferment les chemins d'attaque démontrés, pas forcément tous les autres. Ils complètent une coupure ou un filtrage, ils ne remplacent pas la mise à jour.

Faut-il mettre son site internet hors ligne ? Tout dépend de ce qu'il protège

Le NCSC britannique recommande, lorsqu'une correction immédiate est impossible, d'envisager de couper le système jusqu'à ce qu'il soit entièrement protégé. La NSA, le CERT-EU et l'agence japonaise de cybersécurité ont diffusé des consignes similaires.

Certains ont appliqué ce conseil à la lettre. La Finlande a suspendu les services web publics de son gouvernement. Aux Pays-Bas, l'agence nationale de cybersécurité a retiré son propre site, tout comme l'institut national de santé publique. La fondation Wikimedia a coupé plusieurs systèmes par précaution.

Ces organisations gèrent des données sensibles et constituent des cibles prioritaires. Pour une PME, la décision mérite d'être pesée :

• Site vitrine sur hébergement mutualisé dont l'hébergeur confirme la mise à jour : la coupure est rarement justifiée.
• Boutique, extranet ou CRM contenant des données clients, sur un serveur que vous ne pouvez pas corriger aujourd'hui : coupez, ou remplacez temporairement par une page statique de maintenance.
• Situation intermédiaire : appliquez les réglages d'atténuation ci-dessus, restreignez l'accès à l'administration par adresse IP et placez le site derrière un pare-feu applicatif.

Sur ce dernier point, une bonne nouvelle : depuis le 21 octobre à 5 h (heure de Paris), Cloudflare protège par défaut contre PHP2Shell tous les clients de son pare-feu applicatif, y compris l'offre gratuite. Pour un site qui ne peut pas être mis à jour tout de suite, passer derrière Cloudflare est une mesure d'attente rapide à mettre en place.

Mais restez lucide. Cloudflare indique ajuster ses protections à mesure que de nouveaux vecteurs d'attaque apparaissent, et demande lui-même à ses clients de mettre PHP à jour malgré tout. Un pare-feu applicatif bloque ce qu'il connaît, pas ce qu'un attaquant inventera dans deux heures. C'est un délai gagné, pas une correction.

Une coupure a aussi un coût : commandes perdues, clients inquiets, référencement perturbé si elle dure. Mais quelques jours d'arrêt d'une boutique coûtent en général moins cher qu'une fuite de fichier clients à déclarer à la CNIL.

Correctif installé : vérifier que personne n'est déjà entré

Une vidéo de l'exploit a circulé mardi soir, le correctif est sorti mercredi après-midi et des attaques étaient observées dans la foulée. Entre ces moments, un serveur exposé a pu être visité. Don Smith insiste : il faut chercher les signes qu'un attaquant a déjà pris pied sur le système.

Une mise à jour ferme la porte. Elle ne fait pas sortir quelqu'un qui est déjà à l'intérieur. Les vérifications de base tiennent en quelques points :

• des fichiers PHP apparus dans les dossiers d'envoi de fichiers, comme wp-content/uploads sur WordPress, où ils n'ont rien à faire ;
• des fichiers modifiés ces derniers jours sans intervention de votre part ;
• de nouveaux comptes administrateurs dans le CMS ou dans la base de données ;
• des tâches planifiées (cron) inconnues ;
• dans les journaux du serveur, des requêtes inhabituelles ou des connexions sortantes vers des adresses inconnues.

En cas de doute, changez les secrets : mot de passe de la base de données, clés d'API, identifiants SFTP. C'est d'autant plus justifié ici que les failles permettent de lire la mémoire du serveur, où ces secrets peuvent transiter. Si vous restaurez une sauvegarde, vérifiez sa date. Une sauvegarde réalisée après l'intrusion restaure aussi la porte dérobée.

La recherche de ces traces suit la même méthode qu'un audit de sécurité : partir de ce qui tourne réellement sur le serveur, et non de ce qui est censé y tourner.

Le NCSC ajoute un point souvent négligé : une fois la mise à jour faite, surveillez dans la durée les correctifs publiés par les éditeurs tiers, y compris pour les équipements et services qui intègrent PHP. Le correctif de PHP est disponible, mais chaque éditeur doit encore l'intégrer à ses propres produits, à son propre rythme.

Le vrai risque n'est pas PHP, c'est l'angle mort

Ces deux failles ne révèlent pas un défaut propre à PHP : tout langage utilisé à cette échelle finira par connaître le même scénario, avec des failles trouvées par l'IA en quelques semaines et exploitées en quelques heures. Ce qui sépare une entreprise qui traverse l'épisode en une après-midi d'une autre qui le subit pendant des semaines, c'est un inventaire à jour et une répartition claire des responsabilités.

Si la prochaine alerte tombait demain matin, sauriez-vous citer, sans chercher, chaque outil de votre entreprise qui tourne sur PHP et le nom de la personne chargée de le mettre à jour ?

Sources : BBC News : Websites taken down worldwide as critical cyber-security update issued BleepingComputer : PHP ships emergency patches for critical PHP2Shell flaws The Hacker News : PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws Cloudflare : Cloudflare deploys protections against php2shell vulnerability Sansec : PHP2Shell, Critical PHP RCE IT-Connect : PHP2Shell, les correctifs de sécurité sont là, les attaques aussi Cyberstrat : Faille PHP critique (PHP2Shell), que faire maintenant ?