Cette semaine, la priorité revient aux correctifs : WordPress publie une version de sécurité dense, Ubuntu livre ses paquets nginx corrigés, Brotli corrige son décodeur et Python bloque les certificats eMudhra compromis au niveau de l’interpréteur. Côté infrastructure, la fin de support de PostgreSQL 14 approche, et Codex CLI corrige la gestion de ses permissions. Voici six changements à connaître, avec ce qu’ils impliquent en pratique.
WordPress 7.1.4 : douze failles corrigées, dont une pendant la mise à jour elle-même
Le 28 octobre, l’équipe de WordPress a publié WordPress 7.1.4, une version de sécurité qui corrige douze vulnérabilités et actualise les certificats racine embarqués à la suite de la révocation eMudhra. La faille à retenir concerne le processus de mise à jour : selon l’annonce, une faiblesse peut conduire à une exécution de code à distance « pendant la fenêtre de mise à jour ». La plupart des autres correctifs portent sur des XSS stockées (Interactivity API, plusieurs blocs, Customizer) et deux fuites d’information, dont des changesets du Customizer non publiés découvrables sans authentification. Les rétroportages jusqu’à la branche 4.7 sont annoncés comme encore en cours.
Pourquoi c’est important
Une XSS stockée suppose en général un compte capable de publier du contenu : un blog sans autre auteur est moins exposé qu’un site avec contributeurs. Ce n’est pas une raison pour attendre. Vérifiez la version réellement installée avec wp core version, y compris sur les sites où les mises à jour automatiques sont censées être actives, puis faites une sauvegarde et mettez à jour. Pour les installations sous Docker, l’image officielle wordpress ne remplace pas les fichiers d’un volume déjà initialisé : contrôlez la version servie après le redéploiement. Une mise à jour automatique activée n’est pas une mise à jour appliquée.
Source : annonce officielle de WordPress 7.1.4 du 28 octobre.
nginx sur Ubuntu (USN-8955-1) : les correctifs sont disponibles, Debian bookworm attend encore
La semaine dernière, Ubuntu indiquait encore « needs evaluation » pour les failles corrigées par nginx.org. Le 26 octobre, Canonical a publié USN-8955-1 pour Ubuntu 22.04, 24.04, 26.04 et 26.10. L’avis couvre notamment CVE-2026-15176 (combinaison de alias et de rewrite), CVE-2026-97205 (entrées-sorties asynchrones avec SSI) et CVE-2026-97629 (clés de tickets TLS partagées sans rotation explicite) ; la faille HTTP/3 ne concerne que 26.04 et 26.10.
Côté Debian, trixie est corrigé depuis DSA-6575-1, mais au moment de préparer cette édition, le suivi de sécurité listait toujours bookworm comme vulnérable à CVE-2026-15176, sans correctif disponible.
Pourquoi c’est important
Installez les mises à jour, contrôlez la version avec dpkg -l 'nginx*', validez la configuration avec nginx -t et vérifiez avec systemctl status nginx que les processus ont bien été relancés. Sur bookworm, en attendant le correctif, relisez vos blocs location : la combinaison d’alias, de rewrite et de $request_filename est le cas à éliminer en priorité. Si votre nginx tourne dans un conteneur, le paquet de l’hôte ne change rien : c’est l’image, par exemple nginx:1.30.6 ou plus récente, qui compte. Un statut « needs evaluation » n’est pas un correctif ; il faut revenir le vérifier.
Sources : avis de sécurité Ubuntu USN-8955-1 du 26 octobre et suivi de sécurité Debian pour CVE-2026-15176.
Brotli : une faille du décodeur à corriger sur l’hôte et dans les environnements Python
Le 26 octobre, Ubuntu a publié USN-8956-1 pour la bibliothèque de compression Brotli, après l’avis Debian DSA-6582-1 du 23 octobre pour trixie ; bookworm est corrigé par DLA-4855-1. La faille, CVE-2026-111497, est un débordement de tampon dans le décodeur de Brotli 1.0.3 à 1.2.0 : un flux compressé spécialement construit peut corrompre la mémoire du décodeur, avec un risque de déni de service, voire d’exécution de code. Les versions amont corrigées sont 1.0.10, 1.1.1 et 1.2.1.
Autrement dit, ce n’est pas un outil isolé : sur Ubuntu, libbrotli1 est une dépendance de libcurl.
Pourquoi c’est important
La faille se trouve dans la décompression : le risque concerne d’abord les programmes qui décodent des données venues de l’extérieur, comme un client HTTP. Un nginx qui se contente de compresser ses réponses est moins directement exposé. Appliquez les paquets de votre distribution, vérifiez-les avec apt policy libbrotli1, puis redémarrez les services qui chargent la bibliothèque ; needrestart aide à les repérer. Dans vos projets Python, les paquets Brotli ou brotlicffi installés avec pip peuvent embarquer leur propre copie : contrôlez leur version avec pip show. Corriger la bibliothèque système ne corrige pas les copies qu’elle ne voit pas.
Sources : avis de sécurité Ubuntu USN-8956-1 du 26 octobre et suivi de sécurité Debian pour CVE-2026-111497.
Python 3.15.2 et quatre branches de sécurité : la révocation eMudhra intégrée au module ssl
Le 25 octobre, l’équipe de Python a publié en procédure accélérée 3.15.2, 3.14.10, 3.13.18, 3.12.16 et 3.11.18. Le correctif principal, CVE-2026-115557, fait refuser par le module ssl les clés des intermédiaires eMudhra compromis, en dernier recours. Selon les notes de version, même un pip non mis à jour est ainsi protégé sur un interpréteur corrigé. Ces versions corrigent aussi CVE-2026-114583, un contournement de tarfile.tar_filter par des liens qui remplacent la destination. Pour la branche 3.13, seules les sources sont désormais publiées, sans installateurs binaires.
Pourquoi c’est important
Ces versions complètent les mesures de la semaine dernière ; elles ne les remplacent pas. Les notes officielles ne détaillent que le cas de pip : ne supposez pas que toutes vos dépendances sont couvertes, et gardez certifi à jour dans vos environnements Django. Pour les conteneurs, reconstruisez vos images avec docker build --pull afin de récupérer la nouvelle base python, puis contrôlez python --version dans le conteneur. Si vous utilisez le Python de votre distribution, ces versions amont ne s’appliquent pas telles quelles : suivez les correctifs de votre éditeur. Une version publiée n’est utile que dans l’image qui tourne réellement.
Sources : notes de version officielles de Python 3.15.2 et liste officielle des versions publiées le 25 octobre.
PostgreSQL 14 : dernière version mineure le 12 novembre
Nous l’évoquions le 16 octobre ; il reste désormais moins de deux semaines. La politique de versions de PostgreSQL fixe au 12 novembre 2026 la dernière publication de la branche 14, actuellement en 14.24. Le même jour, selon l’annonce de la RC1, le projet publiera la mise à jour mineure des versions supportées et la RC2 de PostgreSQL 19, dont la disponibilité générale reste prévue le 19 novembre, sauf report ou nouvelle release candidate.
Autrement dit, une faille découverte dans PostgreSQL 14 après cette date ne sera plus corrigée par le projet.
Pourquoi c’est important
Le 13 novembre, vos serveurs ne s’arrêteront pas ; ils cesseront simplement de recevoir des correctifs amont. Commencez par repérer les instances concernées avec SELECT version();, sans oublier les conteneurs postgres:14 lancés par Compose. Choisissez ensuite une cible déjà stable plutôt que PostgreSQL 19 dès sa sortie, puis testez la migration sur une copie restaurée : pg_upgrade ou pg_dump et pg_restore, migrations Django, extensions et requêtes critiques. Si vous utilisez le paquet d’une distribution, sa couverture dépend de l’éditeur et non du projet : vérifiez sa politique avant de conclure que rien ne presse. Une fin de support n’est pas une panne ; c’est une dette qui commence à courir.
Sources : politique de versions officielle de PostgreSQL et annonce officielle de PostgreSQL 19 RC1.
Codex CLI 0.165 et 0.166 : vérifier les permissions des sessions reprises
Le journal des modifications d’OpenAI documente deux versions de Codex CLI cette semaine. La 0.165.0, du 27 octobre, corrige un défaut de validation des URL de marketplace qui pouvait permettre à Git de se connecter à un autre hôte que celui vérifié par les motifs autorisés, et rejette les antislashs dans la partie identifiant des URL HTTP(S). La 0.166.0, du 29 octobre, conserve les réglages d’approbation et de permission déjà acceptés lorsqu’on reprend ou duplique une conversation.
Pourquoi c’est important
Le premier correctif concerne ceux qui installent des extensions depuis une marketplace en s’appuyant sur une liste d’hôtes autorisés ; le second, ceux qui reprennent régulièrement des sessions. Vérifiez la version avec codex --version, mettez à jour, puis contrôlez dans une session reprise que le mode de bac à sable et les approbations correspondent bien à ce que vous aviez choisi. Le journal reste une publication d’OpenAI sur son propre outil : il décrit des corrections, sans indiquer si ces défauts ont été exploités. Une permission accordée une fois ne devrait valoir que là où vous l’avez accordée.
Source : journal des modifications officiel de ChatGPT et Codex (OpenAI).
En production, commencez par WordPress 7.1.4, puis appliquez les paquets nginx et Brotli de votre distribution et redémarrez les services concernés. Reconstruisez ensuite vos images Python, planifiez la migration de vos instances PostgreSQL 14 et mettez à jour Codex CLI. Le fil conducteur de la semaine est la distance entre un correctif annoncé et un correctif actif : entre les deux, il y a un paquet, une image ou un redémarrage à ne pas oublier.
Laisser un commentaire