CVE-2026-114136 in Django REST Framework
Summary
by MITRE • 10/22/2026
Django REST framework is a toolkit for building Web APIs. From 3.6.4 until 3.18.2, JSONParser.parse in rest_framework/parsers.py uses the client-supplied Content-Type charset value with codecs.getreader, which accepts byte-transform codecs such as bz2_codec rather than only text encodings. A remote unauthenticated client can therefore cause a compressed JSON request body to be expanded after Django has enforced DATA_UPLOAD_MAX_MEMORY_SIZE against only the wire bytes, allowing a very small request to consume substantial per-worker memory. The default parser set is sufficient, and any reachable endpoint that accepts a JSON body is affected. This issue is fixed in version 3.18.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The Django REST framework serves as a powerful toolkit for building Web APIs within the Python ecosystem, facilitating the creation of stateful, request-driven web applications. A significant security vulnerability was identified in versions ranging from 3.6.4 through 3.18.2 concerning the JSONParser component located in rest_framework/parsers.py. This flaw stems from an improper handling of character set declarations provided by clients during HTTP requests. Specifically, when parsing incoming JSON data, the framework utilizes Python's codecs.getreader function to decode byte streams into text based on the Content-Type header's charset parameter. The critical technical deficiency lies in the fact that this decoding mechanism is not restricted to standard text encodings such as UTF-8 or ASCII but instead accepts any codec registered with Python's codec registry, including binary-to-binary transformation codecs like bz2_codec.
This architectural oversight creates a severe resource exhaustion vector known as a decompression bomb attack. Because the framework applies the specified codec to transform the incoming byte stream before further processing, an attacker can craft a malicious HTTP request containing a highly compressed JSON payload with a Content-Type header specifying bzip2 compression. The server will then attempt to expand this small compressed file into its full uncompressed size in memory. Crucially, Django's built-in protection mechanism DATA_UPLOAD_MAX_MEMORY_SIZE is enforced against the raw wire bytes received from the network interface. Since the compressed payload can be extremely small while expanding into a massive amount of data upon decompression, the request bypasses these initial size checks. Consequently, a single remote unauthenticated client can trigger substantial memory consumption on the server side, potentially exhausting available RAM and causing denial of service conditions for all users relying on that worker process.
The operational impact of this vulnerability is profound as it affects any endpoint within an application that accepts JSON bodies using the default parser configuration. Since most modern APIs rely heavily on JSON for data exchange, a large portion of Django REST framework applications are susceptible to this attack without requiring specialized or custom parsers. The ability to cause high memory usage with minimal network bandwidth makes this vulnerability particularly dangerous in distributed environments where attackers can launch volumetric attacks from multiple sources simultaneously. This leads to service degradation, application crashes, and potential instability in production systems that do not have additional external rate limiting or WAF protections specifically tuned for decompression bombs.
To mitigate this risk, organizations must ensure they are running Django REST framework version 3.18.2 or later, where the JSONParser has been patched to restrict codec usage strictly to text encodings and reject binary transformation codecs like bz2_codec during parsing. For applications that cannot immediately upgrade due to compatibility constraints, implementing a Web Application Firewall rule to block requests with Content-Type headers indicating non-standard compression in conjunction with JSON content can provide temporary relief. Additionally, developers should consider enforcing stricter limits on request body sizes at the reverse proxy level before they reach Django and validating the integrity of incoming payloads against known decompression bomb patterns. This vulnerability is categorized under CWE-787: Out-of-bounds Write when considering memory corruption risks in broader contexts, but more accurately aligns with CWE-409: Improper Handling of Highly Compressed Data (Data Amplification) as defined by the Common Weakness Enumeration standard. In terms of offensive security tactics, this exploit maps to ATT&CK technique T1496: Resource Hijacking, where attackers leverage compromised or vulnerable systems for computational resources, although in this specific case it is primarily used for denial-of-service rather than cryptomining.