Django : l'avis a une porte, les trois fiches n'ont pas la même suite

L'avis est punaisé sur une seule porte, et il vaut pour trois ateliers. 6.1.2, 6.0.9, 5.2.18. Quatre numéros de dossier, plus un renforcement qui dit lui-même qu'il n'ouvre pas de nouveau numéro. Tu pousses la porte de chaque atelier. Les quatre dossiers y sont. La feuille des travaux en plus, non. L'une a une boucle infinie écrite comme un problème de l'atelier d'à côté. L'atelier d'à côté n'a pas cette ligne. Si tu n'as lu que l'avis, tu as les dossiers. Tu n'as pas la suite.

Le 6 octobre 2026, Sarah Boyce publie sur le journal : des sorties de sécurité pour Django 6.1.2, Django 6.0.9 et Django 5.2.18. La phrase d'ouverture : ces sorties traitent les problèmes de sécurité détaillés plus bas. Tout le monde est encouragé à mettre à jour dès que possible.

Quatre dossiers, et un renforcement qui refuse un cinquième numéro

CVE-2026-77050, sévérité low. get_supported_language_variant() pouvait servir de déni de service avec beaucoup de codes de langue distincts, très longs, utilisés comme clés d'un cache en mémoire avant que leur longueur soit limitée. Les codes de plus de 500 caractères sont maintenant rejected or truncated avant la recherche en cache. « Rejetés ou tronqués. » Je ne choisis pas le verbe. Remerciement à Gleb Lizunov.

CVE-2026-84429, sévérité moderate. parse_header_parameters() avait un temps quadratique quand une valeur a beaucoup de séparateurs dans un paramètre entre guillemets. Une requête non authentifiée peut y arriver par des en-têtes comme Accept ou Content-Type, par exemple via HttpRequest.accepts(). La limite de longueur par appel ne borne pas la taille cumulée d'en-têtes répétés. La fonction, non documentée, passe par email.message.Message. Certaines valeurs mal formées ne se parsent plus pareil : un exemple donné, les valeurs RFC 2231 sans encodage sont maintenant décodées. Remerciement à Jisung Chae.

CVE-2026-87890, sévérité moderate. Les lookups spatiaux acceptaient un raster en bytes sans l'envelopper dans GDALRaster. Ouvert via le système de fichiers virtuel en mémoire de GDAL, ce contenu pouvait être un document VRT qui pointe une source externe, et GDAL pouvait alors faire des requêtes réseau sous l'utilisateur du processus Django. C'est passé à travers le correctif de CVE-2026-15307. Désormais, les bytes d'un raster doivent être enveloppés dans GDALRaster. Les bytes qui sont une géométrie hexadécimale valide restent acceptés. Le journal dit que c'est un changement incompatible. Remerciement à sicksec.

CVE-2026-87975, sévérité moderate. Des formsets de modèles laissaient un POST forgé supprimer des instances hors du queryset limite, ou en créer via des formsets edit-only, quand la clé primaire pouvait être posée par le formulaire : un OneToOneField, ou une clé naturelle, ou un UUID inclus dans les champs. Les modèles dont la clé est le BigAutoField par défaut ne sont pas concernés. Remerciement à Seonggwon Yoon.

Le suivi de CVE-2026-15830 est un cinquième bloc, pas un cinquième CVE. Le contournement : certaines géométries WKB laissaient des géométries profondément imbriquées atteindre GEOS. La phrase du journal : cette mise à jour n'introduit pas un nouveau CVE, elle renforce le correctif d'origine. Remerciements à blacknianthejdan, Kimi Security Team et David Sarkisyan.

Les versions supportées touchées, sur le journal : main, 6.1, 6.0, 5.2. Les sorties émises sont trois archives, pas une archive de main. La clé PGP de cette sortie : Sarah Boyce, 3955B19851EA96EF. La section résolution dit que des correctifs pour résoudre the issue, au singulier, ont été appliqués aux quatre branches. Les intertitres, juste au-dessus, sont cinq.

Le chapeau de 6.1 ne numérote pas le renforcement comme les deux autres

Les trois fiches sont datées du 6 octobre 2026. Leurs quatre blocs de CVE reprennent les mêmes mécanismes, les mêmes sévérités, la même phrase « rejected or truncated ». Les remerciements nominatifs, eux, sont sur le journal. Je ne les recolle pas sur les fiches.

