Essai gratuit
FR

Actualité Mis à jour le

Failles et correctifs · Magento 2 · WordPress

Failles critiques de PHP (CVE-2026-109618 et CVE-2026-109619) : mettre à jour votre boutique Magento ou votre site WordPress

Le 21 octobre 2026, PHP a corrigé deux failles critiques qui permettent de prendre le contrôle d’un serveur sans aucun compte. Toutes les boutiques Magento et tous les sites WordPress tournent sur PHP. Voici comment savoir si vous êtes concerné et quoi faire dès aujourd’hui.

Cédric Michel, développeur Magento certifié Adobe Publié le Mis à jour le Lecture : 10 min
Illustration : la cloche rouge de Tocsin24 sonne au-dessus d'un serveur, devant lequel un bouclier bleu fissuré reçoit un correctif.
Critique · 9,2 / 10 CVE-2026-109618 · CVE-2026-109619 Corrigées le 21 octobre 2026
Effet
Prise de contrôle du serveur Exécution de code à distance, sans aucun compte.
Qui est concerné
Tout site qui tourne sur PHP Magento et WordPress compris, si PHP n'est pas à jour.
Versions corrigées
8.2.358.3.368.4.278.5.12 Aucune version officielle pour PHP 8.1 et antérieures.
Exploitation
Premières preuves de concept publiées Selon le CERT-EU, il est probable que des attaques aient déjà lieu.

En bref

  • Les deux failles touchent PHP lui-même, pas Magento ni WordPress. Une extension de sécurité ne peut pas les bloquer.
  • La seule vraie protection est la mise à jour de PHP vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, selon votre branche, ou vers le paquet corrigé de votre distribution.
  • PHP 8.1 et les versions plus anciennes n’ont pas de version officielle corrigée. Certaines distributions publient leur propre correctif. Les boutiques en Magento 2.4.4 et 2.4.5 sont dans ce cas.
  • Après la mise à jour, PHP doit être redémarré, sinon l’ancienne version peut continuer de tourner.
Sommaire

Ce qui se passe, en clair

PHP est le langage dans lequel sont écrits Magento et WordPress. Le serveur de votre boutique l’utilise à chaque page vue. Le 20 octobre, l’équipe de PHP a annoncé une mise à jour de sécurité critique, publiée le lendemain avec le détail des deux failles.

Un attaquant peut envoyer à votre site des requêtes fabriquées pour provoquer une erreur interne de PHP, puis en profiter pour exécuter son propre code sur le serveur. Il n’a besoin d’aucun compte. Il pourrait alors lire la base de données, modifier des fichiers ou installer un programme malveillant.

Le problème se produit pendant que PHP lit la requête, avant que Magento ou WordPress ne démarrent. Une extension de sécurité installée dans la boutique ne voit donc rien passer.

Pour les développeurs

CVE-2026-109618 (« RCE via OOM corruption », GHSA-w8hw-w9fx-j79w). Une erreur de mémoire insuffisante interrompt PHP alors que des données de la requête ne sont initialisées qu’en partie. Le nettoyage de fin de requête les traite ensuite comme valides. L’exploitation est confirmée sous Apache avec mod_php. PHP-FPM, FrankenPHP et LSAPI sont jugés probablement vulnérables d’après l’analyse du code.

CVE-2026-109619 (« RCE via stale global state », GHSA-6wmf-4rv5-p3rp). Un état interne lié à une requête survit à la libération de sa mémoire, puis une requête suivante traitée par le même processus l’utilise (use-after-free). Des cas sont validés sous mod_php comme sous PHP-FPM.

L’équipe de PHP juge le risque le plus élevé avec mod_php, mais considère toute installation qui sert des pages web comme exposée : PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Scores : 9,2 sur 10 en CVSS 4.0 pour les deux failles selon PHP ; la NVD les note 9,8 (CVE-2026-109618) et 8,1 (CVE-2026-109619) en CVSS 3.1.

