{"id":"CVE-2026-56814","aliases":["EEF-CVE-2026-56814","EUVD-2026-42873","GHSA-95qv-c9g9-rm63"],"status":"published","title":"Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)","description":"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.\n\nBecause 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.\n\nThis 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.\n\nThis 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.","severity":{"version":"4.0","score":6.9,"vector":"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","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.0108,"percentile":0.65559,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-770"],"published":"2026-07-10T11:14:35Z","modified":"2026-11-05T21:32:25Z","fixes":[{"ecosystem":"Hex","package":"plug","fixed_in":["1.16.6","1.17.4","1.18.5","1.19.5","1.20.3"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"plug","ranges":[{"type":"SEMVER","events":[{"introduced":"1.4.0-rc.0"},{"fixed":"1.16.6"}]},{"type":"SEMVER","events":[{"introduced":"1.17.0"},{"fixed":"1.17.4"}]},{"type":"SEMVER","events":[{"introduced":"1.18.0"},{"fixed":"1.18.5"}]},{"type":"SEMVER","events":[{"introduced":"1.19.1"},{"fixed":"1.19.5"}]},{"type":"SEMVER","events":[{"introduced":"1.20.0"},{"fixed":"1.20.3"}]}],"versions":["1.10.0","1.10.1","1.10.2","1.10.3","1.10.4","1.11.0","1.11.1","1.12.0","1.12.1","1.13.0","1.13.1","1.13.2","1.13.3","1.13.4","1.13.5","1.13.6","1.14.0","1.14.1","1.14.2","1.15.0","1.15.1","1.15.2","1.15.3","1.15.4","1.15.5","1.15.6","1.16.0","1.16.1","1.16.2","1.16.3","1.16.4","1.16.5","1.17.0","1.17.1","1.17.2","1.17.3","1.18.0","1.18.1","1.18.2","1.18.3","1.18.4","1.19.1","1.19.2","1.19.3","1.19.4","1.20.0","1.20.1","1.20.2","1.4.0","1.4.0-rc.0","1.4.1","1.4.2","1.4.3","1.4.4","1.4.5","1.5.0","1.5.0-rc.0","1.5.0-rc.1","1.5.0-rc.2","1.5.1","1.6.0","1.6.1","1.6.2","1.6.3","1.6.4","1.7.0","1.7.1","1.7.2","1.8.0","1.8.1","1.8.2","1.8.3","1.9.0"]}],"products":[{"vendor":"elixir-plug","product":"plug"}],"references":[{"url":"https://github.com/elixir-plug/plug/security/advisories/GHSA-95qv-c9g9-rm63","tags":["vendor-advisory","related","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-56814.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-56814","tags":["related","web"]},{"url":"https://github.com/elixir-plug/plug/commit/c52b2f32c90bccd718202bafccb5f95594e30183","tags":["related","fix","web"]},{"url":"https://github.com/elixir-plug/plug/commit/981597d3a4271ede64373c7a731702a42c500dd6","tags":["patch","fix"]},{"url":"https://github.com/elixir-plug/plug/commit/56edca2ce35fe5589cd581644d8a4493fa5f484e","tags":["patch","fix"]},{"url":"https://github.com/elixir-plug/plug/commit/0ee8afcc61466dc5f7a8f048d0632c899165b81f","tags":["patch","fix"]},{"url":"https://github.com/elixir-plug/plug/commit/cae36053350e5215a4e0ca33cd130af9c5fc6364","tags":["patch","fix"]},{"url":"https://github.com/elixir-plug/plug/commit/f7effaed811c00b5f5bf817936bfd9c5df27b7dc","tags":["patch","fix"]},{"url":"https://github.com/elixir-plug/plug/commit/df97d3f17f808a9916a7700a701fb85314559d56","tags":["patch","fix"]},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/56xxx/CVE-2026-56814.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-56814","tags":["advisory"]},{"url":"https://github.com/elixir-plug/plug","tags":["package"]},{"url":"https://hex.pm/packages/plug","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-56814","title":"Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)","description":"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.\n\nBecause 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.\n\nThis 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.\n\nThis 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.","status":"published","published":"2026-07-10T11:14:35.574Z","modified":"2026-09-24T21:31:15.419Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium","assessor":"cna"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T13:37:02.780526Z"}],"euvd":[{"id":"EUVD-2026-42873","description":"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.\n\nBecause 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.\n\nThis 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.\n\nThis 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.","status":"published","published":"2026-07-10T11:14:35Z","modified":"2026-09-24T21:31:15Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"updated_at":"2026-11-02T17:27:56.296478Z"}],"nvd":[{"id":"CVE-2026-56814","description":"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.\n\nBecause 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.\n\nThis 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.\n\nThis 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.","status":"published","published":"2026-07-10T12:17:24.837Z","modified":"2026-10-24T23:10:00.16Z","cvss":[{"version":"4.0","score":6.9,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:12:28.771746Z"}],"osv":[{"id":"CVE-2026-56814","title":"Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)","description":"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.\n\nBecause 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.\n\nThis 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.\n\nThis 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.","status":"published","published":"2026-07-10T11:14:35.574Z","modified":"2026-11-11T10:47:33.436392338Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-11T03:21:28.618498Z"},{"id":"EEF-CVE-2026-56814","title":"Plug: multipart :length limit is not charged for part headers, enabling unbounded temp-file creation (denial of service)","description":"## Summary\n\n`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.\n\nBecause 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.\n\nThis 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`.\n\nThis 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.","status":"published","published":"2026-07-10T11:14:35.574Z","modified":"2026-09-24T21:45:02.547630143Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}