Vulnérabilités PHP RCE : corriger CVE-2026-109618 et CVE-2026-109619

Une vulnérabilité PHP RCE (Remote Code Execution / exécution de code à distance) avérée ne se corrige pas par un patch côté PrestaShop : si le runtime PHP est vulnérable et que l’attaque réussit, l’attaquant peut exécuter du code dans le contexte du processus concerné (PHP-FPM, module Apache ou CGI). Selon les permissions et la configuration, il peut notamment lire app/config/parameters.php (PrestaShop 1.7) ou les fichiers de configuration concernés selon la version, accéder à des secrets, déposer un webshell ou tenter d’atteindre la base de données et d’autres systèmes.

Un identifiant CVE ne suffit toutefois pas à établir qu’il s’agit d’une vulnérabilité PHP, ni à connaître les versions affectées ou le correctif requis. Avant d’attribuer une RCE à CVE-2026-109618 ou CVE-2026-109619, vérifiez les avis officiels de l’éditeur et de votre distribution : ils doivent confirmer le composant concerné, les versions affectées et les paquets corrigés. Les recommandations ci-dessous décrivent la démarche à suivre si ces avis confirment une vulnérabilité du runtime PHP.

Dans le cas d’un site e-commerce, une compromission peut entraîner le vol de données clients, la modification de comptes administrateur, l’injection de skimmer (JavaScript de collecte de données de paiement côté navigateur) ou une fraude au paiement. Si des données personnelles sont concernées, des obligations de notification peuvent également s’appliquer. Au titre du RGPD, une notification à l’autorité de contrôle doit être effectuée, lorsque les conditions sont réunies, dans les meilleurs délais et, si possible, dans les 72 heures après la prise de connaissance de la violation. En France, la CNIL est l’autorité compétente.

Si les avis officiels confirment que CVE-2026-109618 et CVE-2026-109619 affectent votre runtime PHP, la remédiation passe par la mise à jour de PHP au niveau du système d’exploitation ou de l’image Docker, en vérifiant les éventuels correctifs rétroportés par la distribution. En attendant, réduisez la surface d’attaque.

Ce que signifie « RCE PHP » (et pourquoi une RCE avérée est prioritaire)

Une RCE sur PHP permet à un acteur distant d’exécuter des instructions dans le contexte du processus PHP, typiquement l’utilisateur du pool FPM (par exemple www-data, apache ou un compte dédié). Selon les permissions accordées et la configuration du système, les conséquences peuvent dépasser le simple défacement du site : exfiltration de données clients, fraude aux commandes, modification des moyens de paiement, injection de JavaScript côté front ou chiffrement de fichiers accessibles.

Sur une boutique PrestaShop, une RCE peut contribuer à une compromission étendue, même sans privilèges root :

Lecture de secrets : identifiants de base de données, clés API, tokens SMTP/ERP, secrets de session.
Écriture de fichiers : dépôt d’un webshell dans un répertoire servi par le web, si les permissions le permettent, ou modification via un mécanisme de cache, d’override ou de module.
Exfiltration : extraction de données auxquelles le processus a accès, par exemple des tables clients ou commandes, ou tentatives via des requêtes sortantes.
Persistance : tâche planifiée ou porte dérobée dans un module, si les droits et la configuration le permettent.

Mini-scénario réaliste : un attaquant obtient l’exécution de code dans le worker FPM et, si ses permissions le permettent, lit les identifiants MySQL de PrestaShop, exporte des données de ps_customer, ps_orders et ps_order_payment, puis injecte un script dans un template pour tenter de capturer des données de session. Le site peut continuer à fonctionner alors que la confidentialité des données est compromise ; l’incident peut être découvert après une plainte client ou une hausse des erreurs de paiement.

La criticité réelle dépend de votre SAPI (Server API) : PHP-FPM derrière Nginx ou Apache, mod_php, CGI/FastCGI, ainsi que des extensions chargées. Les chemins d’exploitation varient selon la vulnérabilité : analyse de données, corruption mémoire, désérialisation, wrappers de flux ou traitement d’uploads, par exemple. N’attribuez pas ces caractéristiques aux CVE citées sans les avoir confirmées dans un avis officiel.

Sur une boutique PrestaShop, une RCE peut permettre, selon les droits du processus, de lire la configuration, d’accéder à la base, de modifier des fichiers ou de tenter une persistance via cron, systemd user ou une tâche planifiée du panneau d’hébergement.

