Existe-t-il un contournement pour la CVE-2026-109618 et la CVE-2026-109619 ?
Seulement des contournements partiels, et aucun ne corrige la faille. L’avis de PHP l’écrit en toutes lettres : seule une mise à jour est une solution complète ; les mesures suivantes réduisent l’exposition à certains chemins d’attaque, mais ne rendent pas une installation sûre. Pour la CVE-2026-109619, l’avis GitHub ajoute qu’il n’existe aucune mesure de configuration générique et complète. N’utilisez ces réglages que pour gagner du temps en attendant d’installer le correctif PHP2Shell.
En France, l’alerte du CERT-FR (ANSSI) recommande d’isoler les systèmes concernés et de passer à une version maintenue, et précise que les contournements temporaires ne sont pas validés par le CERT-FR.
Quelles sont les mesures temporaires officielles ?
| Réglage | Pour | Ce qu’il bloque | Effets de bord |
|---|---|---|---|
memory_limit=-1 (de façon que les applications ne puissent pas le modifier) | CVE-2026-109618 | L’échec contrôlable lié à la limite de mémoire de PHP. Un échec d’allocation sous-jacent peut toujours atteindre le code vulnérable. | Les processus PHP peuvent consommer une mémoire illimitée ; surveillez les ressources du serveur. |
post_max_size bas : 8M si vous n’avez pas besoin de téléversements, 32M si vous en avez besoin | CVE-2026-109618 | Réduit la quantité de données de requête que l’on peut injecter dans PHP | Les téléversements et formulaires plus volumineux échouent. |
session.upload_progress.enabled=0 | CVE-2026-109619 | Les chemins confirmés passant par les sessions, pas les autres variantes | Les fonctions de suivi de progression des téléversements peuvent cesser de fonctionner. |
fatal_error_backtraces=0 (PHP 8.5 uniquement) | CVE-2026-109619 | Uniquement le chemin confirmé passant par les traces d’erreurs fatales | Moins de détails de diagnostic dans les journaux d’erreurs. |
Chacun de ces réglages ne prend effet qu’après un redémarrage de tous les processus PHP. PHP met aussi en garde : ne les remplacez pas par des limites RLIMIT_AS ou RLIMIT_DATA, qui peuvent justement provoquer l’échec d’allocation vulnérable, et masquer les erreurs avec error_reporting, display_errors ou @ ne sert à rien.
Comment appliquer correctement le contournement session.upload_progress ?
Le réglage doit s’appliquer avant que PHP n’analyse la requête :
- Définissez
session.upload_progress.enabled=0dansphp.ini, dans la configuration du pool PHP-FPM ou dans celle du serveur web. - N’utilisez ni
ini_set()dans le code, ni un fichier.user.iniFPM : ils s’appliquent trop tard. - Redémarrez tous les processus PHP (tous les pools PHP-FPM, ou Apache pour mod_php). Les processus qui n’ont pas redémarré tournent toujours avec l’ancien réglage.
En hébergement mutualisé, vous ne pouvez généralement pas modifier ces réglages vous-même ; adressez-vous à votre hébergeur, ou faites installer le correctif par lui.
« Mon site n’a pas de formulaire d’envoi de fichiers » : est-ce un contournement ?
Non. Les chemins d’attaque se situent dans le traitement des requêtes par PHP, pas dans le formulaire de téléversement de votre site : un site sans envoi de fichiers n’est donc pas automatiquement à l’abri. C’est pour cela que le réglage officiel est une option PHP au niveau du serveur, et non un interrupteur dans l’application.
Un WAF comme Cloudflare compte-t-il comme contournement ?
Non. C’est une couche supplémentaire, pas un correctif. Cloudflare a déployé automatiquement des règles WAF sur toutes les offres qui incluent le WAF, y compris l’offre gratuite, environ neuf heures avant la divulgation, et a signalé que des attaquants modifiaient leurs charges pour les contourner. Un WAF ne filtre que le trafic qui passe par lui, et le PHP de votre serveur reste vulnérable.
Une extension de mode maintenance fait-elle office de contournement ?
Pas de façon fiable. Une page de maintenance WordPress est elle-même servie par PHP, et certains chemins d’attaque interviennent avant l’exécution du code de l’application. Pour couper l’exposition sans correctif, bloquez les requêtes avant qu’elles n’atteignent PHP ou mettez le site hors ligne, comme plusieurs agences nationales l’ont conseillé pour les sites impossibles à mettre à jour.
Combien de temps peut-on s’en remettre à un contournement ?
Seulement jusqu’à ce que vous puissiez mettre à jour, idéalement quelques jours. Les correctifs et les analyses techniques sont publics, et Sansec s’attend à une exploitation de masse. Planifiez la mise à jour dès maintenant. Faites le point avec le vérificateur PHP2Shell, et lisez les pages CVE-2026-109618 et CVE-2026-109619 pour le détail de chaque faille.
Sur quelles sources s’appuie cette page ?
- The PHP Group : avis de sécurité et mesures d’atténuation
- Avis GitHub GHSA-w8hw-w9fx-j79w
- Avis GitHub GHSA-6wmf-4rv5-p3rp
- Cloudflare : protections WAF
- Sansec : recherche sur PHP2Shell
Vérifiez votre PHP face à PHP2Shell
Saisissez la version indiquée par votre site. Nous la comparons à la première version corrigée de sa branche et vous indiquons la marche à suivre.
Vérificateur PHP2Shell →Sources
Les faits essentiels de cette page (versions corrigées, détails des CVE, paquets des distributions et alertes des agences) proviennent de sources officielles. Les travaux de recherche, articles de presse et publications de la communauté sont signalés comme tels.
- Security advisory: Critical remote code execution vulnerabilities, update nowOfficiel The PHP Group
- RCE via OOM corruptionOfficiel The PHP Group
- RCE via stale global stateOfficiel The PHP Group
- Cloudflare deploys protections against php2shell vulnerabilityFournisseur CDN Cloudflare
- PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)Recherche Sansec