Cette semaine, une faille déjà corrigée change de statut : la vulnérabilité de WordPress liée à la fenêtre de mise à jour est désormais exploitée. Le noyau Linux attend toujours son correctif sur Ubuntu pour une faille TCP critique, Django publie six correctifs, Wagtail 8.1 abandonne Python 3.10 et Claude Code ajoute un garde-fou contre les écritures hors du répertoire de travail. Voici cinq changements à connaître, avec ce qu’ils impliquent en pratique.
WordPress (CVE-2026-119977) : la faille de la mise à jour est désormais exploitée
Corrigée la semaine dernière par WordPress 7.1.4, la faille est désormais exploitée. L’avis publié le 29 octobre sur le dépôt wordpress-develop décrit CVE-2026-119977 comme une race condition pendant les mises à jour du cœur : un attaquant non authentifié qui « gagne la course » contre l’extraction de l’archive peut obtenir une exécution de code à distance. Les versions 4.7.0 à 7.1.3 sont concernées ; le correctif figure dans 7.1.4 et a été rétroporté sur chaque branche jusqu’à 4.7.39. Le projet la classe pourtant en sévérité faible.
Le 3 novembre, la CISA américaine a inscrit précisément CVE-2026-119977 dans son catalogue des vulnérabilités exploitées (KEV), ce que confirme également le Centre canadien pour la cybersécurité. Cette inscription signale des exploitations observées, sans indiquer que tous les sites WordPress sont compromis. Le score CVSS 3.1 de 8,1 publié dans les bases de vulnérabilités ne doit pas être confondu avec l’appréciation de sévérité mentionnée dans l’avis du projet.
Pourquoi c’est important
Le signal n’est pas « tous les WordPress sont compromis ». La fenêtre d’attaque n’existe que pendant une mise à jour complète du cœur à partir d’une version vulnérable ; un site déjà en 7.1.4, ou dans la version corrigée de sa branche, n’est plus exposé à cette faille. Vérifiez la version réellement servie avec wp core version sur chaque site, y compris les installations oubliées. Pour un site encore vulnérable, sauvegardez puis mettez à jour sans attendre. Sur les sites mis à jour récemment, relisez les journaux d’accès autour de l’opération et cherchez des fichiers PHP inattendus. Une faille classée faible reste une faille ; quand elle est exploitée, c’est le calendrier qui change.
Sources : avis de sécurité du projet WordPress du 29 octobre et alerte de la CISA du 3 novembre.
Noyau Linux (CVE-2026-98432) : Debian corrigé, Ubuntu encore en attente
Publiée le 15 octobre et notée 9,8 en CVSS 3.1, CVE-2026-98432 est un use-after-free dans la gestion des connexions TCP IPv4 du noyau : des options IP peuvent être libérées alors qu’elles sont encore utilisées, avec un risque d’exécution de code à distance selon Ubuntu, qui la classe en priorité « Critical ». Autrement dit, la surface d’attaque est un port TCP ouvert en IPv4, pas une application.
Côté Debian, le suivi de sécurité indique bookworm corrigé par DLA-4841-1 (6.1.190-1) et trixie par DSA-6568-1. Côté Ubuntu, la page de la CVE, mise à jour le 5 novembre, liste toujours 22.04, 24.04, 26.04 et 26.10 comme vulnérables, avec des noyaux corrigés « en cours » (par exemple 6.8.0-149.149 pour 24.04) mais pas encore publiés.
Pourquoi c’est important
Sur Debian, appliquez les mises à jour, puis redémarrez : c’est uname -r qui doit afficher le nouveau noyau, pas seulement apt. Sur Ubuntu, rien n’est encore à installer : surveillez la page de la CVE et planifiez la fenêtre de redémarrage. Cette page reproduit une règle nftables, proposée par un contributeur externe, qui bloque les paquets TCP IPv4 porteurs d’options IP ; elle réduit le risque sans l’éliminer. Si vous l’appliquez, testez-la d’abord et gardez un accès console de secours. Les conteneurs partagent le noyau de l’hôte : reconstruire une image ne change rien ici. Un noyau installé n’est pas un noyau actif ; un noyau « en cours » n’est pas encore un noyau installé.
Sources : page de sécurité Ubuntu consacrée à CVE-2026-98432, mise à jour le 5 novembre et suivi de sécurité Debian pour CVE-2026-98432.
Django 6.1.3, 6.0.10 et 5.2.19 : six correctifs, surtout pour GeoDjango
Le 3 novembre, l’équipe de Django a publié 6.1.3, 6.0.10 et 5.2.19, qui corrigent six vulnérabilités. La seule de sévérité modérée, CVE-2026-111362, concerne GeoDjango : le membre crs d’une géométrie GeoJSON pouvait amener GDAL à effectuer des requêtes réseau ou à lire des fichiers avec les droits du processus Django. CVE-2026-114582, de sévérité faible, relève du même mécanisme avec SpatialReference ; la protection complète exige GDAL 3.9 ou plus récent, et un nouveau contrôle système gis.W001 avertit quand GDAL est plus ancien.
Les autres correctifs, de sévérité faible, touchent le MultiPartParser (fichiers encodés en base64 gardés entièrement en mémoire), le cache (un en-tête Vary absent et un en-tête vide produisaient la même clé), l’admin (hash du mot de passe visible pour un utilisateur en lecture seule avec certains modèles utilisateur personnalisés) et la journalisation de GeometryField.
Pourquoi c’est important
Si vous n’utilisez pas django.contrib.gis, l’urgence baisse nettement, mais la mise à jour reste la bonne décision. Vérifiez la version avec python -m pip show django, mettez à jour dans la branche que vous suivez, lancez vos tests et python manage.py check, puis redéployez. Sur un projet GeoDjango, contrôlez aussi la version de GDAL de l’image ou du serveur avec gdalinfo --version : Django seul ne suffit pas. Une dépendance système vieillissante peut neutraliser un correctif applicatif.
Source : annonce de sécurité officielle de Django du 3 novembre.
Wagtail 8.1 : Python 3.11 minimum et des redirections automatiques plus limitées
Wagtail 8.1 est sorti le 2 novembre. Trois changements comptent plus que les nouveautés. La prise en charge de Python 3.10 est abandonnée : il faut Python 3.11 ou plus récent avant de mettre à jour. Les redirections ne sont plus créées automatiquement que pour les déplacements et renommages de pages publiées ; WAGTAILREDIRECTS_AUTO_CREATE = 'always' rétablit l’ancien comportement. Enfin, l’API interne /admin/api/main/ est remplacée par un unique point d’accès d’exploration, et le hook construct_admin_api disparaît.
Côté nouveautés, la version ajoute la prise en charge de Python 3.15, la possibilité de servir plusieurs représentations d’une même URL selon l’en-tête Accept, des améliorations de l’API v3, un prototype de CLI et des agent skills officielles.
Pourquoi c’est important
Rien n’impose de migrer cette semaine ; la documentation montre d’ailleurs une version 7.4.5 de la branche LTS en préparation. Commencez par vérifier la version de Python de vos images et environnements avec python --version. Cherchez ensuite dans votre code et vos personnalisations de l’admin toute dépendance à /admin/api/main/ ou à construct_admin_api, puis testez sur une copie le comportement des redirections et le taux de succès de votre cache. Une version mineure peut contenir des changements majeurs pour ceux qui ont personnalisé l’admin.
Source : notes de version officielles de Wagtail 8.1.
Claude Code 2.1.314 et 2.1.316 : bloquer les écritures hors du projet, préparer la fin du fast mode
Le 30 octobre, Anthropic a publié Claude Code 2.1.314, qui ajoute le réglage permissions.blockWritesOutsideWorkingDirectories : les outils Write, Edit et NotebookEdit refusent alors toute écriture hors des répertoires de travail, quel que soit le mode de permission. Cette version corrige aussi un bac à sable inactif dans un worktree repris avec claude -p --resume. La 2.1.316, du 31 octobre, corrige des sessions --restricted qui pouvaient envoyer des fichiers hors des répertoires de travail, et annonce la dépréciation du fast mode pour Opus 4.8 : il sera retiré le 30 novembre, et ces requêtes renverront alors une erreur au lieu de basculer vers le mode standard.
Pourquoi c’est important
Le nouveau réglage est un garde-fou simple si vous laissez l’agent travailler en mode automatique : mettez à jour, contrôlez claude --version, activez-le, puis vérifiez qu’une écriture hors du dépôt est bien refusée. Les commandes shell, elles, restent du ressort du bac à sable. Si vos scripts ou intégrations utilisent le fast mode sur Opus 4.8, repérez-les maintenant ; la migration proposée passe par un autre modèle, dont le coût et le comportement sont à vérifier sur vos tâches. Le journal reste une publication d’Anthropic sur son propre outil. Un agent n’est pas plus sûr parce qu’il est à jour ; il l’est quand ses limites sont configurées.
Sources : notes de version officielles de Claude Code 2.1.314 et notes de version officielles de Claude Code 2.1.316.
En production, commencez par vérifier que tous vos sites WordPress tournent en version corrigée, puis installez et activez le noyau corrigé sur Debian ; sur Ubuntu, préparez la fenêtre de redémarrage en attendant les paquets. Mettez ensuite à jour Django, en priorité sur les projets GeoDjango. Wagtail 8.1 et les réglages de Claude Code peuvent attendre un test au calme ; gardez aussi en tête la dernière version mineure de PostgreSQL 14, le 12 novembre. Le fil conducteur de la semaine est le statut qui change : une faille « faible » devient exploitée, un correctif « en cours » n’est pas encore disponible ; ce qui compte est l’état vérifié chez vous, pas l’étiquette.
Laisser un commentaire