☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Django logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 5.8 🐛 CWE-770
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-56374

CVE-2024-56374 Denial of Service in Django
📅 PUBLISHED: 2025-01-14 00:00 UTC 🔄 UPDATED: 2026-09-23 20:28 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 1.92%
👁️
1.92% probability
48.1× above the median CVE
Tier: HIGH
30-day exploitation window · FIRST.org · updated daily
Country: USA License: Open Source
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
5.8
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-56374 is a denial-of-service (DoS) vulnerability in Django’s IPv6 validation logic. The flaw resides in the undocumented helper functions clean_ipv6_address and is_valid_ipv6_address, as well as the django.forms.GenericIPAddressField form field. By submitting an excessively long string to these functions, an attacker can cause the Python process to consume disproportionate CPU and memory resources, leading to a denial-of-service condition. The django.db.models.GenericIPAddressField model field is not affected.

This vulnerability is classified as a CWE-770: Allocation of Resources Without Limits or Throttling. The CVSS score is 5.8 (Medium), with a network attack vector and low attack complexity. No authentication is required, and the impact is limited to availability.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

Django is a widely used Python web framework distributed via PyPI. This vulnerability affects the core framework itself, not a third-party package. Organizations using Django should treat this as a high-priority update due to the ease of exploitation and the potential for service disruption. The EPSS score is 0.0%, indicating low current exploitation activity, but the vulnerability is trivial to trigger.

CVSS Breakdown & Threat Level

  • CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
  • Base Score: 5.8 (Medium)
  • Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
  • Attack Complexity (AC): Low (L) – No special conditions are required.
  • Privileges Required (PR): None (N) – No authentication needed.
  • User Interaction (UI): None (N) – No user action required.
  • Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
  • Confidentiality (C): None (N) – No data exposure.
  • Integrity (I): None (N) – No data modification.
  • Availability (A): Low (L) – The attack can cause a partial denial of service (resource exhaustion).

Threat Level: Medium. The vulnerability is easy to exploit but only affects availability. It is most dangerous for public-facing Django applications that accept IP address input via forms.

Deep Dive & Mechanics

The vulnerability is rooted in the lack of upper-bound enforcement on the length of strings passed to IPv6 validation functions. When a user submits an extremely long string (e.g., thousands of characters) to a form field that validates IPv6 addresses, the internal parsing logic attempts to process the entire string. This can lead to:

  • CPU Exhaustion: The parser may enter a near-infinite loop or perform excessive backtracking when trying to match the malformed input against IPv6 patterns.
  • Memory Exhaustion: The string itself, along with intermediate data structures, can consume significant memory.

The affected functions are:

  • django.core.validators.validate_ipv6_address (calls is_valid_ipv6_address)
  • django.core.validators.validate_ipv46_address (calls validate_ipv6_address)
  • django.forms.fields.GenericIPAddressField (uses the above validators)

The model field django.db.models.GenericIPAddressField is not vulnerable because it does not perform the same validation at the Python level; it relies on database-level constraints.

Vulnerable vs. Patched Code

Vulnerable Code (Django < 4.2.18, < 5.0.11, < 5.1.5):

In django/core/validators.py, the validate_ipv6_address function calls is_valid_ipv6_address without any length check:

def validate_ipv6_address(value):
    if not is_valid_ipv6_address(value):
        raise ValidationError(
            _('Enter a valid IPv6 address.'),
            code='invalid',
        )

The is_valid_ipv6_address function in django/utils/ipv6.py processes the input without limiting its length:

def is_valid_ipv6_address(value):
    if not isinstance(value, str):
        return False
    # ... parsing logic that can be overwhelmed by long strings

Patched Code (Django >= 4.2.18, >= 5.0.11, >= 5.1.5):

The patch adds a length check before validation. In django/core/validators.py:

def validate_ipv6_address(value):
    if len(value) > 39:  # Maximum length of a valid IPv6 address
        raise ValidationError(
            _('Enter a valid IPv6 address.'),
            code='invalid',
        )
    if not is_valid_ipv6_address(value):
        raise ValidationError(
            _('Enter a valid IPv6 address.'),
            code='invalid',
        )