Les chapeaux ne comptent pas pareil la suite. 6.1.2 : un problème low, trois moderate, un correctif pour une mitigation insuffisante dans 6.1. Puis une perte de données dans 4.0, une boucle infinie dans 5.2, et several bugs in 6.1.1. 6.0.9 : la mitigation insuffisante est dite dans 6.0.8, et la seule suite nommée au chapeau est la perte de données dans 4.0. 5.2.18 : la mitigation insuffisante est dite dans 5.2.17, et la même perte de données dans 4.0. Le chapeau de 6.1 dit « in 6.1 ». Les deux autres disent le numéro de correctif d'avant. Je ne réécris pas 6.1 en 6.1.1 pour que les trois chapeaux aient la même forme.

Onze puces d'un côté, deux de l'autre, et une boucle qui ne visite pas la 5.2

La section Bugfixes de 6.1.2 a 11 puces. La première : une classe de bogues dans Django 6.1 qui permettait de contourner le limiteur de profondeur des collections de géométries imbriquées, et le texte visible du lien est CVE 2026-15830, avec une espace entre CVE et le numéro. L'adresse du lien, elle, porte CVE-2026-15830, avec le trait d'union. Le journal titre Followup to CVE-2026-15830, trait d'union, et il dit que ce n'est pas un nouveau CVE. La puce ajoute que le nouvel algorithme traite WKB et WKT de façon plus cohérente, et qu'il répare un cas rare où une géométrie valide pouvait être refusée.

La deuxième puce : une perte de données dans Django 4.0, des rasters réseau supprimés par GeoDjango à la fermeture. La troisième : une boucle infinie dans Django 5.2, dans les lookups de tuples, l'exemple TupleIn, quand une expression F() est à gauche. Ticket #37291.

Les huit d'après disent Django 6.1, pas 6.1.1. Un srid=None invalide pouvait enregistrer NULL sans erreur, #37322. Le contrôle fields.W225 avertissait à tort que null n'a pas d'effet sur un GeneratedField, #37348. UUID4 gardait des majuscules sur Oracle, #37376. L'admin montrait encore des objets quand delete_confirmation_max_display vaut 0, #37386. FETCH_PEERS ne groupait pas les instances chargées par select_related(), #37344. Des permissions n'étaient pas renommées pour des RenameModel en chaîne, et des permissions au même nom de code sur d'autres modèles de la même application l'étaient, #37361. Un fil d'Ariane vide en trop sur l'index des modèles d'admindocs, #37378. Une expression Value sans champ de sortie JSONField explicite plantait, ou répondait de travers, dans un lookup in de premier niveau sur une base sans JSON natif, #37377.

Le chapeau dit « several bugs in 6.1.1 ». Les puces disent Django 6.1. J'ai compté huit puces dans ce cas, plus la puce de géométrie qui dit aussi Django 6.1. Je ne décide pas que « several » voulait dire huit, ni que 6.1.1 et 6.1 sont le même numéro sur cette page.

6.0.9 a 2 puces. La géométrie, dite dans Django 6.0.8, avec le même « CVE 2026-15830 » visible. La perte de données dans 4.0. 5.2.18 a 2 puces. La géométrie, dite dans Django 5.2.17. La même perte de données. Pas de #37291. Pas de boucle. La fiche 6.1.2 décrit une boucle dans Django 5.2. La fiche 5.2.18, lue le même jour, ne la nomme pas. Je ne conclus pas que le correctif est absent du code de 5.2.18. Je conclus que la page ne l'imprime pas.

Le journal ne parle ni de perte de données, ni de boucle, ni de tickets. Il s'arrête aux dossiers, au renforcement, et à la clé.

✍️ À toi : la fiche que tu as vraiment ouverte, journal, 6.1.2, 6.0.9 ou 5.2.18, et si la boucle y est. Elle est écrite sur la fiche 6.1 comme un problème de 5.2.

Le 6 octobre, Django annonce trois sorties pour quatre CVE et un renforcement qui ne prend pas de nouveau numéro. Les notes recopient les quatre mécanismes. Le chapeau de 6.1.2 place la mitigation insuffisante « in 6.1 », ajoute une boucle dans 5.2 et des bogues « in 6.1.1 », puis aligne 11 puces dont la boucle et huit lignes dites Django 6.1. Les notes de 6.0.9 et de 5.2.18 placent la mitigation dans 6.0.8 et 5.2.17, et elles s'arrêtent à deux puces, géométrie et perte de données. L'avis est sur une porte. La suite dépend de l'atelier.