CVE-2024-49767: Palletsprojects Quart DoS Vulnerability

CVE-2024-49767 Overview

CVE-2024-49767 is a resource exhaustion vulnerability affecting Werkzeug, the popular Web Server Gateway Interface (WSGI) web application library used extensively in Python web development. Applications utilizing werkzeug.formparser.MultiPartParser to parse multipart/form-data requests—including all Flask applications—are vulnerable to a denial of service attack through memory exhaustion.

The vulnerability allows attackers to craft malicious form submission requests that cause the parser to allocate and block 3 to 8 times the upload size in main memory. With no upper limit enforced, a single upload at 1 Gbit/s can exhaust 32 GB of RAM in less than 60 seconds, rendering the application and potentially the entire server unresponsive.

Critical Impact

A single malicious multipart form upload can exhaust server memory within seconds, causing complete service disruption for all Flask and Werkzeug-based applications without proper memory limits configured.

Affected Products

• Palletsprojects Werkzeug versions prior to 3.0.6
• Palletsprojects Quart versions prior to 0.19.7
• All Flask applications using vulnerable Werkzeug versions

Discovery Timeline

• 2024-10-25 - CVE-2024-49767 published to NVD
• 2025-01-03 - Last updated in NVD database

Technical Details for CVE-2024-49767

Vulnerability Analysis

This vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption). The flaw exists in how werkzeug.formparser.MultiPartParser handles memory allocation during the parsing of multipart/form-data requests. When processing large non-file form fields, the parser fails to properly apply the max_form_memory_size limit at the appropriate level, allowing attackers to bypass intended memory restrictions.

The parser's memory consumption behavior is particularly problematic because it can allocate between 3 to 8 times the size of the uploaded data. This amplification factor, combined with the absence of an upper bound on allocation, creates a trivially exploitable denial of service condition. An attacker with modest bandwidth can quickly overwhelm even well-provisioned servers.

Root Cause

The root cause lies in the improper application of max_form_memory_size within the multipart form parsing logic. The security patches reveal that the fix involves applying this memory size constraint "another level up in the parser" to ensure it effectively limits memory consumption during the parsing of large non-file fields.

The vulnerable code path allowed unbounded memory allocation when processing form field data before the size check was properly enforced. The fix introduces proper tracking of field_size and applies memory constraints at the correct parsing stage.

Attack Vector

The attack exploits the network-accessible multipart form parsing functionality. An attacker can craft a specially designed HTTP POST request with multipart/form-data content type containing large non-file form fields. When the vulnerable parser processes this request, it allocates excessive memory without proper bounds checking.

The attack requires no authentication and can be executed remotely against any application endpoint that accepts multipart form submissions. The simplicity of the attack—requiring only a crafted HTTP request—combined with its severe impact makes this vulnerability particularly concerning for public-facing Flask and Quart applications.

# Source: Werkzeug security patch - Fix for max_form_memory_size application
# From: https://github.com/pallets/werkzeug/commit/50cfeebcb0727e18cc52ffbeb125f4a66551179b

        self, stream: t.IO[bytes], boundary: bytes, content_length: int | None
    ) -> tuple[MultiDict[str, str], MultiDict[str, FileStorage]]:
        current_part: Field | File
+       field_size: int | None = None
        container: t.IO[bytes] | list[bytes]
        _write: t.Callable[[bytes], t.Any]

# Source: Quart security patch - New configuration defaults for memory protection
# From: https://github.com/pallets/quart/commit/abb04a512496206de279225340ed022852fbf51f

            "EXPLAIN_TEMPLATE_LOADING": False,
            "MAX_CONTENT_LENGTH": 16 * 1024 * 1024,  # 16 MB Limit
            "MAX_COOKIE_SIZE": 4093,
+           "MAX_FORM_MEMORY_SIZE": 500_000,
+           "MAX_FORM_PARTS": 1_000,
            "PERMANENT_SESSION_LIFETIME": timedelta(days=31),
            # Replaces PREFERRED_URL_SCHEME to allow for WebSocket scheme
            "PREFER_SECURE_URLS": False,

Detection Methods for CVE-2024-49767

Indicators of Compromise

• Unusual memory consumption spikes correlated with incoming HTTP POST requests
• Server or container out-of-memory (OOM) events during multipart form processing
• Large HTTP POST requests with multipart/form-data content type containing oversized non-file fields
• Application crashes or unresponsiveness following form submission activity

Detection Strategies

• Monitor application memory usage patterns and alert on rapid memory growth during request processing
• Implement request logging for multipart form submissions exceeding size thresholds
• Deploy web application firewall (WAF) rules to detect and block abnormally large multipart requests
• Use dependency scanning tools to identify Werkzeug versions prior to 3.0.6 and Quart versions prior to 0.19.7

Monitoring Recommendations

• Configure memory usage alerts at 70-80% thresholds to detect resource exhaustion attempts before service impact
• Enable detailed logging for HTTP request sizes and content types on endpoints accepting form data
• Monitor container or process restart events that may indicate OOM-related crashes
• Track the ratio of request size to memory allocation during multipart parsing if instrumentation is available

How to Mitigate CVE-2024-49767

Immediate Actions Required

• Upgrade Werkzeug to version 3.0.6 or later immediately
• Upgrade Quart to version 0.19.7 or later if using this framework
• Review and configure MAX_FORM_MEMORY_SIZE and MAX_FORM_PARTS in application settings
• Implement request size limits at the reverse proxy or load balancer level as defense in depth

Patch Information

The vulnerability is addressed in Werkzeug version 3.0.6 and Quart version 0.19.7. The patches fix how max_form_memory_size is applied during the parsing of large non-file fields by introducing proper field size tracking and applying memory constraints earlier in the parsing process.

For detailed information about the security fix, refer to the GitHub Werkzeug Security Advisory and the Werkzeug 3.0.6 Release Notes. NetApp users should also consult the NetApp Security Advisory NTAP-20250103-0007.

Workarounds

• Deploy a reverse proxy (nginx, HAProxy) with strict request body size limits to reject oversized uploads before they reach the application
• Configure MAX_CONTENT_LENGTH in Flask/Quart configuration to limit maximum request size
• Implement rate limiting on form submission endpoints to reduce the impact of sustained attack attempts
• Consider temporarily disabling or restricting access to endpoints that accept large file uploads until patching is complete

# Configuration example - nginx request size limit
# Add to nginx server or location block to limit request body size

client_max_body_size 10M;
client_body_buffer_size 128k;

# Flask application configuration example
# Set in your Flask app configuration

# app.config['MAX_CONTENT_LENGTH'] = 16 * 1024 * 1024  # 16 MB limit
# app.config['MAX_FORM_MEMORY_SIZE'] = 500000  # 500 KB limit for form fields
# app.config['MAX_FORM_PARTS'] = 1000  # Limit number of form parts