Deux failles critiques dans PHP, des certificats HTTPS compromis et plusieurs correctifs qui touchent directement la gestion de nos sites : cette semaine, la sécurité passe autant par les versions installées que par les dépendances embarquées dans les applications. Voici cinq dossiers à vérifier sur une stack WordPress, Django ou Linux, sans supposer qu’une mise à jour du serveur corrige automatiquement les conteneurs.
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 : deux failles d’exécution de code à corriger en priorité
Le 21 octobre, l’équipe de PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux vulnérabilités notées 9.2 en CVSS v4.0 et pouvant permettre une exécution de code à distance sans authentification. CVE-2026-109618 concerne le dépassement de mémoire : PHP peut être interrompu alors que les données de la requête ne sont que partiellement initialisées. CVE-2026-109619 laisse survivre un état interne dont la mémoire a été libérée, que la requête suivante du même worker peut réutiliser. Autrement dit, la faille est dans l’interpréteur, pas dans WordPress ou ses extensions.
Toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php, où une requête peut déclencher l’attaque avant toute exécution du code applicatif. Des fuites la veille ont avancé la publication d’un jour, et plusieurs opérateurs ont mis des services hors ligne par précaution.
Pourquoi c’est important
Vérifiez la version réellement servie, pas seulement celle de la ligne de commande : php -v et php-fpm -v peuvent différer. Les distributions ont reçu les correctifs à l’avance ; appliquez leurs paquets, puis redémarrez PHP-FPM ou Apache, car une mise à jour installée n’est pas active tant que les anciens workers tournent. Pour PHP 8.1 et antérieur, le projet ne publie plus de correctif : seuls certains éditeurs fournissent des rétroportages. Les mesures provisoires, comme session.upload_progress.enabled=0, réduisent l’exposition sans rendre l’installation sûre. Pensez aussi aux images Docker wordpress ou php à reconstruire. Un serveur qui n’exécute que du Python n’est pas concerné ; un VPS qui héberge « juste un petit WordPress » l’est entièrement.
Sources : avis de sécurité officiel de PHP du 21 octobre et billet de la PHP Foundation sur cette publication.
eMudhra : une révocation à appliquer dans Linux, Python et Docker
Le 17 octobre, Mozilla a été informé de la compromission des clés privées de huit certificats intermédiaires eMudhra. Ces clés pouvaient servir à fabriquer des certificats HTTPS frauduleux, notamment si un attaquant était en mesure d’intercepter les connexions. Firefox a bloqué ces certificats via OneCRL ; pour les applications et serveurs, il faut aussi corriger les listes d’autorités considérées comme fiables.
Mettre à jour le magasin de certificats du serveur
Le 20 octobre, Ubuntu a publié USN-8944-1 pour ca-certificates sur les versions 22.04, 24.04, 26.04 et 26.10. Sur un serveur concerné, installez les mises à jour de sécurité, vérifiez le paquet avec apt policy ca-certificates et redémarrez les services qui gardent leur magasin de certificats en mémoire. Sur Debian ou une autre distribution, contrôlez les correctifs effectivement fournis par votre éditeur plutôt que de déduire l’état du système de sa seule version.
Corriger les environnements Python et Django
requests utilise souvent certifi, qui fournit sa propre liste d’autorités. La Python Security Response Team recommande au minimum certifi 2026.10.19, pip 26.2.2 et uv 0.13.4. C’est particulièrement important pour pip : sa copie embarquée de certifi continue à faire confiance aux anciennes autorités même si le système Linux est corrigé. Les releases de sécurité Python 3.15.1, 3.14.9 et 3.13.17, publiées le 21 octobre, incluent elles aussi un pip actualisé, mais les environnements virtuels déjà créés doivent être contrôlés séparément.
Recréer les images et vérifier le moteur Docker
Docker Engine 29.9.2, publié le 20 octobre, actualise Go et rejette désormais les chaînes TLS reposant sur les intermédiaires compromis. Un docker pull refusé par un registry utilisant encore cette chaîne est donc une protection, pas une raison d’activer insecure-registries. Attention : mettre à jour le démon Docker ne met pas à jour les bibliothèques ni les certificats contenus dans les images. Il faut reconstruire puis redéployer les conteneurs à partir de bases corrigées.
Pourquoi c’est important
Sur un VPS, nous pouvons avoir trois magasins de certificats distincts : celui de l’hôte, celui de chaque image et celui utilisé par Python. Corriger un seul niveau laisse les autres exposés. Faites l’inventaire des environnements réellement déployés, vérifiez leurs dépendances et planifiez les redémarrages nécessaires.
Sources : Mozilla, 20 octobre, Ubuntu USN-8944-1, Python Security Response Team, Docker Engine et Wagtail.
Wagtail 8.0.1 : corriger les permissions et les exports XLSX
Le 20 octobre, Wagtail a publié des correctifs de sécurité dans les branches 8.0.1, 7.4.4 LTS et 7.0.10 LTS. Ils concernent notamment une modification non autorisée des règles de confidentialité des Collections, l’accès à certaines pages parentes via l’API interne d’administration et l’injection de formules dans un export XLSX. Dans Wagtail 8, l’API v3 expérimentale fait aussi l’objet de corrections d’accès à des brouillons et de filtrage du HTML ; les éditeurs riches tiers utilisant l’ancien convertisseur HTML sont également concernés.
Pourquoi c’est important
Un compte d’administration aux droits limités ne doit pas pouvoir consulter des contenus privés ou modifier les règles d’une autre collection. Quant à l’export XLSX, une donnée saisie dans un formulaire peut être interprétée comme une formule lors de l’ouverture du fichier dans un tableur. L’exploitation dépend des fonctionnalités activées et, souvent, d’une interaction humaine : il ne s’agit pas d’une prise de contrôle anonyme de tous les sites Wagtail. Vérifiez la branche avec python -m pip show wagtail, appliquez sa version corrigée, puis testez les autorisations de vos comptes éditeurs et les exports utilisés.
Sources : Wagtail 8.0.1, Wagtail 7.4.4 et Wagtail 7.0.10.
Nginx 1.30.6 et 1.31.7 : cinq failles corrigées, des distributions encore en retard
Le 14 octobre, nginx.org a publié 1.30.6 (stable) et 1.31.7 (mainline), qui corrigent cinq vulnérabilités classées « medium » par le projet. La plus large, CVE-2026-15176, est un débordement de tampon lorsque alias est combiné à rewrite ; elle touche toutes les versions depuis 0.1.29. Les autres touchent l’évaluation d’expressions avec variables, HTTP/3, la rotation des clés de tickets TLS et ngx_http_ssi_module avec AIO.
Debian a publié DSA-6575-1 pour trixie (1.26.3-3+deb13u10) ; bookworm restait listé vulnérable, sans correctif, lors de notre consultation, et Ubuntu indiquait encore « needs evaluation » pour toutes ses versions.
Pourquoi c’est important
Le classement « medium » est à relativiser : Ubuntu affiche un score CVSS 3.1 de 8.1 pour CVE-2026-15176, une requête non authentifiée pouvant faire tomber un worker, voire exécuter du code si l’ASLR est contourné. Vérifiez votre version avec nginx -v, puis cherchez dans vos configurations les combinaisons alias et rewrite, l’usage de $request_filename, les directives aio et les écoutes quic. Appliquez le paquet corrigé sur trixie ; ailleurs, suivez votre distribution ou passez à une image 1.30.6. Testez avec nginx -t avant de recharger. Une sévérité « moyenne » sur un serveur exposé reste une priorité.
Sources : avis de sécurité officiels de nginx et suivi de sécurité Debian pour CVE-2026-15176.
Claude Code 2.1.305 à 2.1.309 : contrôler les permissions des agents
Le journal de Claude Code signale dans la version 2.1.305 du 20 octobre un changement de comportement : allowedMcpServers ne filtre plus les serveurs stdio de managed-mcp.json qui n’utilisent ${VAR} que dans leur bloc env. Des serveurs que votre liste excluait jusqu’ici peuvent donc se charger après la mise à jour ; Anthropic recommande deniedMcpServers pour les maintenir désactivés. La même version ajoute sandbox.allowNestedUserNamespaces, dont le journal précise qu’il permet de contourner les protections de fichiers du bac à sable.
La version 2.1.309 du 22 octobre corrige des défauts de cloisonnement, dont des fichiers de démarrage du shell exécutés hors du bac à sable.
Pourquoi c’est important
Le changement de filtrage ne concerne que les configurations avec managed-mcp.json et liste d’autorisation ; les corrections de 2.1.309 valent pour tous. Vérifiez la version avec claude --version, relisez les serveurs réellement chargés après la mise à jour et ajoutez des refus explicites. N’activez pas allowNestedUserNamespaces par confort. Le journal reste une publication d’Anthropic sur son propre outil : il documente des corrections, sans indiquer si ces défauts ont été exploités. Une liste d’autorisation ne protège que si elle filtre encore ce que vous croyez.
Sources : Claude Code 2.1.305 et Claude Code 2.1.309 (notes officielles d’Anthropic).
En production, commencez par PHP et le redémarrage de ses workers, puis corrigez Wagtail et les magasins de certificats de vos hôtes et applications. Pour Nginx, vérifiez les correctifs disponibles dans votre distribution et les directives réellement utilisées. Planifiez aussi les mises à jour de Docker et des agents de développement : un serveur corrigé ne garantit pas que ses conteneurs et ses outils le sont.
Laisser un commentaire