GHSA-2m8g-3cmr-wg3w

## Summary While investigating Django REST Framework's request parsing behavior, I identified that DRF's high-level `request.data` parsing appears to bypass Django's configured `DATA_UPLOAD_MAX_MEMORY_SIZE` protection for `application/json` and `application/x-www-form-urlencoded` request bodies. In the tested configurations, Django correctly raises `RequestDataTooBig` when applications access `request.body` or Django's native `request.POST`, but DRF successfully parses the same oversized payloads through `request.data`. This behavior appears to occur because DRF passes the underlying `HttpRequest` object directly to parsers, which consume the request stream through Django's lower-level streaming interface rather than the guarded `request.body` path. I am reporting this privately because I am unsure whether this behavior is considered part of DRF's intended security boundary, but it appears to bypass a documented Django request-size protection for common DRF request parsing paths and may have availability implications. # What I Verified I verified the behavior locally using the following combinations: * Django **6.0.7** + DRF **3.17.1** → **Affected** * Django **6.0.7** + DRF **current upstream main** → **Affected** For both versions, the observed behavior was: ``` Django request.body → RequestDataTooBig Django request.POST (application/x-www-form-urlencoded) → RequestDataTooBig Django request.read() → Reads the entire oversized request body DRF request.data → Successfully parses oversized JSON and urlencoded request bodies ``` I also confirmed that: * `multipart/form-data` remains protected because DRF delegates multipart parsing to Django's multipart parser. * The behavior reproduces on both direct WSGI and ASGI servers without a reverse proxy or external request-size middleware. # Technical Details The relevant execution flow is: ``` APIView ↓ rest_framework.request.Request ↓ request.data ↓ Request._load_data_and_files() ↓ Request._parse() ↓ Request._load_stream() ↓ self._stream = self._request ↓ JSONParser.parse(...) or FormParser.parse(...) ↓ stream.read() / json.load(...) ``` The important implementation detail is that DRF assigns the original Django `HttpRequest` object as the parser stream. Unlike `request.body` and Django's native form parsing, consuming the stream through `HttpRequest.read()` does not trigger Django's `RequestDataTooBig` protection. As a result, DRF's built-in parsers successfully consume oversized request bodies that Django itself would reject through its higher-level request interfaces. # Reproduction Steps ## Environment Python 3.13 Django 6.0.7 Django REST Framework 3.17.1 (also reproduced on current upstream main) Configure: ```python DATA_UPLOAD_MAX_MEMORY_SIZE = 10 ``` Create a simple DRF API view: ```python from rest_framework.views import APIView from rest_framework.response import Response class DemoView(APIView): def post(self, request): return Response(request.data) ``` Start the application. Send an oversized JSON request: ``` POST /demo Content-Type: application/json Content-Length: >10 bytes ``` Example: ```json { "value": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..." } ``` Observed: ``` HTTP 200 JSON successfully parsed ``` Now compare against: ```python request.body ``` Observed: ``` RequestDataTooBig ``` Likewise, compare against: ```python request.POST ``` using ``` application/x-www-form-urlencoded ``` Observed: ``` RequestDataTooBig ``` This demonstrates different enforcement depending on which request API is used. # Root Cause Django documents `HttpRequest.read()` as a streaming interface. DRF exposes `request.data` as the primary high-level request parsing API. Currently, DRF forwards the raw Django request stream directly to parsers before any request-size validation equivalent to Django's `request.body` path occurs. Consequently: * JSONParser * FormParser fully consume oversized request bodies despite Django's configured request-size limit. # Security Impact This does **not** appear to introduce: * Authentication bypass * Authorization bypass * Remote code execution * Information disclosure * Integrity compromise However, it may reduce the effectiveness of deployments relying on Django's `DATA_UPLOAD_MAX_MEMORY_SIZE` to limit request-body resource consumption. Potential consequences include: * Additional memory allocation during JSON parsing * Additional CPU usage while decoding large JSON payloads * Increased resource consumption when handling oversized request bodies * Reduced effectiveness of Django's configured request-size protection for DRF endpoints using `request.data` The practical impact depends on deployment configuration, including: * upstream request-size limits * reverse proxy configuration * authentication * rate limiting * endpoint exposure # Memory Observations During local testing I observed successful parsing of oversized request bodies despite the configured limit. Representative measurements showed significantly increased memory allocation while parsing large JSON and urlencoded payloads. I intentionally did **not** perform destructive concurrency testing or attempt to exhaust system resources. # Scope Confirmed affected: * application/json * application/x-www-form-urlencoded Confirmed not affected: * multipart/form-data # Suggested Fix Direction One possible approach would be for DRF to enforce Django's configured `DATA_UPLOAD_MAX_MEMORY_SIZE` before handing the raw request stream to parsers that fully materialize request bodies in memory. This would preserve Django's configured request-size protection for the common `request.data` API without requiring broader changes to Django's documented streaming interface. # Versions Tested Affected: * Django 6.0.7 + DRF 3.17.1 * Django 6.0.7 + DRF current upstream main I did not perform a complete historical version bisect. # Disclosure I have not publicly disclosed this behavior. I am submitting it privately in accordance with the project's security policy because I am unsure whether maintainers consider this part of DRF's intended security boundary. # Note: **Thank you for taking the time to review this report.** If you determine that this behavior should be addressed, I would be happy to help investigate further, develop a fix, add regression tests, and submit a patch if you'd find that helpful. I have experience as a **Python/Django software engineer, security researcher, and open-source contributor**, and I'd be glad to contribute if you think that would be useful.