CVE-2012-3443
NoneCVSS
—
EPSS
2.7%
Published
Jul 31, 2012
CISA due date
—
Cloudanix analysis
A flaw in a popular web development tool allows an attacker to crash a website simply by uploading a specially crafted image file, making the site unavailable for everyone.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- Web Framework
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability lies in the `django.forms.ImageField` class, which fully decompresses image data into memory during validation. An attacker can upload a specially crafted image file, known as a 'decompression bomb', that is small in size but expands to consume a massive amount of memory upon decompression. This leads to excessive memory allocation, causing the server process to crash or become unresponsive due to memory exhaustion, resulting in a denial of service.
Why it matters to the business
An attacker can render any web application using this vulnerable component completely unavailable to legitimate users. This denial of service can lead to significant business disruption, loss of revenue, and damage to the organization's reputation, especially for services that rely on high availability.
How an attack unfolds
An unauthenticated remote attacker identifies a web application using a vulnerable version of Django with a file upload feature (e.g., for profile pictures or gallery images). The attacker crafts a malicious image file that is small but designed to decompress to an extremely large size. They then upload this file via the application's form. When the Django backend attempts to validate the uploaded file, the `ImageField` class tries to decompress the entire image into memory. This action consumes all available memory, causing the web application's process to crash or be terminated by the operating system's Out-Of-Memory (OOM) killer, taking the service offline.
How to fix it
To remediate this vulnerability, upgrade Django to a patched version. For applications on the 1.3.x branch, upgrade to version 1.3.2 or later. For applications on the 1.4.x branch, upgrade to version 1.4.1 or later. As a general best practice, it is recommended to upgrade to the latest stable and supported version of Django to receive all security updates.
How to confirm the fix worked
To validate the fix, check the installed version of Django within your application's environment using the command `python -m django --version`. Ensure the reported version is 1.3.2 or higher, 1.4.1 or higher, or a more recent major version. In a controlled test environment, you can attempt to upload a known image decompression bomb to a vulnerable endpoint and monitor server memory. A patched system should reject the file without significant memory consumption, while a vulnerable system will exhibit a memory spike and potential process crash.
Typical attack path
- The attacker identifies a target application running a vulnerable version of Django.
- The attacker locates a form that accepts image uploads.
- The attacker crafts a malicious image file (a 'decompression bomb').
- The attacker submits the malicious file through the upload form.
- The server's validation logic attempts to decompress the image, exhausting system memory.
- The application process crashes, resulting in a denial of service for all users.
How to detect it
To detect potential past exploitation, investigate unexplained crashes or restarts of the web application processes. Correlate the timestamps of these events with web server access logs, looking for POST requests to image upload endpoints. Check system logs (e.g., `/var/log/syslog`, `dmesg`) for Out-Of-Memory (OOM) killer events that terminated the application process. The primary indicator is a behavioral pattern of a file upload followed by a server process crash due to memory exhaustion, rather than a static artifact.
What your security team should do
- Immediately audit all web applications to identify those using Django and determine their versions.
- Prioritize upgrading any applications running Django versions before 1.3.2 or 1.4.1 to a secure, supported release.
- If immediate patching is not feasible, implement strict resource limits and monitoring on application server processes to detect and alert on abnormal memory usage.
- Consider implementing file size limits at the web server or load balancer level as a partial, temporary mitigation, though this may not be fully effective against decompression bombs.
The record
The django.forms.ImageField class in the form system in Django before 1.3.2 and 1.4.x before 1.4.1 completely decompresses image data during image validation, which allows remote attackers to cause a denial of service (memory consumption) by uploading an image file.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| PyPI | django | 0 | 1.3.2 |
| PyPI | django | 1.4 | 1.4.1 |
| Debian:11 | python-django | 0 | 1.4.1-1 |
| Debian:12 | python-django | 0 | 1.4.1-1 |
| Debian:13 | python-django | 0 | 1.4.1-1 |
| Debian:6.0 | python-django | 0 | 1.2.3-3+squeeze3 |
| pypi | Django | 1.4 | No fix |
Related vulnerabilities
- GHSA-8p8v-wh79-9r56 Django vulnerable to Uncontrolled Resource Consumption Also affects django
- GHSA-mjgh-79qc-68w3 Django has a Race Condition vulnerability Also affects django
- CVE-2026-25673 An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. Also affects django
- CVE-2026-25674 An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. Also affects django
- GHSA-6426-9fv3-65x8 Django has an SQL Injection issue Also affects django
- GHSA-gvg8-93h5-g6qq Django has an SQL Injection issue Also affects django
- GHSA-2mcm-79hx-8fxw Django has Observable Timing Discrepancy Also affects django
- GHSA-33mw-q7rj-mjwj Django has Inefficient Algorithmic Complexity Also affects django