Votre boutique ou votre site est-il concerné ?

Oui, si sa version de PHP est plus ancienne que la version corrigée de sa branche. La branche, c’est le début du numéro : 8.2, 8.3, 8.4 ou 8.5.

Branche de PHP Vulnérable si la version est… Version corrigée
8.5 antérieure à 8.5.12 8.5.12
8.4 antérieure à 8.4.27 8.4.27
8.3 antérieure à 8.3.36 8.3.36
8.2 antérieure à 8.2.35 8.2.35 (dernière année de support : fin le 31 décembre 2026)
8.1 et antérieures toutes Aucune version officielle (branches plus maintenues par PHP ; correctifs minimaux publiés pour 7.4, 8.0 et 8.1, et paquets corrigés chez certaines distributions)

Source : annonces de sécurité de PHP du 21 octobre 2026.

Ce tableau vaut pour PHP compilé depuis les sources officielles. Les distributions Linux, elles, corrigent parfois sans changer le numéro : sur Ubuntu, un PHP 8.3.6 peut être corrigé. Le cas est détaillé dans la partie pour le serveur.

Le cas des boutiques Magento

Chaque version de Magento ne fonctionne qu’avec certaines branches de PHP. Votre version de Magento détermine donc ce que vous pouvez installer.

Magento / Adobe Commerce PHP compatibles À faire
2.4.9 8.5 Passer en PHP 8.5.12
2.4.8 8.4, 8.3 Passer en PHP 8.4.27 ou 8.3.36
2.4.7 8.3, 8.2 Passer en PHP 8.3.36 ou 8.2.35
2.4.6 8.2, 8.1 Passer en PHP 8.2.35. En PHP 8.1, seul un correctif de la distribution ou d’un éditeur de support étendu protège.
2.4.5 et 2.4.4 8.1 seulement Aucune version officielle corrigée de PHP n’est compatible. Demandez un PHP 8.1 corrigé par la distribution (Ubuntu 22.04 en fournit un) et prévoyez la mise à jour de Magento.

Compatibilités d’après la configuration requise publiée par Adobe.

Pour WordPress, la mise à jour de PHP dans la même branche (par exemple de 8.3.30 à 8.3.36) ne change rien au fonctionnement du site. Un changement de branche, en revanche, demande de vérifier la compatibilité de vos extensions et de votre thème.

Connaître sa version de PHP

  • WordPress : dans l’administration, Outils, Santé du site, onglet Informations, section Serveur.
  • Magento : l’administration ne l’affiche pas. Regardez le panneau de votre hébergeur, ou demandez la version à votre hébergeur ou à votre agence.
  • Tocsin24 l’affiche pour chaque site, avec l’état de sa branche (voir plus bas).

Quoi faire maintenant

  1. Demandez la mise à jour de PHP à votre hébergeur ou à votre agence, aujourd’hui. Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs avant leur publication.
  2. Faites vérifier que la nouvelle version est bien active : PHP doit être redémarré après la mise à jour.
  3. En PHP 8.1 ou plus ancien : demandez si votre hébergeur fournit un correctif rétroporté, et prévoyez la montée de version. Pour Magento 2.4.4 et 2.4.5, il faut passer à une version plus récente de Magento.
  4. Si la mise à jour ne peut pas être faite rapidement, le CERT-EU recommande d’envisager de couper l’accès public au site en attendant. Des réglages temporaires réduisent le risque (voir plus bas), mais ils ne protègent pas complètement.
  5. Après la mise à jour, cherchez des traces d’intrusion : nouveaux comptes administrateurs, fichiers PHP inconnus, modifications de fichiers. La mise à jour ferme la porte, mais elle ne fait pas sortir quelqu’un qui serait déjà entré.
Message à votre hébergeur ou à votre agence

Bonjour,

PHP a publié le 21 octobre 2026 une mise à jour de sécurité critique (CVE-2026-109618 et CVE-2026-109619).

