Cette semaine, deux dossiers de la semaine dernière trouvent leur suite : PostgreSQL publie une mise à jour qui corrige 52 vulnérabilités et clôt la branche 14, et Ubuntu livre enfin ses noyaux corrigés pour la faille TCP critique. PostgreSQL 19 et WordPress 7.2 approchent de leur version finale, et Claude Code corrige plusieurs contournements de ses permissions. Voici cinq changements à connaître, avec ce qu’ils impliquent en pratique.
PostgreSQL 18.7, 17.12, 16.16, 15.20 et 14.25 : 52 failles corrigées, et parfois des index à reconstruire
Le 12 novembre, le PostgreSQL Global Development Group a publié 18.7, 17.12, 16.16, 15.20 et 14.25, qui corrigent 52 vulnérabilités et plus de 140 bogues. Le score CVSS 3.1 le plus élevé, 8,8, est partagé par de nombreuses entrées, dont plusieurs exécutions de code arbitraire, comme CVE-2026-6460 après un ALTER ... SET DATA TYPE. Les outils clients sont aussi touchés, notamment pg_dump (injection SQL, CVE-2026-116318) et pg_restore (exécution de code, CVE-2026-116314).
L’annonce liste des actions après la mise à jour : réindexer les index GIN suspects, les index GiST utilisant gist_trgm_ops et les index B-tree sur des colonnes bpchar déclarées sans longueur, lancer REINDEX TABLE en cas d’erreur « missing chunk number », et refaire une sauvegarde complète si vous utilisez les sauvegardes incrémentales. Autrement dit, remplacer les binaires ne suffit pas toujours.
Pourquoi c’est important
Une version mineure ne demande ni pg_dump ni pg_upgrade : mettez à jour les paquets ou l’image, puis redémarrez le serveur. Contrôlez ensuite la version en service avec SELECT version(); ; pour un conteneur, vérifiez l’image réellement tirée, pas seulement le tag du fichier Compose. Une base dédiée à une seule application est moins exposée qu’un serveur partagé ; ce n’est pas une raison pour reporter. Mettez aussi à jour les clients de vos machines de sauvegarde, puis relisez la liste des index concernés. Un correctif de base de données touche le serveur, les outils et parfois les index ; en oublier un, c’est le faire à moitié.
Source : annonce officielle de PostgreSQL du 12 novembre.
Noyau Ubuntu (CVE-2026-98432) : les correctifs sont publiés, le redémarrage reste à faire
La semaine dernière, Ubuntu listait encore ses noyaux comme vulnérables à CVE-2026-98432, le use-after-free TCP IPv4 noté 9,8 en CVSS 3.1. Les 10 et 11 novembre, Canonical a publié une série d’avis « Linux kernel vulnerabilities » rattachés à cette CVE. La page de la CVE, mise à jour le 11 novembre, indique désormais le paquet linux corrigé sur les quatre versions suivies : 5.15.0-203.213 pour 22.04, 6.8.0-149.149 pour 24.04, 7.0.0-43.43 pour 26.04 et 7.3.0-10.10 pour 26.10. Les noyaux cloud (linux-aws, linux-gcp, linux-azure) de 22.04 et 24.04 sont aussi corrigés, mais certaines variantes HWE, comme linux-hwe-6.17 sur 24.04, restent listées vulnérables.
Pourquoi c’est important
Sur un VPS Ubuntu, identifiez d’abord le noyau en service avec uname -r. Installez les mises à jour, puis redémarrez dans une fenêtre planifiée : tant que uname -r n’affiche pas la version corrigée, le serveur reste exposé. Si vous suivez une pile HWE encore listée comme vulnérable, conservez la règle nftables de mitigation évoquée la semaine dernière, testée et avec un accès console de secours, et revenez vérifier la page. Les serveurs Debian déjà corrigés et redémarrés ne sont pas concernés ; les conteneurs, eux, partagent le noyau de l’hôte. Un correctif publié n’est pas un correctif actif ; entre les deux, il y a un redémarrage.
Source : page de sécurité Ubuntu consacrée à CVE-2026-98432, mise à jour le 11 novembre.
PostgreSQL 14 en fin de vie, PostgreSQL 19 attendu le 19 novembre
La version 14.25, publiée le 12 novembre, est la dernière de la branche : PostgreSQL 14 ne recevra plus de correctifs, ni de sécurité ni de bogues. Le même jour, le projet a publié la RC2 de PostgreSQL 19, dont la disponibilité générale est prévue le 19 novembre 2026, sauf problème imposant un report ou une nouvelle release candidate.
Cette RC2 retire une possibilité ouverte pendant les tests : les index d’expression, colonnes générées et clés de partition qui utilisent JSON_ARRAY() ou JSON_OBJECT() sur des tableaux, des types composites ou des intervalles doivent être supprimés ou redéfinis, sans quoi pg_dump, pg_restore et pg_upgrade échoueront. Avec pg_upgrade, les index de recherche plein texte, pg_trgm ou fuzzystrmatch peuvent demander une réindexation.
Pourquoi c’est important
Le signal n’est pas « migrez vers PostgreSQL 19 la semaine prochaine ». Pour une instance encore en 14, la cible raisonnable reste une branche déjà éprouvée, 17 ou 18 ; PostgreSQL 19 mérite d’abord un essai sur une copie restaurée de vos données, avec vos migrations Django, vos extensions et vos requêtes critiques. Si vous avez testé les RC, cherchez les objets construits avec JSON_ARRAY() ou JSON_OBJECT() avant toute montée de version. Pour le paquet d’une distribution, la couverture dépend de l’éditeur : vérifiez-la. Une branche qui s’arrête crée une dette ; une branche qui démarre n’est pas encore une solution.
Sources : annonce officielle de PostgreSQL du 12 novembre et politique de versions officielle de PostgreSQL.
WordPress 7.2 Beta 5 : un mois pour tester avant la sortie du 8 décembre
Le 10 novembre, l’équipe de WordPress a publié WordPress 7.2 Beta 5, dernière bêta du calendrier : la RC1 est prévue le 17 novembre et la version finale le 8 décembre 2026. Cette bêta envoie un e-mail lors de la création d’un mot de passe d’application et retouche le nouveau thème par défaut, Ipsum. Selon l’annonce, tous les problèmes connus de compatibilité avec PHP 8.6, attendu le 19 novembre, sont résolus dans le cœur, ce qui ne dit rien de vos extensions.
Pourquoi c’est important
Rien n’est à installer en production : une bêta est réservée aux environnements de test. C’est en revanche le bon moment pour copier un site sur une préproduction, lancer wp core update --version=7.2-beta5, puis vérifier vos extensions, votre thème et vos tâches planifiées. Si vous envisagez PHP 8.6, testez la combinaison complète plutôt que le cœur seul, et gardez votre image PHP actuelle en production d’ici là. Si vos scripts créent des mots de passe d’application, prévenez les destinataires des nouveaux e-mails. Un cœur compatible ne fait pas un site compatible ; ce sont les extensions qui tranchent.
Sources : annonce officielle de WordPress 7.2 Beta 5 du 10 novembre et calendrier officiel de WordPress 7.2.
Claude Code 2.1.319 et 2.1.321 : plusieurs contournements de permissions corrigés
Anthropic a publié Claude Code 2.1.319 le 6 novembre, puis 2.1.321 le 9 novembre. La première corrige un contournement des permissions Bash par un préfixe de variables d’environnement, une sortie du bac à sable lors de la création d’un worktree et des règles de refus qui manquaient les mots entre guillemets. Elle ajoute le réglage permissions.denyInsteadOfPrompting, qui refuse un appel d’outil plutôt que d’attendre une réponse.
La 2.1.321 empêche les requêtes OAuth vers des serveurs MCP d’envoyer des refresh tokens à un autre hôte après une redirection, et corrige une commande Bash exécutée hors du bac à sable sans demande. Côté coût, elle fait de Claude Fable 5.2 le modèle Fable par défaut, facturé 8 et 40 dollars par million de tokens.
Pourquoi c’est important
Si l’agent travaille en mode automatique ou avec des connecteurs MCP authentifiés, mettez à jour, contrôlez claude --version et vérifiez qu’une règle de refus bloque aussi une commande écrite autrement. Pour les tâches non surveillées, le nouveau réglage évite une session suspendue sans élargir les autorisations. Si vous utilisez Fable, vérifiez quel modèle votre configuration sélectionne et son coût réel ; rappelons aussi la fin du fast mode d’Opus 4.8 le 30 novembre. Ces notes restent une publication d’Anthropic sur son propre outil, sans indication d’exploitation. Une règle de refus ne vaut que si elle résiste à une autre façon d’écrire la même commande.
Sources : notes de version officielles de Claude Code 2.1.319 et page officielle des versions de Claude Code, dont la 2.1.321.
En production, commencez par PostgreSQL : mettez à jour serveurs et clients, redémarrez, puis traitez les réindexations qui vous concernent. Installez ensuite les noyaux Ubuntu corrigés et redémarrez, en contrôlant uname -r. Planifiez la sortie de PostgreSQL 14 sans vous précipiter vers la 19, testez WordPress 7.2 sur une copie et mettez à jour Claude Code. Le fil conducteur de la semaine est ce qui suit l’installation : un redémarrage, un index à reconstruire, une règle à retester ; c’est là que se joue la différence entre une mise à jour faite et une mise à jour efficace.
Laisser un commentaire