Skip to main content
CVE-2024-24762: When a Regex Pattern Took Down FastAPI AppsIncident
4 min readFor Security Engineers

CVE-2024-24762: When a Regex Pattern Took Down FastAPI Apps

What Happened

FastAPI applications using the python-multipart package were exposed to regular expression denial of service (ReDoS) attacks through CVE-2024-24762. This vulnerability arose from an insecure regex pattern in the dependency that processes multipart form data—a core function in many web applications. An attacker could send a malicious request that caused the regex engine to enter catastrophic backtracking, consuming CPU resources until the application became unresponsive.

The vulnerable pattern, ^(a+)+$, exemplifies exponential time complexity in regex matching. When the engine attempts to match this pattern against a string like "aaaaaaaaaaaaaaaaaaaaX", it explores every possible grouping of the 'a' characters before failing at the 'X'. The attempts increase exponentially with input length.

Timeline

Discovery Phase: Security researchers found the vulnerable regex pattern in python-multipart during routine dependency analysis. The pattern was in code responsible for parsing Content-Type headers and form boundaries.

CVE Assignment: The vulnerability was classified as CVE-2024-24762, affecting python-multipart versions prior to the patched release.

Detection Window: Organizations using automated dependency scanning tools like Snyk received alerts immediately. Teams without continuous monitoring remained exposed until manual updates were applied.

Remediation: The python-multipart maintainers released a patched version with a linear-time regex alternative. FastAPI applications needed a dependency update to incorporate the fix.

Which Controls Failed or Were Missing

Dependency Vulnerability Management: Many organizations lacked automated scanning for transitive dependencies. Python-multipart is often not a direct import in FastAPI projects but is pulled in automatically. Without tools that map the full dependency graph, you might not see it.

Input Validation at Boundaries: Applications accepted unbounded input lengths for multipart form data without rate limiting or size constraints. A 10MB file upload with a malicious boundary string could trigger the vulnerability. Missing controls included input validation that checks both size and complexity before passing data to regex engines.

Runtime Protection: No web application firewall (WAF) rules or runtime application self-protection (RASP) detected the anomalous CPU consumption pattern. When a single request consumes 100% of a CPU core for more than a few seconds, something is wrong. The absence of resource monitoring at the request level meant attacks succeeded before detection.

Regression Testing for Performance: CI/CD pipelines tested functional correctness but not performance under malicious input. A test case with a 1KB payload and nested boundary markers would have exposed the exponential behavior during development.

What the Relevant Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying and addressing security vulnerabilities based on risk ranking. For dependencies processing payment card data, this includes:

  • Maintaining an inventory of all components, including transitive dependencies
  • Monitoring security advisories for those components
  • Applying patches within defined timeframes based on CVSS scores

ReDoS vulnerabilities typically score 5.0-7.5 (Medium to High), requiring remediation within 30 days for PCI compliance.

OWASP ASVS v4.0.3 Requirement 5.1.5 states: "Verify that the application has defenses against HTTP parameter pollution attacks." This requirement addresses input-based attacks broadly. Your implementation should validate input complexity, not just content.

NIST 800-53 Rev 5 Control SI-10 (Information Input Validation) requires checking the validity of inputs, including "length, type, range, and acceptable values." For regex operations, this extends to computational complexity. Your validation layer should reject inputs that could trigger exponential processing time.

ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities) requires obtaining timely information about technical vulnerabilities and evaluating exposure. For Python projects, this means:

  • Running pip-audit or safety check in your CI pipeline
  • Subscribing to security advisories for your framework stack
  • Maintaining a software bill of materials (SBOM) that includes all dependencies

Lessons and Action Items for Your Team

Implement Continuous Dependency Scanning: Add Snyk, GitHub Dependabot, or pip-audit to your CI/CD pipeline. Configure it to fail builds on high-severity vulnerabilities. For existing applications, run the scan weekly and track remediation in your ticketing system.

# Add to your CI pipeline
pip-audit --requirement requirements.txt --vulnerability-service osv

Pin Transitive Dependencies: Your requirements.txt should specify exact versions, but also generate a lock file that captures the entire dependency tree. Use pip-compile from pip-tools:

pip-compile requirements.in --generate-hashes

This creates requirements.txt with cryptographic hashes for every package, including transitive dependencies.

Add Complexity-Based Input Validation: Before any regex operation on user input, check the input length and reject oversized payloads. For multipart uploads, enforce maximum boundary string length (256 bytes is generous) and maximum number of parts (100 for most applications).

Monitor Request Duration: Instrument your application to track request processing time. Set alerts for any endpoint that exceeds 5 seconds. This catches ReDoS attacks and other performance issues:

# Add middleware to track request duration
@app.middleware("http")
async def track_request_duration(request, call_next):
    start = time.time()
    response = await call_next(request)
    duration = time.time() - start
    if duration > 5.0:
        logger.warning(f"Slow request: {request.url} took {duration}s")
    return response

Test Regex Patterns for Complexity: Use tools like regex101.com's debugger or the re module's built-in timeout parameter (Python 3.11+). Any pattern with nested quantifiers ((a+)+, (a*)*, (a+)*) should trigger immediate review.

Establish Patch SLAs by Severity: Define maximum remediation times:

  • Critical (CVSS 9.0-10.0): 7 days
  • High (CVSS 7.0-8.9): 30 days
  • Medium (CVSS 4.0-6.9): 90 days

Track these in your vulnerability management platform and report compliance monthly.

The CVE-2024-24762 incident shows that application security isn't just about your code—it's about the entire supply chain. A regex pattern you never wrote, in a package you never imported directly, can still take down your application. Your controls need to match that reality.

Topics:Incident

You Might Also Like