Équipe sécurité Eurastech, spécialistes PHP, PrestaShop et Laravel au Maroc · Dernière vérification : 22 octobre 2026

Terminal affichant la commande php -v avec la version PHP 8.3.36 corrigée, dans une salle serveur

TL;DR : comment corriger la faille PHP2Shell ?

PHP2Shell (CVE-2026-109618 / CVE-2026-109619, CVSS 9.2) est une faille d'exécution de code à distance dans le moteur PHP, pas dans PrestaShop ni Laravel. La seule correction fiable : mettre à jour PHP vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Si la mise à jour est impossible, appliquez les mitigations php.ini et WAF ci-dessous.

Les correctifs ont été publiés le 21 octobre 2026 à 14:00 UTC (Source : php.net, 2026). Des tentatives d'exploitation ont été observées dès le 17 octobre, soit quatre jours avant la divulgation officielle (Source : AWS Security Blog / Amazon Threat Intelligence, 2026). Chaque heure sans patch augmente le risque.

Vous cherchez d'abord à mesurer l'exposition de votre entreprise ? Lisez PHP2Shell : votre site est-il vulnérable ?.

Qu'est-ce que PHP2Shell ? (CVE-2026-109618, CVE-2026-109619)

Deux vulnérabilités critiques dans le moteur PHP permettent l'exécution de code arbitraire à distance, sans authentification, sur tout serveur web exposant PHP. Le score CVSS v4.0 atteint 9,2/10 (Source : php.net, 2026). Elles touchent PHP lui-même : aucun framework, aucun CMS n'est en cause.

CVE-2026-109618 exploite une corruption mémoire lors d'un dépassement de mémoire (OOM). Quand PHP manque de mémoire en cours de traitement, le nettoyage interne manipule des données partiellement initialisées comme si elles étaient valides. L'attaquant obtient l'exécution de code sur le serveur.

CVE-2026-109619 repose sur un état global obsolète. Des références internes liées à une requête survivent après la libération de la mémoire sous-jacente. La requête suivante réutilise cet état périmé avant que l'initialisation ne le réinitialise.

Les deux failles affectent toutes les installations PHP servant des requêtes web : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed (Source : php.net, 2026). Toutes les versions de PHP 5 à PHP 8 sont concernées (Source : watchTowr, 2026).

PHP alimente 69,3 % des sites web dont le langage serveur est identifiable (Source : W3Techs, octobre 2026). Au Maroc, ce chiffre monte à 75,4 % des sites en .ma (Source : Lodj.ma / W3Techs, 2026). L'ampleur est massive.

Pourquoi mod_php est le plus exposé

Avec mod_php, PHP s'exécute directement dans le processus Apache. L'exploit se déclenche avant que le moindre code applicatif ne s'exécute : ni votre framework, ni votre .htaccess, ni votre WAF applicatif n'ont l'occasion d'intervenir. PHP-FPM et FastCGI restent vulnérables, mais l'isolation des processus réduit légèrement la surface d'attaque. Si vous utilisez encore mod_php en production, la migration vers PHP-FPM est un prérequis de sécurité indépendant de PHP2Shell.

Versions PHP corrigées et branches en fin de vie

Seules les branches PHP 8.2 à 8.5 reçoivent un correctif officiel. PHP 8.1 et antérieur sont en fin de vie : des backports communautaires existent sur GitHub (branches PHP-7.4, PHP-8.0, PHP-8.1) mais ne sont pas recommandés en production (Source : php.net, 2026). Certains hébergeurs (OVH, o2switch) ont néanmoins déployé des correctifs sur ces branches via les paquets CloudLinux.

