CWE-390
AllowedDetection of Error Condition Without Action
Abstraction: Base · Status: Draft
The product detects a specific error, but takes no actions to handle the error.
41 vulnerabilities reference this CWE, most recent first.
GHSA-97FP-2VW9-Q5JG
Vulnerability from github – Published: 2026-07-21 12:33 – Updated: 2026-09-01 21:31A flaw was found in libssh. When ProxyCommand is used, an unchecked fork() failure can be stored as process ID -1; during cleanup, signals may then be sent across the caller's accessible process tree, leading to local denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-59845"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T12:18:58Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libssh. When ProxyCommand is used, an unchecked fork() failure can be stored as process ID -1; during cleanup, signals may then be sent across the caller\u0027s accessible process tree, leading to local denial of service.",
"id": "GHSA-97fp-2vw9-q5jg",
"modified": "2026-09-01T21:31:14Z",
"published": "2026-07-21T12:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59845"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42922"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:55855"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:62217"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:62218"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-59845"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2498178"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FGW4-V983-MGP8
Vulnerability from github – Published: 2025-02-14 17:19 – Updated: 2025-02-14 18:40Summary
A bug in GitHub's Artifact Attestation CLI tool, gh attestation verify, may return an incorrect zero exit status when no matching attestations are found for the specified --predicate-type <value> or the default https://slsa.dev/provenance/v1 if not specified. This issue only arises if an artifact has an attestation with a predicate type different from the one provided in the command. As a result, users relying solely on these exit codes may mistakenly believe the attestation has been verified, despite the absence of an attestation with the specified predicate type and the tool printing a verification failure.
Users are advised to update gh to version v2.67.0 as soon as possible.
Initial report: https://github.com/cli/cli/issues/10418 Fix: https://github.com/cli/cli/pull/10421
Details
The gh attestation verify command fetches, loads, and attempts to verify attestations associated with a given artifact for a specified predicate type. If an attestation is found, but the predicate type does not match the one specified in the gh attestation verify command, the verification fails, but the program exits early.
Due to a re-used uninitialized error variable, when no matching attestations are found, the relevant function returns nil instead of an error, causing the program to exit with a status code of 0, which incorrectly suggests successful verification.
PoC
Run gh attestation verify with local attestations using the --bundle flag and specify a predicate type with --predicate-type that you know will not match any of the attestations the command will attempt to verify. Confirm that the command exits with a zero status code.
Impact
Users who rely exclusively on the exit status code of gh attestation verify may incorrectly verify an attestation when the attestation's predicate type does not match the specified predicate type in the command.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cli/cli/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.49.0"
},
{
"fixed": "2.67.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-25204"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-14T17:19:14Z",
"nvd_published_at": "2025-02-14T17:15:19Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA bug in GitHub\u0027s Artifact Attestation CLI tool, `gh attestation verify`, may return an incorrect zero exit status when no matching attestations are found for the specified `--predicate-type \u003cvalue\u003e` or the default `https://slsa.dev/provenance/v1` if not specified. This issue only arises if an artifact has an attestation with a predicate type different from the one provided in the command. As a result, users relying solely on these exit codes may mistakenly believe the attestation has been verified, despite the absence of an attestation with the specified predicate type and the tool printing a verification failure.\n\nUsers are advised to update `gh` to version `v2.67.0` as soon as possible.\n\nInitial report: https://github.com/cli/cli/issues/10418\nFix: https://github.com/cli/cli/pull/10421\n\n### Details\n\nThe gh attestation verify command fetches, loads, and attempts to verify attestations associated with a given artifact for a specified predicate type. If an attestation is found, but the predicate type does not match the one specified in the `gh attestation verify` command, the verification fails, but the program exits early.\n\nDue to a re-used uninitialized error variable, when no matching attestations are found, the relevant function returns `nil` instead of an error, causing the program to exit with a status code of `0`, which incorrectly suggests successful verification.\n\n### PoC\n\nRun `gh attestation verify` with local attestations using the `--bundle` flag and specify a predicate type with `--predicate-type` that you know will not match any of the attestations the command will attempt to verify. Confirm that the command exits with a zero status code.\n\n### Impact\n\nUsers who rely exclusively on the exit status code of `gh attestation verify` may incorrectly verify an attestation when the attestation\u0027s predicate type does not match the specified predicate type in the command.",
"id": "GHSA-fgw4-v983-mgp8",
"modified": "2025-02-14T18:40:04Z",
"published": "2025-02-14T17:19:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cli/cli/security/advisories/GHSA-fgw4-v983-mgp8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25204"
},
{
"type": "WEB",
"url": "https://github.com/cli/cli/issues/10418"
},
{
"type": "WEB",
"url": "https://github.com/cli/cli/pull/10421"
},
{
"type": "PACKAGE",
"url": "https://github.com/cli/cli"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "`gh attestation verify` returns incorrect exit code during verification if no attestations are present"
}
GHSA-FJ9W-C36G-H5X8
Vulnerability from github – Published: 2026-09-17 17:18 – Updated: 2026-09-17 17:18Impact
For SCRAM, and for Digest with mutual authentication, the client computes the server's verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client's only signal that the peer does not know the secret.
Affected versions
- 3.x: 3.0.8 through 3.0.11
Earlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.
Patches
Fixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.
Known limitations
Verification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.
Verification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.
Details
In the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Known limitation
This fix does not cover Digest exchanges negotiated with qop="auth-int". Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.
A peer that controls the challenge can select this deliberately by offering qop="auth-int" alone, which switches mutual authentication off for the whole exchange. Offering auth,auth-int does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.11"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.8"
},
{
"fixed": "3.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-85716"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:18:39Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nFor SCRAM, and for Digest with mutual authentication, the client computes the server\u0027s verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client\u0027s only signal that the peer does not know the secret.\n\n### Affected versions\n* 3.x: 3.0.8 through 3.0.11\n\nEarlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.\n\n### Patches\nFixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.\n\n### Known limitations\nVerification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.\n\nVerification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.\n\n### Details\nIn the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.\n\nNote that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.\n\n### Known limitation\n\nThis fix does not cover Digest exchanges negotiated with `qop=\"auth-int\"`. Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.\n\nA peer that controls the challenge can select this deliberately by offering `qop=\"auth-int\"` alone, which switches mutual authentication off for the whole exchange. Offering `auth,auth-int` does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.",
"id": "GHSA-fj9w-c36g-h5x8",
"modified": "2026-09-17T17:18:39Z",
"published": "2026-09-17T17:18:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-fj9w-c36g-h5x8"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/pull/2235"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/10b3db9910f0bbad2ea3dc7c7553bae12bc4a5e4"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/685173afea07892462071d966ef6ce5c88cbc66f"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/7fe8700fd5b46c668cee7774624f36b87b9dd32a"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncHttpClient doesn\u0027t verify SCRAM and Digest mutual-authentication responses"
}
GHSA-GC45-PR9V-JW83
Vulnerability from github – Published: 2026-02-10 21:31 – Updated: 2026-02-10 21:31Improper handling of error condition during host-induced faults can allow a local high-privileged attack to selectively drop guest DMA writes, potentially resulting in a loss of SEV-SNP guest memory integrity
{
"affected": [],
"aliases": [
"CVE-2025-0029"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T20:16:43Z",
"severity": "LOW"
},
"details": "Improper handling of error condition during host-induced faults can allow a local high-privileged attack to selectively drop guest DMA writes, potentially resulting in a loss of SEV-SNP guest memory integrity",
"id": "GHSA-gc45-pr9v-jw83",
"modified": "2026-02-10T21:31:30Z",
"published": "2026-02-10T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0029"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-3023.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-GXPV-MFCQ-P5M9
Vulnerability from github – Published: 2025-10-09 06:30 – Updated: 2025-10-09 06:30Memory corruption may occur while processing IOCTL call for DMM/WARPNCC CONFIG request.
{
"affected": [],
"aliases": [
"CVE-2025-27039"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-09T04:16:33Z",
"severity": "MODERATE"
},
"details": "Memory corruption may occur while processing IOCTL call for DMM/WARPNCC CONFIG request.",
"id": "GHSA-gxpv-mfcq-p5m9",
"modified": "2025-10-09T06:30:24Z",
"published": "2025-10-09T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27039"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/october-2025-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JRWV-MV4H-7RRQ
Vulnerability from github – Published: 2025-02-18 21:32 – Updated: 2025-02-19 15:32A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.
{
"affected": [],
"aliases": [
"CVE-2025-26465"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T19:15:29Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client\u0027s memory resource first, turning the attack complexity high.",
"id": "GHSA-jrwv-mv4h-7rrq",
"modified": "2025-02-19T15:32:12Z",
"published": "2025-02-18T21:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26465"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-26465"
},
{
"type": "WEB",
"url": "https://blog.qualys.com/vulnerabilities-threat-research/2025/02/18/qualys-tru-discovers-two-vulnerabilities-in-openssh-cve-2025-26465-cve-2025-26466"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2344780"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1237040"
},
{
"type": "WEB",
"url": "https://ftp.openbsd.org/pub/OpenBSD/patches/7.6/common/008_ssh.patch.sig"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00020.html"
},
{
"type": "WEB",
"url": "https://lists.mindrot.org/pipermail/openssh-unix-announce/2025-February/000161.html"
},
{
"type": "WEB",
"url": "https://seclists.org/oss-sec/2025/q1/144"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2025-26465"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/CVE-2025-26465"
},
{
"type": "WEB",
"url": "https://www.openssh.com/releasenotes.html#9.9p2"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2025/02/18/1"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2025/02/18/4"
},
{
"type": "WEB",
"url": "https://www.theregister.com/2025/02/18/openssh_vulnerabilities_mitm_dos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M4W6-2G7F-9J5P
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers
Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized.
Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator.
Fix this by shifting the error handling responsibility to the callers.
{
"affected": [],
"aliases": [
"CVE-2026-52989"
],
"database_specific": {
"cwe_ids": [
"CWE-390",
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:09Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers\n\nCurrently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds\nPDU length or offset, it triggers nvmet_tcp_fatal_error(cmd-\u003equeue)\nand returns early. However, because the function returns void, the\ncallers are entirely unaware that a fatal error has occurred and\nthat the cmd-\u003erecv_msg.msg_iter was left uninitialized.\n\nCallers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly\noverwrite the queue state with queue-\u003ercv_state = NVMET_TCP_RECV_DATA\nConsequently, the socket receiving loop may attempt to read incoming\nnetwork data into the uninitialized iterator.\n\nFix this by shifting the error handling responsibility to the callers.",
"id": "GHSA-m4w6-2g7f-9j5p",
"modified": "2026-06-30T03:37:12Z",
"published": "2026-06-24T18:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52989"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-52989"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492443"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/046fa5c72d15cd8e2d592e275697ea399d8f76b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3df42a854686fa06484e37ac1a3931c8e3e3453c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2a11441538bdbbc5aa003f190995eba93a89b88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7c8f95f599b3b38a717d2e771c3f8c174f657c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea8e356acb165cb1fd75537a52e1f66e5e76c538"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9204a2b78dd18374d3bcf9bf93d9021ce22de1b"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52989.json"
}
],
"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"
}
]
}
GHSA-PHM4-GGP6-MRRC
Vulnerability from github – Published: 2025-11-13 21:31 – Updated: 2025-11-13 21:31Dell Alienware Command Center 6.x (AWCC), versions prior to 6.10.15.0, contain a Detection of Error Condition Without Action vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Arbitrary Code Execution.
{
"affected": [],
"aliases": [
"CVE-2025-46367"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-13T20:15:49Z",
"severity": "HIGH"
},
"details": "Dell Alienware Command Center 6.x (AWCC), versions prior to 6.10.15.0, contain a Detection of Error Condition Without Action vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Arbitrary Code Execution.",
"id": "GHSA-phm4-ggp6-mrrc",
"modified": "2025-11-13T21:31:19Z",
"published": "2025-11-13T21:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46367"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000379467/dsa-2025-392"
}
],
"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-PV78-Q37W-R4JP
Vulnerability from github – Published: 2025-05-06 09:31 – Updated: 2025-05-06 09:31Memory corruption during memory assignment to headless peripheral VM due to incorrect error code handling.
{
"affected": [],
"aliases": [
"CVE-2024-49841"
],
"database_specific": {
"cwe_ids": [
"CWE-390",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-06T09:15:21Z",
"severity": "HIGH"
},
"details": "Memory corruption during memory assignment to headless peripheral VM due to incorrect error code handling.",
"id": "GHSA-pv78-q37w-r4jp",
"modified": "2025-05-06T09:31:33Z",
"published": "2025-05-06T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49841"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/may-2025-bulletin.html"
}
],
"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-VFV6-G6X5-RCP8
Vulnerability from github – Published: 2026-09-13 21:31 – Updated: 2026-09-13 21:31CyberPanel before 2.4.4 omits a "return 0" that is required by the business logic.
{
"affected": [],
"aliases": [
"CVE-2026-29810"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-13T20:16:50Z",
"severity": "MODERATE"
},
"details": "CyberPanel before 2.4.4 omits a \"return 0\" that is required by the business logic.",
"id": "GHSA-vfv6-g6x5-rcp8",
"modified": "2026-09-13T21:31:41Z",
"published": "2026-09-13T21:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29810"
},
{
"type": "WEB",
"url": "https://github.com/usmannasir/cyberpanel/commit/0a099b1b193946555fbdd387a28486b1521f9961"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
Mitigation
If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.
Mitigation
Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.
No CAPEC attack patterns related to this CWE.