CVE-2026-114136

Django REST framework to zestaw narzędzi do budowania API sieciowych. Przed wersją 3.18.2 funkcja DefaultContentNegotiation.get_accept_list w rest_framework/negotiation.py akceptuje nieograniczoną liczbę i łączny rozmiar tokenów Accept, podczas gdy select_renderer w tym pliku wielokrotnie wywołuje parsowanie _MediaType z rest_framework/utils/mediatypes.py dla każdego tokenu kontrolowanego przez atakującego, każdego renderera i wymuszonej renegocjacji 406. Zdalny nieuwierzytelniony klient może wysłać wiele odrębnych typów mediów zawierających duże wartości parametrów w cudzysłowach z licznymi średnikami, powodując nieproporcjonalne zużycie CPU przez parser parametrów Django i powtarzalną strukturę parsowania DRF. Żądania do dowolnego osiągalnego endpointu mogą blokować synchroniczne workery na dłuższy czas, a równoczesne żądania mogą spowodować niedostępność usługi do momentu zaprzestania żądań. Problem naprawiono w wersji 3.18.2.

W Django REST framework od wersji 3.12.0 do 3.18.2 metoda TokenProxy.delete() używa identyfikatora użytkownika jako klucza głównego, podczas gdy rzeczywiste wiersze identyfikuje ciąg tokena, przez co Django wykonuje zapytanie usuwające, które nie pasuje do żadnego wiersza i zgłasza zero usunięć bez błędu. Aplikacje lub skrypty unieważniające poświadczenia przez TokenProxy mogą sądzić, że token został unieważniony, podczas gdy pozostaje on aktywny i nadal uwierzytelnia, a tokeny DRF nie wygasają automatycznie.

Django REST framework przed wersją 3.17.2 ma podatność w AdminRenderer.render(), która używa override_method() do symulacji GET i bezpośrednio wywołuje view.get() bez view.check_permissions() podczas renderowania nieprawidłowego żądania zapisu, co pozwala odpowiedzi HTML 400 Bad Request ujawnić dane z reprezentacji GET, do której żądający nie ma uprawnień.

Django REST framework przed wersją 3.17.2 ma podatność w parsowaniu request.data w rest_framework/request.py Request._parse(), która przekazuje strumień HttpRequest do JSONParser i FormParser dla ciał application/json i application/x-www-form-urlencoded, omijając ochronę DATA_UPLOAD_MAX_MEMORY_SIZE Django i pozwalając na nadmiernie duże ciała żądań zużywające dodatkową pamięć i CPU. Problem naprawiono w wersji 3.17.2.