Faille PHP2Shell : comment patcher votre site PHP au Maroc en 2026

En bref. Le 21 octobre 2026, l'équipe PHP a publié en urgence des correctifs pour deux failles critiques du cœur de PHP, baptisées PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Une simple requête HTTP, sans mot de passe, peut suffire à prendre le contrôle d'un serveur. Toutes les versions de PHP 5.4 à 8.5.11 sont concernées. Au Maroc, où PHP fait tourner plus d'un site populaire sur deux, c'est le moment de vérifier les vôtres. Ce guide raconte l'affaire en cinq actes, puis vous donne la procédure exacte pour patcher.

Acte 1 : un secret qui n'a pas tenu 24 heures

Normalement, une faille de cette ampleur suit un protocole discret : les chercheurs préviennent les développeurs, les correctifs sont préparés en silence, les distributions Linux reçoivent les paquets en avance, puis tout est annoncé le même jour. Le grand public apprend l'existence de la faille au moment où le remède est déjà disponible.

Cette fois, le scénario a déraillé. Le 20 octobre, les identifiants des deux CVE ont fuité sur un forum très suivi par les développeurs, avec la date prévue de divulgation. En quelques heures, l'information faisait le tour des réseaux sociaux. La PHP Foundation a donc avancé la publication d'un jour : les correctifs sont sortis le 21 octobre à 14h00 UTC.

Détail inquiétant : Amazon Threat Intelligence indique avoir observé une première tentative d'exploitation sur ses serveurs-pièges dès le 17 octobre, quatre jours avant l'annonce. Depuis le 21, Amazon, Cloudflare et watchTowr rapportent des tentatives venant de plusieurs groupes.

Date	Ce qui s'est passé
17 octobre 2026	Première tentative d'exploitation repérée par Amazon, avant toute annonce
20 octobre 2026	Fuite des identifiants CVE, préavis de l'équipe PHP, alerte du CERT-EU
21 octobre 2026	Sortie des versions corrigées, alerte de la CISA américaine, premières attaques signalées
22 octobre 2026	Du code d'exploitation non vérifié circule publiquement

Acte 2 : deux failles, expliquées sans jargon

PHP2Shell n'est pas un bug dans WordPress, PrestaShop ou Laravel. C'est un bug dans l'interpréteur PHP lui-même, le moteur qui exécute le code de votre site. Peu importe la qualité de votre application : si le moteur est vulnérable, le site l'est aussi. Les deux failles sont notées 9,2 sur 10 (CVSS v4.0) par l'équipe PHP. Certains chercheurs les placent même à 10.

CVE-2026-109618 : le verre de thé qui déborde

Imaginez qu'on vous serve du thé dans un verre trop petit. Le verre déborde avant d'être plein, et quelqu'un essuie la table en croyant que le verre a été servi correctement. C'est exactement ce qui se passe ici.

Quand PHP manque de mémoire pendant qu'il prépare une requête (out of memory), il abandonne le travail en cours. Mais le nettoyage qui suit peut traiter des données à moitié initialisées comme si elles étaient valides. Un attaquant peut provoquer ce débordement avec une requête d'envoi de fichiers (multipart) spécialement fabriquée, qui épuise la mémoire même si sa taille semble respecter les limites configurées. Résultat : corruption de la mémoire, puis exécution de code.

Avec Apache mod_php, le scénario fonctionne avant même que votre application ne démarre, avec les réglages par défaut. C'est la configuration la plus exposée.

CVE-2026-109619 : la clé du client précédent

Dans un riad, chaque chambre est nettoyée entre deux clients et les anciennes clés sont désactivées. Imaginez maintenant que le ménage soit interrompu par une alarme, et qu'une vieille clé ouvre encore la porte. Le client suivant entre dans une chambre qui n'est plus censée exister.

Pour aller vite, PHP réutilise le même processus (le worker) pour traiter plusieurs requêtes successives. Si une erreur fatale (mémoire épuisée, délai dépassé) interrompt le nettoyage, une référence vers une zone mémoire déjà libérée reste en place. La requête suivante, traitée par le même worker, peut la réutiliser : c'est une faille de type use-after-free. Les chercheurs ont démontré l'exécution de code via deux chemins actifs par défaut : le suivi de progression des envois (session.upload_progress), qui touche aussi PHP-FPM, et les traces d'erreurs fatales de PHP 8.5.

