Podatności Django

W Django 6.1 przed 6.1.2, 6.0 przed 6.0.9 i 5.2 przed 5.2.18, funkcja django.forms.models.BaseModelFormSet.save_existing_objects() używa obecności klucza głównego na instancji formularza jako dowodu przynależności do queryset. Obiekt spoza queryset może zostać usunięty przez uwierzytelnionego użytkownika bez uprawnień do tego obiektu, poprzez sfałszowane dane formularza. Modele z domyślnym AutoField nie są dotknięte.

W Django 6.1 przed 6.1.2, 6.0 przed 6.0.9 i 5.2 przed 5.2.18, niekompletna poprawka dla CVE-2026-15307 w przestrzennych zapytaniach (spatial lookups) pozwala atakującemu, który może dostarczyć wartości bytes, na spowodowanie, że proces Django wykona żądania sieciowe poprzez spreparowany dokument VRT odwołujący się do zewnętrznego źródła rastrowego.

W Django 6.1 przed 6.1.2, 6.0 przed 6.0.9 i 5.2 przed 5.2.18, funkcja django.utils.http.parse_header_parameters() jest podatna na atak DoS z powodu kwadratowej złożoności czasowej podczas parsowania wartości z wieloma separatorami w cytowanym parametrze. Nieuwierzytelnione żądanie może dotrzeć do tego parsowania przez nagłówki takie jak Accept lub Content-Type.

W Django 6.1 przed 6.1.2, 6.0 przed 6.0.9 i 5.2 przed 5.2.18, funkcja django.utils.translation.get_supported_language_variant() jest podatna na atak DoS podczas przetwarzania wielu różnych, bardzo długich kodów językowych, które są przechowywane jako klucze w pamięci podręcznej i zużywają pamięć procesu.

Django w wersjach przed 1.8.16, 1.9.11 i 1.10.3, gdy ustawienie DEBUG jest włączone, umożliwia zdalnym atakującym przeprowadzenie ataków DNS rebinding z powodu braku walidacji nagłówka HTTP Host względem ustawienia ALLOWED_HOSTS.

Kod parsowania ciasteczek w Django przed wersją 1.8.15 oraz 1.9.x przed wersją 1.9.10, używany na stronie z Google Analytics, pozwala zdalnym atakującym na obejście zamierzonego mechanizmu ochrony CSRF poprzez ustawienie dowolnych ciasteczek.

Funkcja utils.http.is_safe_url w Django przed wersją 1.8.10 oraz 1.9.x przed wersją 1.9.3 umożliwia zdalnym atakującym przekierowywanie użytkowników na dowolne strony internetowe. Może to prowadzić do ataków phishingowych lub potencjalnie do ataków typu cross-site scripting (XSS) za pomocą URL zawierającego podstawową autoryzację.

Wersje Django przed 1.4.21, 1.5.x do 1.6.x, 1.7.x przed 1.7.9 oraz 1.8.x przed 1.8.3 są podatne na atak typu denial of service. Atakujący mogą wykorzystać unikalne klucze sesji do zapełnienia pamięci przechowującej sesje.

W wersjach Django przed 1.4.11, 1.5.x przed 1.5.6, 1.6.x przed 1.6.3 oraz 1.7.x przed 1.7 beta 2 klasy pól modelu FilePathField, GenericIPAddressField i IPAddressField nie wykonują prawidłowej konwersji typów. To może umożliwić zdalnym atakującym wywołanie nieokreślonego wpływu związane z 'typowaniem MySQL'.

W Django 6.0 przed 6.0.2, 5.2 przed 5.2.11 oraz 4.2 przed 4.2.28 odkryto podatność na iniekcję SQL w operacjach rasterowych na polu RasterField (dostępnym tylko z PostGIS). Atakujący zdalnie może wstrzyknąć kod SQL poprzez parametr indeksu pasma (band index).

Django w wersjach 1.8.x przed 1.8.16, 1.9.x przed 1.9.11 oraz 1.10.x przed 1.10.3 używa twardo zakodowanego hasła dla tymczasowego użytkownika bazy danych, co ułatwia zdalnym atakującym uzyskanie dostępu do serwera bazy danych.

W Django 5.2 przed 5.2.17 i 6.0 przed 6.0.8 odkryto problem: funkcja django.contrib.admin.utils.display_for_field() renderuje wartości URLField jako klikalne linki w panelu administracyjnym bez walidacji URL. Wartość zapisana z niebezpiecznym schematem jest wyświetlana jako link na stronach changelist i tylko do odczytu, co umożliwia atak XSS na pracowników, którzy klikną link. Eksploatacja wymaga, aby niebezpieczna wartość była już zapisana w bazie danych. Walidacja URLField przez ModelForm lub panel administracyjny odrzuca niebezpieczne schematy, więc dotyczy to aplikacji, które zapisują dane URLField bez uruchamiania walidacji modelu, na przykład przez bezpośrednie zapisy queryset, deserializację lub masowy import niezaufanych danych.