Branche PHP	Version corrigée	Statut	Action requise
8.5	8.5.12	Supportée	Mettre à jour
8.4	8.4.27	Supportée	Mettre à jour
8.3	8.3.36	Supportée	Mettre à jour
8.2	8.2.35	Sécurité seulement (EOL fin 2026)	Mettre à jour : dernière branche avec patch officiel
8.1	EOL	Fin de vie	Migrer vers 8.2+ ou backport communautaire (non recommandé)
8.0	EOL	Fin de vie	Migrer vers 8.2+
7.4	EOL	Fin de vie	Migrer vers 8.2+

PHP 8.2 arrive en fin de support sécurité le 31 décembre 2026 (Source : php.net, 2026). Planifiez dès maintenant la migration vers 8.3 ou 8.4 : ne patchez pas pour vous retrouver sans support dans deux mois.

Frise des branches PHP : 8.2 à 8.5 corrigées, 8.1, 8.0 et 7.4 en fin de vie face à la faille PHP2Shell

Comment corriger la faille PHP2Shell (5 étapes)

Corriger PHP2Shell se fait en cinq étapes : identifier votre version, mettre à jour PHP, redémarrer les services, vérifier l'absence de compromission, et appliquer les mitigations si la mise à jour est impossible.

Identifier votre version PHP : en SSH, php -v. Via le panneau d'administration : phpinfo() ou cPanel > MultiPHP Manager. Notez la version CLI et la version FPM (elles peuvent différer).
Mettre à jour PHP vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre branche.
Redémarrer PHP-FPM et Apache : sudo systemctl restart php8.x-fpm puis sudo systemctl restart apache2 (ou nginx). Sans redémarrage, l'ancien binaire reste en mémoire.
Vérifier l'absence de compromission : cherchez les fichiers .php créés depuis le 17 octobre (date des premières tentatives d'exploitation). Voir la section détection ci-dessous.
Appliquer les mitigations temporaires si la mise à jour est impossible : section suivante.

Mise à jour sur serveur dédié (apt / yum / compilation)

Debian / Ubuntu (PPA Ondřej Surý) :

sudo apt update
sudo apt upgrade php8.3 -y
sudo systemctl restart php8.3-fpm
php -v  # doit afficher 8.3.36

RHEL / Rocky / AlmaLinux (dépôt Remi) :

sudo dnf update php -y
sudo systemctl restart php-fpm
php -v

AlmaLinux a publié des paquets corrigés dès le 21 octobre (Source : AlmaLinux Blog, 2026).

Compilation depuis les sources : téléchargez l'archive depuis php.net, compilez, installez, redémarrez. Réservez cette option aux configurations où les dépôts ne sont pas disponibles.

Mise à jour via cPanel MultiPHP / Plesk

cPanel :

Connectez-vous à WHM > MultiPHP Manager
Sélectionnez la nouvelle version PHP (8.3.36 par exemple) pour chaque domaine
Confirmez et attendez la propagation
Vérifiez dans cPanel > MultiPHP Manager que la version est active

Interface MultiPHP Manager de cPanel pour choisir une version de PHP corrigée par domaine

Plesk :

Outils & Paramètres > PHP Settings
Sélectionnez la version corrigée
Appliquez. Plesk redémarrera PHP-FPM automatiquement.

Hébergement mutualisé : que faire en attendant votre hébergeur ?

Sur un hébergement mutualisé, vous ne pouvez pas mettre à jour PHP vous-même. Trois actions immédiates :

Vérifiez si votre hébergeur a déjà patché : consultez le tableau des hébergeurs ci-dessous, ou lancez un phpinfo() et comparez la version affichée.
Contactez le support par écrit. Demandez une confirmation écrite que les deux CVE sont corrigées.
En attendant, activez le WAF Cloudflare (le plan gratuit suffit) et appliquez les mitigations .htaccess de la section suivante.

Si votre hébergeur tarde, envisagez un changement : notre comparatif hébergement web Maroc évalue la réactivité sécuritaire de chaque fournisseur.

Corriger PHP2Shell sur PrestaShop

