Lorsqu’un client consulte ses factures sur un extranet, valide un panier ou se connecte à son espace personnel, le serveur doit exécuter plusieurs opérations : vérifier son identité, rechercher des informations et produire une réponse adaptée. PHP est l’un des langages utilisés pour écrire ces instructions. Son moteur les exécute sur le serveur, puis transmet le résultat au navigateur. Il permet notamment de générer des pages dynamiques et de communiquer avec des bases de données. Documentation PHP.

PHP, un composant souvent invisible des services numériques

Informations vérifiées le 22 octobre 2026 à 10 h 58, heure de Paris.

PHP fait fonctionner WordPress, Drupal et de nombreuses applications développées sur mesure. Il peut ainsi se trouver derrière un site institutionnel, une boutique en ligne ou un outil métier, sans que son utilisateur le sache.

Cette présence explique la portée de PHP2Shell. Une faille du moteur peut concerner des organisations très différentes utilisant un même composant. Toutefois, utiliser PHP ne suffit pas à établir une exposition effective : la version installée, les paramètres et les opérations accessibles doivent être examinés.

Pour l’assurance cyber, cet inventaire est essentiel. Un site de présentation et un extranet indispensable à la prise de commandes peuvent partager la même technologie tout en représentant des risques économiques très différents.

PHP2Shell : deux failles permettant d’agir sur le serveur

PHP2Shell désigne deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, classées critiques avec une note de 9,2 sur 10 selon CVSS v4.0. Elles concernent la gestion de la mémoire et des erreurs dans PHP. Les chercheurs ont démontré une exécution de code sans authentification sur plusieurs environnements applicatifs, notamment WordPress et Drupal. Présentation technique des chercheurs.

Leur découverte s’inscrit dans plusieurs travaux. La PHP Foundation explique que les premiers signes du problème d’épuisement mémoire avaient été identifiés en 2024, sans chemin concret d’exécution de code alors établi. La société CALIF spécialisée en cybersécurité a commencé un audit le 30 juillet 2026 et signalé une exploitation le 11 août ; OpenAI a rapporté indépendamment la même cause ce jour-là, puis la plateforme Wiz (plateforme de protection des applications) a transmis d’autres vecteurs le 24 août dernier. Ces recherches ont notamment mobilisé des outils d’intelligence artificielle. Récit de la PHP Foundation.

Des informations ont circulé publiquement le 20 octobre, avant la divulgation coordonnée. PHP a annoncé une publication de sécurité pour le 21 octobre 2026. Les détails et les versions corrigées ont été plubiées le même jour octobre. Chronologie Patchstack.

Le premier mécanisme apparaît lorsqu’un manque de mémoire interrompt PHP pendant la construction de données internes. Leur nettoyage peut ensuite utiliser des éléments incomplets comme s’ils étaient valides. Une requête spécialement préparée peut exploiter cette incohérence. Avis PHP sur CVE-2026-109618.

Le second mécanisme conserve des références vers une mémoire déjà libérée. Une requête ultérieure, traitée par le même processus, peut réutiliser cet état périmé et permettre une lecture de mémoire ou une exécution de code. Les conditions dépendent des opérations et de la configuration. Une exploitation a notamment été validée sur Apache avec mod_php et sur PHP-FPM. Avis PHP sur CVE-2026-109619.

L’attaquant peut alors agir avec les droits du processus web. Cela ne lui donne pas automatiquement les privilèges d’administration de toute l’infrastructure. L’accès à d’autres systèmes dépend des autorisations, des secrets disponibles et des communications permises.

Le risque n’est plus seulement préventif. Amazon rapporte des tentatives contre ses serveurs leurres dès le 17 octobre, puis une activité accrue après publication. L’entreprise parle d’exploitation active, tout en précisant que la réussite des premières tentatives sur des systèmes réels reste incertaine. Ces observations ne constituent donc pas un bilan des entreprises compromises. Analyse Amazon Threat Intelligence.