“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” — Bruce Schneier

Un WAF ou une règle Nginx ne corrige pas une RCE. Ces mesures peuvent gagner du temps, mais le correctif reste la mise à jour du runtime affecté et une isolation adaptée.

Cartographier l’exposition : version PHP, paquets, SAPI et backports

Avant d’intervenir, identifiez ce qui tourne réellement en production. Un serveur peut héberger plusieurs installations de PHP (CLI ≠ FPM), et un reverse proxy peut masquer le service utilisé. Commencez par identifier la version de PHP-FPM, celle de PHP CLI et les pools qui servent la boutique.

Commandes minimales (Debian/Ubuntu, à adapter) :

php -v
php --ini
systemctl status php*-fpm --no-pager
ps aux | grep -E 'php-fpm|php-cgi' | grep -v grep

Complétez avec une vérification « service → socket/port → vhost », particulièrement utile en environnement multi-sites :

# sockets/ports écoutés par FPM
ss -lntp | grep -E 'php-fpm|:9000' || true
ss -lx | grep php || true

# côté Nginx, retrouver le fastcgi_pass effectif
nginx -T 2>/dev/null | grep -nE 'fastcgi_pass|php-fpm' || true

Petit tableau de contrôle pour éviter le piège « j’ai patché le mauvais PHP » :

Élément exposé	À vérifier	Piège classique
PHP CLI	`php -v`	CLI patché, mais le site tourne sur une autre version de PHP-FPM
PHP FPM	`systemctl status php8.x-fpm` + `php-fpm8.x -v`	Plusieurs pools ou vhosts, un seul mis à jour
Paquet OS	`apt-cache policy …` / `dnf info …`	Un correctif rétroporté peut être inclus sans changement apparent de version upstream
Redémarrage effectif	PID / heure de démarrage	Paquets à jour, mais workers non redémarrés

Interrogez le gestionnaire de paquets plutôt que de vous fier uniquement à la version upstream. Les distributions rétroportent parfois des correctifs sans modifier de manière visible la version majeure ou mineure. Vérifiez le bulletin de sécurité et le changelog du paquet concerné.

Vérifier explicitement les CVE dans les changelogs

Sur Debian/Ubuntu :

apt-get update
apt-cache policy php8.2-fpm php8.2-cli
apt changelog php8.2-fpm | grep -E 'CVE-2026-109618|CVE-2026-109619' -n || true

Si apt changelog n’est pas disponible, utilisez apt-get changelog <paquet> lorsque cette commande est prise en charge, ou consultez les annonces de sécurité de votre distribution.

Sur RHEL/Alma/Rocky :

dnf info php php-fpm
dnf updateinfo list cves | grep -E 'CVE-2026-109618|CVE-2026-109619' || true
rpm -q --changelog php-fpm | grep -E 'CVE-2026-109618|CVE-2026-109619' -n || true

Dans un contexte PrestaShop, vérifiez quel vhost et quel pool servent la boutique, particulièrement en environnement multiboutique ou multisite. Une erreur classique consiste à mettre à jour php-cli en oubliant php-fpm, ou à corriger un pool tout en laissant un autre pool exposé, par exemple sur un sous-domaine legacy. L’inventaire doit couvrir tous les services exposés.

Appliquer le correctif : mise à jour PHP sans casser PrestaShop

Pré-requis réalistes : (1) accès root/SSH ou intervention de l’hébergeur, (2) fenêtre de maintenance, (3) sauvegarde exploitable. Si vous êtes en hébergement mutualisé sans maîtrise des paquets, contactez l’hébergeur pour confirmer le correctif et son déploiement.

Pour une intervention en production, visez une procédure courte, traçable et réversible :

Avant : snapshot de la VM ou sauvegarde de la base et des fichiers ; test de restauration si possible.
Pendant : mise à jour ciblée, redémarrage contrôlé, vérification fonctionnelle rapide.
Après : preuve du correctif (changelog et versions), collecte des logs clés et surveillance renforcée pendant 24 à 48 heures.

Stratégie : patcher via la distribution, pas par téléchargement manuel de PHP

En production, privilégiez la mise à jour des paquets OS ou la reconstruction de l’image Docker, en restant dans un canal pris en charge. Compiler PHP à la main sur un serveur e-commerce existant peut créer des écarts de configuration ou des problèmes d’extensions (par exemple opcache ou imagick).