La faille est dans PHP, pas dans le code PrestaShop. Mais PrestaShop impose des contraintes de version PHP : vérifiez la compatibilité avant de mettre à jour, sinon votre boutique ne démarrera pas.

Voici la procédure complète :

Activez le mode maintenance : Back Office > Paramètres de la boutique > Maintenance > Activer le mode maintenance. Cela protège vos clients pendant l'intervention.
Consultez la matrice de compatibilité ci-dessous pour vérifier que votre version PrestaShop supporte un PHP patché.
Mettez à jour PHP sur le serveur (voir les étapes ci-dessus).
Testez la boutique : parcourez le front office, le back office, le tunnel de commande, le paiement. Les modules tiers sont le point de rupture le plus fréquent après un changement de PHP.
Auditez les fichiers suspects : cherchez les fichiers .php créés depuis le 17 octobre dans /modules, /override et la racine du site :

find /var/www/prestashop -name "*.php" -newermt "2026-10-17" -not -path "*/cache/*"

Désactivez le mode maintenance une fois les tests validés.

Le blog officiel PrestaShop Build confirme : "Updating PrestaShop or your modules will not fix this" (Source : PrestaShop Build Blog, 2026). La correction passe par PHP, point final.

Si votre boutique nécessite une refonte plus profonde, notre guide sur l'optimisation PrestaShop couvre les gains de performance et SEO à combiner avec la mise à jour PHP.

Page de maintenance du back-office PrestaShop avec l'option Activer le mode maintenance activée

Matrice de compatibilité PrestaShop / PHP

Ce tableau montre quelles versions PrestaShop peuvent tourner sur un PHP patché, et lesquelles sont bloquées sur du PHP en fin de vie.

PrestaShop	PHP min	PHP max officiel	Peut tourner sur PHP patché ?	Action
1.6.x	5.6	7.4	NON	Migrer PS + PHP
1.7.0 – 1.7.6	7.1	7.4	NON	Migrer PS + PHP
1.7.7 – 1.7.8	7.2	8.1	NON (8.1 = EOL)	Migrer vers PS 9
8.0 – 8.2	7.2	8.1	NON (8.1 = EOL)	Migrer vers PS 9
9.0	8.1	8.4	OUI (8.2.35, 8.3.36, 8.4.27)	Mettre à jour PHP
9.1	8.1	8.5	OUI (8.2.35 – 8.5.12)	Mettre à jour PHP

(Sources : PrestaShop DevDocs 8, PrestaShop DevDocs 9, PrestaShop Build Blog, 2026)

Le constat est brutal. Toute boutique sous PrestaShop 8.x ou antérieur est officiellement limitée à PHP 8.1, une branche en fin de vie sans correctif officiel. Certains hébergeurs déploient des backports sur PHP 8.1, mais ce n'est ni garanti ni pérenne.

La seule solution long terme : migrer vers PrestaShop 9. PS 9.0 supporte PHP 8.2 à 8.4 ; PS 9.1 monte jusqu'à PHP 8.5.

Corriger PHP2Shell sur Laravel

Sur Laravel, mettez à jour PHP via Forge, Vapor ou manuellement, puis redémarrez tous les processus longs : FPM, queue workers, Horizon, Octane. Vérifiez avec php artisan about que la version corrigée est active partout.

Un piège courant : la version CLI et la version FPM divergent. Après la mise à jour, vérifiez les deux :

php -v                          # CLI
php artisan about               # affiche la version PHP utilisée par le framework
composer check-platform-reqs    # confirme que toutes les dépendances sont satisfaites

Processus longs à redémarrer :

Queue workers : php artisan queue:restart. Sans cela, les workers continuent avec l'ancien binaire PHP.
Horizon : arrêtez et relancez Horizon. Un simple queue:restart ne suffit pas si Horizon supervise les workers.
Octane (Swoole / RoadRunner) : php artisan octane:reload. Octane maintient PHP en mémoire, le redémarrage est obligatoire.
Scheduler cron : si vous avez un cron * * * * * php artisan schedule:run, vérifiez que le chemin pointe vers le bon binaire PHP.

