CWE-754
Allowed-with-ReviewImproper Check for Unusual or Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
905 vulnerabilities reference this CWE, most recent first.
GHSA-WVMR-923C-4GW4
Vulnerability from github – Published: 2025-09-11 15:31 – Updated: 2025-09-11 15:31In Content Management versions 20.4- 25.3 authenticated attackers may exploit a complex cache poisoning technique to download unprotected files from the server if the filenames are known.
{
"affected": [],
"aliases": [
"CVE-2025-8716"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T14:15:42Z",
"severity": "MODERATE"
},
"details": "In Content Management versions 20.4- 25.3 authenticated attackers may exploit a complex cache poisoning technique to download unprotected files from the server if the filenames are known.",
"id": "GHSA-wvmr-923c-4gw4",
"modified": "2025-09-11T15:31:17Z",
"published": "2025-09-11T15:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8716"
},
{
"type": "WEB",
"url": "https://support.opentext.com/csm?id=ot_kb_unauthenticated\u0026sysparm_article=KB0847046"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-WWQH-7JM5-GJ7W
Vulnerability from github – Published: 2026-05-08 22:40 – Updated: 2026-06-08 23:47Summary
free5GC's PCF POST /npcf-policyauthorization/v1/app-sessions handler panics on a single authenticated request whose ascReqData.suppFeat == "1" (enabling traffic-routing feature negotiation) and whose medComponents entries supply an afAppId but NO AfRoutReq. The create path then calls provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...) with routeReq == nil and dereferences routeReq.RouteToLocs (and other fields) without a nil check, causing runtime error: invalid memory address or nil pointer dereference. Gin recovery converts the panic into HTTP 500.
The trigger is a single valid authenticated request -- changing only suppFeat from "0" to "1" flips the same shape of POST from a normal 201 Created into a panic-driven 500.
This endpoint requires a valid npcf-policyauthorization OAuth2 access token (PR:L). The PCF process is not killed (Gin recovers); the realized impact is per-request panic-DoS on the app-session create path.
Details
Validated against the PCF container in the official Docker compose lab.
- Source repo tag: v4.2.1
- PCF endpoint: http://10.100.200.9:8000
- Validation date: 2026-03-12
Vulnerable handler path:
postAppSessCtxProcedure
-> medComponents loop
-> appID := medComp.AfAppId
routeReq := medComp.AfRoutReq // nil when AfRoutReq absent
provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, medComp.FStatus)
In provisioningOfTrafficRoutingInfo, routeReq.RouteToLocs, routeReq.UpPathChgSub, and routeReq.AppReloc are dereferenced directly without a nil check. When suppFeat is "0" the traffic-routing branch is not entered and the same input shape returns 201 Created; when suppFeat is "1" the branch is entered and the nil-deref fires.
Code evidence (paths in free5gc/pcf):
- Affected route + dispatch: NFs/pcf/internal/sbi/api_policyauthorization.go
- Create handler path: NFs/pcf/internal/sbi/processor/policyauthorization.go
- Call site that passes nil routeReq into the traffic-routing helper: NFs/pcf/internal/sbi/processor/policyauthorization.go
- Panic site (nil deref of routeReq.* fields): NFs/pcf/internal/sbi/processor/policyauthorization.go:1740
PoC
Reproduced end-to-end against the running PCF at http://10.100.200.9:8000.
- Obtain a valid
npcf-policyauthorizationtoken from NRF:
curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=b84c4f0a-6010-4972-8480-e44e625b9ee4&targetNfType=PCF&scope=npcf-policyauthorization'
- Trigger the panic with a single valid authenticated POST whose
ascReqData.suppFeat == "1",medComponentssuppliesafAppId, andAfRoutReqis absent:
curl -i -X POST 'http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <valid_npcf_policyauthorization_jwt>' \
--data '{"ascReqData":{"suppFeat":"1","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}'
HTTP/1.1 500 Internal Server Error
- Control comparison -- same request shape but
suppFeat="0"-> normal201 Created:
curl -i -X POST 'http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <valid_npcf_policyauthorization_jwt>' \
--data '{"ascReqData":{"suppFeat":"0","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}'
HTTP/1.1 201 Created
- PCF container logs show the panic stack landing in
provisioningOfTrafficRoutingInfowithrouteReq = 0x0:
[ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference
github.com/free5gc/pcf/internal/sbi/processor.provisioningOfTrafficRoutingInfo(..., 0x0, ...)
.../policyauthorization.go:1740
github.com/free5gc/pcf/internal/sbi/processor.(*Processor).postAppSessCtxProcedure
.../policyauthorization.go:288
github.com/free5gc/pcf/internal/sbi/processor.(*Processor).HandlePostAppSessionsContext
.../policyauthorization.go:139
github.com/free5gc/pcf/internal/sbi.(*Server).HTTPPostAppSessions
.../api_policyauthorization.go:119
[INFO][PCF][GIN] | 500 | POST | /npcf-policyauthorization/v1/app-sessions |
Impact
NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the create path passes routeReq straight into provisioningOfTrafficRoutingInfo without a nil check, even though medComp.AfRoutReq is optional and is nil for the demonstrated valid input shape. The control experiment with suppFeat="0" proves the request shape itself is otherwise valid.
Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any authenticated POST against this endpoint with suppFeat="1" and medComponents.*.AfAppId set but AfRoutReq absent returns HTTP 500 with empty body and a stack trace in PCF logs.
Any party that holds (or can obtain) a valid npcf-policyauthorization token can repeatedly drive this code path to sustain a per-request panic-DoS on the app-session create endpoint, with each panic costing more CPU + log writes than the intended controlled response would have.
No Confidentiality impact (the response is 500 with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/879 Upstream fix: https://github.com/free5gc/pcf/pull/65
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/pcf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44317"
],
"database_specific": {
"cwe_ids": [
"CWE-476",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:40:11Z",
"nvd_published_at": "2026-05-27T17:16:36Z",
"severity": "MODERATE"
},
"details": "### Summary\nfree5GC\u0027s PCF `POST /npcf-policyauthorization/v1/app-sessions` handler panics on a single authenticated request whose `ascReqData.suppFeat == \"1\"` (enabling traffic-routing feature negotiation) and whose `medComponents` entries supply an `afAppId` but NO `AfRoutReq`. The create path then calls `provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...)` with `routeReq == nil` and dereferences `routeReq.RouteToLocs` (and other fields) without a nil check, causing `runtime error: invalid memory address or nil pointer dereference`. Gin recovery converts the panic into `HTTP 500`.\n\nThe trigger is a single valid authenticated request -- changing only `suppFeat` from `\"0\"` to `\"1\"` flips the same shape of POST from a normal `201 Created` into a panic-driven `500`.\n\nThis endpoint requires a valid `npcf-policyauthorization` OAuth2 access token (PR:L). The PCF process is not killed (Gin recovers); the realized impact is per-request panic-DoS on the app-session create path.\n\n### Details\nValidated against the PCF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- PCF endpoint: `http://10.100.200.9:8000`\n- Validation date: 2026-03-12\n\nVulnerable handler path:\n```\npostAppSessCtxProcedure\n -\u003e medComponents loop\n -\u003e appID := medComp.AfAppId\n routeReq := medComp.AfRoutReq // nil when AfRoutReq absent\n provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, medComp.FStatus)\n```\n\nIn `provisioningOfTrafficRoutingInfo`, `routeReq.RouteToLocs`, `routeReq.UpPathChgSub`, and `routeReq.AppReloc` are dereferenced directly without a nil check. When `suppFeat` is `\"0\"` the traffic-routing branch is not entered and the same input shape returns `201 Created`; when `suppFeat` is `\"1\"` the branch is entered and the nil-deref fires.\n\nCode evidence (paths in `free5gc/pcf`):\n- Affected route + dispatch: `NFs/pcf/internal/sbi/api_policyauthorization.go`\n- Create handler path: `NFs/pcf/internal/sbi/processor/policyauthorization.go`\n- Call site that passes nil `routeReq` into the traffic-routing helper: `NFs/pcf/internal/sbi/processor/policyauthorization.go`\n- Panic site (nil deref of `routeReq.*` fields): `NFs/pcf/internal/sbi/processor/policyauthorization.go:1740`\n\n### PoC\nReproduced end-to-end against the running PCF at `http://10.100.200.9:8000`.\n\n1. Obtain a valid `npcf-policyauthorization` token from NRF:\n```\ncurl -sS -X POST \u0027http://10.100.200.3:8000/oauth2/token\u0027 \\\n -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n --data \u0027grant_type=client_credentials\u0026nfType=NEF\u0026nfInstanceId=b84c4f0a-6010-4972-8480-e44e625b9ee4\u0026targetNfType=PCF\u0026scope=npcf-policyauthorization\u0027\n```\n\n2. Trigger the panic with a single valid authenticated POST whose `ascReqData.suppFeat == \"1\"`, `medComponents` supplies `afAppId`, and `AfRoutReq` is absent:\n```\ncurl -i -X POST \u0027http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cvalid_npcf_policyauthorization_jwt\u003e\u0027 \\\n --data \u0027{\"ascReqData\":{\"suppFeat\":\"1\",\"notifUri\":\"http://127.0.0.1:9999/appsess\",\"ueIpv4\":\"10.60.0.3\",\"dnn\":\"internet\",\"medComponents\":{\"1\":{\"medCompN\":1,\"afAppId\":\"app1\"}}}}\u0027\n```\n```\nHTTP/1.1 500 Internal Server Error\n```\n\n3. Control comparison -- same request shape but `suppFeat=\"0\"` -\u003e normal `201 Created`:\n```\ncurl -i -X POST \u0027http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cvalid_npcf_policyauthorization_jwt\u003e\u0027 \\\n --data \u0027{\"ascReqData\":{\"suppFeat\":\"0\",\"notifUri\":\"http://127.0.0.1:9999/appsess\",\"ueIpv4\":\"10.60.0.3\",\"dnn\":\"internet\",\"medComponents\":{\"1\":{\"medCompN\":1,\"afAppId\":\"app1\"}}}}\u0027\n```\n```\nHTTP/1.1 201 Created\n```\n\n4. PCF container logs show the panic stack landing in `provisioningOfTrafficRoutingInfo` with `routeReq = 0x0`:\n```\n[ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference\n github.com/free5gc/pcf/internal/sbi/processor.provisioningOfTrafficRoutingInfo(..., 0x0, ...)\n .../policyauthorization.go:1740\n github.com/free5gc/pcf/internal/sbi/processor.(*Processor).postAppSessCtxProcedure\n .../policyauthorization.go:288\n github.com/free5gc/pcf/internal/sbi/processor.(*Processor).HandlePostAppSessionsContext\n .../policyauthorization.go:139\n github.com/free5gc/pcf/internal/sbi.(*Server).HTTPPostAppSessions\n .../api_policyauthorization.go:119\n[INFO][PCF][GIN] | 500 | POST | /npcf-policyauthorization/v1/app-sessions |\n```\n\n### Impact\nNULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the create path passes `routeReq` straight into `provisioningOfTrafficRoutingInfo` without a nil check, even though `medComp.AfRoutReq` is optional and is nil for the demonstrated valid input shape. The control experiment with `suppFeat=\"0\"` proves the request shape itself is otherwise valid.\n\nGin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any authenticated POST against this endpoint with `suppFeat=\"1\"` and `medComponents.*.AfAppId` set but `AfRoutReq` absent returns `HTTP 500` with empty body and a stack trace in PCF logs.\n\nAny party that holds (or can obtain) a valid `npcf-policyauthorization` token can repeatedly drive this code path to sustain a per-request panic-DoS on the app-session create endpoint, with each panic costing more CPU + log writes than the intended controlled response would have.\n\nNo Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/879\nUpstream fix: https://github.com/free5gc/pcf/pull/65",
"id": "GHSA-wwqh-7jm5-gj7w",
"modified": "2026-06-08T23:47:08Z",
"published": "2026-05-08T22:40:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-wwqh-7jm5-gj7w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44317"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/issues/879"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/pcf/pull/65"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/pcf/commit/508d70b8527a6c8c923179dad450ea01e16b6aeb"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"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": "free5GC\u0027s PCF npcf-policyauthorization POST /app-sessions panics on suppFeat=1 with missing AfRoutReq via nil pointer dereference"
}
GHSA-WXPM-2RXR-G39H
Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-17 00:02A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists that could cause a disruption of communication between the Modicon controller and the engineering software, when an attacker is able to intercept and manipulate specific Modbus response data. Affected Product: EcoStruxure Process Expert (V2021 and prior), EcoStruxure Control Expert (V15.0 SP1 and prior)
{
"affected": [],
"aliases": [
"CVE-2022-24323"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists that could cause a disruption of communication between the Modicon controller and the engineering software, when an attacker is able to intercept and manipulate specific Modbus response data. Affected Product: EcoStruxure Process Expert (V2021 and prior), EcoStruxure Control Expert (V15.0 SP1 and prior)",
"id": "GHSA-wxpm-2rxr-g39h",
"modified": "2022-03-17T00:02:09Z",
"published": "2022-03-11T00:02:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24323"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2022-067-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WXXP-W379-49QJ
Vulnerability from github – Published: 2023-09-11 09:31 – Updated: 2024-04-04 07:34When checking if the Browsing Context had been discarded in HttpBaseChannel, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox < 117, Firefox ESR < 115.2, and Thunderbird < 115.2.
{
"affected": [],
"aliases": [
"CVE-2023-4583"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-11T09:15:09Z",
"severity": "HIGH"
},
"details": "When checking if the Browsing Context had been discarded in `HttpBaseChannel`, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox \u003c 117, Firefox ESR \u003c 115.2, and Thunderbird \u003c 115.2.",
"id": "GHSA-wxxp-w379-49qj",
"modified": "2024-04-04T07:34:58Z",
"published": "2023-09-11T09:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4583"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1842030"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2023-34"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2023-36"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2023-38"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X286-GJF2-C426
Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2023-02-02 21:34Improper conditions check in multiple Intel? Processors may allow an authenticated user to potentially enable partial escalation of privilege, denial of service and/or information disclosure via local access.
{
"affected": [],
"aliases": [
"CVE-2019-14607"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-16T20:15:00Z",
"severity": "MODERATE"
},
"details": "Improper conditions check in multiple Intel? Processors may allow an authenticated user to potentially enable partial escalation of privilege, denial of service and/or information disclosure via local access.",
"id": "GHSA-x286-gjf2-c426",
"modified": "2023-02-02T21:34:25Z",
"published": "2022-05-24T17:03:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14607"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191217-0002"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00317.html"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_19_42"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-X2C2-Q32W-4W6M
Vulnerability from github – Published: 2024-01-30 18:42 – Updated: 2024-11-22 20:46Summary
Vyper compiler allows passing a value in builtin raw_call even if the call is a delegatecall or a staticcall. But in the context of delegatecall and staticcall the handling of value is not possible due to the semantics of the respective opcodes, and vyper will silently ignore the value= argument.
A contract search was performed and no vulnerable contracts were found in production.
Details
The IR for raw_call is built in the RawCall class:
https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100
However, the compiler doesn't validate that if either delegatecall or staticall are provided as kwargs, that value wasn't set. For example, the following compiles without errors:
raw_call(self, call_data2, max_outsize=255, is_delegate_call=True, value=msg.value/2)
Impact
If the semantics of the EVM are unknown to the developer, he could suspect that by specifying the value kwarg, exactly the given amount will be sent along to the target. However in fact, no value will be sent.
Here is an example of an potentially problematic implementation of multicall utilizing the raw_call built-in:
value_accumulator: uint256 = empty(uint256)
results: DynArray[Result, max_value(uint8)] = []
return_data: Bytes[max_value(uint8)] = b""
success: bool = empty(bool)
for batch in data:
msg_value: uint256 = batch.value
value_accumulator = unsafe_add(value_accumulator, msg_value)
if (batch.allow_failure == False):
return_data = raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True)
success = True
results.append(Result({success: success, return_data: return_data}))
else:
success, return_data = \
raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True, revert_on_failure=False)
results.append(Result({success: success, return_data: return_data}))
assert msg.value == value_accumulator, "Multicall: value mismatch"
return results
Patches
Fixed in https://github.com/vyperlang/vyper/pull/3755
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-24567"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-30T18:42:28Z",
"nvd_published_at": "2024-01-30T21:15:08Z",
"severity": "MODERATE"
},
"details": "### Summary\nVyper compiler allows passing a value in builtin `raw_call` even if the call is a `delegatecall` or a `staticcall`. But in the context of `delegatecall` and `staticcall` the handling of value is not possible due to the semantics of the respective opcodes, and vyper will silently ignore the `value=` argument.\n\nA contract search was performed and no vulnerable contracts were found in production.\n\n### Details\nThe IR for `raw_call` is built in the `RawCall` class:\nhttps://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100\n\nHowever, the compiler doesn\u0027t validate that if either `delegatecall` or `staticall` are provided as kwargs, that `value` wasn\u0027t set. For example, the following compiles without errors:\n```python\nraw_call(self, call_data2, max_outsize=255, is_delegate_call=True, value=msg.value/2)\n```\n\n### Impact\nIf the semantics of the EVM are unknown to the developer, he could suspect that by specifying the `value` kwarg, exactly the given amount will be sent along to the target. However in fact, no `value` will be sent.\n\nHere is an example of an potentially problematic implementation of multicall utilizing the `raw_call` built-in:\n```python\nvalue_accumulator: uint256 = empty(uint256)\n results: DynArray[Result, max_value(uint8)] = []\n return_data: Bytes[max_value(uint8)] = b\"\"\n success: bool = empty(bool)\n for batch in data:\n msg_value: uint256 = batch.value\n value_accumulator = unsafe_add(value_accumulator, msg_value)\n if (batch.allow_failure == False):\n return_data = raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True)\n success = True\n results.append(Result({success: success, return_data: return_data}))\n else:\n success, return_data = \\\n raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True, revert_on_failure=False)\n results.append(Result({success: success, return_data: return_data}))\n assert msg.value == value_accumulator, \"Multicall: value mismatch\"\n return results\n```\n\n### Patches\nFixed in https://github.com/vyperlang/vyper/pull/3755\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n",
"id": "GHSA-x2c2-q32w-4w6m",
"modified": "2024-11-22T20:46:32Z",
"published": "2024-01-30T18:42:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-x2c2-q32w-4w6m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24567"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/pull/3755"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/a2df08888c318713742c57f71465f32a1c27ed72"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-151.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vyperlang/vyper"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Vyper\u0027s raw_call `value=` kwargs not disabled for static and delegate calls"
}
GHSA-X3F3-63G4-54J4
Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-06-30 03:35Incorrect boundary conditions in the Graphics: Canvas2D component. This vulnerability affects Firefox < 149, Firefox ESR < 115.34, and Firefox ESR < 140.9.
{
"affected": [],
"aliases": [
"CVE-2026-4686"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T13:16:04Z",
"severity": "HIGH"
},
"details": "Incorrect boundary conditions in the Graphics: Canvas2D component. This vulnerability affects Firefox \u003c 149, Firefox ESR \u003c 115.34, and Firefox ESR \u003c 140.9.",
"id": "GHSA-x3f3-63g4-54j4",
"modified": "2026-06-30T03:35:58Z",
"published": "2026-03-24T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4686"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5930"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8287"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8288"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8289"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8290"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8315"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8427"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-4686"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2016351"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450734"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4686.json"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-21"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-22"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-23"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-24"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5931"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5932"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6188"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6342"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6917"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7837"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7838"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7839"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7840"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7841"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7842"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7843"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7845"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7858"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8284"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8285"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8286"
}
],
"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-X44M-V68F-CRCX
Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2022-05-13 01:08gio/gsocketclient.c in GNOME GLib 2.59.2 does not ensure that a parent GTask remains alive during the execution of a connection-attempting enumeration, which allows remote attackers to cause a denial of service (g_socket_client_connected_callback mishandling and application crash) via a crafted web site, as demonstrated by GNOME Web (aka Epiphany).
{
"affected": [],
"aliases": [
"CVE-2019-9633"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-08T08:29:00Z",
"severity": "MODERATE"
},
"details": "gio/gsocketclient.c in GNOME GLib 2.59.2 does not ensure that a parent GTask remains alive during the execution of a connection-attempting enumeration, which allows remote attackers to cause a denial of service (g_socket_client_connected_callback mishandling and application crash) via a crafted web site, as demonstrated by GNOME Web (aka Epiphany).",
"id": "GHSA-x44m-v68f-crcx",
"modified": "2022-05-13T01:08:20Z",
"published": "2022-05-13T01:08:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9633"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/issues/1649"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107391"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X4P9-P8G9-V45F
Vulnerability from github – Published: 2025-01-14 18:31 – Updated: 2025-09-25 21:30Improper Check for Unusual or Exceptional Conditions vulnerability in Phoenix SecureCore™ for Intel Kaby Lake, Phoenix SecureCore™ for Intel Coffee Lake, Phoenix SecureCore™ for Intel Comet Lake, Phoenix SecureCore™ for Intel Ice Lake allows Input Data Manipulation.This issue affects SecureCore™ for Intel Kaby Lake: before 4.0.1.1012; SecureCore™ for Intel Coffee Lake: before 4.1.0.568; SecureCore™ for Intel Comet Lake: before 4.2.1.292; SecureCore™ for Intel Ice Lake: before 4.2.0.334.
{
"affected": [],
"aliases": [
"CVE-2024-29979"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T16:15:28Z",
"severity": "MODERATE"
},
"details": "Improper Check for Unusual or Exceptional Conditions vulnerability in Phoenix SecureCore\u2122 for Intel Kaby Lake, Phoenix SecureCore\u2122 for Intel Coffee Lake, Phoenix SecureCore\u2122 for Intel Comet Lake, Phoenix SecureCore\u2122 for Intel Ice Lake allows Input Data Manipulation.This issue affects SecureCore\u2122 for Intel Kaby Lake: before 4.0.1.1012; SecureCore\u2122 for Intel Coffee Lake: before 4.1.0.568; SecureCore\u2122 for Intel Comet Lake: before 4.2.1.292; SecureCore\u2122 for Intel Ice Lake: before 4.2.0.334.",
"id": "GHSA-x4p9-p8g9-v45f",
"modified": "2025-09-25T21:30:20Z",
"published": "2025-01-14T18:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29979"
},
{
"type": "WEB",
"url": "https://phoenixtech.com/phoenix-security-notifications/cve-2024-29979"
},
{
"type": "WEB",
"url": "https://www.phoenix.com/phoenix-security-notifications/cve-2024-29979"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/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-X4X8-FC23-7GG9
Vulnerability from github – Published: 2022-01-29 00:00 – Updated: 2022-02-04 00:00A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists that could cause a Denial of Service of the RTU when receiving a specially crafted request over Modbus, and the RTU is configured as a Modbus server. Affected Products: SCADAPack 312E, 313E, 314E, 330E, 333E, 334E, 337E, 350E and 357E RTUs with firmware V8.18.1 and prior
{
"affected": [],
"aliases": [
"CVE-2021-22816"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-28T20:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists that could cause a Denial of Service of the RTU when receiving a specially crafted request over Modbus, and the RTU is configured as a Modbus server. Affected Products: SCADAPack 312E, 313E, 314E, 330E, 333E, 334E, 337E, 350E and 357E RTUs with firmware V8.18.1 and prior",
"id": "GHSA-x4x8-fc23-7gg9",
"modified": "2022-02-04T00:00:45Z",
"published": "2022-01-29T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22816"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-313-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Check the results of all functions that return a value and verify that the value is expected.
Mitigation
If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Mitigation
Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
No CAPEC attack patterns related to this CWE.