Des correctifs disponibles, à installer dans chaque environnement

Le 21 octobre, PHP a publié les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L’annonce préalable prévoyait une disponibilité à 14 heures UTC, soit 16 heures à Paris. PHP vise les installations servant des requêtes web, dont PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed, avec un risque particulièrement élevé signalé pour mod_php. Bulletin officiel PHP.

La correction modifie notamment la réaction à l’épuisement mémoire : PHP diffère l’interruption jusqu’à un point sûr et arrête immédiatement le processus si un seuil supérieur est atteint. L’autre correction remet à zéro les états susceptibles de survivre indûment entre deux requêtes. Ces changements traitent les mécanismes sous-jacents. Avis sur la mémoire, avis sur les états persistants.

Les versions corrigées constituent la remédiation complète aux deux vulnérabilités identifiées, sous réserve d’un déploiement effectif. Cela ne garantit pas l’absence de toute autre faille PHP et ne supprime pas une compromission antérieure. Il convient donc de mettre à jour chaque installation concernée et redémarrer les processus : télécharger un paquet ou redémarrer un ancien conteneur ne prouve pas que le moteur corrigé fonctionne réellement.

Les branches anciennes compliquent l’opération. PHP 8.1 et les versions antérieures ne reçoivent plus les publications régulières du projet. Certains fournisseurs proposent toutefois des corrections rétroportées ; PHP fournit aussi des adaptations minimales du code pour 7.4, 8.0 et 8.1. Leur présence doit être confirmée auprès du mainteneur. Consignes PHP.

Au moment de cette vérification, les sources officielles consultées n’annoncent pas de remplacement général des correctifs PHP2Shell pour insuffisance de protection. Les changements de configuration proposés en attendant restent partiels ; le CERT-FR le souligne expressément.

Pourquoi le déploiement exige parfois des tests

Un moteur PHP fonctionne avec des extensions, des bibliothèques et des applications parfois anciennes. Un changement de branche peut rendre incompatible une fonctionnalité métier. Même une mise à jour au sein d’une branche peut introduire une régression, c’est-à-dire perturber un fonctionnement auparavant correct.

Un cas précis est désormais documenté. Le signalement PHP #24488, marqué comme vérifié par le projet, décrit des plantages dans PHP 8.4.27 et 8.5.12 avec SimpleXML, une extension de traitement de documents XML. Le défaut apparaît dans une combinaison particulière : certaines opérations rendent les propriétés d’un objet XML accessibles, puis le mécanisme de récupération de mémoire traite des références circulaires. Une zone mémoire peut alors être libérée deux fois.

Le déclarant reproduit le problème sur des images Docker officielles en environnement ARM et sur macOS. Il rapporte des arrêts de processus dans une suite de tests Laravel/Pest. Un autre participant signale également des échecs de tests, sans impact de production confirmé. La régression est attribuée à une modification de gestion mémoire associée au ticket GH-24050 ; elle ne démontre pas l’échec des corrections PHP2Shell. Signalement vérifié #24488.

Une correction est proposée dans la demande de modification #24494, encore ouverte lors de la consultation. Son approbation technique ne signifie pas qu’une nouvelle version distribuée la contient déjà. Ces éléments établissent un défaut de stabilité ciblé, sans démontrer une panne massive ni une nouvelle exploitation à distance.

Par ailleurs, le nouveau seuil mémoire ultime peut interrompre un processus sans exécuter ses fonctions habituelles de fin de traitement. Les opérations volumineuses et leur reprise doivent donc être testées. Recommandations après correction.

Il faut aussi distinguer ces dysfonctionnements des arrêts volontaires. Le journal le Figaro rapporte que le ministère de l’Intérieur a placé ses sites exposés en maintenance préventive à la demande de l’ANSSI. Cette interruption répond à la menace ; elle n’établit pas un défaut du correctif. Article du 21 octobre.

