En bref
Êtes-vous affecté ?
Si vous exécutez PHP pour servir des requêtes web (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed) dans une version antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, considérez que vous êtes affecté. Cela inclut les applications basées sur PHP telles que WordPress, Drupal, Magento et Laravel.
TR7 est-il affecté ?
Non. Les équipements TR7 ne comportent aucun composant PHP qui traite les requêtes HTTP ; les produits TR7 ne sont donc pas affectés par ces vulnérabilités. Les détails figurent dans TR7 est-il affecté ?.
Que faire maintenant
- Mettez à jour PHP sur vos serveurs d'applications web et redémarrez tous les workers PHP.
- Si vous ne pouvez pas effectuer la mise à jour aujourd'hui, appliquez sur ces serveurs les paramètres PHP temporaires ci-dessous.
- Jusqu'à la fin de la mise à jour, appliquez les paramètres de protection de base dans TR7 WAF-WAAP ; le premier d'entre eux consiste à placer vos applications PHP en Blocking mode.
Informations clés
| Identifiant de l'avis | TR7-SA-2026-001 |
|---|---|
| Nom | PHP2Shell |
| CVE | CVE-2026-109618 (exécution de code à distance via une corruption en situation de mémoire épuisée), CVE-2026-109619 (exécution de code à distance via un état global obsolète) |
| Avis officiels | Annonce de la PHP Security Team GHSA-w8hw-w9fx-j79w (CVE-2026-109618) GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) |
| Gravité | CVSS v4.0 9.2, critique (PHP Security Team) |
| Authentification requise | Non |
| Versions corrigées | PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 |
| Branches plus anciennes | La PHP Security Team a publié des correctifs rétroportés sous forme de code source pour PHP 7.4, 8.0 et 8.1. Les distributions Linux fournissent leurs propres paquets corrigés. |
| Exploitation | Des tentatives d'exploitation sont signalées. Au 22 octobre 2026, aucune compromission réussie n'avait été confirmée publiquement. |
| CISA KEV | Non répertoriée dans le catalogue du 21 octobre 2026 |
Chronologie
- 20 octobre 2026 Les détails des vulnérabilités ont été rendus publics avant la publication coordonnée.
- 21 octobre 2026 Le projet PHP a publié les versions corrigées ainsi que les avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp.
- 21-22 octobre 2026 Des tentatives d'exploitation ont été signalées et du code de preuve de concept public est apparu.
Fonctionnement de l'attaque
Les deux vulnérabilités se trouvent dans PHP lui-même, et non dans le code applicatif. L'attaque a lieu pendant que PHP lit encore la requête entrante, avant qu'une seule ligne de votre application ne s'exécute. Mettre à jour WordPress, une extension ou votre propre code ne corrige pas le problème.
- CVE-2026-109618 exploite le moment où PHP manque de mémoire. Les attaquants envoient des requêtes qui obligent PHP à consommer beaucoup de mémoire pendant l'analyse des données de formulaire et des fichiers téléversés, de sorte que PHP s'arrête dans un état non sûr.
- CVE-2026-109619 laisse des données obsolètes dans un worker PHP après une requête, et une seconde requête adressée au même worker les utilise. Un vecteur documenté utilise la fonctionnalité session upload progress de PHP, activée par défaut et déclenchée par un champ de formulaire nommé
PHP_SESSION_UPLOAD_PROGRESS.
Comme les requêtes qui portent ces attaques sont principalement des requêtes multipart/form-data (téléversement de fichiers), des corps de requête volumineux et des requêtes répétées, un pare-feu applicatif web peut en voir et en restreindre une grande partie. Il ne peut pas voir ce qui se passe dans la mémoire de PHP.
TR7 est-il affecté ?
Ces vulnérabilités se trouvent dans la couche de traitement des requêtes propre à PHP et affectent les serveurs d'applications qui exécutent PHP. Les équipements TR7 ne comportent aucun composant PHP qui traite les requêtes HTTP ; les produits TR7 ne sont donc pas affectés par ces vulnérabilités.
Ce que vous devez faire maintenant
Les actions portent sur deux endroits : vos propres serveurs d'applications web qui exécutent PHP, et TR7 WAF-WAAP. Chaque section numérote ses propres étapes.
Sur vos serveurs
Étape 1 : mettez à jour PHP sur vos serveurs d'applications web (la seule correction complète)
- Mettez à jour PHP sur les serveurs qui exécutent votre application web vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou installez le paquet corrigé de votre distribution Linux. Les paquets des distributions conservent souvent l'ancien numéro de version ; recherchez les numéros CVE dans le journal des modifications du paquet.
- Redémarrez tous les workers PHP (pools PHP-FPM, Apache, LiteSpeed, workers de longue durée). Les processus en cours d'exécution continuent d'utiliser l'ancien code jusqu'à leur redémarrage.
- Reconstruisez les images de conteneur qui embarquent leur propre PHP. La mise à jour de l'hôte ne met pas à jour le PHP présent dans une image.
- PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. Planifiez une migration vers une branche prise en charge.
Étape 2 : paramètres PHP temporaires sur vos serveurs d'applications web (si vous ne pouvez pas effectuer la mise à jour aujourd'hui)
Ces paramètres se définissent dans la configuration PHP du serveur qui exécute votre application web (php.ini ou paramètres du pool PHP-FPM). La PHP Security Team énumère ces mesures. Elles réduisent l'exposition à certains vecteurs d'attaque mais ne rendent pas une installation sûre.
| Paramètre | Objectif |
|---|---|
session.upload_progress.enabled = 0 | Supprime le vecteur session upload progress de CVE-2026-109619. Redémarrez tous les workers. La PHP Security Team suggère de le laisser désactivé après l'application du correctif si vous n'en avez pas besoin. |
fatal_error_backtraces = 0 (PHP 8.5) | Supprime le vecteur fatal error backtrace |
post_max_size = 8M (sans téléversement) ou 32M (avec téléversements), avec une valeur upload_max_filesize inférieure | Réduit la mémoire qu'un attaquant peut forcer PHP à utiliser |
memory_limit = -1, défini avec php_admin_value | Supprime la défaillance contrôlable liée à la limite de mémoire. Une seule requête peut alors utiliser toute la mémoire du serveur ; utilisez des limites de conteneur ou de cgroup, jamais RLIMIT_AS ni RLIMIT_DATA |
Sur TR7 WAF-WAAP
Si vous pouvez mettre à jour PHP immédiatement, c'est la véritable correction. Sinon, jusqu'à la fin de la mise à jour, vous pouvez protéger vos applications PHP contre ces attaques grâce aux paramètres de sécurité que TR7 WAF-WAAP fournit déjà, sans aucune mise à jour TR7. Les trois paramètres de l'étape 1 constituent la protection de base ; les mesures complémentaires de l'étape 2 réduisent davantage la surface d'attaque, choisissez donc celles qui conviennent à votre application. Appliquez les paramètres vService par vService et testez-les d'abord sur un vService hors production.
Étape 1 : protection de base
1.1 Passez le WAF en Blocking mode
Un WAF qui se contente de surveiller n'arrête pas une attaque. Lorsque le WAF est activé pour la première fois, il démarre en Learning mode ; le Monitor mode ne fait qu'enregistrer. Pour chaque vService PHP, ouvrez l'écran WAF Mode et vérifiez qu'il est en Blocking mode.
Attention : Avant de basculer, examinez les exclusions de signatures apprises sur chaque champ. Si les exclusions d'un champ dépassent la valeur Max. owasp exclusions, l'inspection des signatures est désactivée pour ce champ.
1.2 Ajoutez deux règles personnalisées
Sur l'écran Signature & Rule Library (WAF → Signature & Rule Library → Add), ajoutez séparément les deux règles ci-dessous. Démarrez-les toutes les deux dans l'état Monitor et passez-les à Enabled après avoir examiné les Event Logs. Les règles s'appliquent à chaque vService protégé par le WAF.
Règle 1 : champ session upload progress
- Pattern (Regex):
PHP_SESSION_UPLOAD_PROGRESS - Inspection Scopes: Form et Raw
- Score: Very High
Intercepte le champ de formulaire qui déclenche le vecteur session upload progress de CVE-2026-109619. Pour les applications qui utilisent légitimement cette fonctionnalité, excluez uniquement les chemins de téléversement qui en ont besoin.
Règle 2 : champ de formulaire PHPSESSID
- Pattern (Regex):
^PHPSESSID$ - Inspection Scopes: Form
- Score: Very High
Intercepte les requêtes qui transmettent l'identifiant de session dans un champ de formulaire nommé PHPSESSID au lieu d'un cookie ; certains vecteurs d'attaque utilisent cette forme, qui est rare dans le trafic légitime. Si votre application utilise un autre nom de session (session.name), utilisez ce nom.
Pour que les règles fonctionnent : Les règles sont analysées par les inspections Form et RAW du type de page qui correspond à la requête. Sur un type de page sans inspection Form, les corps de formulaire et de téléversement de fichiers ne sont pas analysés.
- Laissez OWASP check activé dans la règle Any Paths et dans les types de page qui disposent de leur propre inspection Form ou RAW.
- Ajoutez à chaque type de page glob sa propre inspection Form et RAW avec les boutons Add common rule for Form et Add common rule for Raw ; ne vous fiez pas aux paramètres hérités.
1.3 Bloquez les corps volumineux et non inspectables
Sur l'écran WAF Rules, effectuez deux réglages dans l'inspection RAW :
- Définissez Raw Body Size sur le plus grand corps dont le chemin a besoin (en octets ; par exemple 8388608 = 8 Mo sur les chemins sans téléversement, 33554432 = 32 Mo sur les chemins de téléversement). La plage par défaut autorise des corps jusqu'à 256 Mo.
- Faites passer le sélecteur de corps non analysé de Allow unparsed body à Block unparsed body. Sinon, un corps qui ne tient pas dans le tampon d'inspection est transmis au Backend Service sans aucune inspection de contenu.
Où ? Le WAF inspecte une requête uniquement avec les paramètres du type de page qui correspond à son chemin. Effectuez ces deux réglages dans la règle Any Paths, dans chaque type de page qui affiche Raw dans la colonne Check Fields, et dans chaque type de page glob ; pour un type de page glob qui n'en possède pas, ajoutez d'abord une inspection RAW avec Add common rule for Raw.
Attention : Raw Body Size s'applique lorsque Structure Checks est activé, sur l'écran Checks. Testez d'abord les téléversements légitimes volumineux. Les corps envoyés sans longueur déclarée ne sont pas mesurés par cette limite ; sur les chemins autres que les chemins de téléversement, ils peuvent être bloqués avec 2.1.
Étape 2 : mesures complémentaires
Ces mesures complètent la protection de base ; choisissez celles qui conviennent à votre application.
2.1 Bloquez les téléversements de fichiers là où vous n'en avez pas besoin
Les requêtes d'attaque sont principalement des requêtes multipart/form-data (téléversement de fichiers). Si seuls quelques chemins de votre application acceptent des fichiers, bloquez les requêtes multipart vers tous les autres chemins à l'aide d'une règle du répartiteur de charge. La règle se compose de deux conditions et d'une action Block. Tous les écrans sont accessibles depuis le Configuration Menu, qui s'ouvre avec le logo TR7 en bas à gauche.
A. Créez les conditions (Load Balancer → Conditions → Add)
- Condition de requête multipart : Criteria = HTTP header, méthode de correspondance Includes, Header Name = Request →
Content-Type, Query =multipart/form-data, Case Insensitive activé. Saisissez un Condition Name tel quemultipart-requestet enregistrez avec Add. - Condition des chemins de téléversement : Criteria = Path, méthode de correspondance Regex, puis saisissez dans Query les chemins qui acceptent des fichiers (par exemple
^/(upload|media/upload)). Saisissez un Condition Name tel queupload-pathset enregistrez avec Add.
B. Créez l'action Block (Load Balancer → Actions → Add)
- Saisissez un Action Name (par exemple
block-multipart), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403. - Dans Conditions, sélectionnez
multipart-requestet!upload-pathsdans le même groupe de conditions (and par défaut). Chaque condition apparaît deux fois dans la liste : elle-même et sa négation (NOT), qui commence par!;!upload-pathssignifie « pas l'un des chemins de téléversement ». - Activez Hit Counter pour compter les requêtes bloquées et enregistrez avec Add.
C. Ajoutez l'action au vService
- Dans Load Balancer → Load Balancer vService List, sélectionnez le vService et cliquez sur Edit, sélectionnez l'action dans Actions sous Details, puis cliquez sur Save.
D. Bloquez également les corps envoyés sans longueur déclarée
- Créez une autre condition HTTP header : méthode de correspondance Is present, Header Name = Request →
Content-Length, Condition Name par exemplehas-length. - Créez une seconde action Block (On Request, Standard, 403). Dans Conditions, sélectionnez la condition prédéfinie If HTTP method is POST,
!has-lengthet!upload-pathsdans le même groupe de conditions, puis ajoutez l'action au champ Actions du vService. La condition POST est obligatoire ; sans elle, les requêtes GET sans corps sont également bloquées.
La limite de taille de 1.3 ne voit pas la taille réelle d'un corps envoyé sans longueur déclarée. Cette règle couvre à la fois les téléversements HTTP/1.1 en flux (chunked) et les corps HTTP/2 sans longueur déclarée sur les chemins autres que les chemins de téléversement. Les requêtes POST sans corps et sans en-tête Content-Length correspondent également à cette règle ; testez-la d'abord sur un vService hors production.
Vérification : Une requête multipart (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), une requête HTTP/1.1 chunked (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) et une requête HTTP/2 sans longueur déclarée (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) vers un chemin autre que les chemins de téléversement doivent recevoir 403, et les requêtes vers vos chemins de téléversement doivent passer. --http1.1 est obligatoire pour le test HTTP/1.1 : curl utilise HTTP/2 par défaut sur https et n'envoie pas Transfer-Encoding en HTTP/2. Le compteur apparaît dans l'onglet Action Hits du tableau de bord du vService.
Attention : Une action Block sans condition sélectionnée s'applique à toutes les requêtes adressées au vService. Listez l'ensemble des chemins de téléversement de manière exhaustive et testez d'abord la règle sur un vService hors production.
2.2 Limitez les requêtes POST par client
Cette règle n'arrête pas une attaque ciblée : l'exploit peut fonctionner avec seulement quelques requêtes. Elle augmente en revanche le coût des outils automatisés qui testent de nombreuses cibles. La règle compte les requêtes POST de chaque adresse IP cliente et bloque avec 429 les requêtes POST d'un client qui dépasse le seuil. Le blocage est levé automatiquement lorsque le compteur repasse sous le seuil.
A. Créez l'action de comptage (Load Balancer → Actions → Add)
- Saisissez un Action Name, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = par exemple
post-rate(3 à 20 caractères ; lettres, chiffres,-,_), Tracking Period = 1 minute. - Dans Conditions, sélectionnez la condition prédéfinie If HTTP method is POST et enregistrez avec Add. Seules les requêtes POST sont alors comptées.
B. Créez la condition de seuil (Load Balancer → Conditions → Add)
- Criteria = Tracking Condition, Tracked Table =
post-rate, Tracking Criteria = HTTP requests, et le seuil avec Tracking Operator (par exemple> 100). Enregistrez avec Add.
C. Créez l'action Block (Load Balancer → Actions → Add)
- Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
- Dans Conditions, sélectionnez la condition de seuil de l'étape 3 et If HTTP method is POST dans le même groupe de conditions (and par défaut). Sans la condition POST, les requêtes GET d'un client qui dépasse le seuil sont également bloquées. Enregistrez avec Add.
D. Ajoutez les actions au vService
- Dans le formulaire Edit du vService, dans Details → Actions, sélectionnez l'action de comptage en premier et l'action Block en second, puis cliquez sur Save. Les actions s'exécutent dans l'ordre de la liste.
Vérification : Dans l'onglet Logs & Tracking du vService, sélectionnez la table de suivi de l'action de comptage dans la liste Logs Type ; les compteurs POST par client s'affichent. Définissez le seuil en fonction du trafic normal de votre application : observez dans la table le nombre de POST par minute des clients légitimes (par exemple des systèmes qui utilisent une API, ou des organisations situées derrière une IP sortante partagée) et fixez le seuil au-dessus.
2.3 Passez la protection DDoS L7 en Active
Si la protection Bot/DDoS fait partie de votre licence, Source IP Request Protection sous L7 DDoS Protection limite le nombre total de requêtes qu'une même adresse source peut effectuer sur une période donnée. Contrairement à 2.2, elle compte toutes les requêtes et ne nécessite aucune règle supplémentaire.
- Dans le formulaire Edit du vService, sélectionnez L7 DDoS & Threat Protection sous Details et cliquez sur Save (si l'option n'est pas activée). Lorsque la protection est activée, L7 DDoS Protection démarre en mode Monitor ; dans ce mode, les dépassements de limite sont uniquement enregistrés en tant qu'événements.
- Dans Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management, cliquez sur le lien Edit de la carte L7 DDoS Protection.
- Définissez DDoS Protection = Active et enregistrez avec le bouton Edit.
- Sur la carte, cliquez sur l'icône en forme de crayon du bloc Source IP Request Protection. Définissez Time Window (10 secondes par défaut), Request Limit (1000 par défaut) et Limit Action (Show Captcha par défaut ; Block peut également être sélectionné) en fonction du trafic de votre application, puis enregistrez avec le bouton Edit.
Attention : Observez les événements en mode Monitor pendant un certain temps avant de passer en Active. Répétez la même observation lorsque vous abaissez la Request Limit.
Vérifiez si vous avez été ciblé
Voir Détection et surveillance. Des tentatives d'exploitation ont été signalées avant la divulgation publique ; examinez donc les journaux à partir du 17 octobre 2026.
Ce qu'un WAF peut et ne peut pas faire
| Un WAF peut | Un WAF ne peut pas |
|---|---|
| Bloquer des formes de requêtes connues, comme le champ session upload progress | Corriger le code vulnérable dans PHP |
| Limiter la taille du corps, les chemins de téléversement et le débit des requêtes | Mesurer l'utilisation de la mémoire dans le processus PHP |
| Bloquer les téléversements sur les chemins qui n'en ont pas besoin | Voir les requêtes qui atteignent votre serveur sans passer par lui |
| Enregistrer les requêtes bloquées et limitées en débit | Annuler du code déjà exécuté sur le serveur |
Les règles WAF font gagner du temps pour la mise à jour ; la correction durable consiste à mettre à jour PHP. Pour que ces protections fonctionnent, tout le trafic destiné à vos applications PHP doit passer par TR7 WAF-WAAP.
Détection et surveillance
Dans TR7
- Sur l'écran Event Logs de chaque vService protégé par le WAF, filtrez les enregistrements par vos règles personnalisées et examinez le champ correspondant et le score.
- Sur le même écran, examinez les requêtes bloquées par les règles de taille du corps et de corps non analysé.
- Si vous avez appliqué les mesures complémentaires, surveillez les compteurs des règles du répartiteur de charge dans l'onglet Action Hits du tableau de bord du vService, ainsi que les clients ayant atteint la limite de débit POST dans la table de suivi de l'onglet Logs & Tracking.
Sur vos serveurs
- Recherchez dans les journaux d'erreurs PHP des erreurs telles que
Allowed memory size ... exhausted, des plantages de workers et des réponses HTTP 500 répétées ; soyez attentif à celles qui surviennent juste après des requêtesmultipart/form-datavolumineuses. - Vérifiez si les réponses contiennent des cookies
PHPSESSIDanormalement volumineux ou malformés. - Recherchez dans les racines web des fichiers nouveaux ou modifiés, et vérifiez la présence de processus inattendus lancés par l'utilisateur du serveur web, de nouvelles tâches cron et de connexions sortantes inattendues.
Questions fréquentes
Non. Les équipements TR7 ne comportent aucun composant PHP qui traite les requêtes HTTP ; les produits TR7 ne sont donc pas affectés par ces vulnérabilités. Voir « TR7 est-il affecté ? ».
Aucun WAF ne peut protéger entièrement contre ces vulnérabilités. TR7 WAF-WAAP réduit la surface d'attaque et bloque les vecteurs d'attaque connus ; la mise à jour de PHP est la seule correction complète.
Utilisez contre PHP2Shell les deux règles personnalisées de TR7 WAF-WAAP 1.2 ; elles s'appliquent immédiatement à tous les vServices protégés par le WAF.
Non. Les vulnérabilités se trouvent dans l'environnement d'exécution PHP. Mettez à jour PHP lui-même, ou demandez à votre hébergeur de le faire.
C'est possible. Les limites de taille du corps, le blocage des téléversements et les règles personnalisées peuvent affecter des téléversements et des formulaires légitimes. Pour les règles WAF, commencez en Monitor mode, examinez les Event Logs, puis passez en Blocking mode. Testez d'abord les règles du répartiteur de charge (2.1, 2.2) sur un vService hors production.
Historique des mises à jour
- 23 octobre 2026 Publication initiale.
Références
- Annonce de la PHP Security Team : php.net/archive/2026.php
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618) : github.com/php/php-src
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) : github.com/php/php-src
- CVE-2026-109618 : cve.org
- CVE-2026-109619 : cve.org
- Catalogue CISA Known Exploited Vulnerabilities : cisa.gov
- Documentation TR7 : docs.tr7.com
Besoin d'aide pour appliquer ces paramètres ?
L'équipe support TR7 peut examiner votre configuration WAF et vous aider à déployer ces protections. Contactez votre représentant TR7 ou l'équipe support TR7 à l'adresse support@tr7.com.