CVE-2026-33033

What it actually does

This vulnerability affects Django's MultiPartParser when processing multipart/form-data uploads that include a Content-Transfer-Encoding: base64 part containing excessive whitespace. The parser can spend disproportionate CPU time and memory/processing resources decoding or normalizing the malformed upload body, allowing a remote attacker with the ability to submit multipart uploads to degrade application availability. The impact is availability-focused: it does not directly allow code execution, data theft, authentication bypass, or data modification, but it can tie up web workers, increase request latency, exhaust compute capacity, and trigger application-level denial of service.

Why it matters to the business

Public or user-facing Django applications that accept file uploads, form submissions, API multipart requests, or media attachments may become slow or unavailable if attackers send crafted multipart payloads. This can disrupt customer-facing services, internal workflows, payment or onboarding flows, and any operational process dependent on upload endpoints. The CVSS availability impact is high, but EPSS is currently low and there is no CISA KEV listing or known ransomware association, so organizations should prioritize remediation based on internet exposure, upload functionality, and business criticality rather than evidence of broad active exploitation.

How an attack unfolds

An attacker first identifies a Django application endpoint that accepts multipart/form-data requests, such as a file upload, profile image upload, document submission, support attachment, or multipart API endpoint. The attacker then sends authenticated or otherwise permitted POST requests containing multipart sections with the header Content-Transfer-Encoding: base64 and unusually large amounts of whitespace embedded in the encoded content. Vulnerable Django versions process the multipart body inefficiently, causing request handling to consume excessive CPU and worker time. By repeating these requests or sending them concurrently, the attacker can keep application workers occupied, increase response times, consume autoscaling capacity, and potentially make the service unavailable to legitimate users. No exploit code execution is required; the attack relies on malformed but protocol-valid HTTP multipart upload traffic.

How to fix it

Upgrade Django to a fixed supported release: Django 6.0.4 or later for the 6.0 series, Django 5.2.13 or later for the 5.2 series, and Django 4.2.30 or later for the 4.2 LTS series. Unsupported Django series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected; migrate unsupported installations to a supported fixed release rather than relying on backports. If immediate upgrade is not possible, reduce exposure by applying strict request body size limits, upload size limits, reverse-proxy timeouts, application worker timeouts, and rate limits on multipart upload endpoints. Consider blocking or rejecting multipart parts that include Content-Transfer-Encoding: base64 when not explicitly required by the application. Place upload endpoints behind authentication, bot protection, WAF rules, or per-user/IP throttling where feasible. Ensure autoscaling does not mask the issue while creating excessive cost exposure.

How to confirm the fix worked

Confirm the installed Django version is 6.0.4 or later, 5.2.13 or later, or 4.2.30 or later, depending on the deployed release branch. Validate dependency manifests, lockfiles, container images, virtual environments, and runtime package inventory because application images may contain older Django versions even after source updates. Exercise upload and multipart form endpoints after patching to confirm expected functionality remains intact. Review reverse proxy, load balancer, and application settings to ensure request size limits, body read timeouts, worker timeouts, and per-client rate limits are in effect. Where safe and authorized, test with a benign multipart request containing Content-Transfer-Encoding: base64 and whitespace-heavy content against a non-production environment to verify patched behavior and that resource consumption remains bounded.

Typical attack path

1. Identify a Django application or API endpoint that accepts multipart/form-data uploads or form submissions.
2. Confirm the endpoint accepts multipart POST requests and reaches Django's multipart request parsing logic.
3. Craft a multipart/form-data request containing a part with Content-Transfer-Encoding: base64.
4. Insert excessive whitespace into the base64-encoded multipart content to trigger inefficient parsing behavior.
5. Send one or more large or repeated crafted requests to the upload endpoint.
6. Scale concurrency or request volume to exhaust web workers, CPU, memory pressure, or upstream timeout budgets.
7. Observe degraded response times, request timeouts, worker saturation, or application unavailability.

How to detect it

Investigate whether the application received suspicious multipart upload traffic before remediation. Review reverse proxy, web server, WAF, CDN, load balancer, and application logs for POST requests to upload or form endpoints with multipart/form-data content types and the header Content-Transfer-Encoding: base64. Prioritize requests with unusually large request bodies, long upstream response times, request timeouts, repeated 4xx/5xx responses, high whitespace-heavy payload characteristics if body logging or WAF sampling is available, and repeated requests from the same IP, account, session, user agent, ASN, or geographic source. Correlate traffic spikes with infrastructure metrics such as CPU saturation, memory pressure, web worker exhaustion, queue backlog, autoscaling events, process restarts, and elevated 502/503/504 responses. In application telemetry, look for slow requests concentrated on multipart endpoints, request parsing time anomalies, or exceptions/timeouts occurring before view logic is reached. If full packet capture, WAF body samples, or HTTP request archives are available, search for multipart boundaries containing Content-Transfer-Encoding: base64 followed by very large amounts of spaces, tabs, CRLFs, or other whitespace interspersed in the encoded content. Because this is a denial-of-service issue, successful exploitation may leave no persistent host artifact; evidence is primarily in traffic, performance, and timeout logs.

• Content-Transfer-Encoding: base64
• multipart/form-data
• Content-Type: multipart/form-data
• POST /upload
• POST /uploads
• POST /media
• POST /api/upload
• POST /api/uploads
• POST /attachments
• POST /files
• POST /documents
• upstream timed out
• request body too large
• client intended to send too large body
• HTTP/1.1" 408
• HTTP/1.1" 413
• HTTP/1.1" 499
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• Broken pipe
• Request timed out
• worker timeout
• WORKER TIMEOUT
• django.http.multipartparser
• MultiPartParser
• Content-Transfer-Encoding

What your security team should do

• Inventory all Django applications, APIs, containers, and serverless deployments that accept multipart/form-data requests or file uploads.
• Prioritize patching internet-facing upload endpoints and business-critical applications to Django 6.0.4+, 5.2.13+, or 4.2.30+ as applicable.
• Migrate unsupported Django branches to a supported fixed branch; do not assume unsupported versions are unaffected.
• Implement compensating controls immediately for exposed upload endpoints: request body limits, rate limiting, WAF rules, authentication requirements, and aggressive request/worker timeouts.
• Create detections for multipart/form-data POST requests containing Content-Transfer-Encoding: base64 with unusually large bodies, high whitespace ratios, repeated retries, or high concurrency from the same source.
• Review application, reverse proxy, WAF, load balancer, and APM telemetry for spikes in upload endpoint latency, 408/413/499/500/502/503/504 responses, worker restarts, CPU saturation, or queue depth increases.
• Coordinate with application teams to verify whether Content-Transfer-Encoding: base64 is needed; if not, block it at the edge or application middleware.
• Monitor for changes in exploit maturity, EPSS trend, and any future KEV or threat actor reporting, but do not delay remediation for exposed upload-heavy services.