PHP2Shell : pourquoi cette faille PHP fait paniquer les entreprises

Ce qui s’est passé

Le 21 octobre 2026, l’équipe PHP a publié des versions de sécurité — 8.5.12, 8.4.27, 8.3.36 et 8.2.35 — pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell ». Notées 9,2 sur 10 (CVSS v4.0), elles permettent à un attaquant non authentifié d’exécuter du code à distance, avec les droits du worker web.

Sont concernées toutes les installations qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le projet PHP juge mod_php le plus exposé, avec un exploit démontré qui peut se déclencher avant l’exécution de tout code applicatif.

Ce qui est établi, et ce qui ne l’est pas

Établi : les correctifs sont publiés ; Amazon Threat Intelligence a observé, dans son honeypot MadPot, une tentative d’exploitation le 17 octobre, quatre jours avant la divulgation ; Cloudflare dit voir émerger des premières attaques.

Plus nuancé : à la publication de son alerte, la CISA n’avait observé aucune exploitation. Rapid7 signale plusieurs codes d’exploitation publics, dont aucun n’est fiable sur toutes les configurations, et l’équipe PHP n’avait pas identifié d’exploit fonctionnel parmi ceux qui circulaient. Le succès réel des tentatives n’est pas confirmé. La situation évolue d’heure en heure : cet article reflète les sources publiées le 22 octobre.

Deux failles, une même conséquence

CVE-2026-109618 est une corruption mémoire liée à un épuisement de mémoire : si une allocation échoue alors que les données de la requête sont à moitié initialisées, le nettoyage de fin de requête traite des données invalides comme valides. D’après Rapid7, des requêtes multipart construites pour l’occasion peuvent provoquer cet épuisement même sous les limites configurées.

CVE-2026-109619 est un état global périmé : l’état interne d’une requête survit à la libération de sa mémoire, et une requête suivante traitée par le même worker peut l’utiliser avant sa réinitialisation.

La conséquence pratique est inconfortable : votre code applicatif peut être irréprochable, il ne vous protège pas, puisque l’attaque vise le moteur qui l’exécute. Un pare-feu applicatif peut offrir une protection partielle en attendant, mais ni la CISA ni PHP ne le présentent comme une solution : seule la mise à jour est complète.

Pourquoi la panique

Des failles critiques, il y en a chaque mois. Celle-ci fait réagir parce qu’elle combine quatre facteurs qui touchent moins les développeurs que l’inventaire, l’exploitation et la gouvernance.

PHP est partout, pas toujours visible

La CISA demande d’inventorier tous les systèmes utilisant PHP, y compris comme composant d’autres logiciels : sa présence n’est pas toujours visible. Cisco a d’ailleurs publié un avis dédié aux produits concernés.

Des versions qui ne reçoivent plus rien

PHP 8.1 et les versions antérieures ne sont plus maintenues. L’équipe PHP a publié des backports minimaux pour 7.4, 8.0 et 8.1, à compiler soi-même. Le code vulnérable le plus ancien identifié remonte à PHP 5.4.0 (relayé par Tenable). Et PHP 8.2 arrive en fin de vie le 31 décembre 2026.

Une fenêtre qui se ferme avant d’avoir commencé

Une tentative d’exploitation a été observée quatre jours avant la divulgation. Rapid7 s’attend à voir apparaître rapidement un exploit plus portable : le délai pour corriger se compte en jours, pas en trimestres.

Des rustines qui font peur

Pour 109618, PHP recommande temporairement memory_limit = -1, c’est-à-dire de supprimer la limite mémoire. Pour 109619 : session.upload_progress.enabled = 0 et, sur PHP 8.5, fatal_error_backtraces = 0, puis redémarrage de tous les workers. Ce sont des palliatifs, pas des correctifs.

À cela s’ajoute un cas particulier : en hébergement mutualisé, PHP appartient à l’hébergeur. Vous ne pouvez pas le mettre à jour vous-même, seulement lui demander sa version et son calendrier. Et quand la mise à jour est impossible, la CISA va loin : elle recommande de mettre hors ligne les systèmes PHP tant qu’ils ne sont pas corrigés ou qu’ils tournent sur une version non supportée.

Notre lecture : la panique est rationnelle. Elle ne mesure pas la qualité de vos développements, mais l’état de votre inventaire, de votre cycle de vie logiciel et de votre capacité à patcher vite. C’est ce que cette semaine met à nu.

Que faire cette semaine

1. Inventorier

Serveurs, conteneurs, images, hébergements, composants embarqués. La version qui compte est celle qui sert réellement les requêtes web.

2. Patcher d’abord ce qui est exposé

Passer en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installer le paquet de votre distribution ou de votre fournisseur LTS qui contient les deux correctifs.

3. Traiter les versions orphelines

8.1 et avant : paquet LTS, backport à compiler, ou migration vers une version supportée. À défaut, isoler ou couper, comme le recommande la CISA.

4. Si le patch attend

Appliquer les palliatifs de l’avis PHP (en configuration administrateur, pas applicative), limiter la taille des requêtes en frontal, redémarrer tous les workers. À éviter : RLIMIT_AS et RLIMIT_DATA, et masquer les erreurs ne protège pas.

5. Surveiller

Chercher des processus de workers PHP qui lancent des shells ou téléchargent des outils : c’est l’indicateur donné par la CISA.

De la faille à l’incident : un schéma connu

Une vulnérabilité critique n’est pas encore un incident. Elle le devient quand l’inventaire est incomplet, que le correctif traîne et que la détection arrive tard. C’est le schéma de nombreux cas documentés : en 2017, Equifax a subi une intrusion à partir d’une vulnérabilité Apache Struts non corrigée, selon la FTC.

Pour rendre ces mécanismes concrets, nous avons ouvert Anatomie d’une fuite : un site qui documente des failles de sécurité réelles du passé, les relie à des cas sourcés, et montre quelles données peuvent fuiter lors d’une compromission. Utile pour une équipe, en sensibilisation ou en formation.

En résumé

Deux failles PHP critiques, corrigées le 21 octobre, exploitables sans authentification, avec au moins une tentative observée avant la divulgation. La seule remédiation complète est la mise à jour ; tout le reste achète du temps. La vraie question de la semaine n’est pas « quel est le correctif ? » mais « sait-on où se trouve notre PHP ? ».