php2shell : deux failles critiques corrigées dans PHP, mod_php en première ligne et des parades seulement partielles

Le 21 octobre 2026, l’équipe du langage PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux failles critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre une exécution de code à distance sans authentification : un inconnu peut, en théorie, prendre la main sur un serveur web sans disposer d’aucun compte. Surnommées « php2shell », elles touchent le moteur PHP lui-même, et non un logiciel particulier. Pour les TPE, les associations et les particuliers qui font tourner WordPress, Nextcloud ou un site maison, la consigne est donc simple : installer la mise à jour PHP sans attendre.

Selon l’avis de sécurité publié sur php.net, toutes les installations PHP qui répondent à des requêtes web sont concernées, qu’elles passent par PHP-FPM, par Apache avec mod_php, par php-cgi, par FrankenPHP ou par LiteSpeed. La première faille, CVE-2026-109618, tient à la gestion des dépassements de mémoire : PHP peut être interrompu alors que les données internes d’une requête ne sont qu’à moitié initialisées, et le nettoyage qui suit les traite ensuite comme valides. La seconde, CVE-2026-109619, concerne un état interne qui survit à la libération de la mémoire qui le contenait : une requête suivante, traitée par le même processus, peut alors réutiliser ces données périmées. L’équipe de sécurité de PHP attribue aux deux failles la note de 9,2 sur l’échelle CVSS v4.0, qui mesure la gravité des vulnérabilités.

Le 20 octobre 2026, l’équipe de sécurité de PHP avait annoncé une publication pour le mercredi 21 octobre 2026 à 14:00 UTC, en se réservant le droit de l’avancer si les détails devenaient publics ou si une exploitation était constatée. Selon watchTowr, cité par Tenable, la divulgation devait initialement avoir lieu le jeudi 22 octobre, sous embargo ; Tenable relève que les identifiants des failles circulaient déjà le 20 octobre sur Hacker News et les réseaux sociaux. La chaîne d’attaque, surnommée « php2shell », a été montrée dans une vidéo diffusée par le chercheur Kirill Firsov. Des chercheurs de Wiz, cités par Help Net Security, estiment pour leur part que des modèles d’intelligence artificielle de pointe ont nettement abaissé la barrière qui séparait une faille ancienne d’un exploit fonctionnel.

mod_php et PHP-FPM : un risque inégal

Le projet PHP considère que le risque est le plus élevé avec mod_php, le module qui intègre PHP directement dans le serveur Apache. Un exploit y a été démontré : une requête non authentifiée peut déclencher l’attaque avant même que le moindre code de l’application ne s’exécute. Autrement dit, peu importe que le site lui-même soit à jour ou soigneusement écrit. L’avis technique consacré à la première faille donne la raison de cette exposition : avec mod_php, Apache lance systématiquement la procédure de fin de requête, même lorsque le démarrage de cette requête a échoué. Help Net Security résume la situation sans détour : ce sont les installations sous mod_php qui courent le plus grand danger.

PHP-FPM est le gestionnaire de processus qui fait tourner PHP à côté du serveur web plutôt qu’à l’intérieur. Pour la première faille, l’avis indique que l’analyse du code source le range parmi les configurations vulnérables, même si aucun exploit complet n’a été démontré sur PHP-FPM. Pour la seconde, en revanche, une exécution de code passant par le cycle de vie des sessions a été validée à la fois contre mod_php et contre PHP-FPM. Elle suppose que deux requêtes successives de l’attaquant atteignent le même processus PHP ; la présence de plusieurs processus et leur recyclage réduisent les chances de succès à chaque tentative, sans supprimer le problème. Passer de mod_php à PHP-FPM réduit le risque, mais ne dispense en rien de la mise à jour.

La mise à jour PHP, sans attendre

Les versions corrigées sont disponibles sur php.net, en sources comme en binaires pour Windows. Sur les serveurs Linux, PHP est toutefois souvent installé à partir des paquets de la distribution. Selon le projet PHP, les distributions et les éditeurs de support à long terme ont reçu les correctifs à l’avance : c’est donc auprès d’eux qu’il faut vérifier la disponibilité des paquets mis à jour. Le projet signale aussi que le dépôt bénévole rpms.remirepo.net n’aura pas de mise à jour le jour de la publication, et invite ses utilisateurs à passer aux paquets de leur distribution ou à compiler PHP à partir des sources. Une fois la mise à jour installée, pensez à redémarrer PHP-FPM ou Apache pour que tous les processus chargent bien la version corrigée.