W Django 6.0 przed 6.0.9 oraz 5.2 przed 5.2.18 wykryto podatność w GeoDjango. Komponent django.contrib.gis.geos.GEOSGeometry jest narażony na potencjalną odmowę usługi podczas przetwarzania głęboko zagnieżdżonych obiektów GEOMETRYCOLLECTION dostarczonych w formacie WKT, WKB lub hex-encoded WKB, co wywołuje nieograniczoną rekurencję i błąd segmentacji w bibliotece GEOS. Dotyczy to również wyszukiwań w polach przestrzennych oraz pola formularza django.contrib.gis.forms.GeometryField.

W Django 5.2 przed 5.2.17 i 6.0 przed 6.0.8 wykryto podatność na odmowę usługi w funkcji django.utils.translation.check_for_language(), która przy wielu różnych, bardzo długich kodach językowych może prowadzić do nadmiernego zużycia pamięci. Kody te mogą trafiać do funkcji przez widok django.views.i18n.set_language(), który nie jest domyślnie routowany. Zużycie pamięci jest ograniczone przez ustawienie DATA_UPLOAD_MAX_MEMORY_SIZE (domyślnie 2,5 MB) i stałą maksymalną liczbę wpisów w pamięci podręcznej.

W Django 5.2 przed 5.2.17 i 6.0 przed 6.0.8 odkryto problem w zapytaniach przestrzennych GeoDjango. Wartości po prawej stronie są optymistycznie parsowane jako raster przez konstruktor GDALRaster, co pozwala na zapis pliku o wybranej nazwie i zawartości lub wykonanie żądania sieciowego. Może to prowadzić do zdalnego wykonania kodu, jeśli plik zostanie zapisany w lokalizacji importowanej przez aplikację.

W Django 6.0 przed 6.0.7 i 5.2 przed 5.2.16 wykryto podatność w walidatorze `DomainNameValidator`, który nie blokuje znaków nowej linii w nazwach domen. Jeśli aplikacja używa takich wartości w odpowiedziach HTTP, może dojść do wstrzyknięcia nagłówków, choć samo Django jest chronione przez `HttpResponse`.

W Django 6.0 przed 6.0.7 i 5.2 przed 5.2.16 wykryto podatność w `django.contrib.gis.gdal.GDALRaster`. Podczas konstruowania obiektu z bajtów dochodzi do odczytu poza buforem pamięci, co może ujawnić sąsiednią pamięć lub spowodować degradację usługi przez błąd segmentacji przy dostępie do właściwości `vsi_buffer`.

W Django 6.0 przed 6.0.7 i 5.2 przed 5.2.16 wykryto podatność w `UpdateCacheMiddleware` i dekoratorze `cache_page()`. Mechanizmy te buforują odpowiedzi zależne od ciasteczek nawet wtedy, gdy żądanie przychodzące zawiera niezwiązane ciasteczka, co umożliwia zdalnemu atakującemu odczytanie prywatnych danych ze współdzielonej pamięci podręcznej.

W Django 5.2 przed 5.2.15 i 6.0 przed 6.0.6, `django.middleware.cache.UpdateCacheMiddleware` nie porównuje dyrektyw `Cache-Control` w odpowiedziach w sposób niewrażliwy na wielkość liter. Zdalny atakujący może odczytać odpowiedzi, które zostały nieprawidłowo zapisane w pamięci podręcznej, ponieważ ich dyrektywy `Cache-Control` używały wielkich lub mieszanych liter.

W Django (wersje 6.0 przed 6.0.6 i 5.2 przed 5.2.15) `EmailBackend` nie zapobiega ponownemu użyciu częściowo zainicjowanego połączenia po nieudanym uzgadnianiu STARTTLS, gdy `fail_silently=True`. Pozwala to atakującym w sieci na odczyt treści e-maili w postaci czystego tekstu.

Podatność w Django (wersje 6.0 przed 6.0.6 i 5.2 przed 5.2.15) w funkcji `get_signed_cookie` powoduje, że atakujący może użyć podpisanego ciasteczka w innym kontekście niż zamierzony, poprzez manipulację nazwą ciasteczka i argumentem salt. Wynika to z nieiniektywnego wyprowadzania soli.

W Django 5.2 przed 5.2.15 i 6.0 przed 6.0.6, `django.utils.cache.has_vary_header()` nie usuwa białych znaków z początku i końca wartości nagłówka `Vary` przed porównaniem. Umożliwia to zdalnym atakującym odczytanie odpowiedzi z pamięci podręcznej poprzez żądania do URL-i, których odpowiedzi zawierają wartości nagłówka Vary z białymi znakami.

W Django 5.2 przed 5.2.15 i 6.0 przed 6.0.6, `django.middleware.cache.UpdateCacheMiddleware` nie dodaje nagłówka `Authorization` do nagłówka odpowiedzi `Vary` dla żądań z tym nagłówkiem bez `Cache-Control: public`. Umożliwia to zdalnym atakującym odczytanie prywatnych odpowiedzi z pamięci podręcznej poprzez nieuwierzytelnione żądania do tego samego URL-a.

