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.

5412 vulnerabilities reference this CWE, most recent first.

GHSA-V432-7F47-9G94

Vulnerability from github – Published: 2025-03-17 14:48 – Updated: 2025-03-19 15:24
VLAI
Summary
PostQuantum-Feldman-VSS'S Dependency Vulnerability in gmpy2 Leading to Interpreter Crash
Details

Description:

PostQuantum-Feldman-VSS, a Python library implementing Feldman's Verifiable Secret Sharing scheme with post-quantum security, was vulnerable to denial-of-service attacks in versions up to and including 0.7.6b0. This vulnerability stems from the library's reliance on the gmpy2 library for arbitrary-precision arithmetic. gmpy2, in turn, depends on the GNU Multiple Precision Arithmetic Library (GMP). GMP, by design, terminates the process when it cannot allocate memory. An attacker could exploit this by providing carefully crafted inputs that cause gmpy2 to attempt to allocate extremely large amounts of memory, leading to a crash of the Python interpreter and thus a denial of service.

Vulnerability Details:

The core issue lies in the behavior of GMP (and thus, gmpy2) when memory allocation fails. Instead of raising a standard Python exception that could be caught and handled, GMP terminates the entire process. This behavior is documented in the GMP and gmpy2 documentation:

Specific operations within the PostQuantum-Feldman-VSS library that were particularly vulnerable include:

  • Large Exponentiation (exp, secure_exp): Exponentiation with very large bases or exponents can lead to extremely large results, consuming excessive memory.
  • Multi-exponentiation (efficient_multi_exp): Similar to exponentiation, but with multiple bases and exponents, increasing the risk.
  • Matrix Operations (_secure_matrix_solve): Large matrices used in polynomial reconstruction could lead to significant memory usage.
  • Polynomial Evaluation (_evaluate_polynomial): Evaluating polynomials with large coefficients or at large values of x could trigger excessive memory allocation.

Mitigations in 0.8.0b2:

Version 0.8.0b2 implements significant mitigations to greatly reduce the risk of this denial-of-service vulnerability. These mitigations do not completely eliminate the underlying issue (as that would require changes to GMP itself), but they make successful exploitation far more difficult. The mitigations include:

  1. Memory Monitoring (MemoryMonitor class):

    • A new MemoryMonitor class is introduced to track estimated memory usage throughout the library's operations.
    • This class allows setting a maximum memory limit (defaulting to 1024MB, but configurable).
    • It provides methods to check_allocation, allocate, and release memory, raising a MemoryError if an operation would exceed the configured limit.

  2. Memory Safety Checks (check_memory_safety function):

    • A new check_memory_safety function is used to estimate the memory requirements of various gmpy2 operations before they are executed.
    • This function considers the operation type (exp, mul, pow, mod, polynomial, matrix, polynomial_eval) and the bit lengths of the operands.
    • It uses conservative estimates and scaling factors to account for gmpy2's internal overhead.
    • If the estimated memory usage exceeds the limit set by the MemoryMonitor, the operation is rejected before calling gmpy2, preventing the crash.

  3. Integration into Core Classes:

    • The CyclicGroup and FeldmanVSS classes now use the check_memory_safety function before performing potentially memory-intensive operations like exp, mul, efficient_multi_exp, _evaluate_polynomial, and _secure_matrix_solve.

  4. Enhanced Input Validation and Error Handling:

    • Added improved input validation in functions.
    • Raises custom exceptions like SecurityError, SerializationError, VerificationError, and ParameterError that include detailed information for forensics and debugging.

  5. Safer Defaults and Configuration:

    • The library is configured to use safe primes and large bit lengths by default, reducing the likelihood of accidental misconfiguration leading to excessively large numbers.
    • The VSSConfig class allows users to customize the prime_bits and cache_size, enabling them to tailor the library to their specific memory constraints.

Limitations of Mitigations:

  • Estimation Inaccuracy: The check_memory_safety function relies on estimations of memory usage. While these estimations are conservative, they are not perfect. It is still theoretically possible (though much less likely) for an operation to consume more memory than estimated, leading to a crash.
  • GMP Behavior: The fundamental issue of GMP terminating the process on memory allocation failure remains. The mitigations prevent most common cases, but a sufficiently determined attacker with knowledge of the estimation algorithm might still be able to craft an input that triggers a crash.
  • Not a Complete Fix: Version 0.8.0b2 is a mitigation, not a complete elimination of the vulnerability.