Sur Debian/Ubuntu :

# 1) mettre à jour l'index
apt-get update

# 2) mise à jour ciblée (ajustez la version selon votre stack)
apt-get install --only-upgrade \
  php8.2-cli php8.2-fpm php8.2-common php8.2-opcache \
  php8.2-mysql php8.2-xml php8.2-curl php8.2-gd

# 3) redémarrage propre
systemctl restart php8.2-fpm
systemctl reload nginx || systemctl reload apache2

Sur RHEL-like :

dnf update -y 'php*'
systemctl restart php-fpm
systemctl reload nginx || systemctl reload httpd

Pour vérifier le redémarrage, capturez le PID et l’heure de démarrage :

systemctl show php8.2-fpm -p MainPID -p ActiveEnterTimestamp

Points de casse fréquents côté PrestaShop

Incompatibilités de version : une mise à jour PHP peut révéler des incompatibilités dans un module non maintenu. Testez en staging et prévoyez un plan de retour arrière. Pour une montée de version PHP, utilisez une approche outillée (PHPStan, PHPUnit) ; voir l’article interne : Migration PHP 8.5 : préparer PrestaShop avec PHPStan et PHPUnit.
OPcache : après une mise à jour, redémarrez les workers FPM pour qu’ils chargent le nouveau runtime. Pour les stacks à fort trafic, prévoyez une rotation progressive plutôt qu’un redémarrage brutal.
Extensions système : les symptômes post-mise à jour peuvent concerner, entre autres, les PDF, les images ou intl. Listez les modules PHP chargés et vérifiez qu’ils sont toujours disponibles après la mise à jour :

   php -m
   php -i | grep -E 'imagick|gd|intl|opcache|curl' || true

Ces commandes interrogent PHP CLI : vérifiez aussi la configuration et les extensions utilisées par PHP-FPM.

Docker/Kubernetes : reconstruisez et redéployez l’image plutôt que de faire un apt upgrade dans le conteneur. Épingler un tag (par exemple php:8.2-fpm-alpine) ne protège pas si l’image n’est jamais reconstruite. Intégrez un job CI qui reconstruit et scanne régulièrement les images.

Pour renforcer le processus de maintenance côté infrastructure, l’approche « patching continu + preuve » recoupe des stratégies décrites côté OS : CVE noyau Linux : stratégie de live patching pour hébergement mutualisé. Le live patching du noyau ne corrige pas PHP ; l’objectif commun est de réduire la fenêtre d’exposition.

Mesures de réduction de la surface d’attaque

Si le correctif ne peut pas être déployé immédiatement (validation, gel commercial, délai de l’hébergeur), réduisez la surface d’attaque. Ces mesures ne corrigent pas une vulnérabilité PHP ; elles peuvent limiter certaines possibilités d’exploitation ou leurs conséquences.

Deux règles aident à prioriser :

réduire ce qui est atteignable depuis Internet (endpoints, méthodes, fichiers) ;
réduire ce qui est possible après une compromission (écriture, exécution, exfiltration).

Durcissement de `php.ini` : ce qui aide, et ce qui ne constitue pas un correctif

Mesures de durcissement à tester, car certaines applications ou modules en dépendent :

; réglages de réduction de surface
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
cgi.fix_pathinfo = 0

; uploads : si le BO en a besoin, ne les coupez pas à l'aveugle
file_uploads = On
upload_max_filesize = 16M
post_max_size = 20M

; empêche la création ou la modification de fichiers Phar
phar.readonly = 1

; désactiver des fonctions, après vérification de compatibilité
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Deux précisions utiles :

disable_functions peut casser certains connecteurs (PDF, outils d’import, connecteurs ERP). Testez les flux métier avant de l’activer.
Avec PHP-FPM, security.limit_extensions côté pool permet de limiter les extensions traitées comme des scripts. Ce réglage n’est pas un bouclier contre une RCE.

phar.readonly limite la création ou la modification de fichiers Phar par PHP ; il ne désactive pas leur lecture et ne constitue pas, à lui seul, une protection contre une exploitation utilisant des métadonnées Phar.

disable_functions n’est pas un sandbox. Ce réglage ne constitue pas une protection fiable contre une RCE dans le runtime lui-même. Il peut cependant retirer certaines fonctions à du code applicatif compromis.