Les branches anciennes posent un problème à part. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet ; certaines distributions et certains éditeurs de support à long terme proposent des correctifs adaptés, et le projet renvoie vers eux. Vu la gravité des failles, l’équipe de sécurité a tout de même publié des correctifs minimaux, sous forme de code source, pour PHP 7.4, 8.0 et 8.1, à l’intention de ceux qui compilent PHP eux-mêmes. Selon Tenable, le CERT-EU estime que les failles pourraient toucher toutes les versions depuis PHP 5. Enfin, le projet rappelle que PHP 8.2 arrivera en fin de vie le 31 décembre 2026 et ne recevra plus aucun correctif de sécurité après cette date.

Selon le projet PHP, les réglages de contournement réduisent l’exposition à certaines voies d’attaque, mais ne rendent pas une installation sûre.

Des parades seulement partielles

Pour qui ne peut pas mettre à jour immédiatement, l’avis officiel détaille des mesures d’attente, tout en rappelant que seule la mise à jour règle le problème. Contre CVE-2026-109618, il propose de fixer memory_limit=-1, c’est-à-dire de supprimer la limite de mémoire de PHP, de préférence au niveau du pool PHP-FPM ou de la configuration Apache, pour que les applications ne puissent pas la rétablir. Le projet prévient lui-même qu’une panne d’allocation de mémoire sous-jacente peut encore atteindre le code vulnérable. Il recommande aussi d’abaisser la taille maximale des envois (post_max_size), avec des valeurs différentes selon que le site accepte ou non des fichiers, et de faire contrôler la taille des requêtes par le serveur web ou le mandataire (proxy) placé devant lui.

Contre CVE-2026-109619, la mesure principale consiste à désactiver le suivi de progression des envois de fichiers, avec le réglage session.upload_progress.enabled=0, puis à redémarrer chaque processus PHP. Ce réglage doit être posé dans php.ini, dans un pool PHP-FPM ou dans la configuration du serveur, et non par une instruction ini_set() ou un fichier .user.ini, qui s’appliquent trop tard. Selon le projet, il bloque les chemins d’attaque confirmés par les sessions, mais pas les autres variantes. Sur PHP 8.5, il conseille également fatal_error_backtraces=0. Il précise enfin que masquer les messages d’erreur, avec error_reporting, display_errors ou l’opérateur @, ne protège de rien.

Sur l’efficacité de ces réglages, les mises en garde sont unanimes. Les deux avis techniques publiés sur GitHub par le projet PHP sont formels : la mise à jour est la seule parade complète, ou la seule fiable. Tenable rapporte aussi les propos d’un développeur du cœur de PHP pour qui la seule atténuation consiste à appliquer le correctif ou à mettre PHP à niveau. Du côté des intermédiaires, Help Net Security indique que les sites PHP placés derrière Cloudflare bénéficient déjà d’un premier jeu de règles de pare-feu applicatif contre les voies d’exploitation connues. Ce filtrage en amont ne couvre que le trafic qui passe par ce service et ne corrige pas le serveur : il peut faire gagner du temps, pas dispenser de la mise à jour.

Exploitation : premières attaques signalées

Sur la question de l’exploitation, nous rapportons les signalements tels quels, sans avoir pu les vérifier nous-mêmes. L’entreprise de sécurité watchTowr affirme qu’une exploitation a été observée dans la nature dès le 21 octobre, d’après son réseau de leurres. Selon Tenable, le directeur technique de Cloudflare, Dane Knecht, a déclaré le même jour que l’entreprise voyait apparaître les premières attaques. Tenable signale par ailleurs que du code présenté comme un exploit de ces failles circule publiquement, sans en avoir vérifié le fonctionnement. Nous déconseillons de télécharger ce type de code pour « tester » son serveur : un exploit trouvé au hasard peut lui-même contenir un logiciel malveillant, et la vérification utile reste celle de la version de PHP installée.

Concrètement, la démarche dépend de l’hébergement. Sur un hébergement mutualisé, c’est l’hébergeur qui gère PHP : vérifiez dans votre espace de gestion la version proposée, ou demandez-lui quand le correctif sera appliqué. Sur un serveur ou un VPS sous Linux, installez les mises à jour de votre distribution, puis redémarrez PHP-FPM ou Apache. Si votre Nextcloud, votre WordPress ou un autre outil tourne dans un conteneur Docker, n’oubliez pas que l’image embarque sa propre copie de PHP : il faudra récupérer l’image corrigée dès sa publication. Et si vous dépendez encore de PHP 8.1 ou plus ancien, c’est le moment de planifier la migration. Si vous ne savez pas où en est votre serveur, notre accompagnement bénévole et gratuit peut vous aider à faire le point, dans la mesure de nos disponibilités.