php2shell : à quelle vitesse les hébergeurs ont fermé la faille critique de PHP

Le 20 octobre, le projet PHP a annoncé pour le lendemain une version de sécurité critique, à 14 h UTC. Le 21 octobre à 16 h, heure allemande, PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 étaient disponibles. Ce qui se passe ensuite échappe, pour la plupart des exploitants de sites, à leur contrôle : avec un hébergement mutualisé ou WordPress géré, vous restez vulnérable tant que l'hébergeur n'a pas installé la mise à jour sur ses serveurs.

Nous gérons un certain nombre de sites et d'applications chez différents hébergeurs, les nôtres et ceux de clients. Pour 27 d'entre eux, nous avons noté ce soir-là quand la nouvelle version est arrivée. Le résultat n'est pas un test d'hébergeurs, mais un regard honnête sur l'écart de rapidité.

Ce qu'est php2shell

Selon l'avis de sécurité du projet PHP, ce nom recouvre deux erreurs dans la gestion de la mémoire entre deux requêtes. Avec CVE-2026-109618, une interruption pour manque de mémoire peut laisser des données dans un état à moitié terminé, que PHP juge valides lors du nettoyage. Avec CVE-2026-109619, l'état interne d'une requête subsiste alors que sa mémoire est déjà libérée, et la requête suivante dans le même processus y accède. Les deux sont notées CVSS 9.2 et permettent, dans le pire des cas, d'exécuter son propre code sur le serveur.

Toute installation PHP qui répond à des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php. L'attaquant n'a pas besoin de s'authentifier, et l'attaque agit avant même que WordPress ou une extension n'exécute du code. Une extension de sécurité n'en voit donc rien.

Les sources évaluent différemment l'ampleur des attaques déjà en cours. Le Centre canadien pour la cybersécurité a signalé les 21 et 23 octobre une preuve de concept publique, mais aucune exploitation constatée (alerte AL26-026). Selon Help Net Security, Amazon a observé une tentative d'exploitation dès le 17 octobre, quatre jours avant la publication.

Notre mesure : 27 systèmes, sept hébergeurs et un serveur à nous

Nous avons mesuré de l'extérieur et en lecture seule. La plupart des hébergeurs indiquent la version de PHP dans l'en-tête de réponse X-Powered-By. Nous l'avons interrogé toutes les cinq minutes chez Hostinger et STRATO, sur wp-login.php, parce que cette page ne vient jamais du cache et que PHP y tourne à coup sûr. Chez Raidboxes, la version figurait dans le rapport système de WooCommerce. All-Inkl masque l'en-tête de réponse ; là, un fichier de test d'une seule ligne a affiché la version et a été supprimé aussitôt après. Chez united-domains et CheckDomain, la version n'était pas lisible de l'extérieur.

Deux réserves s'imposent. Nous avons mesuré nos propres comptes, pas un échantillon sur tous les serveurs d'un hébergeur. Les grands hébergeurs déploient souvent les mises à jour serveur par serveur ; d'autres clients ont pu être servis plus tôt ou plus tard. Et entre le 22 et le 26 octobre, nous n'avons rien mesuré chez Hostinger : nous ne savons donc pas à quel moment exact la 8.3.36 est arrivée.

Ce que nous en retenons

L'écart est grand, et vous ne le voyez pas

Entre l'hébergeur le plus rapide et le plus lent de notre mesure, il y a au moins 13 heures, une nuit entière. De l'extérieur, rien n'indique si le serveur d'un site est déjà corrigé. Qui ne vérifie pas lui-même ne le sait pas.

Un serveur à soi est aussi rapide que son étape la plus lente

Sur notre propre serveur tourne une application sous Docker, construite sur l'image PHP officielle. L'image portant le numéro 8.4.27 est sortie à 17 h 45, la version pour les serveurs Intel et AMD classiques seulement à 18 h 47. Notre reconstruction a tourné à 18 h 51. Pour qu'elle récupère bien la nouvelle image de base au lieu de reprendre l'ancienne depuis le cache, nous avons dû modifier les instructions de construction. Depuis, chaque build va chercher l'image la plus récente.

