PHP2Shell : deux failles critiques dans PHP (CVE-2026-109618 et CVE-2026-109619), comment s'en protéger

Le 20 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ». Toutes deux sont notées 9,2 sur 10 (CVSS v4.0) et peuvent permettre à un attaquant, sans compte ni mot de passe, d'exécuter du code à distance sur un serveur web PHP.

Si votre site ou votre application tourne sous PHP (WordPress, WooCommerce, Laravel, PrestaShop, Joomla, un site sur mesure…), cet article est pour vous.

Que se passe-t-il exactement ?

• CVE-2026-109618 : une erreur de mémoire insuffisante (out-of-memory) pendant certaines opérations laisse les données d'une requête partiellement initialisées. Les routines de fin de requête traitent ensuite cet état invalide comme valide.
• CVE-2026-109619 : une partie de l'état global propre à une requête survit alors que sa mémoire a été libérée. Une requête suivante traitée par le même processus la relit (use-after-free). Cela peut aussi faire fuiter de la mémoire du processus, qui peut contenir mots de passe, jetons ou clés d'API.

Selon l'analyse de Qualys, les déploiements concernés sont PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Apache avec mod_php est le cas jugé le plus urgent. L'exploitation dépend de la configuration et de l'application, mais PHP lui-même fait état d'un exploit démontré, et Cloudflare a signalé du trafic d'attaque.

Versions corrigées

Branche PHP	Version corrigée
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Les versions 8.1 et antérieures ne sont plus supportées officiellement. Le projet PHP a fourni des rétroportages limités du code source pour les branches 7.4, 8.0 et 8.1, mais la vraie solution est de migrer. Attention : les distributions Linux (Ubuntu, Debian, Red Hat…) corrigent souvent sans changer le numéro de version, il faut donc consulter l'avis de sécurité de votre distribution.

L'ampleur du problème

D'après la télémétrie de Qualys, environ 71 % des installations PHP dont la version est connue tournent sur des branches en fin de vie (5.4 à 8.1), qui ne recevront pas de correctif officiel. Un autre fournisseur de sécurité, Palo Alto Networks, estime à plus de 22 millions le nombre d'instances exposées. Ces chiffres varient selon les méthodes de mesure, mais l'ordre de grandeur est clair : c'est une faille qui touche une part énorme du web.

Ce qu'il faut faire, dans l'ordre

1. Inventoriez vos installations PHP. Hébergement mutualisé, VPS, conteneurs Docker, paquets de panneau d'hébergement : php -v en ligne de commande peut afficher un autre PHP que celui qui sert réellement votre site.
2. Mettez à jour vers une version corrigée, ou installez le paquet corrigé de votre distribution.
3. Redémarrez tous les processus PHP (PHP-FPM, Apache…) et vérifiez qu'aucun ne tourne encore avec l'ancienne version.
4. Si vous ne pouvez pas patcher tout de suite, appliquez la mesure d'urgence recommandée par PHP : désactiver session.upload_progress.enabled=0 dans php.ini, dans la configuration du pool FPM ou du serveur, puis redémarrer les processus. Un ini_set() dans le code ou un .user.ini ne suffisent pas. Cette mesure ne bloque que les chemins d'exploitation confirmés, ce n'est pas un correctif complet.
5. Limitez l'exposition : restreignez les tailles de requêtes (post_max_size) et l'upload multipart au niveau du serveur ou du proxy, et placez un pare-feu applicatif (WAF) devant le site si possible.
6. Surveillez et changez les secrets si doute. Comme la faille peut faire fuiter de la mémoire, faites tourner les mots de passe de base de données, clés d'API et jetons si votre serveur était exposé avant correction.

Et si votre site est hébergé par un prestataire ?

Demandez-lui par écrit quelle version PHP tourne sur votre hébergement et quand elle sera corrigée. Sur un hébergement mutualisé, la mise à jour dépend de l'hébergeur ; sur un WordPress, vérifiez aussi que les plugins sont à jour, car une faille PHP s'ajoute aux failles applicatives habituelles.

Ce qu'on retient

Les failles critiques ne préviennent pas : le temps entre la publication d'un correctif et les premières attaques se compte en heures. Le vrai risque pour les PME est moins la faille elle-même qu'un serveur que personne ne surveille. Un site « qui marche » depuis des années sur un vieux PHP est précisément la cible idéale.

Vous n'êtes pas sûr de la version PHP de votre site ou de votre application ? Contactez-nous pour un point rapide sur votre exposition, ou écrivez-nous sur WhatsApp au +225 01 04 09 16 45.

Sources : avis et analyses publiés les 20-22 octobre 2026 par Qualys, CERT-EU, Tenable, Rapid7, Palo Alto Networks (Unit 42) et le NCSC britannique. Les détails techniques peuvent évoluer ; référez-vous à l'avis officiel de votre distribution.