Workarounds (for versions <= 0.7.6b0):

If upgrading to version 0.8.0b2 (or later) is not immediately possible, the following workarounds can help reduce the risk:

  • Limit Input Sizes: Carefully restrict the size of inputs to the library, particularly the bit lengths of secrets, shares, and coefficients, and the threshold value (t). Avoid using excessively large values. Use the check_memory_safety function (available in 0.8.0b2) to manually check the memory usage.
  • Resource Monitoring: Implement external monitoring of your application's memory usage. If memory usage approaches dangerous levels, take action to prevent a crash (e.g., terminate the process, reject new requests, etc.).
  • Input Validation: Thoroughly validate all inputs to the library, ensuring they are within expected ranges and of the correct types.
  • Rate Limiting: Implement rate limiting to prevent an attacker from flooding your system with requests designed to consume excessive memory.
  • Custom Memory Allocation: Advanced users could potentially modify the GMP library to use custom allocation functions that raise Python exceptions instead of terminating the process. This is a complex and potentially risky approach, and is not recommended for most users. (See GMP Custom Allocation Documentation).

Recommendations:

  • Upgrade to 0.8.0b2 (or later) as soon as possible. This is the most important step you can take.
  • Configure Memory Limits: Use the MemoryMonitor in 0.8.0b2 (or later) to set appropriate memory limits for your application. Consider your system's available memory and the expected workload.
  • Monitor Memory Usage: Even with the mitigations, continue to monitor your application's memory usage and be prepared to handle potential memory exhaustion events.
  • Follow Security Best Practices: Implement robust input validation, rate limiting, and other security measures to protect your application from various attacks, not just this specific vulnerability.