Coolify, la plateforme avec laquelle nous gérons ce serveur, a publié sa mise à jour avec la version corrigée de PHP douze minutes seulement après la sortie. Chez nous, elle n'est pourtant arrivée qu'avec la mise à jour automatique nocturne. Les éditeurs rapides servent à peu de chose si la mise à jour reste en attente sur votre système.

Les anciennes branches de PHP ne reçoivent plus rien

Un système tournait encore sous PHP 8.1. Pour 8.1 et les versions plus anciennes, le projet PHP ne publie plus de versions ; il n'existe que des corrections minimales dans le code source, pour ceux qui compilent PHP eux-mêmes. Sur un hébergement mutualisé, seul le passage à une branche prise en charge aide. Un autre système avait déjà cinq versions de retard avant la version de sécurité : 8.2.29 au lieu de 8.2.34. La bonne nouvelle : la version de sécurité l'a entraîné avec elle, lors du relevé suivant il tournait sous 8.2.35.

Sans PHP, pas de faille PHP

Notre site principal hafenstudios.com n'était pas concerné, car il se compose de fichiers HTML statiques. Pour un site WordPress, ce n'est pas une option, mais cela montre pourquoi les parties qui n'ont pas besoin de PHP ne devraient pas en exécuter.

Comment vérifier votre version de PHP dans WordPress

1. Dans le tableau de bord : Outils > Santé du site > onglet Infos, puis déplier la section Serveur. La version de PHP avec laquelle WordPress tourne actuellement y figure.
2. Comparer avec le tableau : votre branche est corrigée à partir du numéro indiqué dans la colonne « Corrigée à partir de ».
3. Bien lire les suffixes : après le numéro peut figurer une abréviation de l'hébergeur, par exemple 8.3.36-nmm1. Seul compte le numéro qui précède.

Une exception : certaines distributions Linux et certains hébergeurs intègrent la correction dans leur propre version, sans changer le numéro. Si vous voyez un numéro plus ancien et que votre hébergeur affirme avoir corrigé, ce n'est pas une contradiction. Dans ce cas, sa confirmation écrite fait foi.

Qui gère beaucoup de sites peut aussi, à partir de WordPress 6.9, consulter l'API REST, avec un mot de passe d'application et en lecture seule : /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run renvoie entre autres la version de PHP.

Si votre hébergeur n'a pas encore corrigé

• Demander. Une courte phrase au support suffit : quand PHP 8.x.y avec la correction de CVE-2026-109618 et CVE-2026-109619 sera-t-il disponible ? La réponse vous montre aussi le sérieux avec lequel votre hébergeur prend la chose.
• Changer de branche. Beaucoup d'hébergeurs proposent plusieurs versions de PHP au choix. Si une autre branche est déjà corrigée, vous pouvez y passer après un bref test. Faites d'abord une sauvegarde, puis parcourez la page d'accueil, la connexion et les formulaires.
• Un pare-feu comme solution transitoire. Cloudflare a déployé des règles contre les voies d'attaque connues, y compris dans l'offre gratuite. Le projet PHP écrit toutefois clairement qu'il n'existe aucune parade complète. Le pare-feu ne remplace pas la mise à jour.
• Sur vos propres serveurs : mettre à jour les paquets, reconstruire les conteneurs avec une image de base récente, puis redémarrer tous les processus PHP. Les réglages avec lesquels le projet PHP propose de combler le délai avant la mise à jour figurent dans l'avis de sécurité.

Un complément est paru le 23 octobre : une troisième faille, CVE-2026-115560, se trouve dans l'indicateur de progression des envois de fichiers dans les sessions. Elle ne joue que si une application change à l'exécution le format de stockage de ses sessions PHP. WordPress lui-même n'utilise pas de sessions PHP ; seules des extensions qui le font entreraient éventuellement en ligne de compte. La correction viendra avec la prochaine version régulière, et d'ici là le projet PHP recommande session.upload_progress.enabled=0. Sur un hébergement mutualisé, seul l'hébergeur peut le définir.

Et si vous faites de toute façon le ménage : les mises à jour de PHP ne sont que la moitié du travail. Pourquoi les extensions obsolètes sont le plus gros problème durable, notre article sur la mise à jour des extensions WordPress l'explique. À quel point les exigences minimales du répertoire d'extensions sont parfois anciennes, notre analyse le montre : 8 131 extensions mentionnent encore PHP 5 (en anglais).

Questions fréquentes