L’arbitrage dépend donc de l’environnement. Les équipes peuvent tester rapidement les parcours essentiels, déployer sur un premier serveur, surveiller les erreurs puis étendre l’installation. La préproduction doit reproduire les extensions et paramètres de production. Les sauvegardes, le retour arrière et le fonctionnement dégradé doivent être préparés. Revenir à une version vulnérable impose toutefois de réexaminer immédiatement son exposition, éventuellement en restreignant les accès.

Ce que risque une entreprise qui reste exposée

Premier exemple hypothétique : une boutique en ligne utilise une version vulnérable dans une configuration exploitable. L’attaquant obtient l’exécution de code avec les droits de l’application. Si celle-ci peut consulter les commandes et les coordonnées clients, ces informations deviennent accessibles. L’incident peut entraîner investigation, restauration, suspension des ventes et examen des obligations liées aux données personnelles. L’accès aux données de paiement dépendrait de leur traitement et de leur stockage effectifs.

Second exemple hypothétique : un extranet client conserve sur son serveur des identifiants donnant accès à une base documentaire. Une compromission du processus web pourrait exposer ces secrets et permettre des accès supplémentaires. Si les permissions sont limitées et les systèmes cloisonnés, les conséquences peuvent rester circonscrites. Dans le cas contraire, l’interruption peut affecter plusieurs fonctions métier.

Ces scénarios prolongent des capacités techniques démontrées ; ils ne décrivent pas des sinistres constatés chez des entreprises identifiées.

Les pertes dépendront autant de l’architecture que de l’activité. Une indisponibilité peut différer certaines commandes, en faire perdre d’autres ou bloquer des engagements de service. Le calcul doit distinguer chiffre d’affaires reporté, marge perdue et dépenses supplémentaires.

Enfin, corriger ne dispense pas d’enquêter. Amazon recommande de rechercher les traces suspectes à partir du 17 octobre au moins. Cette date constitue un point de départ documenté, sans garantir qu’aucune activité antérieure n’existe. Recommandations Amazon.

Assureurs et courtiers : accompagner la prévention et établir la cause en cas d'attaque 

L’accompagnement commence par des questions concrètes : quelles applications utilisent PHP, lesquelles sont accessibles depuis Internet et qui maîtrise leur maintenance ? L’hébergeur doit pouvoir confirmer les paquets corrigés, leur activation et le périmètre couvert. Une application principale mise à jour ne renseigne pas nécessairement sur un ancien portail ou une installation distincte.

L’assureur et le courtier peuvent diffuser une information vérifiée, demander un calendrier adapté à l’exposition et orienter l’entreprise vers des prestataires compétents. Ils gagnent à recueillir une preuve de traitement du risque : correction validée, accès restreint ou exception temporaire documentée avec responsable et échéance.

En cas d’exploitation, les dommages peuvent comprendre frais d’investigation, restauration, pertes d’exploitation et conséquences d’une atteinte aux données. Leur prise en charge dépend des garanties souscrites, des franchises, des limites et des circonstances établies.

La mise à l’arrêt préventif doit également être examiné au regard des dispositions relatives à la menace, à l’arrêt conservatoire et aux frais pour limiter un potentiel dommage. 

L’expertise doit donc préserver une chronologie : premières anomalies, installation, redémarrage, modification des paramètres, isolement et reprise. Les journaux, versions, configurations et tickets d’intervention permettent de départager attaque, régression et mesure volontaire. Le seul fait qu’une panne suive une mise à jour ne démontre ne permet pas d'établir un lien de causalité.

PHP2Shell montre pourquoi une exigence uniforme de correction immédiate reste insuffisante. L’urgence est réelle ; elle doit s’appuyer sur des tests ciblés, une réduction de l’exposition et une reprise préparée. Pour apprécier ensuite les décisions prises, assureurs et experts doivent considérer les informations disponibles à ce moment-là, les alternatives réalisables et les pertes que chaque mesure cherchait à éviter.