Depuis le 20 octobre 2026, les requêtes « php vulnerability 2026 », « php vulnerability october 2026 », « php vulnerability patch » et « php vulnerability wordpress » progressent fortement dans les recherches en France. Cette vague correspond à la divulgation de deux failles critiques du langage PHP, baptisées PHP2Shell et enregistrées sous les références CVE-2026-109618 et CVE-2026-109619. Le 20 octobre 2026, le laboratoire watchTowr a publié une foire aux questions consacrée à ces vulnérabilités, mise à jour le 22 octobre, qui les décrit comme des failles d’exécution de code à distance permettant à un attaquant non authentifié d’exécuter son propre code sur un serveur vulnérable et de potentiellement en prendre le contrôle. Le même laboratoire indique que toutes les versions de PHP depuis PHP 5 seraient concernées, avec un score CVSS de 9,2, et que des correctifs sont désormais disponibles. Le 21 octobre 2026, l’équipe de recherche de Datadog a publié une analyse détaillée avec des versions corrigées et des étapes de remédiation. La presse généraliste a relayé l’événement : CNN évoque des sites fermés dans le monde après la découverte d’une faille touchant une large part du web, et la BBC rapporte le 22 octobre qu’une trentaine de services publics britanniques seraient indisponibles en raison de ce problème mondial de cybersécurité.
Pour une entreprise française, la question n’est pas théorique. Une grande partie des sites vitrines, des boutiques en ligne et des extranets tourne sur PHP, directement ou par l’intermédiaire d’un système de gestion de contenu comme WordPress. Quand le langage lui-même est vulnérable, le correctif ne se limite pas à mettre à jour une extension : il faut identifier où tourne PHP, quelle version est utilisée, qui est chargé de la corriger et ce qui a pu se passer avant la correction. Cet article explique la méthode : d’abord vérifier l’exposition de votre site et appliquer le patch en gardant la preuve de chaque opération, puis qualifier l’incident, informer les personnes concernées lorsque le droit l’impose et organiser le recours contre le prestataire ou l’hébergeur lorsque le contrat le permet. Les développements suivent les questions réellement posées par les internautes et s’appuient sur les sources techniques citées et sur les textes applicables en France.
I. Faille PHP d’octobre 2026 sur un site WordPress : comment vérifier si vous êtes concerné et comment patcher
A. PHP vulnerability WordPress : comment vérifier la version de PHP et l’exposition de votre site ?
La première étape consiste à comprendre ce que la faille permet, selon les sources qui l’ont documentée. D’après la foire aux questions publiée par watchTowr le 20 octobre 2026 et mise à jour le 22 octobre, les vulnérabilités CVE-2026-109618 et CVE-2026-109619 permettraient à un attaquant non authentifié d’exécuter son propre code sur un serveur exécutant une version vulnérable de PHP. Le laboratoire précise que les versions 5, 7 et 8 de PHP seraient concernées dans leur ensemble et retient un score de gravité de 9,2. L’analyse publiée le 21 octobre 2026 par les équipes de recherche de Datadog décrit les mécanismes techniques, les méthodes de détection et les étapes de remédiation. Ces descriptions sont écrites à l’indicatif d’après ces sources : ce que les sources ne disent pas, notamment l’existence ou non d’une exploitation de votre propre serveur, reste à vérifier et s’écrit au conditionnel. Le fait que votre site utilise WordPress ne change pas la nature du problème, car WordPress lui-même s’exécute sur PHP : un site WordPress à jour mais hébergé sur une version vulnérable de PHP resterait exposé tant que le langage n’est pas corrigé.
La vérification commence par une question simple : quelle version de PHP exécute votre site, et qui l’administre ? Dans un hébergement mutualisé, la version de PHP est choisie dans l’interface de l’hébergeur ou fixée par lui. Dans un hébergement sur serveur dédié ou virtuel, ou dans une infogérance confiée à un prestataire, la version est installée par l’administrateur du serveur. Si vous disposez d’un accès, la version peut être lue par une commande ou par une page d’information du serveur ; dans le cas contraire, l’hébergeur ou le prestataire doit vous la communiquer par écrit, avec la date de la réponse. Les sources techniques indiquent les versions corrigées suivantes : 8.5.12, 8.4.27, 8.3.36 et 8.2.35, avec des mises à jour limitées pour les branches 7.4, 8.0 et 8.1, et aucun correctif pour PHP 5. Si votre site tourne encore sur PHP 5, la seule réponse durable serait une migration vers une version maintenue, car aucun patch ne serait publié pour cette branche selon le laboratoire cité. Cette information conditionne toute la suite : une boutique qui encaisse des paiements sur une version sans correctif ne peut pas se contenter d’attendre.
La vérification se poursuit par l’examen des traces. Les journaux d’accès du serveur web, les journaux d’erreurs PHP et les journaux du pare-feu applicatif permettent de repérer des requêtes anormales, des fichiers apparus sans explication ou des modifications récentes de fichiers du site. Une sauvegarde complète du site et de la base de données, réalisée avant toute correction, fige l’état du système et préserve des éléments qui serviront ensuite de preuve. Ce réflexe probatoire est directement soutenu par le droit français. L’article 1353 du Code civil dispose : « Celui qui réclame l’exécution d’une obligation doit la prouver. Réciproquement, celui qui se prétend libéré doit justifier le paiement ou le fait qui a produit l’extinction de son obligation. » Le texte est consultable dans sa version en vigueur sur l’article 1353 du Code civil. Concrètement, si vous reprochez ensuite à un prestataire de ne pas avoir corrigé le serveur, il vous appartiendra de prouver le manquement allégué, et les journaux, les captures datées et les échanges écrits constitueront vos pièces. Entre commerçants, la preuve est libre : l’article L. 110-3 du Code de commerce dispose : « A l’égard des commerçants, les actes de commerce peuvent se prouver par tous moyens à moins qu’il n’en soit autrement disposé par la loi. » Cette liberté ne dispense pas de conserver des éléments exploitables : un journal horodaté vaut mieux qu’un souvenir, et une demande écrite au prestataire vaut mieux qu’un appel dont il ne reste rien.
À ce stade, trois situations se distinguent. Première situation : votre version de PHP figure parmi les versions corrigées et le correctif est appliqué ; l’exposition est réduite, mais la vérification des traces reste utile pour la période antérieure à la correction. Deuxième situation : votre version appartient à une branche pour laquelle seules des mises à jour limitées existent ; il faut interroger par écrit l’hébergeur ou le prestataire sur le correctif disponible et sur le calendrier de migration. Troisième situation : votre site tourne sur une version sans correctif ; la migration devient prioritaire et, dans l’intervalle, des mesures de réduction de l’exposition doivent être examinées avec un professionnel, comme le filtrage des requêtes ou la restriction des accès. Dans les trois cas, chaque demande et chaque réponse doivent être écrites et datées : elles formeront le dossier qui permettra, le cas échéant, d’exiger l’exécution du contrat ou réparation.
B. PHP vulnerability patch : comment appliquer le correctif, garder la preuve et tracer les opérations ?
L’application du correctif suit un ordre que les professionnels de la sécurité rappellent dans chaque bulletin : sauvegarder, tester hors production lorsque c’est possible, corriger, puis vérifier. La sauvegarde préalable porte sur les fichiers et sur la base de données, avec une copie conservée hors du serveur corrigé. La correction consiste à passer à l’une des versions indiquées par les sources comme corrigées, soit 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche, ou à appliquer la mise à jour limitée disponible pour les branches anciennes. Après la mise à jour, le site doit être testé : pages principales, tunnel de commande, formulaires, espace client et connexions aux services de paiement. Si un correctif immédiat est impossible, l’analyse de Datadog évoque des mesures de réduction de l’exposition dans l’attente du patch, comme le filtrage au niveau du pare-feu applicatif ; ces mesures ne remplacent pas la correction et doivent être présentées comme temporaires, par écrit, avec la mention de leur caractère provisoire. Chaque opération est consignée dans un journal : qui est intervenu, à quelle date et à quelle heure, quelle version était installée avant, quelle version est installée après, et quels tests ont été effectués. Ce journal, joint aux factures et aux bons d’intervention, forme la preuve de votre diligence et, symétriquement, le point de comparaison avec les obligations de votre prestataire.
Le contrat est le document central de cette phase. L’article 1103 du Code civil dispose : « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » Autrement dit, le temps de rétablissement écrit dans votre contrat d’hébergement ou d’infogérance, l’étendue de la maintenance prévue et les exclusions acceptées s’appliquent en priorité. L’article 1193 du Code civil ajoute : « Les contrats ne peuvent être modifiés ou révoqués que du consentement mutuel des parties, ou pour les causes que la loi autorise. » Un prestataire ne peut donc pas décider seul de réduire sa prestation au motif que la faille viendrait du langage lui-même et non de son travail : si le contrat lui confie la maintenance du système et l’application des correctifs de sécurité, l’origine de la vulnérabilité ne le libère pas. La demande de correction doit être adressée par écrit, rappeler la clause visée, fixer une échéance opérationnelle et annoncer les vérifications qui suivront. Lorsque le contrat prévoit un engagement de temps de rétablissement, son dépassement se mesure à l’horodatage des tickets et des interventions, ce qui suppose que chaque échange soit tracé dès la découverte de la faille.
Si le prestataire n’agit pas, le droit commun de l’inexécution offre plusieurs voies, rappelées par l’article 1217 du Code civil : « La partie envers laquelle l’engagement n’a pas été exécuté, ou l’a été imparfaitement, peut : – refuser d’exécuter ou suspendre l’exécution de sa propre obligation ; – poursuivre l’exécution forcée en nature de l’obligation ; – obtenir une réduction du prix ; – provoquer la résolution du contrat ; – demander réparation des conséquences de l’inexécution. Les sanctions qui ne sont pas incompatibles peuvent être cumulées ; des dommages et intérêts peuvent toujours s’y ajouter. » Chacune de ces voies suppose une mise en demeure préalable et des pièces : le contrat, la demande écrite de correction, l’absence de réponse ou la réponse insuffisante, et la démonstration du lien entre l’inaction et votre préjudice, comme une boutique fermée ou des commandes perdues. L’article 1231-1 du Code civil précise : « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure. » La découverte d’une faille mondiale ne constitue pas à elle seule un cas de force majeure au profit du prestataire : l’événement était prévisible dans son principe, puisque la maintenance de sécurité est précisément l’objet du contrat, et l’inexécution doit être appréciée au regard des moyens que le contrat mettait à sa charge. Enfin, le montant de la réparation n’est pas libre : l’article 1231-4 du Code civil dispose : « Dans le cas même où l’inexécution du contrat résulte d’une faute lourde ou dolosive, les dommages et intérêts ne comprennent que ce qui est une suite immédiate et directe de l’inexécution. » Les pertes de marge, les frais de remise en service et les coûts de notification doivent donc être justifiés pièce par pièce, avec factures et journaux à l’appui, et non affirmés globalement.
Un point mérite une attention particulière : les clauses qui plafonnent la responsabilité du prestataire. Beaucoup de contrats d’hébergement et d’infogérance comportent un plafond exprimé en mois d’abonnement ou en montant fixe. La Cour de cassation a jugé que ces clauses survivent à la fin du contrat : dans son arrêt de la chambre commerciale du 7 février 2018, pourvoi n° 16-20.352, elle retient « alors qu’en cas de résolution d’un contrat pour inexécution, les clauses limitatives de réparation des conséquences de cette inexécution demeurent applicables ». Autrement dit, mettre fin au contrat ne fait pas disparaître le plafond, et la stratégie contentieuse doit intégrer cette limite dès la mise en demeure. Par ailleurs, l’article 1171 du Code civil dispose : « Dans un contrat d’adhésion, toute clause non négociable, déterminée à l’avance par l’une des parties, qui crée un déséquilibre significatif entre les droits et obligations des parties au contrat est réputée non écrite. » Une clause qui viderait de toute substance l’obligation de sécurité du prestataire pourrait être discutée sur ce fondement, mais la discussion reste casuistique : elle dépend de la rédaction exacte de la clause, de son caractère négociable et de l’économie générale du contrat. C’est pourquoi la relecture du contrat, clause par clause, précède toute décision de rompre ou de poursuivre.
II. Site exposé ou données touchées : notification, information des clients et recours contre le prestataire
A. PHP vulnerability CVE : comment qualifier l’incident, documenter et informer sans affirmer au-delà des sources ?
Une fois le correctif appliqué, il reste à déterminer ce qui s’est passé avant la correction. Les références CVE-2026-109618 et CVE-2026-109619 désignent la vulnérabilité elle-même, pas un incident sur votre serveur. Disposer d’une version vulnérable pendant la période d’exposition ne prouve pas qu’une intrusion a eu lieu ; symétriquement, l’absence de trace visible ne prouve pas qu’il ne s’est rien passé, car un attaquant soigneux efface ses passages. La qualification repose donc sur les éléments concrets du dossier : journaux d’accès montrant des requêtes anormales, fichiers inconnus ou modifiés à des heures inhabituelles, comptes créés sans autorisation, exportations massives de la base clients, ou au contraire journaux complets et cohérents qui n’ont rien enregistré d’anormal. Chaque constat est daté et conservé, avec la méthode de collecte, car c’est sur ces pièces que s’appuieront la plainte éventuelle, la notification à l’autorité et la discussion avec l’assureur. Si les journaux ont été détruits ou si leur conservation n’était pas prévue au contrat, cette lacune doit être notée telle quelle : elle oriente le débat vers les obligations de journalisation et de conservation du prestataire plutôt que vers des affirmations invérifiables.
Lorsque les constatations font apparaître un accès non autorisé, le droit pénal entre en jeu. L’article 323-1 du Code pénal dispose : « Le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie d’un système de traitement automatisé de données est puni de trois ans d’emprisonnement et de 100 000 € d’amende. » Le texte vise l’accès et le maintien frauduleux, ce qui suppose de caractériser la fraude et non la simple existence d’une vulnérabilité : un serveur vulnérable mais jamais visité ne constitue pas à lui seul l’infraction. En pratique parisienne comme ailleurs en Île-de-France, l’entreprise peut signaler les faits au service de police ou de gendarmerie de son ressort ou adresser une plainte au tribunal judiciaire, en joignant le dossier de pièces : version de PHP utilisée pendant la période d’exposition, date d’application du correctif, extraits de journaux, liste des fichiers suspects et estimation des données concernées. La plainte fige la position de victime, ouvre la voie à des investigations sur l’origine de l’accès et permet de se constituer partie civile pour obtenir réparation. Sur ce dernier point, la chambre criminelle de la Cour de cassation a admis que l’atteinte subie par l’employeur pouvait fonder une indemnisation propre : dans son arrêt du 2 septembre 2025, pourvoi n° 24-83.605, elle approuve les juges du fond d’avoir retenu « que la perte de confiance éprouvée par M. [G], suite aux agissements de M. [L], était constitutive d’un préjudice moral découlant directement du délit prévu par l’article 323-1 du code pénal retenu à la charge du prévenu ». Cette solution, rendue à propos d’un maintien frauduleux commis par un ancien administrateur réseau, montre que le préjudice moral d’une structure victime d’une atteinte à son système peut être indemnisé lorsqu’il découle directement du délit. Elle ne dispense pas de prouver l’accès frauduleux lui-même, ni de chiffrer les autres postes de préjudice avec des pièces.
Lorsque des données personnelles sont concernées, un second cercle d’obligations s’ajoute. Le droit européen impose au responsable du traitement une obligation générale de sécurité et de documentation des incidents, avec, selon les cas, une notification à l’autorité de contrôle et une information des personnes concernées. Les conditions, les destinataires et les modalités de ces démarches dépendent de la nature des données, du nombre de personnes touchées et des conséquences prévisibles pour elles : une base clients comportant des mots de passe ou des données bancaires ne s’analyse pas comme une simple liste de lettres d’information. L’entreprise doit donc examiner sans attendre son registre des traitements, recenser les catégories de données exposées pendant la période de vulnérabilité et préparer une communication exacte aux personnes concernées, en expliquant ce qui est établi et ce qui reste vérifié. Toute annonce publique doit rester mesurée : affirmer qu’aucune donnée n’a été compromise alors que les journaux sont incomplets serait aussi risqué que d’annoncer une fuite massive sur la seule foi d’une rumeur. Les guides et les décisions de la CNIL, consultables sur le site de l’autorité, détaillent les critères d’analyse, et un avis juridique permet de trancher les cas limites. Les échanges avec l’autorité, comme les notifications effectuées en ligne, sont conservés avec leurs accusés de réception, car ils démontrent que l’entreprise a réagi en responsable dès qu’elle a eu connaissance de l’incident.
B. PHP vulnerability explication : ce que vos contrats permettent d’exiger du prestataire et de l’hébergeur ?
Le dernier temps de la méthode est contractuel : qui devait faire quoi, et qui paie les conséquences de ce qui n’a pas été fait ? La réponse se lit d’abord dans les documents signés. Le contrat d’infogérance ou de maintenance décrit normalement le périmètre surveillé, la fréquence des mises à jour, la gestion des correctifs de sécurité et les engagements de temps de rétablissement. Le contrat d’hébergement décrit l’infrastructure, la version de PHP fournie, les sauvegardes réalisées par l’hébergeur et les journaux mis à disposition. Lorsque les deux fonctions sont réparties entre deux sociétés, la frontière entre leurs obligations doit être identifiée avec précision : l’hébergeur qui fournit le langage et le prestataire qui administre le serveur peuvent se renvoyer la responsabilité, et seule la lecture croisée des deux contrats permet de savoir lequel devait appliquer le patch. Cette lecture s’effectue à la lumière du principe rappelé plus haut : les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits, de sorte que les engagements écrits priment sur les explications orales données après l’incident. Les devis acceptés, les conditions générales annexées et les échanges précontractuels qui précisent le périmètre complètent utilement l’analyse.
Sur le fondement du contrat, l’entreprise peut exiger l’exécution des prestations promises et, à défaut, mettre en œuvre les sanctions de l’inexécution. La mise en demeure constitue le pivot de cette phase : elle vise les clauses invoquées, décrit les manquements constatés avec leurs dates, rappelle les pièces déjà transmises et fixe ce qui est encore attendu, comme l’application du correctif, la fourniture des journaux ou la restauration d’une sauvegarde saine. Si l’inexécution est établie, l’article 1231-1 du Code civil ouvre droit à des dommages et intérêts, sauf pour le débiteur à justifier que l’exécution a été empêchée par la force majeure, ce qu’une faille documentée par des correctifs publics permet rarement de soutenir pour un professionnel de l’infogérance. Le préjudice réparable comprend les suites immédiates et directes de l’inexécution, comme le rappelle l’article 1231-4 du Code civil : frais de remise en service, perte de marge pendant l’interruption, coût des notifications et de l’assistance aux clients, honoraires d’expertise technique. Chacun de ces postes doit être documenté : comptabilité, relevés de ventes comparés, factures du prestataire de secours et constats d’huissier forment un ensemble probatoire que le juge pourra vérifier. Lorsque les manquements sont graves et répétés, la résolution du contrat peut être envisagée, mais elle ne fait pas disparaître les plafonds de responsabilité, comme l’a jugé la chambre commerciale dans l’arrêt du 7 février 2018 cité plus haut, et elle impose de sécuriser au préalable la migration vers un nouveau prestataire pour éviter une seconde interruption.
En dehors du contrat, deux actions restent ouvertes. D’une part, l’action contre l’auteur de l’intrusion, lorsqu’il est identifié, sur le fondement de la responsabilité extracontractuelle : l’article 1240 du Code civil dispose : « Tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celui par la faute duquel il est arrivé à le réparer. » L’intrusion frauduleuse, l’extraction de données et leur exploitation ultérieure constituent des fautes susceptibles d’engager cette responsabilité, et la condamnation pénale, lorsqu’elle intervient, facilite l’indemnisation civile. D’autre part, la discussion avec l’assureur : les polices couvrant les risques cyber conditionnent leur garantie au respect d’obligations de sécurité et de déclaration, et la déclaration de sinistre doit reprendre le dossier de pièces avec exactitude, sans minimiser ni exagérer. L’assureur qui conteste sa garantie devra être contredit pièces en main, à partir du texte de la police et des exclusions qu’elle comporte. Dans les deux cas, la règle probatoire reste la même : celui qui réclame l’exécution d’une obligation doit la prouver, et entre commerçants, les actes de commerce peuvent se prouver par tous moyens, ce qui donne leur pleine valeur aux journaux, aux constats et aux échanges écrits conservés depuis la découverte de la faille.
Conclusion
La faille PHP2Shell, documentée à partir du 20 octobre 2026 par les laboratoires de sécurité et relayée par la presse internationale, rappelle une règle simple : un site WordPress ou une boutique en ligne ne vaut que par la pile technique qui l’exécute, langage compris. La méthode proposée tient en quatre réflexes. Vérifier sans attendre la version de PHP qui fait tourner le site et la comparer aux versions corrigées annoncées, soit 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Appliquer le correctif après sauvegarde, tester le site et consigner chaque opération dans un journal daté. Qualifier l’incident à partir des traces conservées, déposer plainte en cas d’accès frauduleux avéré et examiner, lorsque des données personnelles sont en cause, les obligations de notification et d’information avec l’aide des guides de l’autorité. Enfin, relire les contrats d’hébergement et d’infogérance, adresser une mise en demeure précise en cas de manquement et chiffrer le préjudice poste par poste, dans la limite des clauses applicables. Les textes et les décisions cités donnent à chaque étape son fondement : force obligatoire du contrat, sanctions de l’inexécution, réparation des suites directes, sanction pénale de l’accès frauduleux et liberté de la preuve entre commerçants. Conservés avec rigueur, les journaux, les sauvegardes et les échanges écrits feront la différence entre une frayeur technique et un contentieux perdu.