Pouvez-vous mettre à jour PHP sur le serveur de notre site vers la version corrigée de sa branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou le paquet corrigé de la distribution), redémarrer PHP et nous confirmer la version active ?

Si notre site utilise PHP 8.1 ou plus ancien, pouvez-vous nous dire quelle solution vous proposez ?

Merci.

Vous gérez le serveur : mettre à jour PHP sur Debian ou Ubuntu

Debian et Ubuntu ont publié les paquets corrigés de leur propre version de PHP :

Système Paquet Version corrigée Avis
Debian 13 (trixie) php8.4 8.4.27-1~deb13u1 DSA-6574-1
Debian 12 (bookworm) php8.2 8.2.35-1~deb12u1 DLA-4848-1
Ubuntu 26.04 LTS php8.5 8.5.4-0ubuntu1.5 USN-8948-1
Ubuntu 24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13 USN-8948-1
Ubuntu 22.04 LTS php8.1 8.1.2-1ubuntu2.28 USN-8948-1

Pour Ubuntu 20.04 et les versions plus anciennes, les correctifs passent par l’abonnement Ubuntu Pro (USN-8948-2).

  1. Installez les mises à jour :

    Terminal
    sudo apt update sudo apt upgrade

  2. Vérifiez la version installée. Remplacez 8.2 par votre branche (8.4 sur Debian 13, 8.3 sur Ubuntu 24.04) :

    Terminal
    apt-cache policy php8.2-fpm dpkg -l | grep php

    La ligne Installed (ou Installé) doit afficher la version corrigée du tableau, par exemple 8.2.35-1~deb12u1 sur Debian 12.

  3. Redémarrez PHP : PHP-FPM, ou Apache s’il utilise mod_php. Le paquet le fait souvent lui-même, mais un PHP qui n’a pas redémarré continue d’exécuter l’ancienne version :

    Terminal
    PHP-FPM (adaptez le numéro de branche) sudo systemctl restart php8.2-fpm Apache avec mod_php sudo systemctl restart apache2

Réglages temporaires, si vous ne pouvez pas mettre à jour tout de suite

L’équipe de PHP et le CERT-EU sont clairs : ces réglages réduisent l’exposition, mais ne rendent pas le serveur sûr. Ils se placent dans le php.ini qui sert le site, ou dans la configuration du pool PHP-FPM, jamais par ini_set() ni dans un .user.ini. Sur Debian et Ubuntu, le php.ini de PHP-FPM est dans /etc/php/<branche>/fpm/, celui d’Apache avec mod_php dans /etc/php/<branche>/apache2/. Redémarrez ensuite tous les processus PHP.

Contenu du fichier /etc/php/8.2/fpm/php.ini
  1. session.upload_progress.enabled = 0
  2. post_max_size = 32M
  3. upload_max_filesize = 16M

Ce que veut dire chaque ligne :

  • session.upload_progress.enabled Coupe la progression des envois de fichiers en session, un des chemins d’attaque confirmés. Elle est active par défaut. L’équipe de PHP conseille de la laisser coupée même après la mise à jour, si vous ne vous en servez pas.
  • post_max_size 8M si le site ne reçoit aucun fichier, 32M sinon. Vérifiez que les envois d’images de l’administration passent toujours.
  • upload_max_filesize Toujours plus petit que post_max_size.

En PHP 8.5, ajoutez aussi fatal_error_backtraces = 0.

Les avis officiels citent aussi memory_limit = -1. Sur une boutique Magento, retirer la limite de mémoire peut faire saturer le serveur : n’appliquez ce réglage qu’en connaissance de cause. N’utilisez pas les limites RLIMIT_AS ni RLIMIT_DATA à la place, car elles déclenchent justement le défaut.

Tocsin24 affiche la version de PHP de chacun de vos sites