Future Work:

  • Rust Integration: The long-term solution is to implement the most memory-intensive and security-critical operations in a lower-level language like Rust, which provides more control over memory management and can avoid the problematic GMP behavior. This is planned for future versions.
  • More Precise Memory Estimation: Research and improve the accuracy of the memory estimation algorithms used in check_memory_safety.
  • Fuzz Testing: Conduct extensive fuzz testing to identify any remaining edge cases that could trigger excessive memory allocation.
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.7.6b0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PostQuantum-Feldman-VSS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.7b0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-17T14:48:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "**Description:**\n\nPostQuantum-Feldman-VSS, a Python library implementing Feldman\u0027s Verifiable Secret Sharing scheme with post-quantum security, was vulnerable to denial-of-service attacks in versions up to and including 0.7.6b0.  This vulnerability stems from the library\u0027s reliance on the `gmpy2` library for arbitrary-precision arithmetic.  `gmpy2`, in turn, depends on the GNU Multiple Precision Arithmetic Library (GMP). GMP, by design, terminates the process when it cannot allocate memory.  An attacker could exploit this by providing carefully crafted inputs that cause `gmpy2` to attempt to allocate extremely large amounts of memory, leading to a crash of the Python interpreter and thus a denial of service.\n\n**Vulnerability Details:**\n\nThe core issue lies in the behavior of GMP (and thus, `gmpy2`) when memory allocation fails.  Instead of raising a standard Python exception that could be caught and handled, GMP terminates the entire process. This behavior is documented in the GMP and gmpy2 documentation:\n\n*   **GMP Memory Management:** [https://gmplib.org/manual/Memory-Management](https://gmplib.org/manual/Memory-Management) (States that the default behavior is to terminate the program.)\n*   **gmpy2 Overview:** [https://gmpy2.readthedocs.io/en/latest/overview.html](https://gmpy2.readthedocs.io/en/latest/overview.html) (Warns that `gmpy2` can crash the interpreter on memory allocation failure.)\n\nSpecific operations within the PostQuantum-Feldman-VSS library that were particularly vulnerable include:\n\n*   **Large Exponentiation (`exp`, `secure_exp`):**  Exponentiation with very large bases or exponents can lead to extremely large results, consuming excessive memory.\n*   **Multi-exponentiation (`efficient_multi_exp`):**  Similar to exponentiation, but with multiple bases and exponents, increasing the risk.\n*   **Matrix Operations (`_secure_matrix_solve`):**  Large matrices used in polynomial reconstruction could lead to significant memory usage.\n*   **Polynomial Evaluation (`_evaluate_polynomial`):** Evaluating polynomials with large coefficients or at large values of `x` could trigger excessive memory allocation.\n\n**Mitigations in 0.8.0b2:**\n\nVersion 0.8.0b2 implements *significant mitigations* to greatly reduce the risk of this denial-of-service vulnerability.  These mitigations **do not** completely eliminate the underlying issue (as that would require changes to GMP itself), but they make successful exploitation *far* more difficult.  The mitigations include:\n\n1.  **Memory Monitoring (`MemoryMonitor` class):**\n    *   A new `MemoryMonitor` class is introduced to track estimated memory usage throughout the library\u0027s operations.\n    *   This class allows setting a maximum memory limit (defaulting to 1024MB, but configurable).\n    *   It provides methods to `check_allocation`, `allocate`, and `release` memory, raising a `MemoryError` if an operation would exceed the configured limit.\n\n2.  **Memory Safety Checks (`check_memory_safety` function):**\n    *   A new `check_memory_safety` function is used to estimate the memory requirements of various `gmpy2` operations *before* they are executed.\n    *   This function considers the operation type (`exp`, `mul`, `pow`, `mod`, `polynomial`, `matrix`, `polynomial_eval`) and the bit lengths of the operands.\n    *   It uses conservative estimates and scaling factors to account for `gmpy2`\u0027s internal overhead.\n    *   If the estimated memory usage exceeds the limit set by the `MemoryMonitor`, the operation is rejected *before* calling `gmpy2`, preventing the crash.\n\n3.  **Integration into Core Classes:**\n    *   The `CyclicGroup` and `FeldmanVSS` classes now use the `check_memory_safety` function before performing potentially memory-intensive operations like `exp`, `mul`, `efficient_multi_exp`, `_evaluate_polynomial`, and `_secure_matrix_solve`.\n\n4.  **Enhanced Input Validation and Error Handling:**\n    *  Added improved input validation in functions.\n    *  Raises custom exceptions like `SecurityError`, `SerializationError`, `VerificationError`, and `ParameterError` that include detailed information for forensics and debugging.\n\n5.  **Safer Defaults and Configuration:**\n    *   The library is configured to use safe primes and large bit lengths by default, reducing the likelihood of accidental misconfiguration leading to excessively large numbers.\n    *   The `VSSConfig` class allows users to customize the `prime_bits` and `cache_size`, enabling them to tailor the library to their specific memory constraints.\n\n**Limitations of Mitigations:**\n\n*   **Estimation Inaccuracy:** The `check_memory_safety` function relies on *estimations* of memory usage. While these estimations are conservative, they are not perfect.  It is still theoretically possible (though much less likely) for an operation to consume more memory than estimated, leading to a crash.\n*   **GMP Behavior:** The fundamental issue of GMP terminating the process on memory allocation failure remains.  The mitigations prevent most common cases, but a sufficiently determined attacker with knowledge of the estimation algorithm *might* still be able to craft an input that triggers a crash.\n*   **Not a Complete Fix:** Version 0.8.0b2 is a *mitigation*, not a complete *elimination* of the vulnerability.\n\n**Workarounds (for versions \u003c= 0.7.6b0):**\n\nIf upgrading to version 0.8.0b2 (or later) is not immediately possible, the following workarounds can help reduce the risk:\n\n*   **Limit Input Sizes:**  Carefully restrict the size of inputs to the library, particularly the bit lengths of secrets, shares, and coefficients, and the threshold value (t).  Avoid using excessively large values.  Use the `check_memory_safety` function (available in 0.8.0b2) to manually check the memory usage.\n*   **Resource Monitoring:** Implement external monitoring of your application\u0027s memory usage.  If memory usage approaches dangerous levels, take action to prevent a crash (e.g., terminate the process, reject new requests, etc.).\n*   **Input Validation:** Thoroughly validate all inputs to the library, ensuring they are within expected ranges and of the correct types.\n*   **Rate Limiting:** Implement rate limiting to prevent an attacker from flooding your system with requests designed to consume excessive memory.\n*  **Custom Memory Allocation**:  *Advanced users* could potentially modify the GMP library to use custom allocation functions that raise Python exceptions instead of terminating the process.  This is a complex and potentially risky approach, and is **not recommended** for most users.  (See [GMP Custom Allocation Documentation](https://gmplib.org/manual/Custom-Allocation)).\n\n**Recommendations:**\n\n*   **Upgrade to 0.8.0b2 (or later) as soon as possible.** This is the *most important* step you can take.\n*   **Configure Memory Limits:**  Use the `MemoryMonitor` in 0.8.0b2 (or later) to set appropriate memory limits for your application.  Consider your system\u0027s available memory and the expected workload.\n*   **Monitor Memory Usage:**  Even with the mitigations, continue to monitor your application\u0027s memory usage and be prepared to handle potential memory exhaustion events.\n*   **Follow Security Best Practices:**  Implement robust input validation, rate limiting, and other security measures to protect your application from various attacks, not just this specific vulnerability.\n\n**Future Work:**\n\n*   **Rust Integration:**  The long-term solution is to implement the most memory-intensive and security-critical operations in a lower-level language like Rust, which provides more control over memory management and can avoid the problematic GMP behavior. This is planned for future versions.\n*   **More Precise Memory Estimation:**  Research and improve the accuracy of the memory estimation algorithms used in `check_memory_safety`.\n*   **Fuzz Testing:**  Conduct extensive fuzz testing to identify any remaining edge cases that could trigger excessive memory allocation.",
  "id": "GHSA-v432-7f47-9g94",
  "modified": "2025-03-19T15:24:59Z",
  "published": "2025-03-17T14:48:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS/security/advisories/GHSA-v432-7f47-9g94"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS"
    }
  ],
  "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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PostQuantum-Feldman-VSS\u0027S Dependency Vulnerability in gmpy2 Leading to Interpreter Crash"
}

