Failles critiques php2shell dans PHP : l’urgence de désactiver cette option par défaut (surtout si vous êtes en 7.4)

De quoi parle-t-on exactement ?

On commence l’année avec une désagréable surprise qui secoue un peu le web. Deux vulnérabilités particulièrement sévères viennent de faire leur apparition au cœur même de PHP, le langage qui alimente encore une très grande majorité des sites internet. Estampillées CVE-2026-109618 et CVE-2026-109619, ces deux brèches reposent sur un problème de gestion de la mémoire, plus précisément ce que l'on appelle dans le jargon un « heap use-after-free ». En clair, un pirate peut s’en servir pour manipuler des données stockées dans la mémoire vive du serveur et, si les conditions s’y prêtent, réussir à exécuter du code à distance sans même avoir besoin de s’authentifier.



Le problème réside dans un composant bien précis nommé « phpsessionrfc1867_callback », intégré au module de session native. Son rôle ? Suivre en temps réel l’envoi de fichiers sur un site pour permettre d’afficher une barre de progression à l’écran. L’intention de départ était plutôt bonne, mais le mécanisme comporte un piège majeur. Il s’active automatiquement dès qu’une requête multipart est reçue, avant même que votre propre script PHP ou votre CMS n’ait commencé à traiter la demande. Ce déclenchement ultra-précoce laisse le champ libre aux attaquants pour envoyer des requêtes trafiquées et prendre la main sur la machine.

Quelles versions sont concernées ?

La nouvelle fâcheuse, c’est que le périmètre est particulièrement vaste. Le code vulnérable traîne dans le projet depuis très longtemps, ce qui veut dire que pratiquement toutes les versions diffusées depuis la branche 5.x sont exposées. Si vous hébergez un environnement récent tournant sous PHP 8.2, 8.3, 8.4 ou 8.5, la situation reste sous contrôle. L’équipe officielle de développement a déjà confirmé l’existence du problème et prépare activement la diffusion de correctifs de sécurité pour l’ensemble de ces branches encore maintenues.

Le vrai cas de figure inquiétant touche plutôt les infrastructures restées bloquées sur des moutures obsolètes. PHP 7.4, dont le support officiel s’est arrêté à la fin de l’année 2022, ne bénéficiera théoriquement d’aucune mise à jour de la part des mainteneurs originaux. C’est un casse-tête bien connu chez les administrateurs système et les hébergeurs : même si certaines distributions garantissent un suivi communautaire à long terme sur leurs anciennes versions, il n’y a aucune certitude qu’un travail de « backport » du patch soit entrepris rapidement pour combler la faille sur cette branche ancienne.

Que faire immédiatement ?

Heureusement, il n’est pas nécessaire de paniquer ou d’attendre les bras croisés que les paquets corrigés fassent leur apparition. Une mesure de contournement très simple à appliquer permet de fermer la porte immédiatement sans casser votre infrastructure. Elle consiste tout simplement à désactiver la fonction incriminée directement dans le fichier de configuration principal de PHP. Il suffit pour cela d’insérer ou de corriger la ligne suivante dans votre fichier php.ini :

La méthode pour appliquer cette modification dépend du mode de gestion de votre environnement, mais la logique reste exactement la même partout :

• Via une interface de gestion web : rendez-vous dans la section consacrée aux paramètres PHP de votre hébergement, ouvrez l’onglet d’édition du fichier de configuration global (php.ini) et ajoutez la directive mentionnée plus haut à la fin du texte avant d’enregistrer.
• Via un accès serveur ou un terminal : éditez le fichier php.ini correspondant à la version concernée directement dans votre dossier de configuration habituel, puis sauvegardez le changement.

Une fois la modification enregistrée, n’oubliez pas de recharger le service PHP ou le serveur web qui gère vos scripts pour que ce nouveau réglage soit bien pris en compte par la machine.

Pour valider que la protection est bien active sur votre système, vous pouvez exécuter un test rapide en ligne de commande ou via un fichier d’information PHP. La directive « session.upload_progress.enabled » doit impérativement afficher la valeur « Off ». Ne craignez pas d’impacter le fonctionnement de vos sites web en appliquant ce réglage. De nos jours, quasiment tous les CMS modernes et les applications récentes gèrent l’affichage de la progression des téléversements directement côté client grâce à JavaScript, sans jamais faire appel à cette vieille option intégrée.

Les limites de cette mitigation

Même si cette modification ferme le vecteur d’attaque principal mis en avant par les chercheurs en sécurité, il faut garder une certaine réserve. Les premières données d’analyse technique montrent que le problème pourrait s’étendre un peu plus loin dans le moteur de traitement des formulaires. Un second chemin d’exploitation potentiel pourrait théoriquement exister au niveau du parseur de requêtes multipart lui-même. Si cela venait à se confirmer, un attaquant habile pourrait réussir à déclencher le bug de gestion mémoire dès la réception du fichier, indépendamment de l’état d’activation du suivi de session.

Il convient donc de considérer cette manipulation comme un bouclier temporaire extrêmement utile, mais pas comme une immunité absolue. En attendant d’avoir un recul complet sur les détails des correctifs officiels, il reste conseillé d’observer une grande prudence. Si votre architecture le permet, vous pouvez par exemple ajouter une règle sur votre pare-feu d’application web (WAF) pour filtrer ou bloquer temporairement les requêtes d’envoi de fichiers trop volumineuses sur les formulaires qui n’en ont pas l’utilité.

Que faire à moyen terme ?

Lorsque les paquets officiels de mises à jour seront rendus publics par les différentes distributions et par le projet PHP, la priorité absolue sera de les déployer sur l’ensemble de vos serveurs encore supportés. Un simple passage par le gestionnaire de paquets permettra de combler définitivement la brèche sur les versions 8.x. Pensez à programmer une plage de maintenance rapide ou à automatiser la récupération des mises à jour de sécurité pour éviter de laisser vos machines exposées inutilement.

Pour les environnements figés sous PHP 7.4, l’apparition de ces deux vulnérabilités doit servir d’élément déclencheur. La seule véritable réponse sur le long terme réside dans une migration vers un environnement plus moderne embarquant une version supportée de PHP (8.2 ou supérieure). Si des contraintes applicatives strictes vous empêchent de sauter le pas immédiatement, sachez qu’il existe des services commerciaux proposant un support étendu payant avec des correctifs rétroportés. Mais gardez en tête que ce n’est qu’un sursis temporaire : maintenir une version en fin de vie finit toujours par coûter plus cher que sa mise à niveau.

Une protection basique, mais un problème de fond

La découverte de ces deux vulnérabilités rappelle à quel point de vieilles fonctionnalités activées par défaut peuvent soudainement transformer un serveur en cible facile. La bonne nouvelle, c’est que la désactivation de l’option « session.upload_progress » vous apporte une protection immédiate, gratuite et sans risque de casse pour vos applications. Prenez cinq minutes dès aujourd’hui pour appliquer ce changement sur vos hébergements.

Cependant, ne perdez pas de vue le fond du problème si vos sites fonctionnent toujours avec une version obsolète. Qu’il s’agisse de PHP 7.4 ou d’une déclinaison encore plus ancienne comme PHP 5.6, rester sur une plateforme abandonnée par ses créateurs vous expose à d’autres failles du même genre dans le futur. Prenez le temps de planifier sereinement votre passage vers PHP 8, surveillez les bulletins de sécurité de vos hébergeurs, et vous garderez un coup d’avance sur les menaces. Mitiger ne veut pas dire corriger !