À retenir : masquer les erreurs (display_errors, error_reporting, l'opérateur @) ne protège pas. L'absence de traces dans vos journaux ne prouve pas que vous êtes à l'abri.

Acte 3 : pourquoi c'est vraiment grave

• Aucune authentification nécessaire. Pas besoin de compte, de mot de passe ni d'un clic de votre part. Une requête suffit.
• Tous les modes de déploiement sont concernés : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed.
• Une portée historique. Le chemin vulnérable existe depuis PHP 5.4, sorti en 2012. Les versions 5.4 à 7.3 ne recevront jamais de correctif.
• Le contrôle total du serveur. Un attaquant qui exécute du code avec les droits de PHP peut lire votre base de données (clients, commandes, mots de passe), installer une porte dérobée, injecter des pages de phishing ou utiliser votre serveur pour attaquer d'autres sites.
• La course a commencé. Les attaques automatisées scannent Internet en continu. Un site oublié depuis trois ans est une cible aussi simple qu'un site neuf.

Acte 4 : le Maroc sous la loupe

Au niveau mondial, PHP fait tourner environ 70 % des sites dont la technologie serveur est connue, selon W3Techs. Mais qu'en est-il chez nous ? Les statistiques publiques par pays sont rares, alors nous avons mesuré nous-mêmes.

Le 22 octobre 2026, au lendemain des correctifs, nous avons pris les 527 domaines en .ma présents dans le classement Tranco du million de sites les plus visités au monde. Nous avons visité chaque page d'accueil une seule fois, comme le ferait un navigateur, sans aucun test d'intrusion. Aucun nom de site n'est publié.

Indicateur	Résultat
Sites .ma populaires joignables	420
Sites montrant des signes clairs de PHP	227, soit 54 % (estimation basse)
Sites sous WordPress	94, soit 22 %
Sites qui affichent publiquement leur version de PHP	66
Parmi eux, versions non corrigées	54 sur 66, soit 82 %
Parmi eux, branches sans correctif officiel (8.1 ou plus ancienne)	31 sur 66, soit 47 %
Parmi eux, encore sur PHP 5 ou 7.3 et plus ancien	9

Trois enseignements :

1. Plus d'un site marocain populaire sur deux repose sur PHP. Le chiffre réel est probablement plus haut, car beaucoup de serveurs masquent leur technologie.
2. Près de la moitié des versions visibles sont en fin de vie. PHP 7.4, arrêté depuis fin 2022, reste la version la plus fréquente après 8.3. Pour ces sites, une simple mise à jour de paquet ne suffira pas : il faut migrer.
3. Afficher sa version est déjà un risque. Ces 66 sites annoncent leur version dans l'en-tête X-Powered-By. Pour un robot d'attaque, c'est une invitation : il sait immédiatement qui est vulnérable.

Bonne nouvelle quand même : 12 sites étaient déjà passés sur une version corrigée moins de 24 heures après la publication. C'est faisable, et rapidement.

Acte 5 : la procédure de correction, étape par étape

Comptez 15 à 30 minutes pour un serveur à jour avec une distribution récente. Comptez plutôt une à trois journées si vous devez migrer depuis PHP 7.x ou 8.0, car il faudra tester la compatibilité de votre application.

Étape 1 : identifier votre version et votre mode d'exécution

php -v
# Apache avec mod_php ?
apache2ctl -M 2>/dev/null | grep -i php
# PHP-FPM ?
systemctl list-units --type=service | grep -i fpm

Attention : la version en ligne de commande peut différer de celle utilisée par le site. En cas de doute, vérifiez la version de PHP-FPM ou celle affichée dans votre panneau d'hébergement.

Étape 2 : comparer avec les versions corrigées

Votre branche	Version à installer
PHP 8.5	8.5.12 ou plus
PHP 8.4	8.4.27 ou plus
PHP 8.3	8.3.36 ou plus
PHP 8.2	8.2.35 ou plus
PHP 7.4, 8.0, 8.1	Pas de version officielle : correctif de votre distribution, ou migration vers 8.3/8.4
PHP 5.4 à 7.3	Aucun correctif : migration obligatoire

Étape 3 : mettre à jour

Sur Ubuntu ou Debian (adaptez le numéro de version) :

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
# Les distributions corrigent souvent sans changer le numéro de version.
# Vérifiez que le correctif est bien présent :
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

Sur un hébergement mutualisé ou cPanel : ouvrez le sélecteur de version PHP (MultiPHP Manager ou équivalent) et choisissez une branche à jour. Si votre hébergeur ne propose pas encore de version corrigée, contactez son support et demandez explicitement une date pour CVE-2026-109618 et CVE-2026-109619.

Avec Docker : mettez à jour l'image de base (par exemple php:8.4-fpm), reconstruisez sans cache, puis redéployez.

Étape 4 : redémarrer tous les processus PHP

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # si vous utilisez mod_php

Sans redémarrage, l'ancien code reste en mémoire et le serveur reste vulnérable.

Étape 5 : si vous ne pouvez pas patcher aujourd'hui

Ces mesures réduisent le risque mais ne remplacent pas la mise à jour. Elles doivent être placées dans php.ini, dans le pool FPM ou dans la configuration Apache, jamais dans un .user.ini ou via ini_set(), qui arrivent trop tard :

; Ferme le chemin d'attaque par les sessions (CVE-2026-109619)
session.upload_progress.enabled = 0
; PHP 8.5 uniquement : ferme le chemin des traces d'erreurs fatales
fatal_error_backtraces = 0
; Masque votre version aux robots (bonne pratique, pas un correctif)
expose_php = Off

Autres mesures recommandées : limiter post_max_size à 8M si votre site n'accepte pas de fichiers (32M sinon), bloquer les requêtes multipart en amont si l'application n'en a pas besoin, et activer un pare-feu applicatif. Cloudflare a déployé des règles de protection, y compris sur son offre gratuite, mais elles ne couvrent que le trafic qui passe par Cloudflare. Pour les sites en fin de vie qui ne peuvent pas être corrigés, la CISA recommande tout simplement de les mettre hors ligne en attendant.

Épilogue : vérifier que personne n'est déjà entré

Des attaques ont été observées avant la publication des correctifs. Une fois votre serveur à jour, prenez dix minutes pour vérifier ces trois points :

1. Des processus suspects lancés par PHP. Un worker PHP qui démarre un shell, curl ou wget est un signal d'alarme :

   ps -ef --forest | grep -B2 -A3 -E 'php-fpm|apache2|httpd'

2. Des fichiers PHP récemment créés ou modifiés que vous ne reconnaissez pas :

   find /var/www -name '*.php' -newermt '2026-10-15' -ls

3. Des comptes administrateurs inconnus dans WordPress, PrestaShop ou votre back-office, et des tâches planifiées (crontab -l) que vous n'avez pas créées.

Si vous trouvez quelque chose de suspect, ne supprimez rien dans la précipitation : isolez le serveur, conservez les journaux, changez les mots de passe (base de données, administration, clés API) depuis une machine saine, puis faites appel à un spécialiste.

Un coup de main, offert par BerryNoon

Derrière chaque site marocain, il y a une entreprise, une association, une école ou un artisan qui compte sur lui. Beaucoup n'ont ni équipe technique ni le temps de lire des bulletins de sécurité en anglais. C'est pour eux que nous écrivons cet article.

Chez BerryNoon, nous croyons qu'un Internet marocain plus sûr profite à tout le monde. Alors si vous avez un site public et un doute, écrivez-nous : nous regarderons avec vous s'il est exposé à PHP2Shell, nous vous indiquerons comment le corriger, et nous vous accompagnerons si vous ne savez pas par où commencer. Sans frais, sans engagement et sans discours commercial. Il suffit de nous laisser un message sur notre page de contact avec l'adresse de votre site.

Questions fréquentes

Mon site WordPress est à jour, suis-je protégé ?

Non, pas forcément. La faille est dans PHP, pas dans WordPress. Un WordPress parfaitement à jour qui tourne sur PHP 8.3.35 reste vulnérable. Vérifiez la version de PHP de votre serveur ou de votre hébergement.

Mon hébergeur s'occupe de tout, dois-je agir ?

Vérifiez quand même. Sur un hébergement mutualisé, c'est souvent vous qui choisissez la version de PHP dans le panneau de contrôle. Si vous avez sélectionné PHP 7.4 il y a quelques années, votre hébergeur ne la changera pas à votre place.

Le pare-feu Cloudflare suffit-il ?

Non. C'est une protection temporaire contre les attaques connues, pas un correctif. Une variante de l'attaque peut passer, et le trafic qui atteint directement votre serveur n'est pas filtré.

Mon serveur affiche toujours 8.3.6 après la mise à jour, est-ce normal ?

Oui, c'est possible sur Ubuntu et Debian : les distributions intègrent le correctif sans changer le numéro principal. Vérifiez le journal des modifications du paquet avec la commande de l'étape 3.

Sources

• CISA : Critical Vulnerabilities in PHP Require Immediate Patching
• Rapid7 : analyse de CVE-2026-109618 et CVE-2026-109619
• Tenable : FAQ PHP2Shell
• BleepingComputer : PHP ships emergency patches for critical PHP2Shell flaws
• W3Techs : parts de marché des langages serveur
• Tranco : classement de référence des sites les plus visités