CWE-755
DiscouragedImproper Handling of Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not handle or incorrectly handles an exceptional condition.
686 vulnerabilities reference this CWE, most recent first.
GHSA-485V-WC7X-92FX
Vulnerability from github – Published: 2026-06-09 21:32 – Updated: 2026-06-09 21:32An issue was discovered in Malwarebytes 4.x and 5.x (and Nebula 2020-10-21 and later). A large number of Firefox preference files can cause the parser to ignore other browser configuration files, leading to a denial of service.
{
"affected": [],
"aliases": [
"CVE-2023-43686"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T19:16:41Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Malwarebytes 4.x and 5.x (and Nebula 2020-10-21 and later). A large number of Firefox preference files can cause the parser to ignore other browser configuration files, leading to a denial of service.",
"id": "GHSA-485v-wc7x-92fx",
"modified": "2026-06-09T21:32:32Z",
"published": "2026-06-09T21:32:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43686"
},
{
"type": "WEB",
"url": "https://www.malwarebytes.com/secure/cves/cve-2023-43686"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4CFH-GW3M-Q584
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:08In a rare scenario, Check Point R80.30 Security Gateway before JHF Take 50 managed by Check Point R80.30 Management crashes with a unique configuration of enhanced logging.
{
"affected": [],
"aliases": [
"CVE-2019-8462"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-02T17:15:00Z",
"severity": "HIGH"
},
"details": "In a rare scenario, Check Point R80.30 Security Gateway before JHF Take 50 managed by Check Point R80.30 Management crashes with a unique configuration of enhanced logging.",
"id": "GHSA-4cfh-gw3m-q584",
"modified": "2024-04-04T02:08:09Z",
"published": "2022-05-24T16:57:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8462"
},
{
"type": "WEB",
"url": "https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=\u0026solutionid=sk153152"
},
{
"type": "WEB",
"url": "https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=\u0026solutionid=sk161812"
}
],
"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-4FFV-765J-GVF6
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2022-05-24 16:56A CWE-248: Uncaught Exception vulnerability exists Modicon M580 (firmware version prior to V2.90), Modicon M340 (firmware version prior to V3.10), Modicon Premium (all versions), and Modicon Quantum (all versions), which could cause a possible denial of service when reading specific coils and registers in the controller over Modbus.
{
"affected": [],
"aliases": [
"CVE-2019-6828"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-17T20:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-248: Uncaught Exception vulnerability exists Modicon M580 (firmware version prior to V2.90), Modicon M340 (firmware version prior to V3.10), Modicon Premium (all versions), and Modicon Quantum (all versions), which could cause a possible denial of service when reading specific coils and registers in the controller over Modbus.",
"id": "GHSA-4ffv-765j-gvf6",
"modified": "2022-05-24T16:56:24Z",
"published": "2022-05-24T16:56:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6828"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4FG4-5R24-WPFF
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30When SAML authentication is enabled, Juniper Networks Mist Cloud UI might incorrectly handle SAML responses, allowing a remote attacker to modify a valid SAML response without invalidating its cryptographic signature to bypass SAML authentication security controls. This issue affects all Juniper Networks Mist Cloud UI versions prior to September 2 2020.
{
"affected": [],
"aliases": [
"CVE-2020-1676"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T21:15:00Z",
"severity": "HIGH"
},
"details": "When SAML authentication is enabled, Juniper Networks Mist Cloud UI might incorrectly handle SAML responses, allowing a remote attacker to modify a valid SAML response without invalidating its cryptographic signature to bypass SAML authentication security controls. This issue affects all Juniper Networks Mist Cloud UI versions prior to September 2 2020.",
"id": "GHSA-4fg4-5r24-wpff",
"modified": "2022-05-24T17:30:52Z",
"published": "2022-05-24T17:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1676"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11072"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4GF2-XV97-63M2
Vulnerability from github – Published: 2021-09-20 20:43 – Updated: 2021-09-16 18:21A flaw was found in keycloak before version 9.0.1. When configuring an Conditional OTP Authentication Flow as a post login flow of an IDP, the failure login events for OTP are not being sent to the brute force protection event queue. So BruteForceProtector does not handle this events.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1744"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-16T18:21:59Z",
"nvd_published_at": "2020-03-24T14:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in keycloak before version 9.0.1. When configuring an Conditional OTP Authentication Flow as a post login flow of an IDP, the failure login events for OTP are not being sent to the brute force protection event queue. So BruteForceProtector does not handle this events.",
"id": "GHSA-4gf2-xv97-63m2",
"modified": "2021-09-16T18:21:59Z",
"published": "2021-09-20T20:43:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1744"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2020-1744"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1744"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Exposure of Sensitive Information in keycloak"
}
GHSA-4H33-V95W-8VH4
Vulnerability from github – Published: 2022-04-03 00:01 – Updated: 2022-04-09 00:00A flaw was found in darkhttpd. Invalid error handling allows remote attackers to cause denial-of-service by accessing a file with a large modification date. The highest threat from this vulnerability is to system availability.
{
"affected": [],
"aliases": [
"CVE-2020-25691"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-01T23:15:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in darkhttpd. Invalid error handling allows remote attackers to cause denial-of-service by accessing a file with a large modification date. The highest threat from this vulnerability is to system availability.",
"id": "GHSA-4h33-v95w-8vh4",
"modified": "2022-04-09T00:00:42Z",
"published": "2022-04-03T00:01:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25691"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1893725"
}
],
"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-4H67-722J-5PMC
Vulnerability from github – Published: 2025-10-27 20:18 – Updated: 2025-10-27 20:18Impact
The implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it's possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. This bug was introduced in the release of Wasmtime 38.0.0 and affects it subsequent patch releases of 38.0.1 and 38.0.2. No other versions of Wasmtime are affected.
In Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of setjmp and longjmp to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn't update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn't present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn't do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.
Component intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the resource.rep intrinsic were directly lifted without having any other wasm in play then it would use the component intrinsic host-to-wasm trampoline. This effectively means that any component required to trigger this bug would have to be carefully crafted for this specific issue. Furthermore triggering this bug would require that these intrinsics are called from the host which requires specific type signatures to be used. Not all embeddings may be invoking functions with exactly the right type signatures, meaning that even if a component could be crafted a pre-built embedding may still not be able to run the component.
Overall the goal of Wasmtime's API is that, without unsafe in Rust, it should not be possible to crash the runtime. With Wasmtime 38.0.{0,1,2} it is possible to crash the runtime, however, hence this security issue. Actually exploiting this in practice would require (a) carefully crafted components, (b) a very specific host embedder using the right type signatures, and (c) a host that updated to 38.0.{0,1,2} within the last few days (38.0.0 was released on 2025-10-20, and this is being published on 2025-10-24). This likely means that almost no embedding is affected, but this security issue is nonetheless being posted for awareness.
Patches
Wasmtime 38.0.3 has been released and is patched to fix this issue.
Workarounds
Affected embeddings have no workaround other than updating to 38.0.3. Users of 37.0.x and prior are not affected. Embeddings that only work with core wasm are not affected. Embeddings may only be affected if functions of specific component type signatures are used/invoked, meaning that if all the prior conditions hold the embedding would need to be audited to see if it's affected.
References
The PR which refactored setjmp/longjmp usage and introduced this issue is https://github.com/bytecodealliance/wasmtime/pull/11592.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "38.0.0"
},
{
"fixed": "38.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62711"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-27T20:18:01Z",
"nvd_published_at": "2025-10-24T22:15:49Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it\u0027s possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. This bug was introduced in the release of Wasmtime 38.0.0 and affects it subsequent patch releases of 38.0.1 and 38.0.2. No other versions of Wasmtime are affected.\n\nIn Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of `setjmp` and `longjmp` to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn\u0027t update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn\u0027t present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn\u0027t do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.\n\nComponent intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the `resource.rep` intrinsic were directly lifted without having any other wasm in play then it would use the component intrinsic host-to-wasm trampoline. This effectively means that any component required to trigger this bug would have to be carefully crafted for this specific issue. Furthermore triggering this bug would require that these intrinsics are called from the host which requires specific type signatures to be used. Not all embeddings may be invoking functions with exactly the right type signatures, meaning that even if a component could be crafted a pre-built embedding may still not be able to run the component.\n\nOverall the goal of Wasmtime\u0027s API is that, without `unsafe` in Rust, it should not be possible to crash the runtime. With Wasmtime 38.0.{0,1,2} it is possible to crash the runtime, however, hence this security issue. Actually exploiting this in practice would require (a) carefully crafted components, (b) a very specific host embedder using the right type signatures, and (c) a host that updated to 38.0.{0,1,2} within the last few days (38.0.0 was released on 2025-10-20, and this is being published on 2025-10-24). This likely means that almost no embedding is affected, but this security issue is nonetheless being posted for awareness.\n\n### Patches\n\nWasmtime 38.0.3 has been released and is patched to fix this issue.\n\n### Workarounds\n\nAffected embeddings have no workaround other than updating to 38.0.3. Users of 37.0.x and prior are not affected. Embeddings that only work with core wasm are not affected. Embeddings may only be affected if functions of specific component type signatures are used/invoked, meaning that if all the prior conditions hold the embedding would need to be audited to see if it\u0027s affected.\n\n### References\n\nThe PR which refactored setjmp/longjmp usage and introduced this issue is https://github.com/bytecodealliance/wasmtime/pull/11592.",
"id": "GHSA-4h67-722j-5pmc",
"modified": "2025-10-27T20:18:01Z",
"published": "2025-10-27T20:18:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4h67-722j-5pmc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62711"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/pull/11592"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/192f2fcdadfec9d0cf6b58548a85a7307450cbf5"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0112.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Wasmtime vulnerable to segfault when using component resources"
}
GHSA-4H99-X2CV-Q42Q
Vulnerability from github – Published: 2024-09-25 12:30 – Updated: 2024-09-25 12:30Improper Handling of Exceptional Conditions vulnerability in the WatchGuard Single Sign-On Client on Windows causes the client to crash while handling malformed commands. An attacker with network access to the client could create a denial of service condition for the Single Sign-On service by repeatedly issuing malformed commands.
This issue affects Single Sign-On Client: through 12.7.
{
"affected": [],
"aliases": [
"CVE-2024-6594"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-25T12:15:05Z",
"severity": "HIGH"
},
"details": "Improper Handling of Exceptional Conditions vulnerability in the WatchGuard Single Sign-On Client on Windows causes the client to crash while handling malformed commands. An attacker with network access to the client could create a denial of service condition for the Single Sign-On service by repeatedly issuing malformed commands.\n\nThis issue affects Single Sign-On Client: through 12.7.",
"id": "GHSA-4h99-x2cv-q42q",
"modified": "2024-09-25T12:30:40Z",
"published": "2024-09-25T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6594"
},
{
"type": "WEB",
"url": "https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2024-00016"
}
],
"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-4J9G-HQRW-W86V
Vulnerability from github – Published: 2022-07-19 00:00 – Updated: 2022-07-27 00:00CVA6 commit d315ddd0f1be27c1b3f27eb0b8daf471a952299a implements an incorrect exception type when an illegal virtual address is loaded.
{
"affected": [],
"aliases": [
"CVE-2022-34637"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-18T23:15:00Z",
"severity": "MODERATE"
},
"details": "CVA6 commit d315ddd0f1be27c1b3f27eb0b8daf471a952299a implements an incorrect exception type when an illegal virtual address is loaded.",
"id": "GHSA-4j9g-hqrw-w86v",
"modified": "2022-07-27T00:00:34Z",
"published": "2022-07-19T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34637"
},
{
"type": "WEB",
"url": "https://github.com/openhwgroup/cva6/issues/904"
}
],
"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-4JVQ-WC69-2RQJ
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37An attacker can craft and send an OpenNamespace message to port 4241 with valid session-id that triggers an unhandled exception in CFTLDManager::HandleRequest function in RnaDaSvr.dll, resulting in process termination. Observed in FactoryTalk Linx 6.11. All versions of FactoryTalk Linx are affected.
{
"affected": [],
"aliases": [
"CVE-2020-5801"
],
"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 attacker can craft and send an OpenNamespace message to port 4241 with valid session-id that triggers an unhandled exception in CFTLDManager::HandleRequest function in RnaDaSvr.dll, resulting in process termination. Observed in FactoryTalk Linx 6.11. All versions of FactoryTalk Linx are affected.",
"id": "GHSA-4jvq-wc69-2rqj",
"modified": "2022-05-24T17:37:29Z",
"published": "2022-05-24T17:37:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5801"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2020-71"
}
],
"schema_version": "1.4.0",
"severity": []
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.