GHSA-V435-P7H6-V9PJ

Vulnerability from github – Published: 2025-04-11 15:32 – Updated: 2025-04-14 21:32
VLAI
Details

Processing a file may lead to a denial-of-service or potentially disclose memory contents. This issue is fixed in macOS 14. The issue was addressed with improved checks.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-42983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-11T15:15:45Z",
    "severity": "MODERATE"
  },
  "details": "Processing a file may lead to a denial-of-service or potentially disclose memory contents. This issue is fixed in macOS 14. The issue was addressed with improved checks.",
  "id": "GHSA-v435-p7h6-v9pj",
  "modified": "2025-04-14T21:32:24Z",
  "published": "2025-04-11T15:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42983"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120950"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V43V-R57X-CXJW

Vulnerability from github – Published: 2022-05-24 17:15 – Updated: 2022-05-24 17:15
VLAI
Details

A Denial of Service vulnerability related to stack exhaustion has been identified in FlexNet Publisher lmadmin.exe 11.16.2. Because the message reading function calls itself recursively given a certain condition in the received message, an unauthenticated remote attacker can repeatedly send messages of that type to cause a stack exhaustion condition.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-8961"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-21T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Denial of Service vulnerability related to stack exhaustion has been identified in FlexNet Publisher lmadmin.exe 11.16.2. Because the message reading function calls itself recursively given a certain condition in the received message, an unauthenticated remote attacker can repeatedly send messages of that type to cause a stack exhaustion condition.",
  "id": "GHSA-v43v-r57x-cxjw",
  "modified": "2022-05-24T17:15:55Z",
  "published": "2022-05-24T17:15:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8961"
    },
    {
      "type": "WEB",
      "url": "https://community.flexera.com/t5/FlexNet-Publisher-Knowledge-Base/CVE-2019-8961-remediated-in-FlexNet-Publisher/ta-p/124601/jump-to/first-unread-message"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V457-WXVJ-P9W9

Vulnerability from github – Published: 2026-04-10 15:36 – Updated: 2026-04-10 15:36
VLAI
Summary
@vitejs/plugin-rsc has a Denial of Service with React Server Components
Details

Impact

@vitejs/plugin-rsc vendors react-server-dom-webpack, which contained a vulnerability in versions prior to 19.2.4. See details in React repository's advisory https://github.com/facebook/react/security/advisories/GHSA-479c-33wc-g2pg

Patches

Upgrade immediately to @vitejs/plugin-rsc@0.5.23 or later.

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.5.22"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@vitejs/plugin-rsc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T15:36:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`@vitejs/plugin-rsc` vendors `react-server-dom-webpack`, which contained a vulnerability in versions prior to 19.2.4. See details in React repository\u0027s advisory https://github.com/facebook/react/security/advisories/GHSA-479c-33wc-g2pg\n\n### Patches\n\nUpgrade immediately to `@vitejs/plugin-rsc@0.5.23` or later.",
  "id": "GHSA-v457-wxvj-p9w9",
  "modified": "2026-04-10T15:36:00Z",
  "published": "2026-04-10T15:36:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite-plugin-react/security/advisories/GHSA-v457-wxvj-p9w9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitejs/vite-plugin-react"
    }
  ],
  "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": "@vitejs/plugin-rsc has a Denial of Service with React Server Components"
}

