Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor
## Summary `defer temp.Close()` sits inside a `for` loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until `ProcessRequest()` exits. Send enough parts and you hit `EMFILE`. With CRS loaded, that flips `MULTIPART_STRICT_ERROR` to 1 and rule `200001` starts returning 400s, including on legitimate requests hitting the same condition. ## Details `internal/bodyprocessors/multipart.go`, line 69: ```go for { p, err := mr.NextPart() // ... temp, err := os.CreateTemp(storagePath, "crzmp*") defer temp.Close() // wrong scope io.Copy(temp, p) } ``` Each iteration opens a temp file and defers its close. All of them stack up and fire together when `ProcessRequest` returns. 500 parts, 500 fds held simultaneously. The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, `Content-Disposition` with `filename=`, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table. Fix is straightforward: call `temp.Close()` explicitly after `io.Copy` instead of deferring it. ## PoC Tested on v3.7.0 (`db9850b`), Go 1.25, Linux x86_64. Add this file at `internal/bodyprocessors/poc_fd_test.go` and run: ```text go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/... ``` ```go package bodyprocessors_test import ( "fmt" "os" "strings" "sync" "sync/atomic" "t
- Products
- github.com/corazawaf/coraza, github.com/corazawaf/coraza/v2, github.com/corazawaf/coraza/v3
- Affected versions
- Not specified
- Fixed versions
- 3.8.0
- CVEs
- CVE-2026-107834
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 31 Oct 2026, 08:44 UTC · Revision 2
Source evidence
Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor
core-osv · Original sourcePublished 8 Oct 2026, 17:52 UTC
## Summary `defer temp.Close()` sits inside a `for` loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until `ProcessRequest()` exits. Send enough parts and you hit `EMFILE`. With CRS loaded, that flips `MULTIPART_STRICT_ERROR` to 1 and rule `200001` starts returning 400s, including on legitimate requests hitting the same condition. ## Details `internal/bodyprocessors/multipart.go`, line 69: ```go for { p, err := mr.NextPart() // ... temp, err := os.CreateTemp(storagePath, "crzmp*") defer temp.Close() // wrong scope io.Copy(temp, p) } ``` Each iteration opens a temp file and defers its close. All of them stack up and fire together when `ProcessRequest` returns. 500 parts, 500 fds held simultaneously. The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, `Content-Disposition` with `filename=`, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table. Fix is straightforward: call `temp.Close()` explicitly after `io.Copy` instead of deferring it. ## PoC Tested on v3.7.0 (`db9850b`), Go 1.25, Linux x86_64. Add this file at `internal/bodyprocessors/poc_fd_test.go` and run: ```text go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/... ``` ```go package bodyprocessors_test import ( "fmt" "os" "strings" "sync" "sync/atomic" "t
osv:GHSA-rp9v-7xv3-r6g3
github.com/corazawaf/coraza/v3
Fixed versions: 3.8.0
Complete source record
{
"id": "409e0a029668c1c85201540922c7a17779f06d66b06fad23f166c18b773863a9",
"url": "https://osv.dev/vulnerability/GHSA-rp9v-7xv3-r6g3",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor",
"summary": "## Summary `defer temp.Close()` sits inside a `for` loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until `ProcessRequest()` exits. Send enough parts and you hit `EMFILE`. With CRS loaded, that flips `MULTIPART_STRICT_ERROR` to 1 and rule `200001` starts returning 400s, including on legitimate requests hitting the same condition. ## Details `internal/bodyprocessors/multipart.go`, line 69: ```go for { p, err := mr.NextPart() // ... temp, err := os.CreateTemp(storagePath, \"crzmp*\") defer temp.Close() // wrong scope io.Copy(temp, p) } ``` Each iteration opens a temp file and defers its close. All of them stack up and fire together when `ProcessRequest` returns. 500 parts, 500 fds held simultaneously. The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, `Content-Disposition` with `filename=`, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table. Fix is straightforward: call `temp.Close()` explicitly after `io.Copy` instead of deferring it. ## PoC Tested on v3.7.0 (`db9850b`), Go 1.25, Linux x86_64. Add this file at `internal/bodyprocessors/poc_fd_test.go` and run: ```text go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/... ``` ```go package bodyprocessors_test import ( \"fmt\" \"os\" \"strings\" \"sync\" \"sync/atomic\" \"t",
"evidence": "osv:GHSA-rp9v-7xv3-r6g3",
"products": [
{
"name": {
"value": "github.com/corazawaf/coraza/v3",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "3.8.0",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "GHSA-rp9v-7xv3-r6g3",
"aliases": [
"CVE-2026-107834",
"GHSA-rp9v-7xv3-r6g3",
"GO-2026-6697"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.8.0"
}
]
}
],
"package": {
"name": "github.com/corazawaf/coraza/v3",
"purl": "pkg:golang/github.com/corazawaf/coraza/v3",
"ecosystem": "Go"
},
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-rp9v-7xv3-r6g3/GHSA-rp9v-7xv3-r6g3.json"
}
}
],
"modified": "2026-10-19T21:41:16.115574313Z",
"provider": "osv",
"references": [
"https://github.com/corazawaf/coraza/security/advisories/GHSA-rp9v-7xv3-r6g3",
"https://github.com/corazawaf/coraza/commit/1bc39036e99c88e7de60cf8e6bb55ee4c311223c",
"https://github.com/corazawaf/coraza",
"https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
],
"provider_metadata": {
"cwe_ids": [
"CWE-400",
"CWE-772"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": null,
"github_reviewed_at": "2026-10-08T17:52:00Z"
}
},
"related_cves": [
{
"value": "CVE-2026-107834",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 376791,
"published_at": "2026-10-08T17:52:00+00:00"
}Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor in github.com/corazawaf/coraza
core-osv · Original sourcePublished 19 Oct 2026, 21:08 UTC
Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor in github.com/corazawaf/coraza
osv:GO-2026-6697
github.com/corazawaf/coraza
Fixed versions: Not specified
github.com/corazawaf/coraza/v2
Fixed versions: Not specified
github.com/corazawaf/coraza/v3
Fixed versions: 3.8.0
Complete source record
{
"id": "c3b5a25d92aa9ccb0f6fe88378c5c69aee89b0528225833b0604f20495e7d5c4",
"url": "https://osv.dev/vulnerability/GO-2026-6697",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor in github.com/corazawaf/coraza",
"summary": "Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor in github.com/corazawaf/coraza",
"evidence": "osv:GO-2026-6697",
"products": [
{
"name": {
"value": "github.com/corazawaf/coraza",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
},
{
"name": {
"value": "github.com/corazawaf/coraza/v2",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
},
{
"name": {
"value": "github.com/corazawaf/coraza/v3",
"evidence": "/affected/2/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "3.8.0",
"evidence": "/affected/2/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "GO-2026-6697",
"aliases": [
"CVE-2026-107834",
"GHSA-rp9v-7xv3-r6g3",
"GO-2026-6697"
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0"
}
]
}
],
"package": {
"name": "github.com/corazawaf/coraza",
"purl": "pkg:golang/github.com/corazawaf/coraza",
"ecosystem": "Go"
},
"database_specific": {
"source": "https://vuln.go.dev/ID/GO-2026-6697.json"
},
"ecosystem_specific": {}
},
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0"
}
]
}
],
"package": {
"name": "github.com/corazawaf/coraza/v2",
"purl": "pkg:golang/github.com/corazawaf/coraza/v2",
"ecosystem": "Go"
},
"database_specific": {
"source": "https://vuln.go.dev/ID/GO-2026-6697.json"
},
"ecosystem_specific": {}
},
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.8.0"
}
]
}
],
"package": {
"name": "github.com/corazawaf/coraza/v3",
"purl": "pkg:golang/github.com/corazawaf/coraza/v3",
"ecosystem": "Go"
},
"database_specific": {
"source": "https://vuln.go.dev/ID/GO-2026-6697.json"
},
"ecosystem_specific": {}
}
],
"modified": "2026-10-19T21:41:16.115574313Z",
"provider": "osv",
"references": [
"https://github.com/corazawaf/coraza/security/advisories/GHSA-rp9v-7xv3-r6g3",
"https://github.com/corazawaf/coraza/commit/1bc39036e99c88e7de60cf8e6bb55ee4c311223c",
"https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
],
"provider_metadata": {
"url": "https://pkg.go.dev/vuln/GO-2026-6697",
"review_status": "UNREVIEWED"
}
},
"related_cves": [
{
"value": "CVE-2026-107834",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 376792,
"published_at": "2026-10-19T21:08:17+00:00"
}