The maximum length of a valid IPv6 address (including the optional zone ID) is 39 characters (e.g., ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff%eth0). Any input longer than this is immediately rejected.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

  • A Django application with a form that uses GenericIPAddressField or a custom validator that calls validate_ipv6_address.
  • Network access to the application.

Exploit Steps:

  1. Identify a vulnerable endpoint. Look for forms that accept IP addresses, such as admin panels, user profile editors, or API endpoints.

  2. Craft a malicious payload. Generate a very long string (e.g., 10,000 characters) that is not a valid IPv6 address.

    # generate_payload.py
    payload = "A" * 10000
    print(payload)
    
  3. Send the payload. Use curl or a Python script to submit the form.

    curl -X POST https://target.com/your-form/ \
         -d "ip_address=AAAAAAAA... (10000 A's)"
    
  4. Observe the impact. The Django process may become unresponsive, consuming high CPU and memory. Multiple concurrent requests can amplify the effect.

Expected Outcome: The target application becomes slow or unresponsive, potentially affecting all users.

Blue Team (Defense & Detection)

Detection:

  • Monitor for unusually long strings in IP address form fields.
  • Set up application-level logging to capture validation failures.
  • Use WAF rules to block requests with IP address fields exceeding 39 characters.

Mitigation:

  • Apply the official patch immediately.

  • If patching is not possible, implement a custom validator that enforces length limits:

    from django.core.exceptions import ValidationError
    from django.utils.translation import gettext_lazy as _
    
    def validate_ipv6_length(value):
        if len(value) > 39:
            raise ValidationError(
                _('IPv6 address is too long.'),
                code='invalid',
            )
    
  • Rate-limit form submissions to reduce the impact of automated attacks.

Indicators of Compromise (IOCs)

  • Network IOCs:

    • HTTP POST requests to forms with ip_address or similar parameters containing strings longer than 39 characters.
    • Repeated requests from the same source IP with varying long strings.
  • Log IOCs:

    • Django error logs showing ValidationError for validate_ipv6_address with extremely long input.
    • Application logs indicating high CPU or memory usage correlated with form submissions.
  • System IOCs:

    • High CPU usage by Python processes.
    • Memory exhaustion in the application server.

Detection Engineering

YARA Rule

rule CVE_2024_56374_Django_IPv6_DoS {
    meta:
        description = "Detects attempts to exploit CVE-2024-56374 by sending overly long IPv6 strings"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-56374"
        severity = "medium"
    strings:
        $long_ipv6 = /[0-9a-fA-F:.]{100,}/  // Matches strings of 100+ hex/colon/dot characters
    condition:
        $long_ipv6
}

Sigma Rule

title: CVE-2024-56374 Django IPv6 DoS Attempt
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests with overly long IPv6 address parameters targeting Django applications
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: django
detection:
    selection:
        c-uri|contains: 
            - "ip_address"
            - "ipv6"
            - "GenericIPAddressField"
        c-uri|length: > 100
    condition: selection
falsepositives:
    - Legitimate long zone IDs (rare, max 39 chars)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-56374 Django IPv6 DoS Attempt"; flow:to_server; content:"ip_address"; http_client_body; pcre:"/[0-9a-fA-F:.]{100,}/Ri"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Patch: Upgrade Django to version 4.2.18, 5.0.11, or 5.1.5 (or later).
    pip install --upgrade django==5.1.5
    
  2. Workaround: If patching is delayed, add a custom validator to all GenericIPAddressField fields:
    from django.core.validators import MaxLengthValidator
    from django.forms import GenericIPAddressField
    
    class SafeGenericIPAddressField(GenericIPAddressField):
        def __init__(self, *args, **kwargs):
            super().__init__(*args, **kwargs)
            self.validators.append(MaxLengthValidator(39))
    

Long-term Measures:

  • Implement input validation at the web server or WAF level.
  • Monitor for similar resource-exhaustion vulnerabilities in other parts of the application.
  • Conduct regular security audits of third-party dependencies.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. All information is provided for educational and defensive purposes only. Unauthorized exploitation of this vulnerability is illegal.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-56374/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.