CWE-755
DiscouragedImproper Handling of Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not handle or incorrectly handles an exceptional condition.
703 vulnerabilities reference this CWE, most recent first.
GHSA-CXW3-2F59-5P7F
Vulnerability from github – Published: 2024-10-21 18:31 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
static_call: Handle module init failure correctly in static_call_del_module()
Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.
If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.
This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.
The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space:
union {
/* bit 0: 0 = mods, 1 = sites */
unsigned long type;
struct static_call_mod *mods;
struct static_call_site *sites;
};
key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.
As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.
Cure it by checking whether the key has a sites or a mods pointer.
If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.
If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.
A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.
{
"affected": [],
"aliases": [
"CVE-2024-50002"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstatic_call: Handle module init failure correctly in static_call_del_module()\n\nModule insertion invokes static_call_add_module() to initialize the static\ncalls in a module. static_call_add_module() invokes __static_call_init(),\nwhich allocates a struct static_call_mod to either encapsulate the built-in\nstatic call sites of the associated key into it so further modules can be\nadded or to append the module to the module chain.\n\nIf that allocation fails the function returns with an error code and the\nmodule core invokes static_call_del_module() to clean up eventually added\nstatic_call_mod entries.\n\nThis works correctly, when all keys used by the module were converted over\nto a module chain before the failure. If not then static_call_del_module()\ncauses a #GP as it blindly assumes that key::mods points to a valid struct\nstatic_call_mod.\n\nThe problem is that key::mods is not a individual struct member of struct\nstatic_call_key, it\u0027s part of a union to save space:\n\n union {\n /* bit 0: 0 = mods, 1 = sites */\n unsigned long type;\n struct static_call_mod *mods;\n struct static_call_site *sites;\n\t};\n\nkey::sites is a pointer to the list of built-in usage sites of the static\ncall. The type of the pointer is differentiated by bit 0. A mods pointer\nhas the bit clear, the sites pointer has the bit set.\n\nAs static_call_del_module() blidly assumes that the pointer is a valid\nstatic_call_mod type, it fails to check for this failure case and\ndereferences the pointer to the list of built-in call sites, which is\nobviously bogus.\n\nCure it by checking whether the key has a sites or a mods pointer.\n\nIf it\u0027s a sites pointer then the key is not to be touched. As the sites are\nwalked in the same order as in __static_call_init() the site walk can be\nterminated because all subsequent sites have not been touched by the init\ncode due to the error exit.\n\nIf it was converted before the allocation fail, then the inner loop which\nsearches for a module match will find nothing.\n\nA fail in the second allocation in __static_call_init() is harmless and\ndoes not require special treatment. The first allocation succeeded and\nconverted the key to a module chain. That first entry has mod::mod == NULL\nand mod::next == NULL, so the inner loop of static_call_del_module() will\nneither find a module match nor a module chain. The next site in the walk\nwas either already converted, but can\u0027t match the module, or it will exit\nthe outer loop because it has a static_call_site pointer and not a\nstatic_call_mod pointer.",
"id": "GHSA-cxw3-2f59-5p7f",
"modified": "2025-11-04T00:31:44Z",
"published": "2024-10-21T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F266-7P9X-6359
Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-07-13 00:01In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.
{
"affected": [],
"aliases": [
"CVE-2021-28876"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-11T20:15:00Z",
"severity": "HIGH"
},
"details": "In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.",
"id": "GHSA-f266-7p9x-6359",
"modified": "2022-07-13T00:01:15Z",
"published": "2022-05-24T17:47:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28876"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/rust/issues/81740"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/rust/pull/81741"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CZ337CM4GFJLRDFVQCGC7J25V65JXOG5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TFUO3URYCO73D2Q4WYJBWAMJWGGVXQO4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VZG65GUW6Z2CYOQHF7T3TB5CZKIX6ZJE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-09"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F2CR-R825-QV2M
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2024-03-21 03:33** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in ReadyTalk Avian 1.2.0. The vm::arrayCopy method defined in classpath-common.h returns silently when a negative length is provided (instead of throwing an exception). This could result in data being lost during the copy, with varying consequences depending on the subsequent use of the destination buffer. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [],
"aliases": [
"CVE-2020-17361"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-12T18:15:00Z",
"severity": "MODERATE"
},
"details": "** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in ReadyTalk Avian 1.2.0. The vm::arrayCopy method defined in classpath-common.h returns silently when a negative length is provided (instead of throwing an exception). This could result in data being lost during the copy, with varying consequences depending on the subsequent use of the destination buffer. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
"id": "GHSA-f2cr-r825-qv2m",
"modified": "2024-03-21T03:33:55Z",
"published": "2022-05-24T17:25:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17361"
},
{
"type": "WEB",
"url": "https://github.com/ReadyTalk/avian/issues"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Aug/10"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Sep/11"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Sep/13"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Sep/14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F3HV-32HF-CQW9
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37An unauthenticated remote attacker can send data to RsvcHost.exe listening on TCP port 5241 to add entries in the FactoryTalk Diagnostics event log. The attacker can specify long fields in the log entry, which can cause an unhandled exception in wcscpy_s() if a local user opens FactoryTalk Diagnostics Viewer (FTDiagViewer.exe) to view the log entry. Observed in FactoryTalk Diagnostics 6.11. All versions of FactoryTalk Diagnostics are affected.
{
"affected": [],
"aliases": [
"CVE-2020-5807"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-29T16:15:00Z",
"severity": "HIGH"
},
"details": "An unauthenticated remote attacker can send data to RsvcHost.exe listening on TCP port 5241 to add entries in the FactoryTalk Diagnostics event log. The attacker can specify long fields in the log entry, which can cause an unhandled exception in wcscpy_s() if a local user opens FactoryTalk Diagnostics Viewer (FTDiagViewer.exe) to view the log entry. Observed in FactoryTalk Diagnostics 6.11. All versions of FactoryTalk Diagnostics are affected.",
"id": "GHSA-f3hv-32hf-cqw9",
"modified": "2022-05-24T17:37:29Z",
"published": "2022-05-24T17:37:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5807"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2020-71"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F46R-RW29-R322
Vulnerability from github – Published: 2025-04-24 16:31 – Updated: 2025-04-25 14:32Summary
After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.
Details
The vulnerable header is X-React-Router-SPA-Mode; adding it to a request sent to a page/endpoint using a loader throws an error. Here is the vulnerable code :
To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.
Steps to reproduce
Versions used for our PoC: - "@react-router/node": "^7.5.0", - "@react-router/serve": "^7.5.0", - "react": "^19.0.0" - "react-dom": "^19.0.0" - "react-router": "^7.5.0"
- Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation)
- Add a simple page using a loader (example:
routes/ssr)
- Send a request to the endpoint using the loader (
/ssrin our case) adding the following header:
X-React-Router-SPA-Mode: yes
Notice the difference between a request with and without the header;
Normal request
With the header
Impact
If a system cache is in place, it is possible to poison the response by completely altering its content (by an error message), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.
Credits
- Rachid Allam (zhero;)
- Yasser Allam (inzo_)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.5.1"
},
"package": {
"ecosystem": "npm",
"name": "react-router"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-43864"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-24T16:31:16Z",
"nvd_published_at": "2025-04-25T01:15:43Z",
"severity": "HIGH"
},
"details": "## Summary\nAfter some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.\n\n## Details\nThe vulnerable header is `X-React-Router-SPA-Mode`; adding it to a request sent to a page/endpoint using a loader throws an error. Here is [the vulnerable code](https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/server.ts#L407) :\n\n\u003cimg width=\"672\" alt=\"Capture d\u2019e\u0301cran 2025-04-07 a\u0300 08 28 20\" src=\"https://github.com/user-attachments/assets/0a0e9c41-70fd-4dba-9061-892dd6797291\" /\u003e\n\nTo use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.\n\n## Steps to reproduce \nVersions used for our PoC: \n- \"@react-router/node\": \"^7.5.0\",\n- \"@react-router/serve\": \"^7.5.0\",\n- \"react\": \"^19.0.0\"\n- \"react-dom\": \"^19.0.0\"\n- \"react-router\": \"^7.5.0\"\n\n1. Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation)\n2. Add a simple page using a loader (example: `routes/ssr`)\n\n\n\n3. Send a request to the endpoint using the loader (`/ssr` in our case) adding the following header:\n```\nX-React-Router-SPA-Mode: yes\n```\n\nNotice the difference between a request with and without the header;\n\n**Normal request**\n\n\n**With the header**\n\n\n\n## Impact\nIf a system cache is in place, it is possible to poison the response by completely altering its content (*by an error message*), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.\n\n## Credits\n- Rachid Allam (zhero;)\n- Yasser Allam (inzo_)",
"id": "GHSA-f46r-rw29-r322",
"modified": "2025-04-25T14:32:54Z",
"published": "2025-04-24T16:31:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/security/advisories/GHSA-f46r-rw29-r322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43864"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/commit/c84302972a152d851cf5dd859ff332b354b70111"
},
{
"type": "PACKAGE",
"url": "https://github.com/remix-run/react-router"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/server.ts#L407"
}
],
"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": "React Router allows a DoS via cache poisoning by forcing SPA mode"
}
GHSA-F48H-92JW-FXC4
Vulnerability from github – Published: 2023-07-05 18:30 – Updated: 2024-04-04 05:23In Progress MOVEit Transfer before 2021.0.9 (13.0.9), 2021.1.7 (13.1.7), 2022.0.7 (14.0.7), 2022.1.8 (14.1.8), and 2023.0.4 (15.0.4), it is possible for an attacker to invoke a method that results in an unhandled exception. Triggering this workflow can cause the MOVEit Transfer application to terminate unexpectedly.
{
"affected": [],
"aliases": [
"CVE-2023-36933"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-05T16:15:09Z",
"severity": "HIGH"
},
"details": "In Progress MOVEit Transfer before 2021.0.9 (13.0.9), 2021.1.7 (13.1.7), 2022.0.7 (14.0.7), 2022.1.8 (14.1.8), and 2023.0.4 (15.0.4), it is possible for an attacker to invoke a method that results in an unhandled exception. Triggering this workflow can cause the MOVEit Transfer application to terminate unexpectedly.",
"id": "GHSA-f48h-92jw-fxc4",
"modified": "2024-04-04T05:23:48Z",
"published": "2023-07-05T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36933"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/MOVEit-Transfer-2020-1-Service-Pack-July-2023"
},
{
"type": "WEB",
"url": "https://www.progress.com/moveit"
}
],
"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-F4J7-9JJ6-PQQX
Vulnerability from github – Published: 2023-03-24 21:30 – Updated: 2023-03-29 15:30In multiple functions of SnoozeHelper.java, there is a possible failure to persist settings due to an uncaught exception. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-261588851
{
"affected": [],
"aliases": [
"CVE-2023-20993"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-24T20:15:00Z",
"severity": "HIGH"
},
"details": "In multiple functions of SnoozeHelper.java, there is a possible failure to persist settings due to an uncaught exception. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-261588851",
"id": "GHSA-f4j7-9jj6-pqqx",
"modified": "2023-03-29T15:30:18Z",
"published": "2023-03-24T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20993"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-05-01"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-03-01"
},
{
"type": "WEB",
"url": "https://www.tenable.com/cve/CVE-2023-20993"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F5P7-9FR5-8JMJ
Vulnerability from github – Published: 2026-05-06 21:24 – Updated: 2026-05-13 16:41Summary
Granian aborts a worker process if a WSGI application returns an invalid HTTP response header name or value. The WSGI response conversion path uses .unwrap() on both the header name and header value constructors, so malformed output from the application becomes a process abort instead of a handled error.
This issue requires a buggy or attacker-influenced WSGI application to emit invalid headers. It is not a parser bug in Granian's request path. The security impact is that application mistakes which should result in a 500 instead kill the worker process.
Details
https://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/wsgi/io.rs#L39-L42
If either conversion fails, .unwrap() panics. In release builds Granian uses panic = "abort", so the panic terminates the worker.
Preconditions
The attacker must be able to influence a header name or value produced by the WSGI application, or the application must otherwise generate invalid headers.
Examples include:
- a header name containing a space
- a header value containing
\r\n - a header value containing a null byte
These are realistic failure modes for applications that reflect user-controlled data into headers such as Location, Content Disposition, or custom response headers.
PoC
Step 1
start Granian with the PoC WSGI app
# app.py
def app(environ, start_response):
path = environ.get("PATH_INFO", "/")
if path == "/crash-name":
headers = [("X Bad Name", "value")]
elif path == "/crash-value":
headers = [("Content-Type", "text/html\r\nX-Injected: evil")]
elif path == "/crash-null":
headers = [("X-Custom", "value\x00end")]
else:
start_response("200 OK", [("Content-Type", "text/plain")])
return [b"OK - server alive\n"]
start_response("200 OK", headers)
return [b"This response kills the worker\n"]
granian --interface wsgi app:app --host 127.0.0.1 --port 8000
Step 2
trigger the crash (any one of these is sufficient)
curl http://127.0.0.1:8000/crash-name
curl http://127.0.0.1:8000/crash-value
curl http://127.0.0.1:8000/crash-null
Expected result:
- the worker aborts after any of the crash paths
- subsequent requests fail until the worker is restarted
Impact
- Worker process denial of service
- A single bad response kills one worker
- Application bugs become process crashes instead of request-scoped failures
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "granian"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.0"
},
{
"fixed": "2.7.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42545"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T21:24:56Z",
"nvd_published_at": "2026-05-12T22:16:34Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nGranian aborts a worker process if a WSGI application returns an invalid HTTP response header name or value. The WSGI response conversion path uses `.unwrap()` on both the header name and header value constructors, so malformed output from the application becomes a process abort instead of a handled error.\n\nThis issue requires a buggy or attacker-influenced WSGI application to emit invalid headers. It is not a parser bug in Granian\u0027s request path. The security impact is that application mistakes which should result in a `500` instead kill the worker process.\n\n### Details\n\nhttps://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/wsgi/io.rs#L39-L42\n\nIf either conversion fails, `.unwrap()` panics. In release builds Granian uses `panic = \"abort\"`, so the panic terminates the worker.\n\n\n#### Preconditions\n\nThe attacker must be able to influence a header name or value produced by the WSGI application, or the application must otherwise generate invalid headers.\n\nExamples include:\n\n- a header name containing a space\n- a header value containing `\\r\\n`\n- a header value containing a null byte\n\nThese are realistic failure modes for applications that reflect user-controlled data into headers such as `Location`, `Content Disposition`, or custom response headers.\n\n### PoC\n\n#### Step 1\n\nstart Granian with the PoC WSGI app\n\n```python\n# app.py\ndef app(environ, start_response):\n path = environ.get(\"PATH_INFO\", \"/\")\n if path == \"/crash-name\":\n headers = [(\"X Bad Name\", \"value\")]\n elif path == \"/crash-value\":\n headers = [(\"Content-Type\", \"text/html\\r\\nX-Injected: evil\")]\n elif path == \"/crash-null\":\n headers = [(\"X-Custom\", \"value\\x00end\")]\n else:\n start_response(\"200 OK\", [(\"Content-Type\", \"text/plain\")])\n return [b\"OK - server alive\\n\"]\n\n start_response(\"200 OK\", headers)\n return [b\"This response kills the worker\\n\"]\n\n```\n\n```bash\ngranian --interface wsgi app:app --host 127.0.0.1 --port 8000\n```\n\n#### Step 2\n\ntrigger the crash (any one of these is sufficient)\n\n```bash\ncurl http://127.0.0.1:8000/crash-name\ncurl http://127.0.0.1:8000/crash-value\ncurl http://127.0.0.1:8000/crash-null\n```\n\n\nExpected result:\n\n- the worker aborts after any of the crash paths\n- subsequent requests fail until the worker is restarted\n\n\n### Impact\n\n- Worker process denial of service\n- A single bad response kills one worker\n- Application bugs become process crashes instead of request-scoped failures",
"id": "GHSA-f5p7-9fr5-8jmj",
"modified": "2026-05-13T16:41:31Z",
"published": "2026-05-06T21:24:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/emmett-framework/granian/security/advisories/GHSA-f5p7-9fr5-8jmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42545"
},
{
"type": "PACKAGE",
"url": "https://github.com/emmett-framework/granian"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Granian vulnerable to DoS via WSGI response header panic"
}
GHSA-F67C-8M2W-79HM
Vulnerability from github – Published: 2023-11-06 12:30 – Updated: 2024-09-11 12:30A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.
{
"affected": [],
"aliases": [
"CVE-2023-5090"
],
"database_specific": {
"cwe_ids": [
"CWE-703",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-06T11:15:09Z",
"severity": "MODERATE"
},
"details": "A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.",
"id": "GHSA-f67c-8m2w-79hm",
"modified": "2024-09-11T12:30:51Z",
"published": "2023-11-06T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5090"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:2758"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3854"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3855"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:4211"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:4352"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-5090"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2248122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F6VF-PQ8C-69M4
Vulnerability from github – Published: 2019-10-16 18:31 – Updated: 2022-02-08 22:07Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.nimbusds:nimbus-jose-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-17195"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2019-10-16T15:26:53Z",
"nvd_published_at": "2019-10-15T14:15:00Z",
"severity": "CRITICAL"
},
"details": "Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.",
"id": "GHSA-f6vf-pq8c-69m4",
"modified": "2022-02-08T22:07:38Z",
"published": "2019-10-16T18:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17195"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcac26c2d4df22341fa6ebbfe93ba1eff77d2dcd3f6106a1dc1f9ac98@%3Cdev.avro.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5e08837e695efd36be73510ce58ec05785dbcea077819d8acc2d990d@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r35f6301a3e6a56259224786dd9c2a935ba27ff6b494d15a3b66efe6a@%3Cdev.avro.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r33dc233634aedb04fa77db3eb79ea12d15ca4da89fa46a1c585ecb0b@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2667286c8ceffaf893b16829b9612d8f7c4ee6b30362c6c1b583e3c2@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/e10d43984f39327e443e875adcd4a5049193a7c010e81971908caf41@%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/8768553cda5838f59ee3865cac546e824fa740e82d9dc2a7fc44e80d@%3Ccommon-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://connect2id.com/blog/nimbus-jose-jwt-7-9"
},
{
"type": "WEB",
"url": "https://bitbucket.org/connect2id/nimbus-jose-jwt/src/master/SECURITY-CHANGELOG.txt"
},
{
"type": "PACKAGE",
"url": "https://bitbucket.org/connect2id/nimbus-jose-jwt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Check for Unusual or Exceptional Conditions in Connect2id Nimbus JOSE+JWT"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.