🔥 Faille PHP2Shell : RCE, correctif + risques (2026)

CVE-2026-109618 : un état incohérent après une erreur mémoire

La première faille concerne la gestion d'un dépassement de la limite mémoire. Quand une requête dépasse la mémoire autorisée, PHP interrompt son traitement. Cette interruption peut survenir alors que certaines structures internes ne sont pas encore entièrement initialisées. Résultat : le code de nettoyage qui s'exécute ensuite peut considérer "valide" un état qui ne l'est pas.

Point important côté exploitation : ce n'est pas parce que votre application "n'a rien exécuté" que vous êtes hors de risque. L'avis PHP décrit une exécution de code à distance par HTTP avec Apache et mod_php, y compris avec une configuration par défaut. Donc, même si votre application est propre, elle ne peut pas réparer à elle seule une faille dans le moteur qui la sert.

Attention toutefois au raccourci : un dépassement mémoire ne conduit pas automatiquement, à chaque fois, à une compromission. On parle d'un mécanisme vulnérable dans certaines circonstances. Mais lorsque la vulnérabilité peut être atteinte avant l'exécution du code applicatif, des contrôles limités à l'application ne suffisent plus.

CVE-2026-109619 : une utilisation de mémoire après sa libération

La seconde faille est une vulnérabilité de type use-after-free. Dit simplement : une partie du code continue à référencer une zone mémoire après que celle-ci a été libérée. Si, entre-temps, le programme réutilise cette zone sans remettre l'état proprement à zéro, le processus peut lire des données qui ne devraient plus être accessibles.

Le scénario vise notamment des états internes liés à une requête qui persistent dans un processus de travail. La vulnérabilité peut apparaître après une erreur fatale ou un dépassement mémoire, puis impacter une requête suivante traitée par le même worker. L'avis PHP décrit plusieurs chemins : la fonctionnalité de retour de trace après erreur fatale (activée par défaut dans PHP 8.5) et la gestion du cycle de vie des sessions, en mod_php comme en PHP-FPM.

Pour une équipe qui gère des serveurs, cette nuance compte : on ne gagne pas grand-chose à cocher "une case" si plusieurs chemins peuvent mener à un problème proche. La surface d'exposition dépend du mode de déploiement et des composants, mais l'avis officiel ne limite pas le risque à une configuration rare.

Une mesure qui bloque un chemin, pas le problème

Dès lors, désactiver le suivi de progression des téléversements ne ferme pas toutes les possibilités d'exploitation de CVE-2026-109619. Les serveurs qui se sont limités à cette seule action restent donc exposés à l'autre chemin décrit par PHP. Le réglage peut réduire une partie du risque, mais il ne remplace pas un correctif du code vulnérable.

C'est le genre de distinction qu'on perd vite en incident response : un contournement peut empêcher un échantillon d'exploitation donné de fonctionner, ou neutraliser une fonctionnalité impliquée dans un scénario. Ça ne prouve pas que la vulnérabilité sous-jacente a disparu. Sans confirmation de l'éditeur, il faut traiter cette désactivation comme une réduction temporaire du risque, pas comme une validation définitive.

La fuite initiale a aussi mélangé plusieurs sujets : la gravité et la cause technique. Les éléments diffusés indiquaient une note CVSS de 10,0, alors que l'évaluation officielle fait 9,2, et attribue le problème à une seule fonctionnalité. Ces écarts ne rendent pas "absurdes" les actions prises par les équipes : elles se sont basées sur ce qui circulait. Ils expliquent surtout pourquoi une information non vérifiée ne doit pas devenir une conclusion de sécurité durable.

Ce que cette situation change pour la gestion d'incident

Quand un contournement est annoncé avant un correctif, il faut distinguer clairement trois niveaux :

• Réduction temporaire du risque : désactiver une fonction ou restreindre un type de requête, si la mesure est documentée et compatible avec votre service.
• Correction confirmée : installer une version explicitement identifiée comme corrigée par l'éditeur.
• Validation de l'exposition : vérifier que tous les environnements (services, conteneurs, instances et préproduction) tournent bien sur la version corrigée.

Cette séparation évite de "clore" une tâche en la croyant résolue alors qu'on n'a fait que réduire un chemin sur les plusieurs connus. Et il faut garder une trace : source de l'information, mesure appliquée, et preuve que le correctif est bien installé.

Dans un contexte européen, ce suivi aide aussi à aligner sécurité, exploitation et responsables conformité lorsque l'évaluation d'un incident doit tenir compte des obligations internes ou du RGPD.

Procédure de vérification en quatre étapes

1. Recensez les points d'entrée PHP. Listez les serveurs web, les pools PHP-FPM, les conteneurs, les machines virtuelles, les environnements d'administration et les services accessibles depuis un réseau. Ne négligez pas ce qui est "moins visible" : une interface interne peut être plus discrète qu'un site client, mais pas forcément moins exposée.

2. Relevez la version effective. Vérifiez la version du binaire ou du paquet utilisé par chaque service. La commande php -v peut aider, mais elle ne garantit pas que le processus web utilise exactement le même binaire que l'interface en ligne de commande. Pour PHP-FPM ou les images conteneurisées, contrôlez aussi l'image et le service réellement déployés.

3. Comparez avec la source de correctif appropriée. Pour PHP 8.2 à 8.5, comparez avec les versions corrigées publiées par PHP. Pour les branches fournies par une distribution, référez-vous à son avis de sécurité et à l'identifiant de paquet. N'appliquez pas mécaniquement une règle de version d'une distribution à une autre : les rétroportages changent la donne.

4. Mettez à jour, puis vérifiez après redémarrage. Déployez le paquet ou l'image corrigée, puis vérifiez que les processus ont bien redémarré. Installer une version ne suffit pas toujours : les workers déjà en mémoire peuvent continuer d'exécuter l'ancien code. Après le déploiement, contrôlez à nouveau la version effective et conservez une preuve horodatée.

Ne laissez pas le calendrier de maintenance décider du risque

Un passage en mise à jour pendant une fenêtre hebdomadaire peut suffire pour des changements "normaux". Mais quand une vulnérabilité est activement ciblée, ce même rythme peut laisser un serveur exposé pendant plusieurs jours après la publication du correctif.

L'enjeu n'est pas de supprimer tout processus de changement. C'est de prévoir une voie accélérée pour les vulnérabilités critiques : responsable identifié, validation minimale, possibilité de retour arrière, et contrôle après déploiement.

Un exemple de parc illustre bien le problème : lors d'une vérification le jour de la publication des correctifs, une application interne d'administration tournait encore en PHP 8.2.33. Son mécanisme de mise à jour automatique ne se déclenchait qu'une fois par semaine. Après une mise à jour manuelle, l'exposition a été corrigée immédiatement, et la fréquence de contrôle a été alignée sur celle des services destinés aux clients. Ce n'est pas une preuve que toutes les mises à jour doivent être instantanées ; c'est un rappel que la cadence doit suivre le niveau de risque et la criticité du service.

Enfin, si vous passez par un hébergeur, évitez les réponses vagues du type "tout est protégé". Demandez quelles versions ou quels paquets sont concernés, comment les services PHP-FPM ou Apache ont été redémarrés, et si les environnements mutualisés sont inclus. La responsabilité opérationnelle peut être partagée, mais la vérification doit rester explicite.