Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)
Plug.Parsers.MULTIPART, the multipart request-body parser used to handle file uploads and multipart forms, does not enforce its :length budget against all consumed resources, allowing an unauthenticated remote attacker to cause denial of service. The parser charges the :length limit only for part body bytes; part header bytes are never counted, and a part with an empty body costs zero. Because every part whose Content-Disposition carries a non-empty filename creates a fresh temporary file (via Plug.Upload) and retains a Plug.Upload struct for the duration of the request, an attacker can send a single request composed of many empty-body file parts. Such a request stays well under the configured :length limit (8,000,000 bytes by default) while creating one temporary file per part, leading to inode and disk exhaustion and unbounded memory growth. Any application using Plug.Parsers with the :multipart parser is affected, and no authentication is required, only reachability of a multipart endpoint over HTTP. This vulnerability is associated with program files lib/plug/parsers/multipart.ex and program routines Plug.Parsers.MULTIPART.parse_multipart/2, Plug.Parsers.MULTIPART.parse_multipart_headers/5, Plug.Parsers.MULTIPART.parse_multipart_body/4, and Plug.Parsers.MULTIPART.parse_multipart_file/4. This issue affects plug: from 1.4.0-rc.0 before 1.16.6, from 1.17.0 before 1.17.4, from 1.18.0 before 1.18.5, from 1.19.1 before 1.19.5, and from 1.20.0 before 1.20.3.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-56814
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 03:18 UTC · Revision 1
Source evidence
Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)
core-osv · Original sourcePublished 10 Jul 2026, 11:14 UTC
Plug.Parsers.MULTIPART, the multipart request-body parser used to handle file uploads and multipart forms, does not enforce its :length budget against all consumed resources, allowing an unauthenticated remote attacker to cause denial of service. The parser charges the :length limit only for part body bytes; part header bytes are never counted, and a part with an empty body costs zero. Because every part whose Content-Disposition carries a non-empty filename creates a fresh temporary file (via Plug.Upload) and retains a Plug.Upload struct for the duration of the request, an attacker can send a single request composed of many empty-body file parts. Such a request stays well under the configured :length limit (8,000,000 bytes by default) while creating one temporary file per part, leading to inode and disk exhaustion and unbounded memory growth. Any application using Plug.Parsers with the :multipart parser is affected, and no authentication is required, only reachability of a multipart endpoint over HTTP. This vulnerability is associated with program files lib/plug/parsers/multipart.ex and program routines Plug.Parsers.MULTIPART.parse_multipart/2, Plug.Parsers.MULTIPART.parse_multipart_headers/5, Plug.Parsers.MULTIPART.parse_multipart_body/4, and Plug.Parsers.MULTIPART.parse_multipart_file/4. This issue affects plug: from 1.4.0-rc.0 before 1.16.6, from 1.17.0 before 1.17.4, from 1.18.0 before 1.18.5, from 1.19.1 before 1.19.5, and from 1.20.0 before 1.20.3.
osv:CVE-2026-56814
Complete source record
{
"id": "66fa7414e0b36669a3a64c7fa8cc942d26180b74b64273338ef43609c5c6ca05",
"url": "https://osv.dev/vulnerability/CVE-2026-56814",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)",
"summary": "Plug.Parsers.MULTIPART, the multipart request-body parser used to handle file uploads and multipart forms, does not enforce its :length budget against all consumed resources, allowing an unauthenticated remote attacker to cause denial of service. The parser charges the :length limit only for part body bytes; part header bytes are never counted, and a part with an empty body costs zero. Because every part whose Content-Disposition carries a non-empty filename creates a fresh temporary file (via Plug.Upload) and retains a Plug.Upload struct for the duration of the request, an attacker can send a single request composed of many empty-body file parts. Such a request stays well under the configured :length limit (8,000,000 bytes by default) while creating one temporary file per part, leading to inode and disk exhaustion and unbounded memory growth. Any application using Plug.Parsers with the :multipart parser is affected, and no authentication is required, only reachability of a multipart endpoint over HTTP. This vulnerability is associated with program files lib/plug/parsers/multipart.ex and program routines Plug.Parsers.MULTIPART.parse_multipart/2, Plug.Parsers.MULTIPART.parse_multipart_headers/5, Plug.Parsers.MULTIPART.parse_multipart_body/4, and Plug.Parsers.MULTIPART.parse_multipart_file/4. This issue affects plug: from 1.4.0-rc.0 before 1.16.6, from 1.17.0 before 1.17.4, from 1.18.0 before 1.18.5, from 1.19.1 before 1.19.5, and from 1.20.0 before 1.20.3.",
"evidence": "osv:CVE-2026-56814",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-56814",
"aliases": [
"CVE-2026-56814",
"EEF-CVE-2026-56814",
"GHSA-95qv-c9g9-rm63"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/elixir-plug/plug",
"type": "GIT",
"events": [
{
"introduced": "c52b2f32c90bccd718202bafccb5f95594e30183"
},
{
"fixed": "981597d3a4271ede64373c7a731702a42c500dd6"
},
{
"fixed": "c52b2f32c90bccd718202bafccb5f95594e30183"
},
{
"fixed": "56edca2ce35fe5589cd581644d8a4493fa5f484e"
},
{
"fixed": "0ee8afcc61466dc5f7a8f048d0632c899165b81f"
},
{
"fixed": "cae36053350e5215a4e0ca33cd130af9c5fc6364"
},
{
"fixed": "f7effaed811c00b5f5bf817936bfd9c5df27b7dc"
},
{
"fixed": "df97d3f17f808a9916a7700a701fb85314559d56"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "c52b2f32c90bccd718202bafccb5f95594e30183"
},
{
"fixed": "981597d3a4271ede64373c7a731702a42c500dd6"
}
],
"source": "AFFECTED_FIELD",
"strategy": "ChangesAt"
},
{
"range": [
{
"fixed": "c52b2f32c90bccd718202bafccb5f95594e30183"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "981597d3a4271ede64373c7a731702a42c500dd6"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "56edca2ce35fe5589cd581644d8a4493fa5f484e"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "0ee8afcc61466dc5f7a8f048d0632c899165b81f"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "cae36053350e5215a4e0ca33cd130af9c5fc6364"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "f7effaed811c00b5f5bf817936bfd9c5df27b7dc"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "df97d3f17f808a9916a7700a701fb85314559d56"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-56814.json"
}
}
],
"modified": "2026-10-28T02:30:25.473711724Z",
"provider": "osv",
"references": [
"https://cna.erlef.org/cves/CVE-2026-56814.html",
"https://github.com",
"https://osv.dev/vulnerability/EEF-CVE-2026-56814",
"https://repo.hex.pm",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/56xxx/CVE-2026-56814.json",
"https://github.com/elixir-plug/plug/security/advisories/GHSA-95qv-c9g9-rm63",
"https://nvd.nist.gov/vuln/detail/CVE-2026-56814",
"https://github.com/elixir-plug/plug/commit/0ee8afcc61466dc5f7a8f048d0632c899165b81f",
"https://github.com/elixir-plug/plug/commit/56edca2ce35fe5589cd581644d8a4493fa5f484e",
"https://github.com/elixir-plug/plug/commit/981597d3a4271ede64373c7a731702a42c500dd6",
"https://github.com/elixir-plug/plug/commit/c52b2f32c90bccd718202bafccb5f95594e30183",
"https://github.com/elixir-plug/plug/commit/cae36053350e5215a4e0ca33cd130af9c5fc6364",
"https://github.com/elixir-plug/plug/commit/df97d3f17f808a9916a7700a701fb85314559d56",
"https://github.com/elixir-plug/plug/commit/f7effaed811c00b5f5bf817936bfd9c5df27b7dc",
"https://github.com/elixir-plug/plug"
],
"provider_metadata": {
"cwe_ids": [
"CWE-770"
],
"cna_assigner": "EEF",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"introduced": "1.4.0-rc.0"
},
{
"fixed": "1.16.6"
},
{
"introduced": "1.17.0"
},
{
"fixed": "1.17.4"
},
{
"introduced": "1.18.0"
},
{
"fixed": "1.18.5"
},
{
"introduced": "1.19.1"
},
{
"fixed": "1.19.5"
},
{
"introduced": "1.20.0"
},
{
"fixed": "1.20.3"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/56xxx/CVE-2026-56814.json"
}
},
"related_cves": [
{
"value": "CVE-2026-56814",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 492142,
"published_at": "2026-07-10T11:14:35.574+00:00"
}