22/10/2026

Failles critiques dans PHP du 21 octobre 2026 : comprendre et se protéger

Deux failles critiques ont été corrigées dans PHP, un langage majeur internet. Découvrons ensemble simplement ce qu’elles permettent, qui est concerné et ce qu’il faut faire.

Le 21 octobre 2026, l’équipe qui développe PHP a publié une alerte de sécurité : deux failles jugées critiques peuvent permettre à un inconnu de prendre la main sur un serveur web, à distance. Si votre site tourne avec WordPress ou a été développé sur-mesure, il y a de bonnes chances qu’il utilise PHP. Voici ce qu’il faut comprendre, et surtout ce qu’il faut faire.

PHP, c’est quoi ?

Quand vous ouvrez une page internet, elle n’existe pas toujours toute prête. Souvent, elle est fabriquée à la demande par le serveur, l’ordinateur qui héberge le site. PHP est l’un des langages qui servent à cette fabrication.  C’est aussi l’un des moteurs qui font tourner WordPress. D’après le site de statistiques W3Techs, PHP est utilisé par environ 69 % des sites dont on connaît le langage côté serveur.

Quelques mots de vocabulaire

  • Une faille de sécurité : une erreur dans un logiciel, qu’une personne malveillante peut utiliser pour lui faire faire ce qu’il ne devrait pas.
  • Une CVE : un numéro unique attribué à chaque faille connue, un peu comme le numéro d’un rappel de produit. Ici, il s’agit des CVE-2026-109618 et CVE-2026-109619.
  • La note de gravité : chaque faille reçoit une note sur 10, selon un barème international appelé CVSS. Ces deux failles sont notées 9,2 : c’est le niveau critique.
  • L’exécution de code à distance : le scénario le plus grave. Depuis n’importe où sur Internet, un attaquant fait exécuter ses propres commandes à votre serveur. Il pourrait alors modifier votre site, y cacher un programme malveillant ou accéder aux données qu’il contient.
Pour ces deux failles, l’attaquant n’a besoin d’aucun identifiant ni mot de passe. L’équipe PHP juge l’attaque complexe à mettre en œuvre, mais les chercheurs qui ont signalé les failles l’ont bel et bien démontrée.

Faille n°1 : quand la mémoire déborde

Pour fabriquer une page, PHP dispose d’une quantité de mémoire limitée. Si on lui en demande trop, il s’arrête net. Le problème, c’est qu’il peut s’arrêter au milieu d’une tâche et la laisser inachevée. Au moment de terminer son travail, PHP traite cette tâche incomplète comme si elle était valide.

Un attaquant peut provoquer ce débordement volontairement, par exemple en envoyant un formulaire fabriqué pour consommer énormément de mémoire. Il profite ensuite de cette incohérence pour glisser ses propres instructions.

Sur certaines installations, notamment le serveur Apache avec son module PHP, tout se joue avant même que le code de votre site ne s’exécute. La qualité du site n’y change donc rien.

Faille n°2 : les restes du visiteur précédent

Un serveur PHP fonctionne un peu comme un guichet : le même agent enchaîne les visiteurs. Entre deux visiteurs, il doit effacer ses notes. Mais dans certains cas, notamment après une erreur grave, une note du visiteur précédent reste en place, alors que le dossier auquel elle renvoie a déjà été rendu. Le visiteur suivant arrive, et l’agent consulte cette note périmée.

Un attaquant peut organiser les deux passages : une première visite pour laisser la note piégée, une seconde pour la faire utiliser. Cette faille a été démontrée sur Apache avec son module PHP, ainsi que sur PHP-FPM, une autre façon de faire tourner PHP sur un serveur.

Qui est concerné ?

Selon l’équipe PHP, toutes les installations qui servent des pages web sont exposées, quelle que soit leur configuration. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Toute version antérieure de ces branches est vulnérable.

Les versions plus anciennes posent un problème à part. PHP 8.1 et les versions précédentes ne reçoivent plus de mises à jour du projet PHP. Or, toujours selon W3Techs, plus d’un tiers des sites en PHP tournent encore sur une version 7 ou plus ancienne. Pour eux, la vraie solution est de passer à une version maintenue, sauf si l’hébergeur fournit lui-même un correctif. À noter aussi : PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.

 Pourquoi il faut agir vite

