CVE-2026-114136

### Summary An unauthenticated attacker can defeat Django's `DATA_UPLOAD_MAX_MEMORY_SIZE` limit and force a worker process to allocate arbitrary memory, by naming a compression codec in the Content-Type charset parameter. A 108-byte request body produces a 50,331,648-character value inside the view, an amplification factor of 466,033, and grows process peak RSS by about 97 MiB. No application configuration is required beyond DRF's default parser set; the endpoint only has to accept a JSON body. ### Details `JSONParser.parse` decodes the request body with the charset the client supplied on the Content-Type header: ```python # rest_framework/parsers.py encoding = parser_context.get('encoding', settings.DEFAULT_CHARSET) try: decoded_stream = codecs.getreader(encoding)(stream) parse_constant = json.strict_constant if self.strict else None return json.load(decoded_stream, parse_constant=parse_constant) except ValueError as exc: raise ParseError('JSON parse error - %s' % str(exc)) ``` Of the roughly 455 codec names `codecs.lookup` resolves on CPython 3.14, about 18 are byte transforms instead of character sets: `bz2_codec`, `zlib_codec`, `base64_codec`, `hex_codec`, `quopri_codec`, `uu_codec` and similar. `codecs.getreader` is the only entry point in the `codecs` module that does not consult `CodecInfo._is_text_encoding`, so it accepts all of them. Sending `Content-Type: application/json; charset=bz2_codec` wraps the request stream in a bz2 decompressor before `json.load` reads it. The ordering is what makes this exploitable. Django charges `DATA_UPLOAD_MAX_MEMORY_SIZE` against the bytes that arrived on the wire: `rest_framework/request.py` hands `JSONParser` an `io.BytesIO(self.body)`, and `HttpRequest.body` is where `_check_data_too_big()` runs. Decompression happens afterwards, inside the parser, where nothing is counting. This is DRF's defect and not Django's. Django resolves the charset parameter and assigns `request.encoding`, and `codecs.look