Vulnérabilités critiques dans PHP (CVE-2026-109618 et CVE-2026-109619) : ce que nous avons fait

Le 21 octobre, l'équipe de PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux vulnérabilités critiques connues sous le nom de PHP2Shell : CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 sur 10. Elles permettent d'exécuter du code sur un serveur avec une simple requête au site, sans identifiant ni mot de passe, et touchent pratiquement toute installation de PHP, quelle que soit l'application : WordPress, PrestaShop, Laravel ou un site fait main.

Vous n'avez rien à faire : toutes les versions de PHP de nos serveurs, de la 5.2 à la 8.5, sont corrigées depuis les premières heures du 22 octobre.

Le 23 octobre, PHP a signalé une troisième voie, CVE-2026-115560, qui n'a pas encore de correctif. Sur nos serveurs, elle était fermée depuis le 21 : nous l'expliquons plus bas.

Si votre site utilise PHP 8.2, 8.3, 8.4 ou 8.5, vous verrez le même numéro que celui publié par PHP, par exemple 8.5.12. Avec une version plus ancienne, vous verrez celui de toujours, par exemple 7.4.33, et c'est normal : PHP ne publie pas de nouvelles versions de ces branches, et CloudLinux, qui maintient les versions de PHP que nous utilisons, y intègre la correction sans changer le numéro. Le tableau plus bas indique la version corrigée de chaque branche. Voici ce que nous avons fait.

Avant la sortie du correctif

La veille, PHP avait annoncé qu'il publierait le correctif le 21 à 16 h, heure d'Espagne, et les détails ont fuité avant l'heure. Nous n'avons pas attendu le correctif : nous suivons les alertes de sécurité par tous les canaux, pas seulement les canaux officiels, et dès que les premiers rapports non officiels ont commencé à circuler :

• Nous avons désactivé sur tous les serveurs la fonction de PHP par laquelle entrait la partie confirmée de l'attaque : le suivi de la progression des envois de fichiers dans la session. Nous l'avons fait dans toutes les versions de PHP que nous proposons, de la 5.2 à la 8.5, et nous avons vérifié compte par compte qu'elle était bien désactivée.
• Nous avons ajouté nos propres règles au pare-feu applicatif web de tous les serveurs, qui rejettent les tentatives connues avant qu'elles n'atteignent PHP. Elles s'ajoutent à celles que CloudLinux a déployées dans Imunify360.

Aucune de ces mesures ne change quoi que ce soit pour votre site. La seule chose qui cesse de fonctionner est la barre de progression des applications qui la calculaient avec cette fonction de PHP, ce qui est très rare : la plupart la calculent dans le navigateur.

Ces mesures réduisent le risque, mais elles ne remplacent pas la mise à jour. C'est ce que dit l'équipe de PHP elle-même, et c'est pourquoi nous l'avons installée dès qu'elle a été disponible.

La mise à jour

Nos serveurs utilisent les versions de PHP maintenues par CloudLinux. Nous avons installé ses versions corrigées au fur et à mesure de leur publication, et depuis les premières heures du 22 octobre, la correction est appliquée sur tous les serveurs, dans toutes les versions que nous proposons : de la 5.2 à la 8.5.

De la 8.2 à la 8.5, le numéro est désormais celui que PHP a publié avec la correction : 8.5.12, par exemple. Dans les versions plus anciennes, CloudLinux intègre la correction sans changer le numéro de version, c'est pourquoi PHP affiche toujours le même : 7.4.33, par exemple.

Pour la 8.2, la 8.3, la 8.4 et la 8.5, CloudLinux a d'abord publié la correction sans changer le numéro, et c'est ce que nous avons installé les 21 et 22 : si vous avez vu 8.5.11 sur votre site ces jours-là, il était déjà corrigé. CloudLinux a ensuite publié les mêmes corrections avec les numéros de PHP, et nous les avons installées aussi : elles changent le numéro, pas la protection, en place depuis le 22. Selon les mots de CloudLinux : « If you have already installed the fixed packages from our earlier updates (for example alt-php85 8.5.11-5), your servers are already protected against CVE-2026-109618 and CVE-2026-109619. This update only brings the version numbers in line with PHP.net ». Autrement dit : ceux qui avaient déjà les paquets précédents, comme le 8.5.11-5, étaient protégés, et les nouveaux ne font qu'aligner le numéro sur celui de PHP. CloudLinux l'explique dans son avis sur ces vulnérabilités.

La mise à jour ne vous a demandé aucune action et n'a pas interrompu le service.

L'avis du 23 octobre : CVE-2026-115560

Le 23 octobre, l'équipe de PHP a signalé une autre voie pour exécuter du code sur le serveur, CVE-2026-115560. Les versions du 21 ne la corrigent pas : la correction arrivera avec la prochaine version de PHP. C'est une voie différente, et ce que ces versions corrigent, CVE-2026-109618 et CVE-2026-109619, reste corrigé.

Elle ne peut être exploitée que dans une combinaison peu courante : l'application modifie, dans son propre code, le format dans lequel PHP enregistre la session et, en plus, le suivi de la progression des envois de fichiers dans la session est activé. En attendant la correction, PHP recommande de désactiver cette fonction, et précise que ceux qui l'ont déjà fait après son avis du 21 n'ont rien d'autre à faire.

C'est notre cas : c'est la même fonction que nous avons désactivée le 21 octobre sur tous les serveurs et dans toutes les versions de PHP, de la 5.2 à la 8.5, et elle est toujours désactivée. Les règles du pare-feu applicatif web que nous avons ajoutées ce jour-là rejettent en outre les requêtes qui tentent de l'utiliser avant qu'elles n'atteignent PHP. Vous n'avez rien à faire. Quand PHP et CloudLinux publieront la correction, nous l'installerons comme celle-ci.

Et si mon site utilise une ancienne version de PHP ?

Le projet PHP ne corrige que les versions qu'il maintient : à partir de la 8.2. Pour la 8.1, la 7.x et la 5.x, il ne publie pas de nouvelles versions. Chez la plupart des hébergeurs, un site en PHP 7.4 reste aujourd'hui sans protection.

Pas chez Hostsuar. CloudLinux maintient des correctifs de sécurité pour toutes les versions que nous proposons, de la 5.2 à la 8.5, et a aussi corrigé ces deux vulnérabilités dans les anciennes. La correction y est déjà installée, comme dans les autres : votre site est protégé sans changer de version.

Tenir à jour la version que vous utilisez, c'est notre travail : vous n'avez donc pas à changer de version de PHP à cause de ces vulnérabilités. Si un jour vous voulez passer à une version plus récente, pour les performances ou parce qu'une nouvelle extension le demande, vous pouvez voir les versions disponibles dans Versions de PHP disponibles sur tous les services d'hébergement et changer celle de votre site dans Changer la version de PHP d'un site avec vérification et retour arrière : nous vérifions que le site répond toujours avec la nouvelle version et, sinon, il revient à la précédente. Si votre site a besoin de modifications pour fonctionner avec une version actuelle, écrivez-nous et nous regarderons.

Si vous avez PHP ailleurs

Si vous gérez vous-même un serveur avec PHP en dehors de Hostsuar, mettez-le à jour vers la 8.5.12, la 8.4.27, la 8.3.36 ou la 8.2.35, ou installez le paquet corrigé de votre distribution, puis redémarrez PHP. Pour CVE-2026-115560, définissez aussi session.upload_progress.enabled = 0 dans le php.ini ou dans la configuration de PHP-FPM avant de le redémarrer : avec ini_set() depuis l'application, cela ne fonctionne pas. Si vous avez des questions, écrivez-nous.