GHSA-V464-R2R9-WWW7

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 17:25
VLAI
Summary
Ollama Vulnerable to Denial of Service (DoS) via Crafted GZIP
Details

An Out-Of-Memory (OOM) vulnerability exists in the ollama server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the ollama server crashing. The vulnerability is present in the makeRequestWithRetry and getAuthorizationToken functions, which use io.ReadAll to read the response body. This can result in excessive memory usage and a Denial of Service (DoS) condition.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ollama/ollama"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-12886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T17:25:07Z",
    "nvd_published_at": "2025-03-20T10:15:31Z",
    "severity": "HIGH"
  },
  "details": "An Out-Of-Memory (OOM) vulnerability exists in the `ollama` server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the `ollama` server crashing. The vulnerability is present in the `makeRequestWithRetry` and `getAuthorizationToken` functions, which use `io.ReadAll` to read the response body. This can result in excessive memory usage and a Denial of Service (DoS) condition.",
  "id": "GHSA-v464-r2r9-www7",
  "modified": "2025-03-21T17:25:07Z",
  "published": "2025-03-20T12:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12886"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ollama/ollama"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/f115fe52-58af-4844-ad29-b1c25f7245df"
    }
  ],
  "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": "Ollama Vulnerable to Denial of Service (DoS) via Crafted GZIP"
}

GHSA-V47J-C7R7-829C

Vulnerability from github – Published: 2024-07-11 18:31 – Updated: 2024-07-11 18:31
VLAI
Details

An Uncontrolled Resource Consumption vulnerability in the aftmand process of Juniper Networks Junos OS Evolved allows an unauthenticated, network-based attacker to consume memory resources, resulting in a Denial of Service (DoS) condition. The processes do not recover on their own and must be manually restarted.

This issue affects both IPv4 and IPv6. 

Changes in memory usage can be monitored using the following CLI command: user@device> show system memory node | grep evo-aftmann This issue affects Junos OS Evolved: 

  • All versions before 21.2R3-S8-EVO, 
  • 21.3 versions before 21.3R3-S5-EVO, 
  • 21.4 versions before 21.4R3-S5-EVO, 
  • 22.1 versions before 22.1R3-S4-EVO, 
  • 22.2 versions before 22.2R3-S4-EVO,
  • 22.3 versions before 22.3R3-S3-EVO,
  • 22.4 versions before 22.4R2-S2-EVO, 22.4R3-EVO, 
  • 23.2 versions before 23.2R1-S1-EVO, 23.2R2-EVO.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/R:U
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-39548"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-11T17:15:14Z",
    "severity": "HIGH"
  },
  "details": "An Uncontrolled Resource Consumption vulnerability in the aftmand process of Juniper Networks Junos OS Evolved allows an unauthenticated, network-based attacker to consume memory resources, resulting in a Denial of Service (DoS) condition. The processes do not recover on their own and must be manually restarted.\n\nThis issue affects both IPv4 and IPv6.\u00a0\n\nChanges in memory usage can be monitored using the following CLI command:\nuser@device\u003e show system memory node \u003cfpc slot\u003e | grep evo-aftmann\nThis issue affects Junos OS Evolved:\u00a0\n\n\n\n  *  All versions before 21.2R3-S8-EVO,\u00a0\n  *  21.3 versions before 21.3R3-S5-EVO,\u00a0\n  *  21.4 versions before 21.4R3-S5-EVO,\u00a0\n  *  22.1 versions before 22.1R3-S4-EVO,\u00a0\n  *  22.2 versions before 22.2R3-S4-EVO,\n  *  22.3 versions before 22.3R3-S3-EVO,\n  *  22.4 versions before 22.4R2-S2-EVO, 22.4R3-EVO,\u00a0\n  *  23.2 versions before 23.2R1-S1-EVO, 23.2R2-EVO.",
  "id": "GHSA-v47j-c7r7-829c",
  "modified": "2024-07-11T18:31:14Z",
  "published": "2024-07-11T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39548"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA83010"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-V47R-RWV6-47CQ

