PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre

En octobre 2026, le projet PHP a corrigé 2 vulnérabilités critiques qui peuvent permettre à un attaquant d'exécuter du code sur un serveur sans se connecter. La CISA les désigne sous le nom de « php2shell ». Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et toutes deux obtiennent un score de 9,2 en CVSS v4.0. Si une partie du service en ligne de votre entreprise tourne sous PHP, la marche à suivre est simple : assurez-vous qu'il utilise PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou une version plus récente, ou bien une version de votre fournisseur qui intègre le correctif.

Cet article explique ce qui a été corrigé, quelles versions contiennent le correctif, comment savoir quelle version annonce votre serveur et quoi demander aux personnes qui gèrent votre hébergement. Vous pouvez aussi vérifier quelle version de PHP annonce votre site en quelques secondes.

Qu'est-ce que PHP2Shell

L'avis de sécurité PHP du 21 octobre 2026 décrit 2 failles dans la manière dont PHP gère les données internes des requêtes :

• CVE-2026-109618, corruption mémoire en cas de mémoire épuisée. Lorsque PHP manque de mémoire, il peut être interrompu alors que les données internes de la requête ne sont que partiellement initialisées, et le nettoyage peut ensuite traiter des données invalides comme valides.
• CVE-2026-109619, état de requête obsolète. Un état interne appartenant à une requête peut subsister après la libération de sa mémoire, et une requête ultérieure traitée par le même worker peut l'utiliser.

Les 2 failles peuvent permettre une exécution de code à distance sans authentification. Selon l'avis, toute installation PHP qui répond à des requêtes web est concernée, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP considère mod_php comme le cas le plus risqué, car une requête peut déclencher l'attaque avant même l'exécution du moindre code applicatif. Cela signifie aussi que l'application installée par-dessus (WordPress, une boutique en ligne, un portail sur mesure) ne vous protège pas à elle seule : le correctif se trouve dans PHP.

Versions corrigées et chronologie

• 21 octobre 2026 : le projet PHP a publié les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 avec le correctif. Le même jour, le CSIRT national slovaque SK-CERT a publié une alerte et la CISA a émis un avertissement.
• 26 octobre 2026 : la CISA a ajouté les 2 CVE à son catalogue Known Exploited Vulnerabilities, la liste des vulnérabilités dont l'exploitation réelle est avérée.

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP (voir les versions prises en charge). L'avis précise que certaines distributions Linux et certains fournisseurs de support étendu rétroportent les correctifs, et que l'équipe de sécurité PHP a publié des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1 à l'intention de ceux qui compilent PHP eux-mêmes. Si votre service utilise l'une de ces branches, demandez à votre fournisseur si le correctif est inclus et planifiez le passage à une branche prise en charge.

Comment savoir quelle version de PHP vous utilisez

La réponse définitive vient du serveur lui-même, pas de l'extérieur :

• Demandez à la personne qui gère le service (votre hébergeur, votre agence ou votre équipe informatique) la version exacte de PHP et si elle inclut les correctifs du 21 octobre.
• Si vous avez un accès shell, lancez php -v. Le serveur web peut utiliser un autre binaire PHP que la ligne de commande : contrôlez donc aussi la version dans votre panneau d'hébergement ou dans le pool PHP-FPM.
• Les gestionnaires de paquets affichent les versions des fournisseurs : sous Debian et Ubuntu dpkg -l | grep php, sous RHEL et systèmes similaires rpm -qa | grep php. Comparez la version du paquet avec l'avis de sécurité de votre fournisseur, car les fournisseurs conservent souvent le numéro de version d'origine et y ajoutent le correctif.

Vu de l'extérieur, certains serveurs annoncent leur version dans les en-têtes de réponse HTTP :

X-Powered-By: PHP/8.3.12
Server: Apache/2.4.62 (Debian)

Vous pouvez voir vos propres en-têtes avec curl -sI https://www.example.com/. Notre contrôle PHP2Shell lit ces 2 mêmes en-têtes, X-Powered-By et Server, et compare le numéro avec les versions corrigées.

Ce que l'en-tête peut et ne peut pas vous dire

Lisez l'en-tête avec prudence, dans les 2 sens :

• Un ancien numéro ne prouve pas que le serveur est vulnérable. De nombreux hébergeurs appliquent le correctif au niveau du système et conservent la chaîne de version d'origine.
• Un numéro à jour est bon signe, pas une preuve. L'en-tête peut être modifié, ou défini par un proxy placé devant le serveur.
• Pas de numéro, pas d'information. La plupart des serveurs n'envoient pas du tout leur version de PHP. Lors de notre mesure portant sur 8 221 domaines d'entreprises slovaques le 31 octobre 2026, seuls 332 des 8 171 domaines qui ont répondu indiquaient une version de PHP dans leurs en-têtes (4,1 %). Pour tous les autres, l'en-tête ne dit rien dans un sens comme dans l'autre, et la question revient à la personne qui gère le service.

Que faire maintenant

1. Mettez PHP à jour vers 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou une version plus récente, ou installez le paquet corrigé de votre fournisseur. Redémarrez PHP-FPM ou le serveur web pour que la nouvelle version tourne réellement.
2. Demandez par écrit à votre hébergeur quelle version de PHP fait tourner votre service et si elle contient les correctifs de CVE-2026-109618 et CVE-2026-109619. Posez la même question pour les serveurs de préproduction et les anciens projets ; voir les serveurs de préproduction et de test oubliés.
3. Planifiez l'abandon de PHP 8.1 et des versions antérieures si aucun correctif rétroporté n'est disponible.
4. Cessez d'annoncer la version. Définissez expose_php = Off dans php.ini pour supprimer X-Powered-By, et limitez l'en-tête Server (ServerTokens Prod pour Apache, server_tokens off pour nginx). Cela ne corrige rien en soi, mais cesse d'exposer des détails aux scanners automatisés. Pour aller plus loin : les en-têtes de sécurité HTTP que tout site d'entreprise devrait envoyer.

Si vous ne pouvez pas mettre à jour immédiatement, l'avis énumère des mesures temporaires qui réduisent certains vecteurs d'attaque précis, et indique clairement que seule la mise à jour constitue une solution complète.

Comment Datahorses vous aide

Nous surveillons votre entreprise depuis l'extérieur chaque jour, telle qu'un attaquant la verrait, et nous n'avons besoin d'aucun accès à vos systèmes. Lorsqu'un serveur commence à annoncer une version logicielle obsolète, le constat est accompagné d'étapes précises pour la personne qui le gère. Découvrez ce que nous surveillons ou demandez une proposition.