Sur la page Failles de chaque site, Tocsin24 affiche la version de PHP qui sert le site : le module Magento et l’extension WordPress la lisent dans le PHP qui répond aux pages (PHP-FPM ou Apache), pas dans celui de la ligne de commande. Elle est relevée à chaque vérification du site, toutes les heures par défaut, avec l’état de sa branche et la dernière version publiée quand la vôtre est en retard. Après la mise à jour, la nouvelle version s’affiche au relevé suivant.

Tocsin24 ne suit pas encore les failles de PHP une par une : il n’affiche pas « exposé à CVE-2026-109618 ». Comparez la version affichée au tableau de cet article. La liste des dernières versions de PHP est relue une fois par semaine, et sur Ubuntu le numéro reste l’ancien même quand le paquet est corrigé : dans ce cas, fiez-vous à la version du paquet. Tocsin24 surveille aussi les nouveaux comptes administrateurs et l’intégrité des fichiers, les premières traces d’une intrusion.

Essayer gratuitement Voir la surveillance Magento 2

PHP

8.2.35

Correctifs de sécurité seulement, jusqu’au 31 décembre 2026

Version corrigée

PHP

8.3.30

Correctifs de sécurité seulement, jusqu’au 31 décembre 2027

Mise à jour disponible : PHP 8.3.36

À mettre à jour

PHP

8.1.34

Plus maintenue depuis le 31 décembre 2025 : aucune faille n’est plus corrigée

Branche à changer

Carte PHP de la page Failles, pour trois serveurs d’exemple. Les étiquettes de couleur sont ajoutées pour l’article.

Écrans de l’application avec des valeurs d’exemple.

Questions fréquentes

Mon hébergeur s’occupe-t-il de la mise à jour de PHP tout seul ?

Sur un hébergement mutualisé ou infogéré, souvent oui, mais pas toujours le jour même, et le redémarrage n’est pas toujours fait. Demandez-lui de vous confirmer la version active. Sur un serveur que vous gérez, c’est à vous de le faire.

Mon pare-feu ou mon extension de sécurité me protège-t-il ?

Une extension de sécurité de Magento ou de WordPress, non : la faille se déclenche avant elle. Un pare-feu placé devant le serveur peut réduire le risque s’il limite la taille et la forme des requêtes, mais seule la mise à jour de PHP corrige le défaut.

La mise à jour de PHP peut-elle casser ma boutique ?

Rester dans la même branche (par exemple de 8.3.30 à 8.3.36) n’apporte que des corrections, et le risque est faible. Changer de branche (de 8.1 à 8.2) demande des tests, et pour Magento, une version compatible.

Après la mise à jour sur Ubuntu, php -v affiche toujours 8.3.6. Est-ce normal ?

Oui. Ubuntu corrige ses paquets sans changer le numéro de PHP. Vérifiez plutôt la version du paquet avec apt-cache policy php8.3-fpm : elle doit être 8.3.6-0ubuntu0.24.04.13 ou plus récente sur Ubuntu 24.04.

Comment savoir si quelqu’un a déjà profité de la faille ?

Cherchez les traces habituelles d’une intrusion : comptes administrateurs inconnus, fichiers PHP que vous n’avez pas créés, fichiers du site modifiés, tâches planifiées inconnues. En cas de doute, faites intervenir un spécialiste avant de tout effacer.

Portrait de Cédric Michel

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Badge Adobe Commerce Developer Expert Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Sources

  1. PHP : annonces du 20 et du 21 octobre 2026
  2. PHP : avis GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
  3. PHP : avis GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
  4. CERT-EU : avis de sécurité 2026-018 (version 1.1)
  5. NVD : CVE-2026-109618
  6. NVD : CVE-2026-109619
  7. Debian : suivi de sécurité de CVE-2026-109618
  8. Ubuntu : avis USN-8948-1
  9. Ubuntu : avis USN-8948-2 (Ubuntu 20.04 et plus anciens)
  10. Adobe Commerce : configuration requise