Laravel 11 requiert PHP 8.2 minimum, mais son support sécurité a pris fin en mars 2026 (Source : Laravel.com, 2026). Laravel 13 (la version active) exige PHP 8.3+ (Source : Laravel.com, 2026). Si vous êtes encore sur Laravel 11, combinez le patch PHP avec une migration Laravel.

Laravel Forge / Vapor / Octane : spécificités

Forge :

Ouvrez le serveur dans Forge
Onglet PHP > cliquez "Update PHP"
Forge met à jour le paquet et redémarre FPM automatiquement
Redémarrez manuellement les queue workers et Horizon depuis l'interface

Sur une dizaine de serveurs, répétez l'opération pour chacun depuis l'interface Forge.

Vapor (Lambda) :

Modifiez vapor.yml pour spécifier le runtime PHP patché, puis lancez vapor deploy production. La couche Lambda sera reconstruite avec la nouvelle version.

Octane :

php artisan octane:reload

Octane garde PHP en mémoire. Sans reload, vous servez des requêtes avec le binaire vulnérable même après la mise à jour du paquet.

Mitigations temporaires (WAF, php.ini, .htaccess)

Si vous ne pouvez pas mettre à jour PHP immédiatement, ces mitigations réduisent la surface d'attaque sans l'éliminer. Aucune n'est complète : la mise à jour reste la seule correction fiable selon l'avis officiel php.net (Source : php.net, 2026).

Pour CVE-2026-109618 (corruption OOM) :

; php.ini ou pool FPM (utiliser php_admin_value, pas ini_set)
memory_limit = -1
post_max_size = 8M        ; 32M si vous avez besoin d'uploads
upload_max_filesize = 4M   ; toujours < post_max_size

Paradoxe : memory_limit = -1 empêche le déclenchement de l'OOM qui permet l'exploit. Mais attention aux conteneurs : ajoutez une limite cgroup pour éviter qu'un script n'épuise la RAM du serveur. Les limites RLIMIT_AS et RLIMIT_DATA ne fonctionnent pas comme protection ici.

Pour CVE-2026-109619 (état global obsolète) :

; php.ini ou pool FPM (ini_set() est IGNORÉ pour cette directive)
session.upload_progress.enabled = 0
; PHP 8.5 uniquement :
fatal_error_backtraces = 0

o2switch a désactivé session.upload_progress dès le 20 octobre, avant même la publication des patchs (Source : o2switch Forum, 2026).

WAF Cloudflare :

Cloudflare a déployé des règles dédiées le 21 octobre (Source : PrestaShop Build Blog, 2026). Activez le WAF même sur le plan gratuit. Ce n'est pas suffisant seul, mais c'est une couche supplémentaire.

Blocage .htaccess (Apache) :

# Bloquer les requêtes multipart/form-data suspectes (mesure temporaire)
<If "%{CONTENT_TYPE} =~ /multipart\/form-data/ && %{REQUEST_METHOD} == 'POST'">
    # Autoriser uniquement les chemins d'upload connus
    <If "! %{REQUEST_URI} =~ m#^/(admin|upload|api)/#">
        Require all denied
    </If>
</If>

Adaptez les chemins autorisés à votre application. Le CERT-FR recommande également de bloquer ou superviser les requêtes HTTP avec un Content-Type multipart (Source : CERT-FR CERTFR-2026-ALE-014, 2026).

Détecter une compromission (IOCs PHP2Shell)

Si votre serveur exécutait une version vulnérable entre le 17 et le 22 octobre, vérifiez l'absence de compromission avant de considérer le problème résolu. Amazon Threat Intelligence a observé des tentatives d'exploitation dès le 17 octobre, quatre jours avant la divulgation (Source : AWS Security Blog, 2026).

