Article mis à jour le 24 octobre 2026.
Le 21 octobre 2026, le projet PHP a publié en urgence des versions correctives pour deux failles critiques, surnommées PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Elles permettent à un attaquant non authentifié d’exécuter du code à distance sur un serveur qui fait tourner PHP. Si votre site, votre extranet ou votre application métier repose sur PHP (WordPress, Drupal, Laravel, Symfony, Prestashop…), vous êtes potentiellement concerné.
Que se passe-t-il ?
Les deux failles touchent le cœur de PHP, et non une application en particulier :
- CVE-2026-109618 : lorsque PHP manque de mémoire pendant la préparation d’une requête, des données internes incomplètes peuvent ensuite être traitées comme valides, ce qui ouvre la voie à une exécution de code.
- CVE-2026-109619 : un état interne lié à une requête peut survivre à la libération de sa mémoire et être réutilisé par une requête suivante traitée par le même processus.
Le projet PHP leur attribue un score CVSS v4 de 9,2 sur 10. Tous les modes d’exécution qui servent des requêtes web sont concernés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php, car l’attaque peut se déclencher avant même l’exécution du code de l’application.
Les failles sont-elles exploitées ?
Plusieurs acteurs de la sécurité (Amazon, Cloudflare, watchTowr) indiquent avoir observé des tentatives d’exploitation, dont certaines dès le 17 octobre, avant la publication officielle. Les constats ne sont pas tous alignés : au moment de son alerte, l’agence américaine CISA n’avait pas observé d’exploitation. Du code présenté comme un exploit circule aussi publiquement, sans être vérifié : ne l’exécutez pas, il peut contenir des logiciels malveillants. Dans tous les cas, le niveau de risque justifie d’agir sans attendre.
Quelles versions sont concernées ?
- PHP 8.5 : corrigé en 8.5.12
- PHP 8.4 : corrigé en 8.4.27
- PHP 8.3 : corrigé en 8.3.36
- PHP 8.2 : corrigé en 8.2.35
- PHP 8.1, 8.0, 7.4 et antérieures : versions en fin de vie, sans version corrigée officielle. L’équipe sécurité de PHP a seulement publié des correctifs minimaux à compiler soi-même pour 7.4, 8.0 et 8.1, et certaines distributions ou éditeurs de support étendu proposent leurs propres correctifs.
Autrement dit, un serveur encore en PHP 8.1 ou plus ancien, chez un hébergeur mutualisé par exemple, reste exposé tant qu’il n’est pas migré vers une version supportée ou corrigé par son fournisseur.
Que faire, concrètement ?
- Vérifiez votre version de PHP. Sur un serveur :
php -v. Sur WordPress : Outils → Santé du site → Informations → Serveur. Chez un hébergeur : votre espace client. - Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou plus récent), via les paquets de votre distribution ou votre hébergeur. C’est la seule correction complète.
- Redémarrez tous les processus PHP (PHP-FPM, Apache) après la mise à jour, pour que la nouvelle version soit réellement utilisée.
- Si vous êtes en PHP 8.1 ou plus ancien, planifiez la migration vers une version supportée : c’est l’occasion de sortir d’une version qui ne reçoit plus de correctifs. En attendant, demandez à votre hébergeur s’il applique un correctif.
- N’oubliez pas les logiciels qui embarquent leur propre PHP (panneaux d’administration, appliances, outils internes) : vérifiez auprès de chaque éditeur.
Et si la mise à jour est impossible tout de suite ?
Le projet PHP propose des mesures temporaires qui réduisent l’exposition sans rendre l’installation sûre. Elles doivent être appliquées dans la configuration serveur (php.ini ou pool PHP-FPM), puis suivies d’un redémarrage des processus PHP :
- désactiver le suivi de progression des uploads :
session.upload_progress.enabled = 0; - limiter la taille des requêtes (
post_max_size) et imposer des limites au niveau du serveur web ou du proxy ; - sur PHP 8.5, définir
fatal_error_backtraces = 0.
D’autres réglages sont décrits dans l’avis officiel, avec des précautions importantes : appliquez-les en connaissance de cause, idéalement avec un administrateur système. Si un site exposé sur Internet ne peut pas être corrigé, le CERT-EU recommande de l’isoler en attendant.
Une troisième faille à surveiller
Le 23 octobre, PHP a signalé une autre faille, CVE-2026-115560, liée elle aussi au suivi de progression des uploads de session. Elle ne concerne que des configurations particulières et sera corrigée dans la prochaine version régulière. La mesure session.upload_progress.enabled = 0 la neutralise également.
En résumé
Vérifiez votre version de PHP aujourd’hui, mettez à jour, redémarrez, et profitez-en pour faire le point sur les serveurs encore en version non supportée. Une politique de mises à jour régulière et automatisée reste la meilleure protection contre ce type d’alerte.
Besoin d’aide pour identifier vos serveurs exposés, mettre à jour PHP ou migrer depuis une version obsolète ? Contactez-nous ou écrivez à contact@senetech.eu.