Le 21 octobre 2026 à 14:00 UTC, l’équipe PHP a publié les correctifs de deux failles critiques, CVE-2026-109618 et CVE-2026-109619, connues sous le nom de PHP2Shell. Nous avons commencé environ une heure plus tard. Vers 17:00 UTC, tous les serveurs que nous maintenons étaient sécurisés : 88 projets sous notre support. Voici comment nous avons procédé et ce qui nous a freinés, car les mêmes obstacles se trouvent sur beaucoup de serveurs que personne n’a encore corrigés.
Si vous voulez seulement savoir si votre site est concerné et quoi demander à votre hébergeur, lisez notre premier article sur PHP2Shell.
Première heure : couper le chemin d’attaque partout
Installer un PHP corrigé sur des dizaines de serveurs prend du temps. Désactiver le mécanisme vulnérable prend quelques minutes. Nous avons donc commencé par là, sur chaque serveur, avant de compiler quoi que ce soit.
L’avis de sécurité de PHP cite session.upload_progress.enabled parmi les chemins d’exploitation de CVE-2026-109619. Nous l’avons désactivé dans la configuration PHP principale de chaque version de PHP sur chaque serveur, puis redémarré les workers PHP. L’avis précise que .user.ini et ini_set() ne comptent pas, nous avons donc modifié les fichiers au niveau du serveur. Sous PHP 8.5, nous avons aussi désactivé fatal_error_backtraces, comme l’avis le suggère.
Cela fermait uniquement le chemin confirmé de CVE-2026-109619 par les sessions. Pour CVE-2026-109618, il fallait la mise à jour elle-même.
Trois types de serveurs, trois façons de corriger
Nos 88 projets tournent sur des configurations variées, et chacune demandait sa propre méthode.
Serveurs avec PHP issu des paquets de la distribution. Ici, le correctif vient des mainteneurs des paquets. Ubuntu a publié des paquets corrigés le jour même. Un piège pour qui vérifie un tel serveur : après la mise à jour, php -v peut encore afficher l’ancien numéro, par exemple 8.3.6, car Ubuntu corrige le paquet sans changer la version. Vérifiez plutôt la version du paquet.
Serveurs gérés par un panneau d’hébergement. Plusieurs serveurs utilisent aaPanel, qui compile son propre PHP. Le jour de la publication, le panneau n’avait pas de PHP à jour. Attendre le panneau revenait à laisser ces serveurs ouverts pour une durée inconnue, alors nous avons compilé PHP nous-mêmes.
Conteneurs Docker. Certains projets font tourner PHP dans des conteneurs construits à partir d’images existantes. Reconstruire et redéployer toute une application en plein incident ajoute du risque. Nous avons plutôt corrigé le PHP à l’intérieur des conteneurs en cours d’exécution et planifié des reconstructions d’images propres pour plus tard.
Compiler PHP nous-mêmes sans casser le panneau
Le PHP d’un panneau n’est pas compilé comme un PHP standard. Si vous compilez PHP avec les options par défaut et le remplacez tel quel, des extensions disparaissent et le panneau ne reconnaît plus son propre PHP.
Nous avons écrit un script de compilation et l’avons lancé pour chaque version de PHP sur chaque serveur à panneau :
- il lit les options configure exactes du PHP déjà installé, pour que la nouvelle compilation ait les mêmes extensions et les mêmes chemins ;
- il compile la version corrigée depuis les sources officielles ;
- il vérifie contre quelles bibliothèques OpenSSL et curl le nouveau binaire est lié. Le panneau lie certaines versions de PHP à ses propres copies, plus anciennes, de ces bibliothèques, et le script s’assure que la nouvelle compilation utilise les mêmes ;
- il sauvegarde les anciens binaires, installe les nouveaux et redémarre PHP ;
- si PHP ne redémarre pas, il restaure lui-même les anciens binaires.
Grâce au script, nous pouvions corriger une version de PHP sur un serveur, vérifier les sites, puis recommencer sur le suivant sans travail manuel à chaque fois.
PHP 7.4, 8.0 et 8.1 : pas de version officielle
L’équipe PHP ne publie plus de versions pour ces branches. Pour PHP2Shell, elle n’a publié que les modifications du code source pour 7.4, 8.0 et 8.1. Certains de nos projets tournent encore sur ces versions.
Pour eux, nous avons appliqué les correctifs de l’équipe PHP à la dernière version de chaque branche et compilé avec le même script. Les modifications publiées touchent aussi des fichiers de version et des changelogs, qui ne s’appliquent pas proprement sur une version publiée. Nous n’avons donc appliqué que les modifications du code.
Un serveur faisait tourner PHP 7.4 depuis les paquets d’Ubuntu 20.04. Pour cette version d’Ubuntu, le correctif n’arrive que par la maintenance de sécurité étendue d’Ubuntu (ESM), que ce serveur n’utilise pas. Nous avons compilé PHP 7.4 avec les mêmes options de compilation qu’Ubuntu et remplacé uniquement le binaire PHP-FPM, en gardant l’original à côté. Une future mise à jour du paquet écraserait notre compilation, et nous l’avons noté dans la documentation du projet.
Conteneurs : corrigés maintenant, reconstruits plus tard
Pour chaque conteneur, nous avons compilé le PHP corrigé dans une copie propre de l’image officielle pour le même système d’exploitation. Ensuite, nous avons copié uniquement les binaires PHP et les extensions nécessaires dans le conteneur en cours d’exécution, avec une sauvegarde des originaux à l’intérieur.
Une image basée sur Alpine demandait les mêmes patchs supplémentaires sur les sources que ceux appliqués par l’image Docker officielle de PHP. Sans eux, la compilation échouait avec un compilateur plus récent.
Le piège de cette approche : le correctif ne tient que jusqu’à ce que quelqu’un recrée le conteneur à partir de l’ancienne image. Si votre équipe a corrigé des conteneurs de cette façon, prévoyez une reconstruction des images, sinon la faille revient au prochain déploiement.
Après le correctif : les journaux
Une fois que chaque serveur tournait avec un PHP corrigé, nous avons parcouru les journaux du serveur web et de PHP sur tous les serveurs, à la recherche de requêtes correspondant à une exploitation possible des failles. Nous n’avons trouvé aucun signe d’exploitation.
Ce que nous dirions à un propriétaire de site après cette soirée
- La vitesse de votre hébergeur est votre vitesse. Si votre PHP vient d’un panneau ou d’un prestataire qui attend ce panneau, votre site reste ouvert tant qu’il n’agit pas. Demandez-lui aujourd’hui quelle version vous utilisez.
- Un vieux PHP continue de coûter. PHP 8.1 et antérieurs n’ont reçu cette fois que des correctifs sous forme de code source. La prochaine fois, il n’y en aura peut-être aucun. Le support de PHP 8.2 se termine le 31 décembre 2026.
- Les conteneurs et les compilations maison ont besoin d’un responsable. Personne ne les met à jour automatiquement. Quelqu’un doit savoir qu’ils existent et comment les reconstruire.
Notre supervision automatique tourne en continu, et nos ingénieurs interviennent quand elle signale un incident.
Si vous avez besoin de la même chose pour vos serveurs
Nous vérifions votre version de PHP et la mettons à jour en un jour ouvré. Écrivez-nous.
Pour un suivi régulier, voyez notre maintenance de serveurs, notre maintenance de sites et nos services DevOps. Si votre application mobile communique avec un backend PHP, ce backend a besoin de la même mise à jour. Nous le prenons en charge dans le cadre de la maintenance d’applications mobiles. Pour savoir si autre chose reste ouvert, commandez un test d’intrusion.
Sources
- Annonce et mesures d’atténuation de l’équipe PHP : https://www.php.net/archive/2026.php
- Avis de sécurité : https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w et https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu : https://ubuntu.com/blog/php2shell-vulnerability-fixes-available