Pour un cadrage général sur le risque lié aux composants non à jour, la page OWASP sur Vulnerable and Outdated Components est une référence utile : https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

Nginx/Apache : limiter certains chemins exposés

Côté serveur web, vous pouvez réduire l’exposition en limitant les endpoints et les méthodes, en bloquant certains accès directs et en verrouillant des répertoires. Les règles doivent être adaptées à votre configuration et validées en staging.

Exemples Nginx :

# Empêcher l'exécution dans des répertoires d'upload, si applicable
location ~* ^/(img|upload|downloads)/.*\.php$ {
  return 404;
}

# Bloquer l'accès direct à certains fichiers sensibles
location ~* /(\.env|composer\.(json|lock)|app/config/parameters\.php) {
  deny all;
}

# Limiter les méthodes : vérifiez la compatibilité avec les fonctions utilisées
location / {
  limit_except GET POST HEAD { deny all; }
}

Ne vous contentez pas de cacher les fichiers sensibles : vérifiez aussi qu’ils n’existent pas dans un webroot public (par exemple un fichier .env déployé par erreur) et que les règles de déploiement CI/CD les excluent.

En cas de scans ou d’attaques, vous pouvez mettre en place une limitation de débit et un filtrage (Cloudflare/WAF, fail2ban). Pour une approche de scan en boîte noire qui aide à repérer un endpoint inattendu exposé, voir : Wapiti : scanner open source de vulnérabilités web en boîte noire.

Isolation et permissions

L’isolation réduit l’impact potentiel d’une compromission : un pool PHP-FPM par site, un utilisateur Unix dédié et des permissions d’écriture limitées. Si une RCE survient, l’objectif est que le processus ne puisse pas modifier l’ensemble du code ou accéder à des données sans rapport avec le site.

Concrètement :

un utilisateur www-data partagé entre 20 vhosts augmente le périmètre d’impact ; envisagez des comptes dédiés comme ps_shop1 et ps_shop2 ;
rendez le code en lecture seule pour l’utilisateur FPM et n’autorisez l’écriture que dans les répertoires qui en ont réellement besoin, comme var/, img/ ou un répertoire de cache ;
limitez les permissions sur les fichiers de secrets et l’egress réseau.

Demandez-vous si l’utilisateur du pool FPM doit réellement pouvoir écrire dans modules/ ou override/. En production, ces écritures ne sont généralement nécessaires que lors d’opérations de mise à jour planifiées. Verrouiller ces répertoires réduit la capacité à modifier durablement la boutique.

Pour cadrer l’hébergement et les responsabilités (qui met à jour quoi et qui redémarre les services), l’article interne PrestaShop auto-hébergé : prérequis d’installation, maintenance et sécurité sert de check-list.

Vérifier la remédiation : preuves, tests, logs et indicateurs de compromission

Après la mise à jour, vérifiez plus que le bon fonctionnement apparent du site. Conservez une preuve technique de la version effective, du redémarrage des services et des vérifications effectuées. Par exemple : la version de PHP-FPM, le changelog du paquet ou le bulletin de sécurité de la distribution, et l’heure de redémarrage du service.

Une check-list de preuves utile pour les tickets hébergeur ou les audits :

paquet PHP installé et version (dpkg -l | grep php8.2 ou rpm -qa | grep php) ;
extrait de changelog mentionnant les CVE, si applicable, ou bulletin de sécurité de la distribution ;
PID et heure de démarrage de FPM après redémarrage ;
date et heure du déploiement, personne responsable et périmètre concerné (pool et vhost).

Tests fonctionnels PrestaShop après mise à jour PHP

Testez au moins : connexion au BO, panier et checkout, paiement (en sandbox si possible), génération de PDF, e-mails transactionnels et, s’il est activé, webservice. Des incompatibilités PHP peuvent notamment toucher intl, gd/imagick, SOAP ou certains modules.

Ajoutez un test métier ciblé : créer une commande de test, déclencher un e-mail, générer une facture et vérifier que la page de paiement ne charge pas de scripts inattendus. Cette dernière vérification peut aider à repérer une injection, sans remplacer une investigation de sécurité.

Si vous avez une chaîne CI, exécutez un smoke test HTTP et quelques scénarios. Sur PrestaShop, les logs Symfony peuvent notamment se trouver dans var/logs/, selon la version et la configuration. En cas de 503 après redémarrage, consultez rapidement les logs côté serveur : Erreur HTTP 503 : diagnostiquer PHP et logs Apache/LiteSpeed.

