En bref : le correctif virtuel pour PHP comble le temps jusqu'à l'installation de la vraie mise à jour. Nous combinons pour cela des règles d'un pare-feu d'applications web avec les mesures transitoires que php.net a publiées pour PHP2Shell, et définissons aussitôt la voie vers le correctif régulier. Cela n'offre pas une protection complète, mais réduit le risque pendant la période transitoire.
Quand le correctif virtuel pour PHP est judicieux
Pour PHP2Shell, le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande la mise à jour immédiate et, si ce n'est pas possible, de déconnecter temporairement les serveurs web du réseau. Pour de nombreuses entreprises, ni l'un ni l'autre n'est réalisable sur-le-champ : une boutique doit rester joignable, un développement spécifique exige un test avant la mise à jour, ou le serveur fonctionne avec PHP 8.1 ou antérieur, pour lequel il n'existe plus de mises à jour officielles.
Dans ces cas, le correctif virtuel est un pont. Il ne remplace pas la décision de savoir si une exploitation hors ligne serait plus appropriée. Cette pesée vous appartient, nous fournissons l'appréciation technique.
Pourquoi un WAF seul ne suffit pas
Cloudflare a signalé des tentatives d'attaque observées et a déployé des règles de protection, mais avertit que des règles fondées sur les seules données de la requête ne suffisent pas. La raison tient à la nature des failles. Avec CVE-2026-109618, un état de mémoire insuffisante (out of memory) peut interrompre PHP alors que les données de la requête ne sont initialisées qu'en partie. Avec CVE-2026-109619, un état interne peut subsister après la libération de la mémoire et être exploité par une requête ultérieure dans le même worker. De telles erreurs dépendent de l'état du serveur, pas seulement du contenu d'une requête isolée.
C'est pourquoi nous misons sur plusieurs couches : des règles WAF en amont du serveur, des mesures transitoires dans PHP lui-même et une surveillance renforcée du serveur. Chaque couche arrête une partie, aucune ne suffit seule. Ensemble, elles vous donnent le temps d'installer la mise à jour de façon ordonnée.
Les mesures transitoires selon php.net
php.net cite plusieurs réglages qui réduisent le risque, expressément sans protection complète. Il est important que les applications ne puissent pas écraser ces valeurs. Un exemple pour un pool PHP-FPM avec envois de fichiers :
; Mesures transitoires PHP2Shell (pas de protection complète), puis redémarrer tous les workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 uniquement :
php_admin_flag[fatal_error_backtraces] = off
Sans envois de fichiers, php.net recommande post_max_size = 8M. Comme memory_limit est levé, une limite de mémoire au niveau du conteneur ou du cgroup en fait partie, et non via RLIMIT_AS ou RLIMIT_DATA. Le réglage session.upload_progress.enabled=0 relève de php.ini, du pool FPM ou de la configuration du serveur, pas de ini_set() ni de .user.ini. C'est aussi la parade à l'avis relatif à CVE-2026-115560. Toutes les mesures en un coup d'œil figurent sous Mesures immédiates si vous ne pouvez pas encore appliquer le correctif.
Les mesures transitoires ne produisent d'effet qu'après un redémarrage de tous les workers PHP. Et elles ne protègent que contre de futures attaques : elles ne répondent pas à la question de savoir si quelqu'un s'est déjà introduit auparavant.
Quand l'exploitation hors ligne est le meilleur choix
Le correctif virtuel n'est pas la bonne réponse dans toutes les situations. Dans certaines configurations, nous conseillons de suivre le BSI et de déconnecter temporairement le serveur web du réseau jusqu'à l'application du correctif :
- le serveur fonctionne avec Apache et mod_php, où l'équipe PHP estime le risque le plus élevé et où un exploit a été démontré avant même que le code de l'application ne s'exécute
- le serveur contient des données particulièrement sensibles, par exemple des données de santé, de clients de cabinets ou de paiement
- il n'existe aucune possibilité de définir les mesures transitoires de façon fixe dans la configuration du serveur, par exemple avec certaines offres d'hébergement mutualisé
- il existe déjà des indices que le serveur a été attaqué
Une exploitation hors ligne temporaire ne signifie pas que votre site web a été piraté. Certains fournisseurs ont mis des sites web hors ligne par précaution. Une brève page d'information sobre pour les visiteurs est alors généralement une meilleure solution qu'une panne inexpliquée.
Comment PHP SOS aide-t-il concrètement ?
- Examiner la situation : nous recensons les versions de PHP, les modes d'exécution et les couches de protection existantes comme le CDN, le WAF ou le proxy inverse. Avec mod_php, nous signalons le risque accru que l'équipe PHP y constate.
- Construire les couches : nous activons ou complétons les règles WAF, définissons les mesures transitoires de façon fixe dans la configuration du serveur et limitons la mémoire via le conteneur ou le cgroup. Pour les configurations Nginx, nous nous appuyons sur Sécuriser Nginx avec PHP-FPM.
- Redémarrage et test : tous les processus PHP sont redémarrés, puis nous vérifions les envois de fichiers, les formulaires, la connexion et la caisse.
- Observer : pendant la période transitoire, nous surveillons plus attentivement les plantages de workers, les pics de mémoire et les processus inhabituels.
- Planifier le correctif : nous fixons quand et comment la mise à jour régulière arrive, et la mettons en œuvre via le service de correctifs PHP.
Ce que vous recevez, ce dont nous avons besoin et ce que nous ne promettons pas
Vous recevez une documentation de toutes les règles et réglages définis avec justification, les résultats des tests et un calendrier et plan de mesures pour le vrai correctif. De votre part, nous avons besoin d'un accès au serveur ou au panneau d'administration, d'un accès au CDN ou au WAF s'il y en a un, d'un interlocuteur technique et d'indications sur les fonctions d'envoi de fichiers de vos applications.
Nous ne promettons pas que le correctif virtuel empêche une attaque. Il réduit le risque pour une durée limitée. Pour PHP 8.1 et antérieur, ce n'est pas un état durable ; la migration vers une version prise en charge doit figurer au plan.
Questions fréquentes
Qu'est-ce que le correctif virtuel ?
Le correctif virtuel consiste à protéger une faille connue en amont de l'application, au lieu de modifier le code lui-même. Cela se fait généralement par un pare-feu d'applications web ou des modifications de configuration. C'est un pont provisoire, pas un substitut à la mise à jour.
Le WAF de mon fournisseur de CDN suffit-il contre PHP2Shell ?
En règle générale, pas à lui seul. Cloudflare a déployé des règles de protection, mais avertit lui-même que des règles fondées sur les seules données de la requête ne suffisent pas. Le WAF est une couche supplémentaire à côté des mesures transitoires et du correctif.
Combien de temps puis-je compter sur le correctif virtuel ?
Le moins longtemps possible. Il doit combler le temps jusqu'à la mise à jour régulière, par exemple jusqu'à ce qu'une fenêtre de maintenance soit disponible ou qu'une application ait été testée. Pour PHP 8.1 et antérieur, un plan de migration en fait partie.
Les mesures transitoires peuvent-elles perturber mon site web ?
Oui, c'est possible. Des limites d'envoi plus basses peuvent empêcher l'envoi de gros fichiers, et la désactivation de Session Upload Progress affecte les barres de progression lors de l'envoi. Nous testons les fonctions les plus importantes après chaque modification.