Trois commandes pour un premier diagnostic :

# Fichiers PHP créés ou modifiés depuis le 17 octobre
find /var/www -name "*.php" -newermt "2026-10-17" -not -path "*/cache/*" -not -path "*/var/cache/*"

# Signatures de webshell classiques
grep -rl "eval(base64_decode\|system(\|passthru(\|shell_exec(" /var/www/ --include="*.php"

# Pics de requêtes POST multipart dans les logs
zgrep "multipart/form-data" /var/log/apache2/access.log* | grep "POST" | awk '{print $4}' | sort | uniq -c | sort -rn | head -20

Terminal avec les commandes find et grep pour détecter des fichiers PHP suspects après la faille PHP2Shell

Si vous trouvez des fichiers suspects :

Isolez le serveur du réseau. Ne supprimez rien avant d'avoir copié les preuves.
Préservez les logs Apache/Nginx, les logs FPM, et les fichiers suspects dans un répertoire hors serveur web.
Identifiez l'étendue : base de données, fichiers clients, données de paiement.
Notification CNDP au Maroc (loi 09-08) ou CNIL en Europe (RGPD, article 33) : si des données personnelles sont concernées, vous avez 72 heures pour notifier (Source : GDPR-text.com, 2016).

Si votre site a déjà été compromis via PHP2Shell, notre guide détaille la procédure complète de nettoyage et sécurisation.

Hébergeurs FR/MA : état des correctifs

L'état des correctifs varie selon les hébergeurs. Voici le suivi au 22 octobre 2026 ; vérifiez la page statut de votre hébergeur pour l'information la plus récente.

Hébergeur	Correctif déployé ?	Branches patchées	Comment vérifier	Source
OVHcloud	OUI (21 oct, 17h53 UTC)	PHP 7.4 – 8.5	Espace client > Hébergement > PHP	OVHcloud Status
o2switch	OUI (21 oct)	PHP 5.2 – 8.5 (via CloudLinux)	cPanel > MultiPHP Manager	o2switch Forum
Infomaniak	Non confirmé	—	Panel > Sites > PHP	Vérifier status.infomaniak.com
PlanetHoster	Non confirmé	—	Panel > PHP	Vérifier status.planethoster.com
LWS	Non confirmé	—	Panel > PHP	Contacter le support
ADK Media (Maroc)	Non confirmé	—	Contacter le support	—
Genious (Maroc)	Non confirmé	—	Contacter le support	—

Attention : o2switch utilise CloudLinux, qui reconstruit ses paquets avec une numérotation interne. Votre PHP 8.3 peut afficher 8.3.35 (paquet 8.3.35-6) tout en incluant le correctif (Source : o2switch Forum, 2026). Un php -v ne suffit pas toujours : demandez confirmation à votre hébergeur.

Si votre hébergeur n'a pas patché et ne communique pas de calendrier, c'est un signal d'alarme sur sa maturité sécuritaire. Consultez notre comparatif hébergement web Maroc pour évaluer vos options.

Suivi ANSSI / CERT-FR et DGSSI Maroc

Le CERT-FR a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre 2026, qualifiant les deux CVE de critiques et recommandant la mise à jour immédiate (Source : CERT-FR, 2026). Le CERT-FR préconise également d'isoler les équipements affectés et de bloquer ou superviser les requêtes multipart.

