CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5645 vulnerabilities reference this CWE, most recent first.
GHSA-72WR-XHP6-G67F
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40ZIV Automation 4CCT-EA6-334126BF firmware version 3.23.80.27.36371, allows an unauthenticated, remote attacker to cause a denial of service condition on the device. An attacker could exploit this vulnerability by sending specific packets to the port 7919.
{
"affected": [],
"aliases": [
"CVE-2021-25909"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-29T14:15:00Z",
"severity": "HIGH"
},
"details": "ZIV Automation 4CCT-EA6-334126BF firmware version 3.23.80.27.36371, allows an unauthenticated, remote attacker to cause a denial of service condition on the device. An attacker could exploit this vulnerability by sending specific packets to the port 7919.",
"id": "GHSA-72wr-xhp6-g67f",
"modified": "2022-05-24T17:40:38Z",
"published": "2022-05-24T17:40:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25909"
},
{
"type": "WEB",
"url": "https://www.incibe-cert.es/en/early-warning/ics-advisories/4cct-vulnerable-denial-service-attack"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7325-GCX9-7XH4
Vulnerability from github – Published: 2024-01-19 21:30 – Updated: 2024-01-19 21:30An incorrect permissions vulnerability was reported in the Lenovo App Store app that could allow an attacker to use system resources, resulting in a denial of service.
{
"affected": [],
"aliases": [
"CVE-2023-6450"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-404"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-19T20:15:12Z",
"severity": "MODERATE"
},
"details": "An incorrect permissions vulnerability was reported in the Lenovo App Store app that could allow an attacker to use system resources, resulting in a denial of service.",
"id": "GHSA-7325-gcx9-7xh4",
"modified": "2024-01-19T21:30:36Z",
"published": "2024-01-19T21:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6450"
},
{
"type": "WEB",
"url": "https://iknow.lenovo.com.cn/detail/419672"
}
],
"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-733M-275P-P27Q
Vulnerability from github – Published: 2022-05-24 17:16 – Updated: 2024-04-04 02:50CServer::SendMsg in engine/server/server.cpp in Teeworlds 0.7.x before 0.7.5 allows remote attackers to shut down the server.
{
"affected": [],
"aliases": [
"CVE-2020-12066"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-22T17:15:00Z",
"severity": "HIGH"
},
"details": "CServer::SendMsg in engine/server/server.cpp in Teeworlds 0.7.x before 0.7.5 allows remote attackers to shut down the server.",
"id": "GHSA-733m-275p-p27q",
"modified": "2024-04-04T02:50:01Z",
"published": "2022-05-24T17:16:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12066"
},
{
"type": "WEB",
"url": "https://github.com/teeworlds/teeworlds/commit/c68402fa7e279d42886d5951d1ea8ac2facc1ea5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AVYG7CCPS5F3OPOQMJKVNXTQ7BXSEX2V"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AVYG7CCPS5F3OPOQMJKVNXTQ7BXSEX2V"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4553-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4763"
},
{
"type": "WEB",
"url": "https://www.teeworlds.com/forum/viewtopic.php?id=14785"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00044.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00045.html"
}
],
"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-733V-P3H5-QPQ7
Vulnerability from github – Published: 2025-04-25 15:14 – Updated: 2025-04-29 16:45Summary
A query cost restriction using the cost-limit can be bypassed if ignoreIntrospection is enabled (which is the default configuration) by naming your query/fragment __schema.
Details
At the start of the computeComplexity function, we have the following check for ignoreIntrospection option:
if (this.config.ignoreIntrospection && 'name' in node && node.name?.value === '__schema') {
return 0;
}
However, the node can be FieldNode | FragmentDefinitionNode | InlineFragmentNode | OperationDefinitionNode | FragmentSpreadNode
So, for example, sending the following query
query hello {
books {
title
}
}
would create an OperationDefinitionNode with node.name.value == 'hello'
The proper way to handle this would be to check for the __schema field, which would create a FieldNode.
The fix is
if (
this.config.ignoreIntrospection &&
'name' in node &&
node.name?.value === '__schema' &&
node.kind === Kind.FIELD
) {
return 0;
}
to assert that the node must be a FieldNode
PoC
query {
...__schema
}
fragment __schema on Query {
books {
title
author
}
}
query __schema {
books {
title
author
}
}
Impact
Applications using GraphQL Armor Cost Limit plugin with ignoreIntrospection enabled.
Fix:
Fixed on 772. A quick patch would be to set ignoreIntrospection to false.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@escape.tech/graphql-armor-cost-limit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-25T15:14:36Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nA query cost restriction using the `cost-limit` can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`.\n\n### Details\nAt the start of the `computeComplexity` function, we have the following check for `ignoreIntrospection` option:\n\n```ts\n if (this.config.ignoreIntrospection \u0026\u0026 \u0027name\u0027 in node \u0026\u0026 node.name?.value === \u0027__schema\u0027) {\n return 0;\n }\n```\n\nHowever, the `node` can be `FieldNode | FragmentDefinitionNode | InlineFragmentNode | OperationDefinitionNode | FragmentSpreadNode`\n\nSo, for example, sending the following query\n\n```gql\nquery hello {\n books {\n title\n }\n}\n```\n\nwould create an `OperationDefinitionNode` with `node.name.value == \u0027hello\u0027`\n\nThe proper way to handle this would be to check for the `__schema` field, which would create a `FieldNode`.\n\nThe fix is\n\n```ts\n if (\n this.config.ignoreIntrospection \u0026\u0026\n \u0027name\u0027 in node \u0026\u0026\n node.name?.value === \u0027__schema\u0027 \u0026\u0026\n node.kind === Kind.FIELD\n ) {\n return 0;\n }\n```\n\nto assert that the node must be a `FieldNode`\n\n### PoC\n```gql\nquery {\n ...__schema\n}\n\nfragment __schema on Query {\n books {\n title\n author\n }\n}\n```\n\n```gql\nquery __schema {\n books {\n title\n author\n }\n}\n```\n\n### Impact\nApplications using GraphQL Armor Cost Limit plugin with `ignoreIntrospection` enabled.\n\n### Fix:\nFixed on [772](https://github.com/Escape-Technologies/graphql-armor/pull/772). A quick patch would be to set `ignoreIntrospection` to false.",
"id": "GHSA-733v-p3h5-qpq7",
"modified": "2025-04-29T16:45:56Z",
"published": "2025-04-25T15:14:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Escape-Technologies/graphql-armor/security/advisories/GHSA-733v-p3h5-qpq7"
},
{
"type": "WEB",
"url": "https://github.com/Escape-Technologies/graphql-armor/pull/772"
},
{
"type": "WEB",
"url": "https://github.com/Escape-Technologies/graphql-armor/commit/5a329541cf32a359ee1f69748738f91231b26eba"
},
{
"type": "PACKAGE",
"url": "https://github.com/Escape-Technologies/graphql-armor"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "GraphQL Armor Cost-Limit Plugin Bypass via Introspection Query Obfuscation"
}
GHSA-735F-PC8J-V9W8
Vulnerability from github – Published: 2024-09-19 16:06 – Updated: 2025-09-10 20:53Summary
When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.
Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team ecosystem@trailofbits.com
Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.
Severity
CVE-2024-7254 High CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.
Proof of Concept
For reproduction details, please refer to the unit tests (Protobuf Java LiteTest and CodedInputStreamTest) that identify the specific inputs that exercise this parsing weakness.
Remediation and Mitigation
We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: * protobuf-java (3.25.5, 4.27.5, 4.28.2) * protobuf-javalite (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) * com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0.rc.1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0.rc.1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-7254"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-19T16:06:03Z",
"nvd_published_at": "2024-09-19T01:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nWhen parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.\n\nReporter: Alexis Challande, Trail of Bits Ecosystem Security Team \u003cecosystem@trailofbits.com\u003e\n\nAffected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.\n\n### Severity\n[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication)\nThis is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.\n\n### Proof of Concept\nFor reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness.\n\n### Remediation and Mitigation\nWe have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages:\n* protobuf-java (3.25.5, 4.27.5, 4.28.2)\n* protobuf-javalite (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2)\n* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)",
"id": "GHSA-735f-pc8j-v9w8",
"modified": "2025-09-10T20:53:03Z",
"published": "2024-09-19T16:06:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-735f-pc8j-v9w8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7254"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/4728531c162f2f9e8c2ca1add713cfee2db6be3b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/850fcce9176e2c9070614dab53537760498c926b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/9a5f5fe752a20cbac2e722b06949ac985abdd534"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/ac9fb5b4c71b0dd80985b27684e265d1f03abf46"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/cc8b3483a5584b3301e3d43d17eb59704857ffaa"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/d6c82fc55a76481c676f541a255571e8950bb8c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/google-protobuf/CVE-2024-7254.yml"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241213-0010"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250418-0006"
}
],
"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": "protobuf-java has potential Denial of Service issue"
}
GHSA-736H-7P7R-VH9C
Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2025-11-04 18:31Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.37 and prior and 8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2024-21171"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T23:15:20Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.37 and prior and 8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-736h-7p7r-vh9c",
"modified": "2025-11-04T18:31:08Z",
"published": "2024-07-17T00:32:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21171"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240801-0001"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2024.html"
}
],
"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-737H-R3Q7-C58R
Vulnerability from github – Published: 2023-04-13 00:30 – Updated: 2025-11-04 00:30GQUIC dissector crash in Wireshark 4.0.0 to 4.0.4 and 3.6.0 to 3.6.12 allows denial of service via packet injection or crafted capture file
{
"affected": [],
"aliases": [
"CVE-2023-1994"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-12T22:15:00Z",
"severity": "MODERATE"
},
"details": "GQUIC dissector crash in Wireshark 4.0.0 to 4.0.4 and 3.6.0 to 3.6.12 allows denial of service via packet injection or crafted capture file",
"id": "GHSA-737h-r3q7-c58r",
"modified": "2025-11-04T00:30:37Z",
"published": "2023-04-13T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1994"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2023/CVE-2023-1994.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/wireshark/wireshark/-/issues/18947"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/04/msg00029.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00049.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EHLTD25WNQSPQNELX52UH6YLP4TBLKTT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FZA7IMATNNQPLIM6WMRPM3T5ZY24NRR2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PFJERBHVWYLYWXO2B3V47QH66IEB6EZ3"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EHLTD25WNQSPQNELX52UH6YLP4TBLKTT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FZA7IMATNNQPLIM6WMRPM3T5ZY24NRR2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PFJERBHVWYLYWXO2B3V47QH66IEB6EZ3"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202309-02"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5429"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2023-11.html"
}
],
"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-73CQ-MCGH-379C
Vulnerability from github – Published: 2026-08-04 20:42 – Updated: 2026-08-04 20:42Summary
In every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single FREQ=MINUTELY rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop.
Preconditions
Any user who can create an automation. USER_PERMISSIONS_FEATURES_AUTOMATIONS defaults to false, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. UVICORN_WORKERS defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: FREQ=MINUTELY with no DTSTART, or with a DTSTART set well in the past, is enough.
Impact
Availability, against every other user of the instance. One evaluation of RRULE:FREQ=MINUTELY takes 18.9 s of blocking CPU; adding a ten-value BYSECOND list multiplies the walk and takes 64.2 s. FREQ=HOURLY costs 0.34 s and is not materially exploitable on its own. The cost does not stop at creation: once the automation is stored, the scheduler recomputes the next run for every claimed row on each poll, so the same walk repeats on a default 10 s interval and the instance stays wedged rather than recovering. Instances that have not enabled the automations feature for non-admin users are exposed only to an admin doing this.
Fix
Fixed in 0.11.0. Sub-daily rules are now anchored to the current clock instead of the year-2000 date, so the walk starts at the next occurrence rather than a quarter-century behind it. A caller-supplied DTSTART is honoured only when the number of occurrences it implies stays under a fixed bound, and is otherwise replaced by the clock-aligned anchor. The same rules that cost 18.9 s and 64.2 s now cost under a millisecond. Upgrading fully resolves the issue, no configuration change is required.
Root cause
Affected component: backend/open_webui/utils/automations.py, _parse_rule, reached from the automation create, update and toggle handlers in backend/open_webui/routers/automations.py and from the scheduler's claim path in backend/open_webui/models/automations.py. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped.
The fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that "every 5 minutes" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread.
Proof of concept
Measured cost of a single next-run computation against the shipped 0.10.2 parser:
| rule | cost |
|---|---|
RRULE:FREQ=MINUTELY |
18,880 ms |
RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9 |
64,236 ms |
DTSTART:20000101T000000 + RRULE:FREQ=MINUTELY |
26,237 ms |
RRULE:FREQ=HOURLY |
339 ms |
Measured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance.
Credits
Reported by @Classic298.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70489"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T20:42:34Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nIn every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single `FREQ=MINUTELY` rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop.\n\n## Preconditions\nAny user who can create an automation. `USER_PERMISSIONS_FEATURES_AUTOMATIONS` defaults to `false`, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. `UVICORN_WORKERS` defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: `FREQ=MINUTELY` with no `DTSTART`, or with a `DTSTART` set well in the past, is enough.\n\n## Impact\nAvailability, against every other user of the instance. One evaluation of `RRULE:FREQ=MINUTELY` takes 18.9 s of blocking CPU; adding a ten-value `BYSECOND` list multiplies the walk and takes 64.2 s. `FREQ=HOURLY` costs 0.34 s and is not materially exploitable on its own. The cost does not stop at creation: once the automation is stored, the scheduler recomputes the next run for every claimed row on each poll, so the same walk repeats on a default 10 s interval and the instance stays wedged rather than recovering. Instances that have not enabled the automations feature for non-admin users are exposed only to an admin doing this.\n\n## Fix\nFixed in 0.11.0. Sub-daily rules are now anchored to the current clock instead of the year-2000 date, so the walk starts at the next occurrence rather than a quarter-century behind it. A caller-supplied `DTSTART` is honoured only when the number of occurrences it implies stays under a fixed bound, and is otherwise replaced by the clock-aligned anchor. The same rules that cost 18.9 s and 64.2 s now cost under a millisecond. Upgrading fully resolves the issue, no configuration change is required.\n\n## Root cause\nAffected component: `backend/open_webui/utils/automations.py`, `_parse_rule`, reached from the automation create, update and toggle handlers in `backend/open_webui/routers/automations.py` and from the scheduler\u0027s claim path in `backend/open_webui/models/automations.py`. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped.\n\nThe fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that \"every 5 minutes\" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread.\n\n## Proof of concept\nMeasured cost of a single next-run computation against the shipped 0.10.2 parser:\n\n| rule | cost |\n| --- | --- |\n| `RRULE:FREQ=MINUTELY` | 18,880 ms |\n| `RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9` | 64,236 ms |\n| `DTSTART:20000101T000000` + `RRULE:FREQ=MINUTELY` | 26,237 ms |\n| `RRULE:FREQ=HOURLY` | 339 ms |\n\nMeasured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance.\n\n## Credits\nReported by @Classic298.",
"id": "GHSA-73cq-mcgh-379c",
"modified": "2026-08-04T20:42:34Z",
"published": "2026-08-04T20:42:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-73cq-mcgh-379c"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/c4ae8c86786fed521960466f6d8eef8af22c2946"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.0"
}
],
"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"
}
],
"summary": "Open WebUI: Instance-wide stall via automation recurrence rules that force multi-second parsing"
}
GHSA-73JC-5MRQ-PRW7
Vulnerability from github – Published: 2026-05-19 20:10 – Updated: 2026-07-06 22:53Impact
In deployments where untrusted users can provide SQL queries to be linted, an untrusted user can submit a malicious long query to any application using the parser to trigger a Denial of Service through resource exhaustion.
Patches
Versions 4.2.0 and up contain a configurable parse node limit, which is enabled by default, to prevent this manner of exploit.
Credit
Ori Nakar from Imperva Threat Research Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "sqlfluff"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46374"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:10:53Z",
"nvd_published_at": "2026-06-09T23:16:59Z",
"severity": "HIGH"
},
"details": "### Impact\n\nIn deployments where untrusted users can provide SQL queries to be linted, an untrusted user can submit a malicious long query to any application using the parser to trigger a Denial of Service through resource exhaustion.\n\n### Patches\n\nVersions 4.2.0 and up contain a configurable parse node limit, which is enabled by default, to prevent this manner of exploit.\n\n### Credit\n\nOri Nakar from Imperva Threat Research Team.",
"id": "GHSA-73jc-5mrq-prw7",
"modified": "2026-07-06T22:53:28Z",
"published": "2026-05-19T20:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sqlfluff/sqlfluff/security/advisories/GHSA-73jc-5mrq-prw7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46374"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/sqlfluff/PYSEC-2026-210.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/sqlfluff/sqlfluff"
}
],
"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": "SQLFluff: Uncontrolled Resource Consumption in SQLFluff Parser"
}
GHSA-73M2-3PWG-5FGC
Vulnerability from github – Published: 2020-02-04 03:07 – Updated: 2024-11-19 15:34Impact
When waitress receives a header that contains invalid characters it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions.
This would allow an attacker to send a single request with an invalid header and take the service offline.
Invalid header example:
Bad-header: xxxxxxxxxxxxxxx\x10
Increasing the number of x's in the header will increase the amount of time Waitress spends in the regular expression engine.
This issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230.
Patches
The regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible.
Workarounds
If you have deployed a reverse proxy in front of Waitress it may already be rejecting requests that include invalid headers.
Thanks
The Pylons Project would like to thank Fil Zembowicz for reaching out and disclosing this vulnerability!
References
Catastrophic backtracking explained: https://www.regular-expressions.info/catastrophic.html
For more information
If you have any questions or comments about this advisory:
- open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)
- email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "waitress"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.2"
},
{
"fixed": "1.4.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.4.2"
]
}
],
"aliases": [
"CVE-2020-5236"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-02-04T03:06:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen waitress receives a header that contains invalid characters it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions.\n\nThis would allow an attacker to send a single request with an invalid header and take the service offline.\n\nInvalid header example:\n\n```\nBad-header: xxxxxxxxxxxxxxx\\x10\n```\n\nIncreasing the number of `x`\u0027s in the header will increase the amount of time Waitress spends in the regular expression engine.\n\nThis issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230.\n\n### Patches\n\nThe regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible.\n\n### Workarounds\n\nIf you have deployed a reverse proxy in front of Waitress it may already be rejecting requests that include invalid headers.\n\n### Thanks\n\nThe Pylons Project would like to thank [Fil Zembowicz](https://github.com/fzembow) for reaching out and disclosing this vulnerability!\n\n### References\n\nCatastrophic backtracking explained: https://www.regular-expressions.info/catastrophic.html\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)\n- email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)",
"id": "GHSA-73m2-3pwg-5fgc",
"modified": "2024-11-19T15:34:34Z",
"published": "2020-02-04T03:07:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/security/advisories/GHSA-73m2-3pwg-5fgc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5236"
},
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/commit/6e46f9e3f014d64dd7d1e258eaf626e39870ee1f"
},
{
"type": "PACKAGE",
"url": "https://github.com/Pylons/waitress"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/waitress/PYSEC-2020-155.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Catastrophic backtracking in regex allows Denial of Service in Waitress"
}
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.