Particularité de cette affaire : les failles ont fuité avant leur publication officielle. L’équipe PHP a donc dû avancer son correctif, et les chercheurs leur ont donné un surnom, « PHP2Shell ».

Depuis le 21 octobre, des entreprises spécialisées en cybersécurité observent des tentatives d’attaque visant ces deux failles, et certaines parlent déjà d’une exploitation à grande échelle. Autrement dit, des attaquants cherchent activement les serveurs qui n’ont pas encore été mis à jour. Au moindre doute sur le vôtre, c’est à vérifier dès aujourd’hui.

Comment s’en prémunir

La seule protection complète est de mettre à jour PHP. Concrètement, la marche à suivre dépend de qui gère votre site :

  • Votre site est sur un hébergement mutualisé, c’est-à-dire une offre où l’hébergeur gère le serveur pour vous : c’est en général lui qui met PHP à jour. Vérifiez dans votre espace client la version de PHP choisie pour votre site. Si c’est une version 8.1 ou plus ancienne, prévoyez de passer à une version récente, après avoir vérifié que votre site la supporte.
  • Votre site est géré par un prestataire : posez-lui la question par écrit, par exemple : « Quelle version de PHP fait tourner mon site, et intègre-t-elle les correctifs de sécurité du 21 octobre 2026 ? »
  • Votre site est sur un serveur que vous administrez, ou que quelqu’un administre pour vous : la mise à jour doit être faite sur ce serveur. Les distributions Linux ont reçu les correctifs en avance, ils sont donc normalement disponibles dans les mises à jour habituelles.
  • Votre site tourne sous WordPress : mettre à jour WordPress et ses extensions reste indispensable, mais ne suffit pas ici. La faille se trouve dans PHP, sous WordPress. Les deux mises à jour sont nécessaires, et l’une ne remplace pas l’autre.

Pour les personnes à l’aise avec la technique

  • Mettez à jour vers une version corrigée, ou installez les paquets à jour de votre distribution, puis redémarrez tous les processus PHP.
  • Si vous ne pouvez pas mettre à jour immédiatement, l’équipe PHP propose des mesures qui réduisent l’exposition sans la supprimer. Il s’agit d’imposer memory_limit=-1 au niveau administrateur, en le combinant avec une limite mémoire au niveau du système ou du conteneur. Il faut aussi garder un post_max_size bas, désactiver session.upload_progress.enabled et, sur PHP 8.5, désactiver fatal_error_backtraces. Ces réglages se font dans php.ini ou dans la configuration du serveur, pas via ini_set() ni .user.ini, et il faut redémarrer tous les processus après les avoir modifiés.
  • Pour PHP 7.4, 8.0 et 8.1, l’équipe PHP a publié des correctifs minimaux à compiler soi-même, pour les cas sans support étendu.
  • Tous les détails sont dans l’alerte officielle et les deux bulletins techniques, en lien dans les sources.

Ce que j’en retiens

Ce que cette affaire rappelle à tous, c’est qu’un site internet n’est jamais vraiment « fini ». Comme n'importe quel outil de travail, il doit être pensé pour une utilisation quotidienne et nécessite un entretien régulier.

Cet entretien demande deux choses. D’abord, ne pas le repousser. Garder une vieille version de PHP pour ne pas toucher à un site qui « marche » paraît plus simple et moins cher sur le moment. Mais le jour où une faille comme celle-ci tombe, il n’y a plus de correctif à appliquer, seulement une migration à faire dans l’urgence. Je préfère de loin des mises à jour régulières et sans stress à un chantier précipité.

Ensuite, savoir qui s’en charge. Une faille dans PHP ne se corrige pas en modifiant le site, mais le serveur qui le fait tourner. Or, l’hébergeur pense parfois que c’est le prestataire, le prestataire que c’est l’hébergeur, et le propriétaire du site que tout est compris. Une faille comme celle-ci ne crée pas ce flou, elle le révèle.

Si vous ne savez pas qui gère la version de PHP de votre site, c’est le bon moment pour le découvrir. Et si vous avez besoin d’aide pour y voir clair, écrivez-moi.

Sources

← Retour au blog