Notes de sécurité.
Le 21 octobre, le projet PHP a publié un avis de sécurité critique avec une consigne courte : mettez à jour maintenant. Deux failles d'exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, sont toutes deux notées CVSS 9.2. La première se déclenche lorsque PHP manque de mémoire en pleine préparation d'une requête puis nettoie des données qui n'ont jamais été entièrement initialisées. La seconde permet à l'état interne d'une requête de survivre à sa mémoire, si bien que la requête suivante traitée par le même worker peut le récupérer. Toutes les configurations PHP qui servent du trafic web sont concernées — PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed —, mod_php présentant le risque le plus élevé.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L'avis est clair : il n'existe pas de contournement complet, la mise à jour est la seule option sûre.
Ce que nous avons fait avant le correctif. Les vulnérabilités ont été annoncées avant la publication des versions, nous avons donc réduit l'exposition des serveurs dont nous avons la charge pendant les heures intermédiaires. Nous avons désactivé le session upload progress, cité dans l'avis comme atténuation partielle de la seconde faille, et imposé le strict session mode comme durcissement supplémentaire. Ces deux réglages ont été appliqués à chaque environnement PHP de chaque hôte et dans les conteneurs applicatifs, et nous les avons vérifiés sur les workers PHP qui répondent réellement aux requêtes plutôt que de nous fier aux fichiers de configuration.
Correction le jour même. À la sortie des versions, les paquets habituels des distributions et les images de conteneurs officielles n'étaient pas encore à jour. Plutôt que d'attendre, nous avons compilé les versions corrigées à partir des sources officielles de PHP, vérifiées par somme de contrôle, en conservant les extensions et réglages existants de chaque serveur, et recompilé OPcache en conséquence. Les applications encore sous PHP 8.0 ou 8.1, qui ne reçoivent plus de versions publiques, ont bénéficié des backports de sécurité officiels du projet PHP plutôt que d'une montée de version en urgence. Les applications conteneurisées ont été migrées vers l'image corrigée 8.4.27, avec une image de base épinglée pour qu'une future compilation ne puisse pas revenir discrètement à une version vulnérable.
Vérifier, pas supposer. Un numéro de version ne prouve rien à lui seul lorsqu'une version corrigée et une version non corrigée peuvent afficher la même chaîne. Chaque pool web actif a donc été vérifié pour le moteur et la version d'OPcache qu'il exécute réellement, puis nous avons contrôlé les boutiques publiques, les pages de connexion et les sites de démonstration. Les vingt-trois pools PHP actifs de nos environnements et de ceux de nos clients ont passé la vérification.
Ce que cela signifie pour votre boutique. Si vous utilisez Magento ou toute autre application PHP et n'avez pas fait de mise à jour depuis le 21 octobre, considérez-le comme urgent. Vérifiez la version de PHP réellement exécutée par vos workers web, pas seulement celle de la ligne de commande, et planifiez l'abandon de PHP 8.0 et 8.1 si vous en dépendez encore. Les backports de sécurité font gagner du temps ; ils ne sont pas une solution durable.
Si vous souhaitez un regard extérieur sur votre stack, ou que nous prenions en charge ce type de mises à jour pour vous, contactez-nous — assurer la sécurité et la disponibilité des boutiques fait largement partie de notre quotidien.