CVE-2026-107834 in Coraza
Summary
by MITRE • 10/09/2026
OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the multipart loop in internal/bodyprocessors/multipart.go executes defer temp.Close() for every uploaded file part, so each temporary-file descriptor remains open until the complete request returns. An unauthenticated attacker can submit a multipart body containing many minimal file parts and exhaust the process file-descriptor table within the request-body size limit, causing os.CreateTemp failures, MULTIPART_STRICT_ERROR responses, blocked legitimate uploads, and process-wide inability to open files or sockets. This issue is fixed in version 3.8.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in OWASP Coraza WAF versions ranging from 3.0.0 through 3.8.0 represents a critical resource exhaustion flaw rooted in the handling of multipart form data uploads. As a Go-based library compatible with ModSecurity, Coraza processes incoming HTTP requests to inspect and filter malicious content before it reaches backend applications. The specific defect resides within the internal body processor for multipart payloads, specifically in the file located at internal/bodyprocessors/multipart.go. When processing an uploaded file part, the implementation executes a defer statement that schedules temp.Close() to run only when the surrounding function returns. This design choice means that every temporary file descriptor created during the parsing of individual parts remains open and allocated throughout the entire duration of the request lifecycle, rather than being released immediately after each part is processed.
This architectural oversight allows an unauthenticated attacker to exploit the system by submitting a multipart body containing a large number of minimal file parts. Because there is no limit on the count of these small parts within the overall request-body size constraint, an adversary can craft a payload that triggers the creation of thousands or even millions of temporary files. Each part consumes one file descriptor from the operating system's limited pool for the current process. As the number of open descriptors grows, it eventually exhausts the available file-descriptor table allocated to the Coraza process. This exhaustion leads directly to os.CreateTemp failures when subsequent parts are processed, resulting in MULTIPART_STRICT_ERROR responses being returned to clients.
The operational impact of this vulnerability extends beyond simple request rejection for malicious actors. Legitimate users attempting to upload files may find their requests blocked or failed due to the system's inability to allocate necessary resources. More critically, because file descriptors are a shared resource within the process, the exhaustion caused by one attacker can degrade service availability for all other concurrent connections handled by that instance of Coraza. In severe cases, this could lead to a broader denial-of-service condition where the WAF process becomes unable to open new files or network sockets entirely, effectively halting its ability to function as a security gateway until the process is restarted or the underlying OS limits are adjusted.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of resource allocation exhaustion and more accurately with CWE-400: Uncontrolled Resource Consumption. In the context of the MITRE ATT&CK framework, this behavior is indicative of T1496: Resource Hijacking, where an attacker consumes system resources to disrupt service availability. The flaw highlights a common pitfall in Go programming regarding the misuse of defer statements for resource cleanup within loops or high-volume processing paths, where immediate closure is required rather than deferred execution at function exit.
The issue has been addressed and fixed in version 3.8.0 of OWASP Coraza WAF. Organizations running affected versions should upgrade to this patched release immediately to restore proper file descriptor management during multipart uploads. Until the upgrade can be performed, mitigation strategies include configuring web server or reverse proxy settings to limit the maximum number of parts allowed in a single multipart request, thereby capping the potential resource consumption before it reaches Coraza. Additionally, increasing the system-level file descriptor limits for the process may provide temporary relief but does not resolve the underlying logic flaw and should be viewed only as a compensating control rather than a permanent solution. Regular monitoring of open file descriptors and error logs related to temp file creation can help detect exploitation attempts in real-time while patching efforts are underway.