W Django w wersjach 6.0 przed 6.0.5 oraz 5.2 przed 5.2.14 komponent django.middleware.cache.UpdateCacheMiddleware błędnie buforuje żądania, w których nagłówek Vary zawierał gwiazdkę ('*'), co może prowadzić do przechowywania i serwowania prywatnych danych.

W Django w wersjach 6.0 przed 6.0.5 oraz 5.2 przed 5.2.14 żądania ASGI z brakującym lub zaniżonym nagłówkiem Content-Length mogą ominąć limit FILE_UPLOAD_MAX_MEMORY_SIZE, co może prowadzić do ładowania dużych plików do pamięci i degradacji usługi.

W Django w wersjach 6.0 przed 6.0.5 oraz 5.2 przed 5.2.14 nagłówki odpowiedzi nie różnią się w zależności od ciasteczek, gdy sesja nie jest modyfikowana, ale ustawiono SESSION_SAVE_EVERY_REQUEST na True. Zdalny atakujący może ukraść sesję użytkownika po odwiedzeniu przez niego publicznej strony z pamięci podręcznej. Wcześniejsze, niewspierane serie (5.0.x, 4.1.x, 3.2.x) nie zostały ocenione i mogą być również podatne.

W Django w wersjach 6.0 przed 6.0.4, 5.2 przed 5.2.13 oraz 4.2 przed 4.2.30 wykryto problem, w którym formularze changelist w panelu administracyjnym używające ModelAdmin.list_editable nieprawidłowo pozwalały na tworzenie nowych instancji poprzez sfałszowane dane POST. Wcześniejsze, niewspierane serie Django (5.0.x, 4.1.x, 3.2.x) również mogą być podatne.

W Django w wersjach 6.0 przed 6.0.4, 5.2 przed 5.2.13 oraz 4.2 przed 4.2.30 komponent MultiPartParser pozwala zdalnym atakującym pogorszyć wydajność poprzez przesyłanie plików multipart z nagłówkiem Content-Transfer-Encoding: base64 zawierającym nadmiarowe białe znaki. Starsze, niewspierane serie Django również mogą być podatne.

W Django 6.0 przed 6.0.3, 5.2 przed 5.2.12 i 4.2 przed 4.2.29 funkcja `URLField.to_python()` wywołuje `urllib.parse.urlsplit()`, która na Windows wykonuje normalizację NFKC. Dla niektórych znaków Unicode jest ona nieproporcjonalnie wolna, co umożliwia zdalnemu atakującemu przeprowadzenie ataku typu odmowa usługi (DoS) poprzez przesłanie dużych URL-i zawierających te znaki.

W Django wykryto podatność na iniekcję SQL w metodzie `.QuerySet.order_by()`. Problem występuje, gdy alias kolumny zawiera kropkę i jest używany z `FilteredRelation` przy rozwijaniu słownika. Luka dotyczy wersji 6.0 przed 6.0.2, 5.2 przed 5.2.11 oraz 4.2 przed 4.2.28; starsze, niewspierane serie również mogą być podatne.

W Django 6.0 przed 6.0.2, 5.2 przed 5.2.11 oraz 4.2 przed 4.2.28 wykryto podatność na wstrzykiwanie SQL w aliasach kolumn w `FilteredRelation`. Atakujący może wykorzystać kontrolowane znaki w słowniku przekazanym jako `**kwargs` do metod `annotate()`, `aggregate()`, `extra()`, `values()`, `values_list()` i `alias()`.

W Django w wersjach 5.2 przed 5.2.9, 5.1 przed 5.1.15 i 4.2 przed 4.2.27 występuje złożoność algorytmiczna w django.core.serializers.xml_serializer.getInnerText(). Zdalny atakujący może wywołać atak odmowy usługi (DoS) poprzez wyczerpanie CPU i pamięci przy użyciu specjalnie spreparowanego wejścia XML przetwarzanego przez deserializator XML.

Podatność w Django polega na SQL Injection w aliasach kolumn za pomocą odpowiednio spreparowanego słownika z rozszerzeniem słownika jako **kwargs przekazanego do QuerySet.annotate() lub QuerySet.alias() na PostgreSQL. Dotyczy wersji 5.2 przed 5.2.9, 5.1 przed 5.1.15 i 4.2 przed 4.2.27.

W Django 4.2 przed 4.2.25, 5.1 przed 5.1.13 i 5.2 przed 5.2.7 wykryto problem w funkcji django.utils.archive.extract(), używanej przez komendy "startapp --template" i "startproject --template". Umożliwia ona częściowe przejście poza katalog (directory traversal) poprzez archiwum z plikami, których ścieżki mają wspólny prefiks z katalogiem docelowym.

W Django 4.2 przed 4.2.25, 5.1 przed 5.1.13 i 5.2 przed 5.2.7 odkryto problem. Metody QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate() i QuerySet.extra() są podatne na wstrzykiwanie SQL w aliasach kolumn, gdy używany jest odpowiednio spreparowany słownik z rozwinięciem słownika jako **kwargs przekazany do tych metod (na MySQL i MariaDB).