En bref : une mise à jour PHP LiteSpeed concerne les paquets lsphp, par lesquels LiteSpeed exécute PHP via LSAPI. Après la mise à jour, tous les processus lsphp doivent redémarrer, et c'est précisément ce qui ne se produit pas toujours automatiquement avec le serveur web chez LiteSpeed. Vérifiez l'état des paquets et l'heure de démarrage des processus avant de classer le serveur comme corrigé.
LiteSpeed, LSAPI et lsphp en bref
LiteSpeed Web Server et sa variante libre OpenLiteSpeed n'exécutent pas PHP comme module, mais via une interface propre appelée LSAPI. Les programmes PHP correspondants s'appellent lsphp et proviennent le plus souvent de sources de paquets dédiées, par version par exemple lsphp83 ou lsphp84. Sur des panneaux comme cPanel, Plesk ou CyberPanel, des paquets PHP propres au panneau peuvent s'y ajouter.
PHP2Shell regroupe les failles CVE-2026-109618 et CVE-2026-109619 dans PHP lui-même, chacune évaluée à CVSS v4.0 9.2. Le projet PHP cite expressément LiteSpeed parmi les modes d'exécution concernés. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Mise à jour PHP LiteSpeed : recenser l'existant
Déterminez d'abord quelles versions de lsphp sont installées et lesquelles sont utilisées. Les commandes suivantes se contentent de lire. Les chemins et noms de paquets sont des exemples et dépendent de l'installation et de la distribution.
# Versions de lsphp installées (chemin typique)
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null
for p in /usr/local/lsws/lsphp*/bin/lsphp; do echo "$p"; "$p" -v | head -1; done
# État des paquets (exemples)
rpm -qa | grep -E '^lsphp[0-9]+' | sort
dpkg -l | grep -E 'lsphp[0-9]+'
# Processus lsphp en cours avec heure de démarrage
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Comparez la liste avec la configuration : quel hôte virtuel utilise quel External App Handler ? Dans l'interface LiteSpeed, vous le trouvez sous Server Configuration et dans les paramètres des hôtes virtuels. Les versions sans attribution doivent malgré tout être mises à jour ou supprimées.
Tenir compte des backports et des sources de paquets
Si lsphp provient d'une source tierce, c'est l'état de ses paquets qui décide. Si un panneau ou une distribution fournit PHP, c'est son indication qui fait foi. Dans les deux cas, une correction peut être livrée sous forme de backport sans que le numéro de version affiché change. Vérifiez donc les notes de modification du fournisseur de paquets et faites-vous confirmer l'état en cas de doute. Le numéro de version seul n'est pas une preuve.
Redémarrage : ce qui compte avec LiteSpeed
LiteSpeed peut exploiter PHP dans ce qu'on appelle le Detached Mode. Les processus lsphp continuent alors de tourner indépendamment du serveur web, afin que les sites répondent plus vite après un redémarrage du serveur web. Pour une mise à jour de sécurité, c'est un piège : le serveur web est redémarré, mais d'anciens processus PHP avec le code vulnérable restent actifs.
# Redémarrer le serveur web (chemin à titre d'exemple)
/usr/local/lsws/bin/lswsctrl restart
# Puis contrôler : tous les processus lsphp sont-ils plus récents que la mise à jour ?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Si un processus lsphp affiche une heure de démarrage antérieure à la mise à jour, arrêtez-le de façon ciblée. À la requête suivante, LiteSpeed démarre un nouveau processus avec le code mis à jour. Planifiez cette étape en dehors des heures de forte charge, car la première requête par site peut ensuite prendre un peu plus de temps.
Après la mise à jour de PHP, un serveur n'est corrigé que lorsque aucun processus lsphp n'est plus ancien que la mise à jour. Consignez le contrôle avec la date et l'heure.
Mesures transitoires en attendant le correctif
Si aucun paquet corrigé n'est encore disponible pour une version de lsphp, php.net recommande des mesures transitoires. Elles n'offrent pas de protection complète. Définissez les valeurs dans le php.ini de la version de lsphp concernée ou dans la configuration du serveur, pas dans .user.ini ni via ini_set().
; php.ini de la version de lsphp concernée (chemin selon l'installation)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Avec une fonction d'envoi de fichiers, php.net indique post_max_size = 32M, avec upload_max_filesize en dessous. Sur PHP 8.5, fatal_error_backtraces=0 s'y ajoute. Définissez les limites de mémoire via les cgroups, sur CloudLinux par exemple via les limites qui y sont prévues, et non via RLIMIT_AS ou RLIMIT_DATA. Suit alors un nouveau redémarrage de tous les processus lsphp. Autres détails : Mesures immédiates sans correctif. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement un serveur web du réseau lorsque la mise à jour n'est pas possible immédiatement.
Après la mise à jour
Un correctif ferme la faille, mais ne supprime pas un logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. Conservez les journaux d'accès à partir du 20 octobre 2026 et recherchez sur les sites de nouveaux fichiers PHP dans les répertoires d'envoi, des comptes administrateur étrangers et des connexions sortantes inhabituelles. Notre supervision de sécurité propose des repères pour la surveillance continue. Sur les serveurs cPanel avec LiteSpeed, un coup d'œil à cPanel et WHM vaut la peine en complément.
De nombreux serveurs LiteSpeed fonctionnent sous un panneau d'hébergement comme cPanel, Plesk, DirectAdmin ou CyberPanel. Le panneau détermine alors de quelle source provient lsphp et comment les mises à jour sont installées. Dans ce cas, effectuez les mises à jour via le panneau ou ses sources de paquets et n'installez pas en parallèle depuis une seconde source, sinon il devient difficile de savoir quelle version tourne réellement. Consignez en outre quel site fonctionne avec quelle version de lsphp. Sur les serveurs comptant de nombreux comptes clients, cette liste est la base pour informer les titulaires de comptes de façon ciblée et pour vérifier par sondage, après la mise à jour, que les sites fonctionnent sans erreur. Les sites qui exigent une version de PHP qui n'est plus prise en charge doivent figurer sur une liste distincte, car aucune mise à jour officielle ne viendra pour eux.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons toutes les versions de lsphp, sources de paquets et attributions de handlers de votre serveur.
- Via le service de correctifs PHP, nous mettons à jour, arrêtons tous les anciens processus lsphp et documentons la preuve.
- Là où aucun paquet n'est encore disponible, nous définissons les valeurs transitoires pour tout le serveur et limitons la mémoire par cgroup.
- Nous examinons les sites à la recherche de traces d'une attaque et sauvegardons les journaux.
Questions fréquentes
LiteSpeed est-il concerné par PHP2Shell ?
Oui. Selon le projet PHP, LiteSpeed fait partie des modes d'exécution concernés. Les failles se trouvent dans PHP lui-même, que LiteSpeed exécute via LSAPI. C'est donc l'état des paquets lsphp qui est déterminant.
Pourquoi d'anciens processus lsphp tournent-ils encore après la mise à jour ?
LiteSpeed peut laisser les processus PHP tourner indépendamment du serveur web afin de gagner du temps de chargement. Selon le mode d'exécution, un redémarrage du serveur web ne les arrête pas immédiatement. Vérifiez donc l'heure de démarrage de tous les processus lsphp.
Cela vaut-il aussi pour OpenLiteSpeed ?
En principe oui. OpenLiteSpeed utilise également lsphp via LSAPI. Les chemins, les sources de paquets et l'interface d'administration diffèrent, mais le principe reste le même : mise à jour, redémarrage et contrôle.
Le cache LiteSpeed protège-t-il contre la faille ?
Non. Un cache de pages sert certes certaines pages sans PHP, mais les requêtes qui atteignent PHP restent vulnérables. Un cache ne remplace pas la mise à jour de PHP.