Recherche pragmatique d’indicateurs de compromission

Quelques contrôles rapides, à adapter à votre OS :

# fichiers récemment modifiés dans le webroot (48h)
find /var/www/monshop -type f \( -name '*.php' -o -name '*.phtml' \) -mtime -2 | head

# recherche de patterns courants de webshell (contrôle très imparfait)
grep -R --line-number --binary-files=without-match \
  -E "(eval\(|base64_decode\(|gzinflate\(|shell_exec\(|passthru\()" \
  /var/www/monshop | head

# processus suspects : résultats à interpréter, car certains noms peuvent être légitimes
ps auxf | grep -E 'php-fpm|curl|wget|nc|bash -i' | grep -v grep

Ajoutez deux contrôles utiles en e-commerce :

tâches planifiées (persistance) : crontab -l (root et utilisateurs), /etc/cron.*, systemctl list-timers ;
écriture inattendue : surveillez les répertoires modules/, override/ et themes/ ; un module inconnu ou un override modifié mérite une investigation.

Ne vous contentez pas d’un grep : le code malveillant peut être obfusqué. L’objectif de ces contrôles est de repérer des compromissions opportunistes, pas de remplacer une analyse forensique. Pour une supervision continue (saturation FPM, erreurs 5xx, hausse anormale de latence), couplez logs et métriques ; article interne : Monitoring PrestaShop : KPI e-commerce, paiements et prévention des erreurs 503.

Vérification reproductible du correctif

Sans preuve de concept publique fiable — ou sans vouloir l’exécuter en production — procédez ainsi :

confirmez que l’avis officiel de l’éditeur ou de la distribution associe bien la CVE au composant concerné et identifie le paquet corrigé ;
confirmez que le paquet corrigé est installé ;
confirmez que le service effectif a redémarré (PID ou heure de démarrage) ;
confirmez que l’inventaire est complet : pas d’ancien pool ou de version vulnérable encore exposée.

Pour rechercher des informations publiques, consultez les sources suivantes :

NVD (recherche) : https://nvd.nist.gov/vuln/search
MITRE CVE : https://cve.mitre.org/
Annonces de sécurité PHP : https://www.php.net/security

Durcir durablement une stack PrestaShop contre les RCE du runtime

Une fois l’incident traité, l’objectif est de réduire la probabilité et l’impact de futures vulnérabilités du runtime ou de composants associés (PHP, OpenSSL, traitement d’images, etc.). PrestaShop ne fournit pas à lui seul un modèle de sécurité « zero trust » : l’infrastructure et le processus de livraison doivent imposer des garde-fous.

Premier axe : séparation. Utilisez un pool FPM par boutique, un utilisateur dédié et des droits Unix minimaux ; envisagez un chroot, un namespace ou un conteneur si votre environnement le permet. En multiboutique ou multisite, l’objectif est de limiter le périmètre d’une compromission.

Deuxième axe : déploiements reproductibles. Si la production est modifiée à la main, il est difficile de vérifier que le correctif est présent partout. Automatisez le provisionnement (IaC), la construction des images, les déploiements et les health checks. Pour cadrer cette approche sur PrestaShop, voir : PrestaShop : modernisation et reprise de boutique avec déploiements automatisés.

Troisième axe : réduction de l’exposition applicative. Des endpoints legacy, un webservice trop permissif ou un back-office sans restriction peuvent augmenter les risques. Des mesures possibles :

restreindre l’accès au BO (liste d’adresses IP autorisées ou VPN ; éventuellement 2FA via un module réputé) ;
désactiver les fonctionnalités rarement utilisées, notamment le webservice s’il est inutile ;
limiter les privilèges du compte SQL de l’application plutôt que d’utiliser un compte root.

Pour le webservice, voir : Webservice PrestaShop : sécuriser les clés API et permissions.

La remédiation de CVE-2026-109618 et CVE-2026-109619 ne peut être définie qu’après confirmation, dans des avis officiels, du composant affecté et du correctif disponible. Si ces CVE concernent bien votre runtime PHP, la démarche comprend l’inventaire précis, l’installation du paquet corrigé, le redémarrage du service effectif, des mesures temporaires si nécessaire, des vérifications post-déploiement et un durcissement structurel.