DRF's request.data walked past Django's memory limit; 3.17.2 closes it

Django's memory limit is not a gate at the edge of the request. It fires at the point a body is pulled into memory: request.body raises RequestDataTooBig once the configured limit is small enough, and request.POST enforces the same cap for urlencoded form data ^[5]. Read the stream directly and there is nothing to trip. The reporter's trace puts the bypass in one hop: request.data descends through _load_data_and_files, _parse and _load_stream, and _load_stream can supply the underlying Django HttpRequest as the object the parser consumes ^[8][9]. JSONParser and FormParser drain it, and the same oversized body that request.body rejected comes back parsed ^[6][11]. Django's request interfaces do not all check at the same place ^[10], and DRF took the one that does not check.

Two of the three built-in body types lost the protection this way ^[17]. The one that kept it, multipart, kept it because DRF hands multipart work back to Django's own parsing machinery rather than consuming the stream itself ^[12]. Delegation inherited the check. The reimplemented read did not.

How much of this reaches production is a narrower question than the version range suggests. Zain Nadeem, who reported the issue, is explicit that practical impact turns on reverse-proxy request limits, upstream server configuration, endpoint exposure, authentication requirements, rate limiting and other infrastructure-level request controls ^[15]. The deployments genuinely running unbounded are the ones that treated DATA_UPLOAD_MAX_MEMORY_SIZE as the body cap and put nothing in front of it. A minimal APIView whose post method returns Response(request.data) was enough to reproduce the behaviour ^[16], which is to say the vulnerable shape is the shape in the getting-started docs.

The severity number is consistent with that reading. Moderate, CVSS 3.1 score 5.3, filed under CWE-400 and CWE-770 ^[3], with the reporter ruling out remote code execution, information disclosure, privilege escalation, authentication bypass and integrity compromise ^[13]. What remains is memory and CPU spent during parsing on requests an operator believed were already refused ^[14], and that is the entire basis of the rating ^[19]. It is worth being clear where the account comes from: the reporter's own writeup, verified against Django 6.0.7, DRF 3.17.1 and DRF's then-current upstream main branch ^[4][7]. The behavioural difference between two request attributes on the same oversized payload is the kind of finding that reproduces in ten minutes on any box with a small limit configured, which is the part that does not need to be taken on trust.