Vulnerability from github – Published: 2022-05-14 00:54 – Updated: 2022-05-14 00:54
VLAI
Details

CiffDirectory::readDirectory() at crwimage_int.cpp in Exiv2 0.26 has excessive stack consumption due to a recursive function, leading to Denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-17581"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-28T09:29:00Z",
    "severity": "MODERATE"
  },
  "details": "CiffDirectory::readDirectory() at crwimage_int.cpp in Exiv2 0.26 has excessive stack consumption due to a recursive function, leading to Denial of service.",
  "id": "GHSA-v47r-rwv6-47cq",
  "modified": "2022-05-14T00:54:46Z",
  "published": "2022-05-14T00:54:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17581"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Exiv2/exiv2/issues/460"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SegfaultMasters/covering360/blob/master/Exiv2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/02/msg00038.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00004.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3852-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V486-MQFX-FV74

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2022-05-24 00:01
VLAI
Details

Windows User Account Profile Picture Denial of Service Vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-22002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Windows User Account Profile Picture Denial of Service Vulnerability.",
  "id": "GHSA-v486-mqfx-fv74",
  "modified": "2022-05-24T00:01:04Z",
  "published": "2022-02-10T00:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22002"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-22002"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-22002"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-317"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4C2-68G7-MPCF

Vulnerability from github – Published: 2025-10-28 18:30 – Updated: 2025-10-29 15:31
VLAI
Details

Bitcoin Core through 29.0 allows Uncontrolled Resource Consumption (issue 2 of 2).

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-54605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-28T17:15:37Z",
    "severity": "HIGH"
  },
  "details": "Bitcoin Core through 29.0 allows Uncontrolled Resource Consumption (issue 2 of 2).",
  "id": "GHSA-v4c2-68g7-mpcf",
  "modified": "2025-10-29T15:31:54Z",
  "published": "2025-10-28T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54605"
    },
    {
      "type": "WEB",
      "url": "https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-54605"
    },
    {
      "type": "WEB",
      "url": "https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bitcoin/bitcoin/releases"
    }
  ],
  "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-V4CP-84G9-JWMP

Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-10-27 19:00
VLAI
Details

A vulnerability in the PROFINET feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, adjacent attacker to cause an affected device to crash and reload, resulting in a denial of service (DoS) condition on the device. The vulnerability is due to insufficient processing logic for crafted PROFINET packets that are sent to an affected device. An attacker could exploit this vulnerability by sending crafted PROFINET packets to an affected device for processing. A successful exploit could allow the attacker to cause the device to crash and reload, resulting in a DoS condition on the device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-3409"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-24T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the PROFINET feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, adjacent attacker to cause an affected device to crash and reload, resulting in a denial of service (DoS) condition on the device. The vulnerability is due to insufficient processing logic for crafted PROFINET packets that are sent to an affected device. An attacker could exploit this vulnerability by sending crafted PROFINET packets to an affected device for processing. A successful exploit could allow the attacker to cause the device to crash and reload, resulting in a DoS condition on the device.",
  "id": "GHSA-v4cp-84g9-jwmp",
  "modified": "2022-10-27T19:00:33Z",
  "published": "2022-05-24T17:29:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3409"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-profinet-J9QMCHPB"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/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