Le même jour, la DGSSI marocaine (Direction Générale de la Sécurité des Systèmes d'Information) a émis le bulletin de sécurité 69782110/26, classant le risque et l'impact au niveau maximal (Source : Morocco World News, 2026). Le bulletin signale que du code d'exploitation (PoC) est déjà disponible publiquement.

Le ministère de l'Intérieur français a fermé temporairement ses sites exposés, y compris ceux des préfectures (Source : Journal du Coin, 2026). Si des institutions gouvernementales jugent la menace suffisante pour couper, votre boutique PrestaShop ou votre application Laravel mérite au minimum un patch dans les heures qui viennent.

FAQ : PHP2Shell

Comment savoir si mon serveur est vulnérable à PHP2Shell ?

Lancez php -v en SSH. Si la version affichée est inférieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, votre serveur est vulnérable. Sur cPanel, allez dans MultiPHP Manager. Sur PrestaShop, Back Office > Paramètres avancés > Informations affiche la version PHP. Toute version PHP 8.1 ou inférieure est vulnérable et ne recevra pas de correctif officiel.

Faut-il mettre à jour PrestaShop ou PHP ?

PHP. La faille se situe dans le moteur PHP, pas dans le code PrestaShop. Mettre à jour PrestaShop ou ses modules ne corrige rien. Cependant, consultez la matrice de compatibilité ci-dessus : PrestaShop 8.x ne supporte que PHP 8.1 maximum. Si vous êtes sur PS 8, la migration vers PS 9 est nécessaire pour accéder à un PHP patché officiellement.

Que faire si mon hébergeur n'a pas encore patché PHP ?

Contactez le support par écrit et demandez un calendrier. En attendant, appliquez les mitigations temporaires : désactivez session.upload_progress.enabled, réduisez post_max_size, activez le WAF Cloudflare. Si l'hébergeur ne répond pas sous 48 heures, envisagez sérieusement une migration. La section mitigations détaille chaque mesure.

Les versions PHP 7.x et 8.1 sont-elles corrigées ?

Pas officiellement. PHP 7.4, 8.0 et 8.1 sont en fin de vie. Le projet PHP a publié des branches de backport sur GitHub (code source uniquement, pas de binaires). Certains hébergeurs comme OVH et o2switch ont déployé ces correctifs via CloudLinux. Mais la recommandation reste la migration vers PHP 8.2 ou supérieur.

Comment bloquer l'exploitation avec un WAF ou .htaccess ?

Le WAF Cloudflare a déployé des règles dédiées le 21 octobre. Activez-le même en plan gratuit. En .htaccess, vous pouvez bloquer les requêtes POST multipart sur les chemins non essentiels. Le CERT-FR recommande cette approche en complément. Détails et code dans la section mitigations ci-dessus.

Mon site PrestaShop 1.7 est bloqué sur PHP 8.1, que faire ?

PrestaShop 1.7 supporte PHP 8.1 au maximum, une branche en fin de vie. Vos options : utiliser le backport communautaire PHP 8.1 (risque en production, support non garanti), ou, la vraie réponse, migrer vers PrestaShop 9, qui supporte PHP 8.2 à 8.5. La migration est un investissement, mais rester sur PS 1.7 avec du PHP non patché est un risque plus coûteux.

Protégez votre infrastructure PHP : intervention d'urgence Eurastech

Eurastech intervient en urgence sur les infrastructures PHP au Maroc : audit, patch, détection de compromission, migration PrestaShop et Laravel.

Ce n'est pas théorique. Nous avons stabilisé des boutiques PrestaShop compromises dans des conditions similaires : le cas client Universparadiscount documente une intervention de remise en service après compromission. Notre guide de réparation après piratage est la procédure que nous appliquons en interne.

Ce que nous faisons en intervention PHP2Shell :

Audit de version PHP et détection de compromission sur l'ensemble du serveur
Application du patch PHP et vérification post-déploiement
Migration PrestaShop 8 vers 9 pour débloquer l'accès aux branches PHP supportées
Mise en place d'un SLA de maintenance pour ne plus subir la prochaine faille
Reprise de code legacy bloqué sur des versions PHP obsolètes

Pour un cadrage plus large, notre guide cybersécurité PME et notre page d'audit de sécurité détaillent l'approche complète.

Contactez-nous maintenant : [email protected] ou via le formulaire sur eurastech.ma.

PHP2Shell : corriger la faille PHP sur PrestaShop et Laravel (guide d'urgence)