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.
975 vulnerabilities reference this CWE, most recent first.
GHSA-V2P2-Q52J-R78G
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03Improper Check for Unusual or Exceptional Conditions vulnerability exists in Triconex Model 3009 MP installed on Tricon V11.3.x systems that could cause module reset when TCM receives malformed TriStation packets while the write-protect keyswitch is in the program position. This CVE ID is unique from CVE-2021-22742, CVE-2021-22744, CVE-2021-22745, and CVE-2021-22746.
{
"affected": [],
"aliases": [
"CVE-2021-22747"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-26T20:15:00Z",
"severity": "LOW"
},
"details": "Improper Check for Unusual or Exceptional Conditions vulnerability exists in Triconex Model 3009 MP installed on Tricon V11.3.x systems that could cause module reset when TCM receives malformed TriStation packets while the write-protect keyswitch is in the program position. This CVE ID is unique from CVE-2021-22742, CVE-2021-22744, CVE-2021-22745, and CVE-2021-22746.",
"id": "GHSA-v2p2-q52j-r78g",
"modified": "2022-05-24T19:03:16Z",
"published": "2022-05-24T19:03:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22747"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-130-03"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V2PF-75PF-9C5H
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
tls: fix handling of zero-length records on the rx_list
Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record
If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.
Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).
Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.
{
"affected": [],
"aliases": [
"CVE-2025-39682"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-05T18:15:44Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix handling of zero-length records on the rx_list\n\nEach recvmsg() call must process either\n - only contiguous DATA records (any number of them)\n - one non-DATA record\n\nIf the next record has different type than what has already been\nprocessed we break out of the main processing loop. If the record\nhas already been decrypted (which may be the case for TLS 1.3 where\nwe don\u0027t know type until decryption) we queue the pending record\nto the rx_list. Next recvmsg() will pick it up from there.\n\nQueuing the skb to rx_list after zero-copy decrypt is not possible,\nsince in that case we decrypted directly to the user space buffer,\nand we don\u0027t have an skb to queue (darg.skb points to the ciphertext\nskb for access to metadata like length).\n\nOnly data records are allowed zero-copy, and we break the processing\nloop after each non-data record. So we should never zero-copy and\nthen find out that the record type has changed. The corner case\nwe missed is when the initial record comes from rx_list, and it\u0027s\nzero length.",
"id": "GHSA-v2pf-75pf-9c5h",
"modified": "2026-05-12T15:31:03Z",
"published": "2025-09-05T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39682"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2902c3ebcca52ca845c03182000e8d71d3a5196f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29c0ce3c8cdb6dc5d61139c937f34cb888a6f42e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3439c15ae91a517cf3c650ea15a8987699416ad9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62708b9452f8eb77513115b17c4f8d1a22ebf843"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c09dd3773b5950e9cfb6c9b9a5f6e36d06c62677"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V39V-59XW-J98G
Vulnerability from github – Published: 2026-09-10 22:42 – Updated: 2026-09-10 22:42Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
Summary
Calendar events carry a free-form meta object that is stored exactly as submitted, with no validation of the values inside it. The scheduler reads the per-event alert offset out of that object in a single pass that covers every user's upcoming events, and compares it numerically without checking that it is a number. Any verified user could store a text value there, which made the comparison raise and abort the whole pass, so no calendar reminder fired for anyone on the instance while that event stayed inside the lookahead window.
Preconditions
- Calendar is enabled (
ENABLE_CALENDAR/calendar.enable, defaultTrue). - The attacker is a verified user (role
useroradmin) holding thecalendarfeature permission, which is granted to all users by default (USER_PERMISSIONS_FEATURES_CALENDAR, defaultTrue). - The event's start time falls inside the scheduler's one hour lookahead window, so the shared alert pass selects it.
No admin access, no shared calendar, no recurrence rule and no open registration are required, an invited account is enough. Deployments running with the calendar disabled, or with the calendar feature permission removed from regular users, are not affected.
Impact
Availability loss on one feature, affecting every user on the instance. While a single event carrying a non-numeric alert value sat in the upcoming window, the shared alert pass raised before emitting anything, so no user received calendar alerts and no event was recorded as alerted. The same events were selected again on the next poll, so the suppression lasted as long as the event stayed in the window, roughly one hour per event, and could be sustained by storing a new one. Every user on a default deployment holds the permission needed to do this.
Chat, timers, automations and the HTTP API kept working throughout, and authenticated calendar reads continued to succeed. There is no crash, no code execution, and no access to other users' data. Alerts resumed on their own once the event left the window or was deleted.
Fix
Fixed in https://github.com/open-webui/open-webui/pull/28790, released in 0.11.1. The scheduler now treats any non-numeric alert value as unset and falls back to the default alert offset, so a stored text value can no longer interrupt the pass. Upgrading is sufficient and no configuration change is required. Events already holding a bad value simply revert to the default alert timing.
Root cause
Affected component: the upcoming-event lookup in the calendar event model, which the scheduler's alert pass calls every poll. Affected setup: every build carrying the calendar feature, which was introduced in 0.9.0.
Event meta is an untyped dictionary and was written to the database exactly as submitted, so nothing on the write path guaranteed that the alert offset was a number. The alert pass then read that value back and compared it numerically on the assumption that the write path had already constrained it, and the loop had no per-event error handling. Because a single background pass serves the whole instance rather than one user at a time, one unusable value from one user aborted the pass for everyone.
Proof of concept
Reported with a scripted reproduction against 0.11.0 (ghcr.io/open-webui/open-webui:latest) with the calendar enabled and two ordinary user accounts. The first account created an upcoming event with the alert offset stored as the text "5", the second created a normal upcoming event with a numeric offset. Across several scheduler polls the second user's event was never marked as alerted and no alert was delivered, while the server logged a type error from the alert pass on each poll. Health checks and authenticated calendar reads returned normally during the fault. After the first account's event was deleted, the second user's event was marked as alerted on the next poll and alerting resumed.
Credits
Binbin Xu of Tencent YUNDING LAB CodeBuddy Security.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87012"
],
"database_specific": {
"cwe_ids": [
"CWE-1287",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:42:48Z",
"nvd_published_at": "2026-09-09T21:17:06Z",
"severity": "MODERATE"
},
"details": "# Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value\n\n## Summary\n\nCalendar events carry a free-form `meta` object that is stored exactly as submitted, with no validation of the values inside it. The scheduler reads the per-event alert offset out of that object in a single pass that covers every user\u0027s upcoming events, and compares it numerically without checking that it is a number. Any verified user could store a text value there, which made the comparison raise and abort the whole pass, so no calendar reminder fired for anyone on the instance while that event stayed inside the lookahead window.\n\n## Preconditions\n\n- Calendar is enabled (`ENABLE_CALENDAR` / `calendar.enable`, default `True`).\n- The attacker is a verified user (role `user` or `admin`) holding the `calendar` feature permission, which is granted to all users by default (`USER_PERMISSIONS_FEATURES_CALENDAR`, default `True`).\n- The event\u0027s start time falls inside the scheduler\u0027s one hour lookahead window, so the shared alert pass selects it.\n\nNo admin access, no shared calendar, no recurrence rule and no open registration are required, an invited account is enough. Deployments running with the calendar disabled, or with the calendar feature permission removed from regular users, are not affected.\n\n## Impact\n\nAvailability loss on one feature, affecting every user on the instance. While a single event carrying a non-numeric alert value sat in the upcoming window, the shared alert pass raised before emitting anything, so no user received calendar alerts and no event was recorded as alerted. The same events were selected again on the next poll, so the suppression lasted as long as the event stayed in the window, roughly one hour per event, and could be sustained by storing a new one. Every user on a default deployment holds the permission needed to do this.\n\nChat, timers, automations and the HTTP API kept working throughout, and authenticated calendar reads continued to succeed. There is no crash, no code execution, and no access to other users\u0027 data. Alerts resumed on their own once the event left the window or was deleted.\n\n## Fix\n\nFixed in https://github.com/open-webui/open-webui/pull/28790, released in 0.11.1. The scheduler now treats any non-numeric alert value as unset and falls back to the default alert offset, so a stored text value can no longer interrupt the pass. Upgrading is sufficient and no configuration change is required. Events already holding a bad value simply revert to the default alert timing.\n\n## Root cause\n\nAffected component: the upcoming-event lookup in the calendar event model, which the scheduler\u0027s alert pass calls every poll. Affected setup: every build carrying the calendar feature, which was introduced in 0.9.0.\n\nEvent `meta` is an untyped dictionary and was written to the database exactly as submitted, so nothing on the write path guaranteed that the alert offset was a number. The alert pass then read that value back and compared it numerically on the assumption that the write path had already constrained it, and the loop had no per-event error handling. Because a single background pass serves the whole instance rather than one user at a time, one unusable value from one user aborted the pass for everyone.\n\n## Proof of concept\n\nReported with a scripted reproduction against 0.11.0 (`ghcr.io/open-webui/open-webui:latest`) with the calendar enabled and two ordinary user accounts. The first account created an upcoming event with the alert offset stored as the text `\"5\"`, the second created a normal upcoming event with a numeric offset. Across several scheduler polls the second user\u0027s event was never marked as alerted and no alert was delivered, while the server logged a type error from the alert pass on each poll. Health checks and authenticated calendar reads returned normally during the fault. After the first account\u0027s event was deleted, the second user\u0027s event was marked as alerted on the next poll and alerting resumed.\n\n## Credits\n\nBinbin Xu\u200b of Tencent YUNDING LAB CodeBuddy Security.",
"id": "GHSA-v39v-59xw-j98g",
"modified": "2026-09-10T22:42:48Z",
"published": "2026-09-10T22:42:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-v39v-59xw-j98g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87012"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/28790"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/abc69000b33b4894fbd97fc2c962139cf9a8d784"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value"
}
GHSA-V4G8-GWFH-3CJ3
Vulnerability from github – Published: 2025-10-09 18:30 – Updated: 2025-10-09 18:30An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated, network-based attacker to cause impact to confidentiality and availability.
When an output firewall filter is configured with one or more terms where the action is 'reject', packets matching these terms are erroneously sent to the Routing Engine (RE) and further processed there. Processing of these packets will consume limited RE resources. Also responses from the RE back to the source of this traffic could reveal confidential information about the affected device. This issue only applies to firewall filters applied to WAN or revenue interfaces, so not the mgmt or lo0 interface of the routing-engine, nor any input filters.
This issue affects Junos OS Evolved on PTX Series:
- all versions before 22.4R3-EVO,
- 23.2 versions before 23.2R2-EVO.
{
"affected": [],
"aliases": [
"CVE-2025-59958"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-09T16:15:45Z",
"severity": "MODERATE"
},
"details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated, network-based attacker to cause impact to confidentiality and availability.\n\nWhen an output firewall filter is configured with one or more\u00a0terms where the action is \u0027reject\u0027, packets matching these terms are\u00a0erroneously sent to the Routing Engine (RE) and further processed there.\u00a0Processing of these packets will consume limited RE resources. Also responses from the RE back to the source of this traffic could reveal confidential information about the affected device.\nThis issue only applies to firewall filters applied to WAN or revenue interfaces, so not the mgmt or lo0 interface of the routing-engine, nor any input filters.\n\nThis issue affects Junos OS Evolved on PTX Series:\n\n\n\n * all versions before 22.4R3-EVO,\n * 23.2 versions before 23.2R2-EVO.",
"id": "GHSA-v4g8-gwfh-3cj3",
"modified": "2025-10-09T18:30:36Z",
"published": "2025-10-09T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59958"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA103147"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/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:M/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-V528-7HRM-FRQP
Vulnerability from github – Published: 2021-06-16 18:03 – Updated: 2023-02-15 18:39An issue was discovered in netplex json-smart-v1 through 2015-10-23 and json-smart-v2 through 2.4. An exception is thrown from a function, but it is not caught, as demonstrated by NumberFormatException. When it is not caught, it may cause programs using the library to crash or expose sensitive information.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart-mini"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-27568"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-18T22:30:13Z",
"nvd_published_at": "2021-02-23T02:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in netplex json-smart-v1 through 2015-10-23 and json-smart-v2 through 2.4. An exception is thrown from a function, but it is not caught, as demonstrated by NumberFormatException. When it is not caught, it may cause programs using the library to crash or expose sensitive information.",
"id": "GHSA-v528-7hrm-frqp",
"modified": "2023-02-15T18:39:26Z",
"published": "2021-06-16T18:03:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27568"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v1/issues/7"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/issues/60"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/issues/62"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/pull/72"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v1/commit/768db58ee0e3e344fcdb574b7629765308a1d0af"
},
{
"type": "PACKAGE",
"url": "https://github.com/netplex/json-smart-v2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb6287f5aa628c8d9af52b5401ec6cc51b6fc28ab20d318943453e396@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re237267da268c690df5e1c6ea6a38a7fc11617725e8049490f58a6fa@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf70210b4d63191c0bfb2a0d5745e104484e71703bf5ad9cb01c980c6@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
}
],
"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": "Improper Check for Unusual or Exceptional Conditions in json-smart"
}
GHSA-V55M-MM25-X584
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48An Improper Check for Unusual or Exceptional Conditions in Juniper Networks Junos OS Evolved may cause the stateless firewall filter configuration which uses the action 'policer' in certain combinations with other options to not take effect. An administrator can use the following CLI command to see the failures with filter configuration: user@device> show log kfirewall-agent.log | match ERROR Jul 23 14:16:03 ERROR: filter not supported This issue affects Juniper Networks Junos OS Evolved: Versions 19.1R1-EVO and above prior to 20.3R1-S2-EVO, 20.3R2-EVO. This issue does not affect Juniper Networks Junos OS.
{
"affected": [],
"aliases": [
"CVE-2021-0225"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "An Improper Check for Unusual or Exceptional Conditions in Juniper Networks Junos OS Evolved may cause the stateless firewall filter configuration which uses the action \u0027policer\u0027 in certain combinations with other options to not take effect. An administrator can use the following CLI command to see the failures with filter configuration: user@device\u003e show log kfirewall-agent.log | match ERROR Jul 23 14:16:03 ERROR: filter not supported This issue affects Juniper Networks Junos OS Evolved: Versions 19.1R1-EVO and above prior to 20.3R1-S2-EVO, 20.3R2-EVO. This issue does not affect Juniper Networks Junos OS.",
"id": "GHSA-v55m-mm25-x584",
"modified": "2022-05-24T17:48:10Z",
"published": "2022-05-24T17:48:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0225"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11120"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V62P-F565-PFXR
Vulnerability from github – Published: 2026-06-11 00:32 – Updated: 2026-07-14 15:31A memory corruption vulnerability in the processing of tunnel traffic in Palo Alto Networks PAN-OS® software allows an authenticated user to initiate system reboots using a maliciously crafted packet. Repeated attempts to initiate a reboot causes the firewall to enter maintenance mode.
Panorama, Cloud NGFW, and Prisma® Access are not impacted by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2026-0269"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-10T22:16:53Z",
"severity": "MODERATE"
},
"details": "A memory corruption vulnerability in the processing of tunnel traffic in Palo Alto Networks PAN-OS\u00ae software allows an authenticated user to initiate system reboots using a maliciously crafted packet. Repeated attempts to initiate a reboot causes the firewall to enter maintenance mode.\n\n\n\nPanorama, Cloud NGFW, and Prisma\u00ae Access are not impacted by this vulnerability.",
"id": "GHSA-v62p-f565-pfxr",
"modified": "2026-07-14T15:31:59Z",
"published": "2026-06-11T00:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0269"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-967325.html"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2026-0269"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/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:N/R:A/V:D/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-V6P4-R397-Q442
Vulnerability from github – Published: 2024-09-25 09:30 – Updated: 2024-09-25 15:31An unauthenticated remote attacker can causes the CODESYS web server to access invalid memory which results in a DoS.
{
"affected": [],
"aliases": [
"CVE-2024-8175"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-25T08:15:04Z",
"severity": "HIGH"
},
"details": "An unauthenticated remote attacker can\u00a0causes the CODESYS web server to access invalid memory which results in a DoS.",
"id": "GHSA-v6p4-r397-q442",
"modified": "2024-09-25T15:31:12Z",
"published": "2024-09-25T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8175"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2024-057"
},
{
"type": "WEB",
"url": "https://customers.codesys.com/index.php?eID=dumpFile\u0026t=f\u0026f=18604\u0026token=d5e1e2820ee63077b875b3bb41014b1f102e88a3\u0026download="
}
],
"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-V787-C3F2-P88R
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
posix-clock: Fix missing timespec64 check in pc_clock_settime()
As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64().
As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid.
There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.
{
"affected": [],
"aliases": [
"CVE-2024-50195"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-08T06:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: Fix missing timespec64 check in pc_clock_settime()\n\nAs Andrew pointed out, it will make sense that the PTP core\nchecked timespec64 struct\u0027s tv_sec and tv_nsec range before calling\nptp-\u003einfo-\u003esettime64().\n\nAs the man manual of clock_settime() said, if tp.tv_sec is negative or\ntp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,\nwhich include dynamic clocks which handles PTP clock, and the condition is\nconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()\nonly check the timespec is valid, but not ensure that the time is\nin a valid range, so check it ahead using timespec64_valid_strict()\nin pc_clock_settime() and return -EINVAL if not valid.\n\nThere are some drivers that use tp-\u003etv_sec and tp-\u003etv_nsec directly to\nwrite registers without validity checks and assume that the higher layer\nhas checked it, which is dangerous and will benefit from this, such as\nhclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),\nand some drivers can remove the checks of itself.",
"id": "GHSA-v787-c3f2-p88r",
"modified": "2025-11-04T00:31:57Z",
"published": "2024-11-08T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-V8G7-64M9-F7WF
Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2025-05-05 18:31Improper conditions check in the Intel(R) IPP Crypto library before version 2021.2 may allow an authenticated user to potentially enable information disclosure via local access.
{
"affected": [],
"aliases": [
"CVE-2021-33147"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "Improper conditions check in the Intel(R) IPP Crypto library before version 2021.2 may allow an authenticated user to potentially enable information disclosure via local access.",
"id": "GHSA-v8g7-64m9-f7wf",
"modified": "2025-05-05T18:31:34Z",
"published": "2022-02-11T00:00:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33147"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00600.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.