CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6200 vulnerabilities reference this CWE, most recent first.
GHSA-484G-RJCP-74RC
Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2022-05-24 17:12An exploitable denial-of-service vulnerability exists in the resource allocation handling of Videolabs libmicrodns 0.1.0. When encountering errors while parsing mDNS messages, some allocated data is not freed, possibly leading to a denial-of-service condition via resource exhaustion. An attacker can send one mDNS message repeatedly to trigger this vulnerability through decoding of the domain name performed by rr_decode.
{
"affected": [],
"aliases": [
"CVE-2020-6079"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-24T21:15:00Z",
"severity": "MODERATE"
},
"details": "An exploitable denial-of-service vulnerability exists in the resource allocation handling of Videolabs libmicrodns 0.1.0. When encountering errors while parsing mDNS messages, some allocated data is not freed, possibly leading to a denial-of-service condition via resource exhaustion. An attacker can send one mDNS message repeatedly to trigger this vulnerability through decoding of the domain name performed by rr_decode.",
"id": "GHSA-484g-rjcp-74rc",
"modified": "2022-05-24T17:12:34Z",
"published": "2022-05-24T17:12:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6079"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202005-10"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1002"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4671"
}
],
"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-4857-C55P-2WHX
Vulnerability from github – Published: 2022-04-22 00:24 – Updated: 2024-04-03 23:05A local file inclusion flaw was found in the way the phpLDAPadmin before 0.9.8 processed certain values of the "Accept-Language" HTTP header. A remote attacker could use this flaw to cause a denial of service via specially-crafted request.
{
"affected": [],
"aliases": [
"CVE-2011-4082"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-26T05:15:00Z",
"severity": "HIGH"
},
"details": "A local file inclusion flaw was found in the way the phpLDAPadmin before 0.9.8 processed certain values of the \"Accept-Language\" HTTP header. A remote attacker could use this flaw to cause a denial of service via specially-crafted request.",
"id": "GHSA-4857-c55p-2whx",
"modified": "2024-04-03T23:05:42Z",
"published": "2022-04-22T00:24:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-4082"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2011-4082"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4082"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2011-4082"
}
],
"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-485P-MRJ5-8W2V
Vulnerability from github – Published: 2022-10-21 20:50 – Updated: 2025-01-02 21:55Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 6.0, .NET 5.0 and .NET Core 3.1. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
A vulnerability exists in .NET 6.0, .NET 5.0 and .NET Core 3.1 where a malicious client can cause a Denial of Service via excess memory allocations through HttpClient.
Affected software
- Any .NET 6.0 application running on .NET 6.0.4 or earlier.
- Any .NET 5.0 application running .NET 5.0.16 or earlier.
- Any .NET Core 3.1 applicaiton running on .NET Core 3.1.24 or earlier.
Patches
-
If you're using .NET Core 6.0, you should download and install Runtime 6.0.5 or SDK 6.0.105 (for Visual Studio 2022 v17.0) or SDK 6.0.203 (for Visual Studio 2022 v17.1) from https://dotnet.microsoft.com/download/dotnet-core/6.0.
-
If you're using .NET 5.0, you should download and install Runtime 5.0.17 or SDK 5.0.214 (for Visual Studio 2019 v16.9) or SDK 5.0.408 (for Visual Studio 2011 v16.11) from https://dotnet.microsoft.com/download/dotnet-core/5.0.
-
If you're using .NET Core 3.1, you should download and install Runtime 3.1.25 or SDK 3.1.419 (for Visual Studio 2019 v16.9 or Visual Studio 2011 16.11 or Visual Studio 2022 17.0 or Visual Studio 2022 17.1 ) from https://dotnet.microsoft.com/download/dotnet-core/3.1.
.NET 6.0, .NET 5.0 and .NET Core 3.1 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.
Other Details
Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/221 An Issue for this can be found at https://github.com/dotnet/runtime/issues/69149 MSRC details for this can be found at https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-23267
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.1"
},
{
"fixed": "5.0.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23267"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-21T20:50:24Z",
"nvd_published_at": "2022-05-10T21:15:00Z",
"severity": "HIGH"
},
"details": "Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 6.0, .NET 5.0 and .NET Core 3.1. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA vulnerability exists in .NET 6.0, .NET 5.0 and .NET Core 3.1 where a malicious client can cause a Denial of Service via excess memory allocations through HttpClient.\n\n### Affected software\n\n* Any .NET 6.0 application running on .NET 6.0.4 or earlier.\n* Any .NET 5.0 application running .NET 5.0.16 or earlier.\n* Any .NET Core 3.1 applicaiton running on .NET Core 3.1.24 or earlier.\n\n### Patches\n* If you\u0027re using .NET Core 6.0, you should download and install Runtime 6.0.5 or SDK 6.0.105 (for Visual Studio 2022 v17.0) or SDK 6.0.203 (for Visual Studio 2022 v17.1) from https://dotnet.microsoft.com/download/dotnet-core/6.0.\n\n* If you\u0027re using .NET 5.0, you should download and install Runtime 5.0.17 or SDK 5.0.214 (for Visual Studio 2019 v16.9) or SDK 5.0.408 (for Visual Studio 2011 v16.11) from https://dotnet.microsoft.com/download/dotnet-core/5.0.\n\n* If you\u0027re using .NET Core 3.1, you should download and install Runtime 3.1.25 or SDK 3.1.419 (for Visual Studio 2019 v16.9 or Visual Studio 2011 16.11 or Visual Studio 2022 17.0 or Visual Studio 2022 17.1 ) from https://dotnet.microsoft.com/download/dotnet-core/3.1.\n\n.NET 6.0, .NET 5.0 and .NET Core 3.1 updates are also available from Microsoft Update. To access this either type \"Check for updates\" in your Windows search, or open Settings, choose Update \u0026 Security and then click Check for Updates.\n\n### Other Details\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/221\nAn Issue for this can be found at https://github.com/dotnet/runtime/issues/69149\nMSRC details for this can be found at https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-23267",
"id": "GHSA-485p-mrj5-8w2v",
"modified": "2025-01-02T21:55:35Z",
"published": "2022-10-21T20:50:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/runtime/security/advisories/GHSA-485p-mrj5-8w2v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23267"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/announcements/issues/221"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GNXQL7EZORGU4PZCPJ5EPQ4P7IEY3ZZO"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IBYSBUDJYQ76HK4TULXVIIPCKK2U6WDB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/W5FPEQ6BTYRGTS6IYCDTZW6YF5HLQ3BY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GNXQL7EZORGU4PZCPJ5EPQ4P7IEY3ZZO"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IBYSBUDJYQ76HK4TULXVIIPCKK2U6WDB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/W5FPEQ6BTYRGTS6IYCDTZW6YF5HLQ3BY"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23267"
}
],
"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": ".NET Denial of Service Vulnerability"
}
GHSA-486P-H2PV-QHWH
Vulnerability from github – Published: 2023-05-10 15:30 – Updated: 2024-04-04 04:00Uncontrolled resource consumption in the Intel(R) Unite(R) android application before Release 17 may allow an authenticated user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2023-25179"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-10T14:15:31Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption in the Intel(R) Unite(R) android application before Release 17 may allow an authenticated user to potentially enable denial of service via local access.",
"id": "GHSA-486p-h2pv-qhwh",
"modified": "2024-04-04T04:00:41Z",
"published": "2023-05-10T15:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25179"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00825.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-487G-3M3V-HJHQ
Vulnerability from github – Published: 2024-02-19 18:31 – Updated: 2024-02-29 03:33Insufficient file size checks resulted in a denial of service risk in the file picker's unzip functionality.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25978"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-21T00:08:30Z",
"nvd_published_at": "2024-02-19T17:15:08Z",
"severity": "HIGH"
},
"details": "Insufficient file size checks resulted in a denial of service risk in the file picker\u0027s unzip functionality.",
"id": "GHSA-487g-3m3v-hjhq",
"modified": "2024-02-29T03:33:05Z",
"published": "2024-02-19T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25978"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/9ba14233597480fb78c04d531050c090de4e60a2"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/a73e0ac76d77b67602f91bb211962813d60bc573"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2264074"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KXGBYJ43BUEBUAQZU3DT5I5A3YLF47CB"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=455634"
},
{
"type": "WEB",
"url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-74641"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncontrolled Resource Consumption in moodle"
}
GHSA-488G-HW5F-X29P
Vulnerability from github – Published: 2026-02-02 12:31 – Updated: 2026-02-02 22:04The SimpleDirectoryReader component in llama_index.core version 0.12.23 suffers from uncontrolled memory consumption due to a resource management flaw. The vulnerability arises because the user-specified file limit (num_files_limit) is applied after all files in a directory are loaded into memory. This can lead to memory exhaustion and degraded performance, particularly in environments with limited resources. The issue is resolved in version 0.12.41.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "llama-index-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.41"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-6208"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-02T22:04:45Z",
"nvd_published_at": "2026-02-02T11:16:17Z",
"severity": "MODERATE"
},
"details": "The `SimpleDirectoryReader` component in `llama_index.core` version 0.12.23 suffers from uncontrolled memory consumption due to a resource management flaw. The vulnerability arises because the user-specified file limit (`num_files_limit`) is applied after all files in a directory are loaded into memory. This can lead to memory exhaustion and degraded performance, particularly in environments with limited resources. The issue is resolved in version 0.12.41.",
"id": "GHSA-488g-hw5f-x29p",
"modified": "2026-02-02T22:04:45Z",
"published": "2026-02-02T12:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6208"
},
{
"type": "WEB",
"url": "https://github.com/run-llama/llama_index/commit/53614e2f7913c0e86b58add9470b3c900b6c60b2"
},
{
"type": "PACKAGE",
"url": "https://github.com/run-llama/llama_index"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/7d722bb6-6567-4608-8b23-f95048d7605a"
}
],
"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": "llama-index-core vulnerable to Uncontrolled Resource Consumption"
}
GHSA-4899-MPCH-38P3
Vulnerability from github – Published: 2026-08-20 18:43 – Updated: 2026-08-20 18:43BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding
- ID: BHTTP-LOOP-001
- Severity: High
- CVSS v3.1: 7.5 —
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - CWE: CWE-835 (Loop with Unreachable Exit Condition) — secondary CWE-400 (Uncontrolled Resource Consumption)
- Affected component:
codec-bhttp→io.netty.incubator.codec.bhttp.BinaryHttpParser#readFieldSection, filecodec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-626 - Affected version: netty-incubator-codec-ohttp HEAD
d3f2b49(release0.0.22.Final+ 3 commits). The loop has existed since the parser was introduced and is present in the latest code; all published advisory fixes are already applied. - Reachable from:
io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder#decodeChunk(codec-ohttp/.../OHttpRequestResponseContext.java:214), i.e. the auto-wired OHTTP server and client codecs. - Confidence: High (empirically reproduced hang + thread dump against the unmodified parser).
Summary
BinaryHttpParser decodes Binary HTTP (RFC 9292) messages. An OHTTP gateway/client built on this library feeds the decrypted OHTTP body straight into BinaryHttpParser.parse(...). The field-section decoding loop terminates only on the exact condition fieldSectionLength != 0 and relies on a Java assert to guarantee forward progress. Because (a) the loop counter can be driven negative and (b) readFieldLine(...) legitimately consumes zero bytes and returns null on a truncated/over-long field line, the loop can spin forever. Assertions are disabled in any normal production JVM, so the two assert statements meant to catch this provide no protection.
A single ~17-byte Binary HTTP message — encapsulated by an unauthenticated attacker inside a normal OHTTP request, using the gateway's public key configuration — pins one Netty event-loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event-loop group and takes the OHTTP gateway (or client) fully offline.
Root cause
BinaryHttpParser.java:619-626:
HeaderType lastType = HeaderType.PSEUDO_HEADER;
while (fieldSectionLength != 0) { // 619 — "!= 0", not "> 0"
int readableBytes = in.readableBytes();
lastType = readFieldLine(in, headers, lastType, trailers);
assert lastType != null; // 622 — no-op without -ea
int read = readableBytes - in.readableBytes();
assert read > 0; // 624 — no-op without -ea
fieldSectionLength -= read; // 625
}
Two cooperating defects:
-
Counter can never hit zero.
fieldSectionLengthis the declared field-section byte length read from the wire (line 592). The loop subtracts the bytes eachreadFieldLineactually consumes. If a field line consumes more bytes than the (attacker-understated) declared length,fieldSectionLengthgoes negative and!= 0stays true forever. -
Zero-progress iterations.
readFieldLine(lines 654-707) returnsnullwithout consuming any bytes when the remaining buffer cannot hold a complete field line — at lines 656, 664, 670, and 681 (thein.skipBytes(sumBytes)that advances the reader is only reached on the success path, line 705). When it returnsnull,read == 0,fieldSectionLengthis unchanged, and the loop re-enters with identical state — a tight busy spin.
The only constructs that would have stopped either case are the assert statements on lines 622 and 624, which the JVM strips unless started with -ea. Production deployments do not run with assertions enabled.
Reachability (hop-by-hop, every guard resolved)
Attacker model: OHTTP gateways publish their HPKE key configuration so that any client can encrypt requests to them. The attacker therefore encrypts a malicious BHTTP body under the gateway's public key — a perfectly valid OHTTP request. HPKE decapsulation succeeds; the plaintext is attacker-chosen.
OHttpServerCodec.decode→OHttpRequestResponseContext.parse→ chunk decode →ContentDecoder.decodeChunk.OHttpRequestResponseContext.java:211decrypts the chunk intodecryptedChunk; line 212 cumulates it; line 214 callsbinaryHttpParser.parse(binaryHttpCumulation, completeBodyReceived)— attacker-controlled plaintext, no application code in between.parse→READ_KNOWN_LENGTH_REQUEST_HEAD→readRequestHead(line 190).readRequestHeadreads the control data, then at lines 445-451 slices all remaining readable bytes as the field section and callsreadFieldSection(..., knownLength=true, maxFieldSectionSize).- Inside
readFieldSection: - Guard
checkFieldSectionTooLarge(fieldSectionLength, max)(line 607): bounds only the declared length, which the PoC sets to1. Passes — not a barrier. - Guard
in.readableBytes() < sumBytes(line 609):sumBytesis built from the declared length, also tiny. Passes — not a barrier. - Guards
assert(lines 622, 624): no-ops in production. Defeated by default. - Loop entered → spins forever (defects 1 + 2).
No reachable guard bounds the actual consumption or forces progress. maxFieldSectionSize is irrelevant because the declared length is small and the loop is CPU-bound on a fixed, small buffer (no allocation, no memory growth to trip any size cap).
Proof of concept (executed locally, benign liveness oracle)
The real codec-bhttp sources were compiled unmodified against netty 4.1.135.Final (the version pinned in pom.xml). The harness builds a valid known-length BHTTP request whose declared field-section length (0x01) is understated relative to the actual field line, then calls parse(in, true) on a worker thread with a 6-second watchdog. No payload, no side effects — purely a timing/CPU oracle.
Malicious message (17 bytes):
00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01
│ └method g └scheme h └auth a └path p │ └hdr a:b──┘ └ partial line
└ framing 0 (known-length request) └ declared field-section length = 1
Observed (production default, assertions OFF):
[*] malicious BHTTP bytes (17): 0001670168016101700101610162016301
[!!] HANG CONFIRMED: parse() still running after 6000 ms
[!!] worker thread CPU time: 6029 ms (≈100% of one core => busy spin)
[!!] worker stack (top frames):
at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626)
at io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHead(BinaryHttpParser.java:451)
at io.netty.incubator.codec.bhttp.BinaryHttpParser.parse(BinaryHttpParser.java:190)
CPU time ≈ wall time ⇒ a busy spin (RUNNABLE), not a blocked wait.
Controls:
- Same input with -ea: parse() throws AssertionError at readFieldSection:624 immediately — proving the assertion is the only would-be guard and is absent in production.
- Well-formed request (declared length matches): parse() returns DefaultBinaryHttpRequest promptly — proving the harness does not hang on valid input.
PoC sources: findings/netty-incubator-codec-ohttp/raw/Poc.java (hang + control 1) and raw/Poc2.java (negative control).
Impact
Unauthenticated, pre-business-logic remote denial of service. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU. Netty event-loop groups have a small fixed thread count (default 2 × cores); a handful of requests exhausts every I/O thread, after which the gateway/client accepts no further connections and serves no traffic — a complete, persistent DoS that survives until process restart. Availability impact High; no confidentiality/integrity impact.
Adversarial re-reading (attempts to refute)
- "
maxFieldSectionSizecaps it." No — the declared length in the PoC is1; the cap (line 607) checks the declared value only. The spin happens on a 17-byte buffer with no allocation. Refutation fails. - "An upstream HTTP size limit /
HttpObjectAggregatorblocks it." No — the bug is CPU-bound, not memory-bound. The whole malicious message is tiny and well within any size limit. Refutation fails. - "This is just CVE-2024-40642 (absent input validation)." No — that advisory was about missing validation of method/scheme/authority/path enabling injection; that fix (the
ALLOWED_TOKEN/ALLOWED_SCHEMEvalidators, lines 76-122/461-466) is present and unrelated. This is a control-flow/termination defect in field-section length accounting. Distinct class, distinct code. - "The hang might be a harness artifact." No — the thread dump pinpoints
readFieldSection:626; CPU≈wall confirms a spin; the-eacontrol throws at the exact assert; the well-formed control returns. The hang is for the claimed reason. - "
completeBodyReceivedmust be true." Not required — the loop is insidereadFieldSection, reached viareadRequestHeadonce the control data is present, independent of that flag. The flag only affects a branch taken afterreadRequestHeadreturnsnull, which never happens here.
No concrete blocker survived. Verdict: CONFIRMED.
Remediation
- Change the loop exit condition to
while (fieldSectionLength > 0)so an overshoot (negative counter) terminates. - Treat a
null/ zero-progress return fromreadFieldLinewhilefieldSectionLength > 0as a hard framing error — throwCorruptedFrameException("truncated or over-long field line")instead of re-looping. - Reject any field line whose consumed byte count would drive
fieldSectionLengthbelow 0 (the declared length must be consumed exactly, per RFC 9292 §3.6). - Do not rely on
assertfor wire-format invariants on attacker-controlled input; assertions are disabled in production. Promote lines 622/624 to explicit exceptions.
Example:
while (fieldSectionLength > 0) {
int readableBytes = in.readableBytes();
lastType = readFieldLine(in, headers, lastType, trailers);
int read = readableBytes - in.readableBytes();
if (lastType == null || read <= 0) {
throw new CorruptedFrameException("truncated or over-long field line");
}
if (read > fieldSectionLength) {
throw new CorruptedFrameException("field line exceeds declared field-section length");
}
fieldSectionLength -= read;
}
Notes
- The indeterminate-length field-section path (framing indicators 2/3) shares the same loop and the same
!= 0/ zero-progress structure; the fix above should cover both. A dedicated trace ofgetIndeterminateLength(lines 538-566) under non-defaultmaxFieldSectionSizeis recorded separately as a lead. - Default
maxFieldSectionSizefor the OHTTP codecs is8 * 1024(OHttpCodecBuilder.DEFAULT_MAX_FIELD_SECTION_SIZE), and is irrelevant to this CPU-bound spin.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.0.22.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty.incubator:netty-incubator-codec-bhttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.23.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63202"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:43:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding\n\n- **ID:** BHTTP-LOOP-001\n- **Severity:** High\n- **CVSS v3.1:** 7.5 \u2014 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`\n- **CWE:** CWE-835 (Loop with Unreachable Exit Condition) \u2014 secondary CWE-400 (Uncontrolled Resource Consumption)\n- **Affected component:** `codec-bhttp` \u2192 `io.netty.incubator.codec.bhttp.BinaryHttpParser#readFieldSection`, file `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-626`\n- **Affected version:** netty-incubator-codec-ohttp HEAD `d3f2b49` (release `0.0.22.Final` + 3 commits). The loop has existed since the parser was introduced and is present in the latest code; all published advisory fixes are already applied.\n- **Reachable from:** `io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder#decodeChunk` (`codec-ohttp/.../OHttpRequestResponseContext.java:214`), i.e. the auto-wired OHTTP server **and** client codecs.\n- **Confidence:** High (empirically reproduced hang + thread dump against the unmodified parser).\n\n## Summary\n\n`BinaryHttpParser` decodes Binary HTTP (RFC 9292) messages. An OHTTP gateway/client built on this library feeds the **decrypted** OHTTP body straight into `BinaryHttpParser.parse(...)`. The field-section decoding loop terminates only on the exact condition `fieldSectionLength != 0` and relies on a Java `assert` to guarantee forward progress. Because (a) the loop counter can be driven negative and (b) `readFieldLine(...)` legitimately consumes **zero** bytes and returns `null` on a truncated/over-long field line, the loop can spin forever. Assertions are disabled in any normal production JVM, so the two `assert` statements meant to catch this provide no protection.\n\nA single ~17-byte Binary HTTP message \u2014 encapsulated by an unauthenticated attacker inside a normal OHTTP request, using the gateway\u0027s **public** key configuration \u2014 pins one Netty event-loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event-loop group and takes the OHTTP gateway (or client) fully offline.\n\n## Root cause\n\n`BinaryHttpParser.java:619-626`:\n\n```java\nHeaderType lastType = HeaderType.PSEUDO_HEADER;\nwhile (fieldSectionLength != 0) { // 619 \u2014 \"!= 0\", not \"\u003e 0\"\n int readableBytes = in.readableBytes();\n lastType = readFieldLine(in, headers, lastType, trailers);\n assert lastType != null; // 622 \u2014 no-op without -ea\n int read = readableBytes - in.readableBytes();\n assert read \u003e 0; // 624 \u2014 no-op without -ea\n fieldSectionLength -= read; // 625\n}\n```\n\nTwo cooperating defects:\n\n1. **Counter can never hit zero.** `fieldSectionLength` is the *declared* field-section byte length read from the wire (line 592). The loop subtracts the bytes each `readFieldLine` actually consumes. If a field line consumes more bytes than the (attacker-understated) declared length, `fieldSectionLength` goes negative and `!= 0` stays true forever.\n\n2. **Zero-progress iterations.** `readFieldLine` (lines 654-707) returns `null` **without consuming any bytes** when the remaining buffer cannot hold a complete field line \u2014 at lines 656, 664, 670, and 681 (the `in.skipBytes(sumBytes)` that advances the reader is only reached on the success path, line 705). When it returns `null`, `read == 0`, `fieldSectionLength` is unchanged, and the loop re-enters with identical state \u2014 a tight busy spin.\n\nThe only constructs that would have stopped either case are the `assert` statements on lines 622 and 624, which the JVM strips unless started with `-ea`. Production deployments do not run with assertions enabled.\n\n## Reachability (hop-by-hop, every guard resolved)\n\nAttacker model: OHTTP gateways publish their HPKE key configuration so that *any* client can encrypt requests to them. The attacker therefore encrypts a malicious BHTTP body under the gateway\u0027s public key \u2014 a perfectly valid OHTTP request. HPKE decapsulation succeeds; the plaintext is attacker-chosen.\n\n1. `OHttpServerCodec.decode` \u2192 `OHttpRequestResponseContext.parse` \u2192 chunk decode \u2192 `ContentDecoder.decodeChunk`.\n2. `OHttpRequestResponseContext.java:211` decrypts the chunk into `decryptedChunk`; line 212 cumulates it; **line 214** calls `binaryHttpParser.parse(binaryHttpCumulation, completeBodyReceived)` \u2014 attacker-controlled plaintext, no application code in between.\n3. `parse` \u2192 `READ_KNOWN_LENGTH_REQUEST_HEAD` \u2192 `readRequestHead` (line 190).\n4. `readRequestHead` reads the control data, then at lines 445-451 slices **all** remaining readable bytes as the field section and calls `readFieldSection(..., knownLength=true, maxFieldSectionSize)`.\n5. Inside `readFieldSection`:\n - **Guard `checkFieldSectionTooLarge(fieldSectionLength, max)` (line 607):** bounds only the *declared* length, which the PoC sets to `1`. **Passes \u2014 not a barrier.**\n - **Guard `in.readableBytes() \u003c sumBytes` (line 609):** `sumBytes` is built from the *declared* length, also tiny. **Passes \u2014 not a barrier.**\n - **Guards `assert` (lines 622, 624):** no-ops in production. **Defeated by default.**\n - Loop entered \u2192 spins forever (defects 1 + 2).\n\nNo reachable guard bounds the *actual* consumption or forces progress. `maxFieldSectionSize` is irrelevant because the declared length is small and the loop is CPU-bound on a fixed, small buffer (no allocation, no memory growth to trip any size cap).\n\n## Proof of concept (executed locally, benign liveness oracle)\n\nThe real `codec-bhttp` sources were compiled unmodified against netty `4.1.135.Final` (the version pinned in `pom.xml`). The harness builds a valid known-length BHTTP request whose declared field-section length (`0x01`) is understated relative to the actual field line, then calls `parse(in, true)` on a worker thread with a 6-second watchdog. No payload, no side effects \u2014 purely a timing/CPU oracle.\n\nMalicious message (17 bytes):\n```\n00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01\n\u2502 \u2514method g \u2514scheme h \u2514auth a \u2514path p \u2502 \u2514hdr a:b\u2500\u2500\u2518 \u2514 partial line\n\u2514 framing 0 (known-length request) \u2514 declared field-section length = 1\n```\n\nObserved (production default, assertions OFF):\n```\n[*] malicious BHTTP bytes (17): 0001670168016101700101610162016301\n[!!] HANG CONFIRMED: parse() still running after 6000 ms\n[!!] worker thread CPU time: 6029 ms (\u2248100% of one core =\u003e busy spin)\n[!!] worker stack (top frames):\n at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626)\n at io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHead(BinaryHttpParser.java:451)\n at io.netty.incubator.codec.bhttp.BinaryHttpParser.parse(BinaryHttpParser.java:190)\n```\nCPU time \u2248 wall time \u21d2 a busy spin (RUNNABLE), not a blocked wait.\n\nControls:\n- **Same input with `-ea`:** `parse()` throws `AssertionError` at `readFieldSection:624` immediately \u2014 proving the assertion is the only would-be guard and is absent in production.\n- **Well-formed request (declared length matches):** `parse()` returns `DefaultBinaryHttpRequest` promptly \u2014 proving the harness does not hang on valid input.\n\nPoC sources: `findings/netty-incubator-codec-ohttp/raw/Poc.java` (hang + control 1) and `raw/Poc2.java` (negative control).\n\n## Impact\n\nUnauthenticated, pre-business-logic remote denial of service. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU. Netty event-loop groups have a small fixed thread count (default `2 \u00d7 cores`); a handful of requests exhausts every I/O thread, after which the gateway/client accepts no further connections and serves no traffic \u2014 a complete, persistent DoS that survives until process restart. Availability impact High; no confidentiality/integrity impact.\n\n## Adversarial re-reading (attempts to refute)\n\n- *\"`maxFieldSectionSize` caps it.\"* No \u2014 the declared length in the PoC is `1`; the cap (line 607) checks the declared value only. The spin happens on a 17-byte buffer with no allocation. Refutation fails.\n- *\"An upstream HTTP size limit / `HttpObjectAggregator` blocks it.\"* No \u2014 the bug is CPU-bound, not memory-bound. The whole malicious message is tiny and well within any size limit. Refutation fails.\n- *\"This is just CVE-2024-40642 (absent input validation).\"* No \u2014 that advisory was about missing validation of method/scheme/authority/path enabling injection; that fix (the `ALLOWED_TOKEN`/`ALLOWED_SCHEME` validators, lines 76-122/461-466) is present and unrelated. This is a control-flow/termination defect in field-section length accounting. Distinct class, distinct code.\n- *\"The hang might be a harness artifact.\"* No \u2014 the thread dump pinpoints `readFieldSection:626`; CPU\u2248wall confirms a spin; the `-ea` control throws at the exact assert; the well-formed control returns. The hang is for the claimed reason.\n- *\"`completeBodyReceived` must be true.\"* Not required \u2014 the loop is inside `readFieldSection`, reached via `readRequestHead` once the control data is present, independent of that flag. The flag only affects a branch taken *after* `readRequestHead` returns `null`, which never happens here.\n\nNo concrete blocker survived. Verdict: **CONFIRMED**.\n\n## Remediation\n\n1. Change the loop exit condition to `while (fieldSectionLength \u003e 0)` so an overshoot (negative counter) terminates.\n2. Treat a `null` / zero-progress return from `readFieldLine` while `fieldSectionLength \u003e 0` as a hard framing error \u2014 throw `CorruptedFrameException(\"truncated or over-long field line\")` instead of re-looping.\n3. Reject any field line whose consumed byte count would drive `fieldSectionLength` below 0 (the declared length must be consumed exactly, per RFC 9292 \u00a73.6).\n4. Do not rely on `assert` for wire-format invariants on attacker-controlled input; assertions are disabled in production. Promote lines 622/624 to explicit exceptions.\n\nExample:\n```java\nwhile (fieldSectionLength \u003e 0) {\n int readableBytes = in.readableBytes();\n lastType = readFieldLine(in, headers, lastType, trailers);\n int read = readableBytes - in.readableBytes();\n if (lastType == null || read \u003c= 0) {\n throw new CorruptedFrameException(\"truncated or over-long field line\");\n }\n if (read \u003e fieldSectionLength) {\n throw new CorruptedFrameException(\"field line exceeds declared field-section length\");\n }\n fieldSectionLength -= read;\n}\n```\n\n## Notes\n\n- The indeterminate-length field-section path (framing indicators 2/3) shares the same loop and the same `!= 0` / zero-progress structure; the fix above should cover both. A dedicated trace of `getIndeterminateLength` (lines 538-566) under non-default `maxFieldSectionSize` is recorded separately as a lead.\n- Default `maxFieldSectionSize` for the OHTTP codecs is `8 * 1024` (`OHttpCodecBuilder.DEFAULT_MAX_FIELD_SECTION_SIZE`), and is irrelevant to this CPU-bound spin.",
"id": "GHSA-4899-mpch-38p3",
"modified": "2026-08-20T18:43:38Z",
"published": "2026-08-20T18:43:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-4899-mpch-38p3"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty-incubator-codec-ohttp"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-ohttp/releases/tag/netty-incubator-codec-parent-ohttp-0.0.23.Final"
}
],
"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": "netty-incubator-codec-ohttp BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding"
}
GHSA-48FJ-RPWG-8HJQ
Vulnerability from github – Published: 2026-01-20 15:33 – Updated: 2026-02-02 18:31A security issue exists within ArmorStart® LT that can result in a denial-of-service condition. During execution of the Achilles EtherNet/IP and CIP grammar tests, the device reboots unexpectedly, causing the Link State Monitor to go down for several seconds.
{
"affected": [],
"aliases": [
"CVE-2025-9466"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T14:16:17Z",
"severity": "HIGH"
},
"details": "A security issue exists within ArmorStart\u00ae LT that can result in a denial-of-service condition. During execution of the Achilles EtherNet/IP and CIP grammar tests, the device reboots unexpectedly, causing the Link State Monitor to go down for several seconds.",
"id": "GHSA-48fj-rpwg-8hjq",
"modified": "2026-02-02T18:31:31Z",
"published": "2026-01-20T15:33:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9466"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1768.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"
},
{
"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-48G8-MW8P-W6J7
Vulnerability from github – Published: 2026-05-26 18:31 – Updated: 2026-05-26 18:31IBM HTTP Server 8.5, and 9.0 is vulnerable to denial of service in configurations where an attacker has write access to parts of the server configuration.
{
"affected": [],
"aliases": [
"CVE-2026-8856"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T18:16:57Z",
"severity": "HIGH"
},
"details": "IBM HTTP Server 8.5, and 9.0 is vulnerable to denial of service in configurations where an attacker has write access to parts of the server configuration.",
"id": "GHSA-48g8-mw8p-w6j7",
"modified": "2026-05-26T18:31:51Z",
"published": "2026-05-26T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8856"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7274065"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-48JH-3GJ7-FG8V
Vulnerability from github – Published: 2026-09-04 21:37 – Updated: 2026-09-04 21:37Summary
The fix for GHSA-rwxx-mrjm-wc2m ("ReDoS via structured_outputs.regex compiled without timeout") wrapped the regex compile in the xgrammar and outlines backends with compile_regex_with_timeout (and, for outlines, validate_regex_is_buildable). The lm-format-enforcer backend was left unguarded: it compiles the attacker-supplied regex with no timeout and no buildability check. A single request with a catastrophic regex hangs the structured-output compile step and stalls the engine worker (denial of service).
Affected code (HEAD d6d39c1)
vllm/v1/structured_output/backend_lm_format_enforcer.py:
- line 110: character_level_parser = lmformatenforcer.RegexParser(grammar_spec) — builds an interegular FSM from the attacker regex synchronously, no timeout.
- line 155: validate_structured_output_request_lm_format_enforcer returns immediately on if so_params.regex: — no validation.
Sibling backends that WERE patched by GHSA-rwxx:
- backend_xgrammar.py:92 → compile_regex_with_timeout(...).
- backend_outlines.py:65 → compile_regex_with_timeout(...) (plus validate_regex_is_buildable).
lm-format-enforcer uses the same interegular DFA-construction primitive the advisory cites for the outlines backend.
Reproduction (runtime-verified against the sink)
The sink lmformatenforcer.RegexParser(<regex>) was exercised directly (this is exactly what the backend calls):
baseline '[0-9]{3}' -> 0.0002 s
attacker '(a{1,300}){300}' -> DID NOT COMPLETE in 20 s (one core pegged at 100% in interegular FSM construction)
End-to-end: start vllm serve <model> --structured-outputs-config '{"backend":"lm-format-enforcer"}', then POST /v1/completions with {"structured_outputs":{"regex":"(a{1,300}){300}"}, ...}. The request never returns; because grammar compile runs in the engine's structured-output path, concurrent requests stall = worker-level DoS. The identical request against the outlines backend is bounded by compile_regex_with_timeout and returns a clean error.
Impact
Unauthenticated denial of service (vLLM ships with no authentication by default). One request pegs a CPU core and blocks the structured-output engine path.
Reachability precondition: the operator must have selected backend=lm-format-enforcer via --structured-outputs-config (the default is auto → xgrammar). This is the same opt-in tier as the outlines backend that GHSA-rwxx already covered.
Suggested remediation
Route the lm-format-enforcer regex compile (backend_lm_format_enforcer.py:110) through the same compile_regex_with_timeout guard already applied to the xgrammar and outlines backends, and reject un-buildable / oversized patterns in validate_structured_output_request_lm_format_enforcer.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73556"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T21:37:00Z",
"nvd_published_at": "2026-08-13T15:20:17Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe fix for `GHSA-rwxx-mrjm-wc2m` (\"ReDoS via `structured_outputs.regex` compiled without timeout\") wrapped the regex compile in the **xgrammar** and **outlines** backends with `compile_regex_with_timeout` (and, for outlines, `validate_regex_is_buildable`). The **lm-format-enforcer** backend was left unguarded: it compiles the attacker-supplied regex with no timeout and no buildability check. A single request with a catastrophic regex hangs the structured-output compile step and stalls the engine worker (denial of service).\n\n### Affected code (HEAD d6d39c1)\n\n`vllm/v1/structured_output/backend_lm_format_enforcer.py`:\n- line 110: `character_level_parser = lmformatenforcer.RegexParser(grammar_spec)` \u2014 builds an `interegular` FSM from the attacker regex synchronously, **no timeout**.\n- line 155: `validate_structured_output_request_lm_format_enforcer` returns immediately on `if so_params.regex:` \u2014 **no validation**.\n\nSibling backends that WERE patched by GHSA-rwxx:\n- `backend_xgrammar.py:92` \u2192 `compile_regex_with_timeout(...)`.\n- `backend_outlines.py:65` \u2192 `compile_regex_with_timeout(...)` (plus `validate_regex_is_buildable`).\n\nlm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.\n\n### Reproduction (runtime-verified against the sink)\n\nThe sink `lmformatenforcer.RegexParser(\u003cregex\u003e)` was exercised directly (this is exactly what the backend calls):\n\n```\nbaseline \u0027[0-9]{3}\u0027 -\u003e 0.0002 s\nattacker \u0027(a{1,300}){300}\u0027 -\u003e DID NOT COMPLETE in 20 s (one core pegged at 100% in interegular FSM construction)\n```\n\nEnd-to-end: start `vllm serve \u003cmodel\u003e --structured-outputs-config \u0027{\"backend\":\"lm-format-enforcer\"}\u0027`, then `POST /v1/completions` with `{\"structured_outputs\":{\"regex\":\"(a{1,300}){300}\"}, ...}`. The request never returns; because grammar compile runs in the engine\u0027s structured-output path, concurrent requests stall = worker-level DoS. The identical request against the outlines backend is bounded by `compile_regex_with_timeout` and returns a clean error.\n\n### Impact\n\nUnauthenticated denial of service (vLLM ships with no authentication by default). One request pegs a CPU core and blocks the structured-output engine path.\n\n**Reachability precondition:** the operator must have selected `backend=lm-format-enforcer` via `--structured-outputs-config` (the default is `auto` \u2192 xgrammar). This is the same opt-in tier as the outlines backend that GHSA-rwxx already covered.\n\n### Suggested remediation\n\nRoute the lm-format-enforcer regex compile (`backend_lm_format_enforcer.py:110`) through the same `compile_regex_with_timeout` guard already applied to the xgrammar and outlines backends, and reject un-buildable / oversized patterns in `validate_structured_output_request_lm_format_enforcer`.",
"id": "GHSA-48jh-3gj7-fg8v",
"modified": "2026-09-04T21:37:00Z",
"published": "2026-09-04T21:37:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-48jh-3gj7-fg8v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73556"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/47595"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/c9a788eedc412acceaa5112e0d44624b49841577"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/releases/tag/v0.26.0"
}
],
"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": "vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) \u2014 missed sibling of GHSA-rwxx-mrjm-wc2m"
}
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.