Une mise à jour de sécurité Django, une nouvelle version de Docker Engine et un changement discret dans les outils d’administration d’Ubuntu : cette semaine, les sujets les plus utiles ne sont pas forcément les plus spectaculaires. Plusieurs concernent directement la maintenance d’une application ou d’un VPS. Voici six changements à connaître, avec ce qu’ils impliquent en pratique.
Django : quatre failles corrigées dans les branches maintenues
Le 6 octobre, l’équipe de Django a publié 6.1.2, 6.0.9 et 5.2.18. Ces versions corrigent quatre vulnérabilités, dont certaines sont exploitables par des requêtes HTTP sans authentification. Ce n’est donc pas une mise à jour à reporter simplement parce que votre application « fonctionne ».
La première faille pouvait faire grossir un cache mémoire en lui fournissant des codes de langue excessivement longs. Une autre concernait le traitement de certains en-têtes HTTP, notamment Accept et Content-Type : des valeurs spécialement construites pouvaient provoquer un travail disproportionné du serveur. Dans les deux cas, l’effet recherché est le déni de service, autrement dit rendre l’application lente ou indisponible.
Les deux autres cas sont plus ciblés. GeoDjango pouvait effectuer une requête réseau involontaire en traitant certains rasters fournis sous forme d’octets non fiables. Enfin, certains model formsets avec clé primaire modifiable pouvaient accepter des données POST falsifiées permettant de sortir du périmètre normalement autorisé. Les modèles utilisant la clé primaire BigAutoField par défaut ne sont pas concernés par ce dernier problème.
Pourquoi c’est important
Sur une application exposée à Internet, commencez par identifier la branche Django réellement déployée et mettre à jour vers la version corrective correspondante. Faites ensuite tourner les tests et vérifiez les formulaires concernés. Si vous utilisez GeoDjango, notez un changement de compatibilité : les octets de raster doivent désormais être explicitement encapsulés dans GDALRaster. Testez cette compatibilité en préproduction avant déploiement.
Source : annonce de sécurité officielle de Django du 6 octobre.
Docker Engine 29.9.0 : corriger aussi les composants sous le capot
Docker Engine 29.9.0 est sorti le 8 octobre, peu après les correctifs de la série 29.8. Cette fois, plusieurs corrections de sécurité arrivent par une mise à jour du runtime Go et de bibliothèques réseau utilisées par Docker.
Quatre vulnérabilités touchent le traitement de connexions HTTP/2 : selon le scénario, un client peut provoquer une consommation excessive de mémoire ou de processeur, voire faire tomber le démon. Une autre correction concerne Windows et la manipulation de répertoires dans l’espace de données Docker. L’actualisation de golang.org/x/net applique aussi les protections HTTP/2 aux composants gRPC concernés, notamment dans BuildKit.
Cette version règle également plusieurs soucis de réseau, en particulier autour des réseaux overlay et de Swarm. Les systèmes qui utilisent le mode rootless bénéficient d’une correction d’une fuite de connexions vers RootlessKit.
Pourquoi c’est important
Le démon Docker est une brique d’infrastructure, pas seulement un outil pour lancer des conteneurs. Si vous gérez vos applications avec Compose, vérifiez la version effectivement installée avec docker version, lisez les notes relatives à votre distribution et planifiez la mise à jour du moteur. Elle peut nécessiter un redémarrage du service et doit tenir compte de vos conteneurs en production. Gardez aussi l’API Docker à l’écart d’Internet : ce correctif ne remplace ni l’isolation du socket ni une configuration réseau prudente.
Source : notes de version officielles de Docker Engine 29.9.0.
Ubuntu 26.04 : vérifier vos règles sudo avant une migration de serveur
La documentation serveur d’Ubuntu a été actualisée le 1er octobre pour détailler un changement déjà introduit avec Ubuntu 25.10 et présent dans 26.04 : l’implémentation historique de sudo laisse par défaut la place à sudo-rs, écrite en Rust.
Le nom de la commande ne change pas, mais son comportement n’est pas parfaitement identique. Certains réglages de sudoers ou certaines options ne sont pas pris en charge de la même manière. Le message demandant le mot de passe diffère également ; un script qui attend un texte précis avec expect peut donc rester bloqué. La documentation signale aussi l’absence de sudoreplay et de certaines fonctions d’enregistrement des sessions.
Un administrateur a signalé la perte d’accès sudo après migration : l’ancienne directive Defaults !authenticate n’était plus acceptée. C’est un cas isolé, pas une panne générale.
Pourquoi c’est important
Quand on administre seul un VPS à distance, perdre sudo peut être plus gênant qu’un service applicatif en panne. Avant de passer de 24.04 à 26.04, faites une copie de vos règles, confrontez-les à man sudoers-rs et testez-les sur une machine de préproduction. Conservez un accès de secours à la console de l’hébergeur. Le bon moment pour découvrir une incompatibilité n’est pas après avoir fermé la dernière session administrateur.
Source : documentation officielle Ubuntu Server sur sudo-rs.
WordPress : des correctifs rétroportés ne prolongent pas le support d’une vieille branche
Le 6 octobre, WordPress a publié notamment 5.3.26, une mise à jour de sécurité destinée à une ancienne branche. Sa page de version mentionne plusieurs problèmes traités : du JavaScript injecté dans l’administration des commentaires, une possibilité de déni de service dans WP_Http::make_absolute_url() et des failles de permissions ou de divulgation liées à certaines publications et commentaires.
La présence d’un correctif sur une série aussi ancienne peut donner une fausse impression de sécurité durable. L’équipe WordPress précise pourtant que seule la version la plus récente bénéficie d’un support actif. Les correctifs proposés sur d’anciennes branches le sont à titre de courtoisie et ne constituent pas une promesse de maintenance complète.
Pourquoi c’est important
Si un site reste figé sur une vieille version à cause d’un thème ou d’un plugin, appliquer son correctif de sécurité est utile, mais ce n’est pas un plan de maintenance. Vérifiez la version du cœur, l’état des extensions et les sauvegardes, puis préparez une montée de version sur une copie du site. Une incompatibilité de thème est un problème à résoudre ; elle ne devrait pas décider indéfiniment du niveau de sécurité du serveur.
Source : documentation officielle WordPress 5.3.26.
Wagtail publie des « agent skills » pour mieux guider les assistants de développement
Le 8 octobre, l’équipe de Wagtail a présenté des agent skills, c’est-à-dire de petits fichiers d’instructions que les assistants de programmation peuvent charger pour travailler avec les conventions du CMS. Le projet distingue notamment les besoins liés aux modèles, au développement backend, aux templates, à l’API et aux mises à niveau.
L’idée est d’éviter deux écueils fréquents : un assistant qui invente une API et un contexte permanent tellement volumineux qu’il devient contre-productif. Wagtail recommande une compétence d’entrée générale, capable de renvoyer vers des consignes plus spécialisées et vers la documentation actualisée. Elle peut s’installer localement dans .agents/skills/wagtail/ via le nouvel outil en ligne de commande wt.
Pourquoi c’est important
Dans un projet Wagtail, cette approche peut rendre un agent plus pertinent sans multiplier les prompts. La limite reste la même que pour tout code généré : les migrations, les permissions et le rendu des pages doivent être relus et testés. Une skill oriente l’assistant ; elle ne certifie pas la justesse de son travail.
Source : présentation officielle des agent skills Wagtail.
Python 3.15 : une troisième release candidate au lieu de la version finale
Python 3.15 devait arriver en version finale début octobre. Le 2 octobre, les mainteneurs ont finalement publié une troisième release candidate, 3.15.0rc3, afin de corriger et de retester des blocages de dernière minute liés aux lazy imports. Cette optimisation permet de différer certains imports de modules jusqu’au moment où ils deviennent nécessaires, avec des conséquences possibles sur l’ordre d’exécution de l’application.
La RC3 regroupe environ 156 corrections et améliorations depuis la précédente candidate. La version finale était annoncée pour le 9 octobre ; au moment de préparer cette édition, sa publication n’était pas encore confirmée sur la page officielle consultée.
Pourquoi c’est important
Le signal pour une application Django n’est pas « mettez Python 3.15 en production aujourd’hui ». C’est plutôt le moment de vérifier si vos bibliothèques, vos dépendances natives et vos images de conteneurs sont prêtes. Un test sur une branche ou un environnement isolé permet d’identifier les paquets sans roue binaire compatible, les changements de comportement et les tests qui échouent. Les mainteneurs indiquent qu’aucun changement d’ABI n’est attendu à ce stade, ce qui facilite la préparation des extensions natives ; cela ne garantit pas pour autant la compatibilité de toutes les bibliothèques.
Source : annonce officielle Python 3.15.0rc3.
Pour les applications et serveurs déjà en production, les deux opérations les plus pressantes sont les correctifs Django et l’examen de la mise à jour Docker. Les changements Ubuntu et WordPress demandent davantage de préparation si vous dépendez d’anciennes configurations ; les nouveautés Wagtail et Python méritent d’abord un essai dans un environnement de développement. Dans tous les cas, une version annoncée et une version effectivement déployée sont deux choses différentes : la première étape reste de vérifier ce qui tourne réellement chez vous.
Laisser un commentaire