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.
909 vulnerabilities reference this CWE, most recent first.
GHSA-CF97-GPJM-X8FJ
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix the missing xa_store error check
xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.
{
"affected": [],
"aliases": [
"CVE-2024-50284"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix the missing xa_store error check\n\nxa_store() can fail, it return xa_err(-EINVAL) if the entry cannot\nbe stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed,\nso check error for xa_store() to fix it.",
"id": "GHSA-cf97-gpjm-x8fj",
"modified": "2025-11-04T00:32:03Z",
"published": "2024-11-19T03:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50284"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3abab905b14f4ba756d413f37f1fb02b708eee93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/726c1568b9145fa13ee248df184b186c382a7ff8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2a232c4f790f4bcd4d218904c56ac7a39a448f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8664ce789bd46290c59a00da6897252f92c237d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CHRH-M3H6-4898
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it knows are poisoned. Avoid even trying to reclaim poisoned pages.
The longer story:
Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.
epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic.
Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time.
Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming.
Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths.
The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply.
This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even inside a microcode operation (actually easy to trigger due to the amount of time spent in them.)
The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.
{
"affected": [],
"aliases": [
"CVE-2025-38334"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T09:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Prevent attempts to reclaim poisoned pages\n\nTL;DR: SGX page reclaim touches the page to copy its contents to\nsecondary storage. SGX instructions do not gracefully handle machine\nchecks. Despite this, the existing SGX code will try to reclaim pages\nthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.\n\nThe longer story:\n\nPages used by an enclave only get epc_page-\u003epoison set in\narch_memory_failure() but they currently stay on sgx_active_page_list until\nsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.\n\nepc_page-\u003epoison is not checked in the reclaimer logic meaning that, if other\nconditions are met, an attempt will be made to reclaim an EPC page that was\npoisoned. This is bad because 1. we don\u0027t want that page to end up added\nto another enclave and 2. it is likely to cause one core to shut down\nand the kernel to panic.\n\nSpecifically, reclaiming uses microcode operations including \"EWB\" which\naccesses the EPC page contents to encrypt and write them out to non-SGX\nmemory. Those operations cannot handle MCEs in their accesses other than\nby putting the executing core into a special shutdown state (affecting\nboth threads with HT.) The kernel will subsequently panic on the\nremaining cores seeing the core didn\u0027t enter MCE handler(s) in time.\n\nCall sgx_unmark_page_reclaimable() to remove the affected EPC page from\nsgx_active_page_list on memory error to stop it being considered for\nreclaiming.\n\nTesting epc_page-\u003epoison in sgx_reclaim_pages() would also work but I assume\nit\u0027s better to add code in the less likely paths.\n\nThe affected EPC page is not added to \u0026node-\u003esgx_poison_page_list until\nlater in sgx_encl_release()-\u003esgx_free_epc_page() when it is EREMOVEd.\nMembership on other lists doesn\u0027t change to avoid changing any of the\nlists\u0027 semantics except for sgx_active_page_list. There\u0027s a \"TBD\" comment\nin arch_memory_failure() about pre-emptive actions, the goal here is not\nto address everything that it may imply.\n\nThis also doesn\u0027t completely close the time window when a memory error\nnotification will be fatal (for a not previously poisoned EPC page) --\nthe MCE can happen after sgx_reclaim_pages() has selected its candidates\nor even *inside* a microcode operation (actually easy to trigger due to\nthe amount of time spent in them.)\n\nThe spinlock in sgx_unmark_page_reclaimable() is safe because\nmemory_failure() runs in process context and no spinlocks are held,\nexplicitly noted in a mm/memory-failure.c comment.",
"id": "GHSA-chrh-m3h6-4898",
"modified": "2025-12-16T18:31:29Z",
"published": "2025-07-10T09:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00a88e9ea1b170d579c56327c38f7e8cf689df87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31dcbac94bfeabb86bf85b0c36803fdd6536437b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62b62a2a6dc51ed6e8e334861f04220c9cf8106a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc5de5bd6deabd327ced2b2b1d0b4f14cd146afe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed16618c380c32c68c06186d0ccbb0d5e0586e59"
},
{
"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:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CJ48-543V-8FR9
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-17 00:01On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when an Active mode-enabled FTP profile is configured on a virtual server, undisclosed traffic can cause the virtual server to stop processing active FTP data channel connections. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
{
"affected": [],
"aliases": [
"CVE-2022-26130"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "MODERATE"
},
"details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when an Active mode-enabled FTP profile is configured on a virtual server, undisclosed traffic can cause the virtual server to stop processing active FTP data channel connections. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
"id": "GHSA-cj48-543v-8fr9",
"modified": "2022-05-17T00:01:48Z",
"published": "2022-05-06T00:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26130"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K82034427"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-CJW7-M4QF-XC59
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-04-29 21:31In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Prevent state corruption in __fpu__restore_sig()
The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer.
Prior to XSAVES support, it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible but not corrupting the state in the first place is more robust.
Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms.
Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path.
[ Changelog polished by Dave Hansen ]
{
"affected": [],
"aliases": [
"CVE-2021-47227"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Prevent state corruption in __fpu__restore_sig()\n\nThe non-compacted slowpath uses __copy_from_user() and copies the entire\nuser buffer into the kernel buffer, verbatim. This means that the kernel\nbuffer may now contain entirely invalid state on which XRSTOR will #GP.\nvalidate_user_xstate_header() can detect some of that corruption, but that\nleaves the onus on callers to clear the buffer.\n\nPrior to XSAVES support, it was possible just to reinitialize the buffer,\ncompletely, but with supervisor states that is not longer possible as the\nbuffer clearing code split got it backwards. Fixing that is possible but\nnot corrupting the state in the first place is more robust.\n\nAvoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()\nwhich validates the XSAVE header contents before copying the actual states\nto the kernel. copy_user_to_xstate() was previously only called for\ncompacted-format kernel buffers, but it works for both compacted and\nnon-compacted forms.\n\nUsing it for the non-compacted form is slower because of multiple\n__copy_from_user() operations, but that cost is less important than robust\ncode in an already slow path.\n\n[ Changelog polished by Dave Hansen ]",
"id": "GHSA-cjw7-m4qf-xc59",
"modified": "2025-04-29T21:31:33Z",
"published": "2024-05-21T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47227"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/076f732b16a5bf842686e1b43ab6021a2d98233e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/484cea4f362e1eeb5c869abbfb5f90eae6421b38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec25ea1f3f05d6f8ee51d1277efea986eafd4f2a"
}
],
"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-CMH9-RX85-XJ38
Vulnerability from github – Published: 2024-02-13 18:34 – Updated: 2024-02-20 16:40Summary
Cross site scripting (XSS) potentially exposing cookies / sessions / localStorage, fixed by sidekiq-unique-jobs v8.0.7.
Specifically, this is a Reflected (Server-Side), Non-Self, Cross Site Scripting vulnerability, considered a P3 on the BugCrowd taxonomy with the following categorization: Cross-Site Scripting (XSS) > Reflected > Non-Self
It was initially thought there was a second vulnerability (RCE), but it was a false alarm. Injection is impossible with Redis:
String escaping and NoSQL injection The Redis protocol has no concept of string escaping, so injection is impossible under normal circumstances using a normal client library. The protocol uses prefixed-length strings and is completely binary safe.
Ref: https://redis.io/docs/management/security/
XSS Vulnerability
Specially crafted GET request parameters handled by any of the following endpoints of sidekiq-unique-jobs' "admin" web UI, allow a super-user attacker, or an unwitting, but authorized, victim, who has received a disguised / crafted link, to successfully execute malicious code, which could potentially steal cookies, session data, or local storage data from the app the sidekiq-unique-jobs web UI is mounted in.
/changelogs/locks/expiring_locks
This means if your sidekiq-unique-jobs web UI is mounted at /sidekiq, the vulnerable paths are:
/sidekiq/changelogs/sidekiq/locks/sidekiq/expiring_locks
XSS vulnerability is an instance of CAPEC-32: XSS Through HTTP Query Strings, which is related to CWE-80. In certain cases where it results in a server error with status 500, it could be considered a vector for uncontrolled resource consumption, given that errors can be much more resource intensive that normal requests, and thus CWE-400 & CWE-754 may also be relevant.
Details
Fix for the XSS vulnerability was released in sidekiq-unique-jobs v8.0.7.
This is an analogous attack vector to that which affected sidekiq gem from version v7.0.4 to v7.0.7, and was given identifiers GHSA-h3r8-h5qw-4r35 & CVE-2023-1892.
The vulnerability in sidekiq-unique-jobs' was not fixed by sidekiq v7.0.8, nor the more recent sidekiq v7.2.0 releases; they are similar but unrelated, distinct vulnerabilities in adjacent projects.
Note #1: The admin web UI for sidekiq-unique-jobs is not protected by any authorization constraint in the default configuration. Auth constraints must be configured by the programmer. It is recommended and expected that users will configure authorization constrains on the "admin" UI. This is not specifically related to the vulnerability but may make users who fail to constrain their "admin" UI even more vulnerable.
Note #2: Most users of the library will not have configured the UI on a sandboxed subdomain, making all their cookies, localStorage data and session secrets vulnerable to exposure. The purpose of a sandboxed subdomain is expressly to prevent leaking sensitive data through XSS attacks.
XSS Fix PR: https://github.com/mhenrixon/sidekiq-unique-jobs/pull/829
PoC
XSS
Use a string like:
%22%3E%3Cimg/src/onerror=alert(document.domain)%3E
as the value for one of the parameters that are handled without escaping. Reference: https://liveoverflow.com/do-not-use-alert-1-in-xss/
- Visit /sidekiq/changelogs - with a crafted query string like one of the following:
a. Screenshot:
b.
filteris XSS vulnerable:?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3Ec.countis vulnerable to triggering an application error (status 500), potentially allowing resource exhaustion?count=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E- Screenshot:
- Screenshot:
- Visit /sidekiq/locks - with a crafted query string like one of the following:
a. Screenshot:
b.
filteris XSS vulnerable:?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3Ec.countis vulnerable to triggering an application error (status 500), potentially allowing resource exhaustion?count=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E- Screenshot:
- Screenshot:
- Visit /sidekiq/expiring_locks - with a crafted query string like one of the following:
a. Screenshot:
b.
filteris XSS vulnerable:?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E
Impact
This is a vulnerability of critical severity, which impacts many thousands of sites, since sidekiq-unique-jobs is widely deployed across the industry, with multiple attack vectors.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "sidekiq-unique-jobs"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "sidekiq-unique-jobs"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0.rc7"
},
{
"fixed": "7.1.33"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25122"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-754",
"CWE-79",
"CWE-80"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-13T18:34:16Z",
"nvd_published_at": "2024-02-13T19:15:11Z",
"severity": "HIGH"
},
"details": "### Summary\n\nCross site scripting (XSS) potentially exposing cookies / sessions / localStorage, fixed by `sidekiq-unique-jobs` v8.0.7.\n\nSpecifically, this is a Reflected (Server-Side), Non-Self, Cross Site Scripting vulnerability, considered a **_P3_** on the BugCrowd [taxonomy](https://bugcrowd.com/vulnerability-rating-taxonomy) with the following categorization:\nCross-Site Scripting (XSS) \u003e Reflected \u003e Non-Self\n\nIt was initially thought there was a second vulnerability (RCE), but it was a false alarm. Injection is impossible with Redis:\n\n\u003e String escaping and NoSQL injection\n\u003e The Redis protocol has no concept of string escaping, so injection is impossible under normal circumstances using a normal client library. The protocol uses prefixed-length strings and is completely binary safe.\n\nRef: https://redis.io/docs/management/security/\n\n**XSS Vulnerability**\n\nSpecially crafted `GET` request parameters handled by any of the following endpoints of `sidekiq-unique-jobs`\u0027 \"admin\" web UI, allow a super-user attacker, or an unwitting, but authorized, victim, who has received a disguised / crafted link, to successfully execute malicious code, which could potentially steal cookies, session data, or local storage data from the app the `sidekiq-unique-jobs` web UI is mounted in.\n\n1. `/changelogs`\n2. `/locks`\n3. `/expiring_locks`\n\nThis means if your `sidekiq-unique-jobs` web UI is mounted at `/sidekiq`, the vulnerable paths are:\n\n1. `/sidekiq/changelogs`\n2. `/sidekiq/locks`\n3. `/sidekiq/expiring_locks`\n\nXSS vulnerability is an instance of [CAPEC-32: XSS Through HTTP Query Strings](https://capec.mitre.org/data/definitions/32.html), which is related to [CWE-80](https://cwe.mitre.org/data/definitions/80.html). In certain cases where it results in a server error with status 500, it could be considered a vector for uncontrolled resource consumption, given that errors can be much more resource intensive that normal requests, and thus [CWE-400](https://cwe.mitre.org/data/definitions/400.html) \u0026 [CWE-754](https://cwe.mitre.org/data/definitions/754.html) may also be relevant.\n\n### Details\n\nFix for the XSS vulnerability was released in `sidekiq-unique-jobs` [v8.0.7](https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v8.0.7).\n\nThis is an analogous attack vector to that which affected `sidekiq` gem from version v7.0.4 to v7.0.7, and was given identifiers [GHSA-h3r8-h5qw-4r35](https://github.com/advisories/GHSA-h3r8-h5qw-4r35) \u0026 [CVE-2023-1892](https://github.com/advisories/GHSA-h3r8-h5qw-4r35).\n\nThe vulnerability in `sidekiq-unique-jobs`\u0027 was *not* fixed by `sidekiq` [v7.0.8](https://github.com/sidekiq/sidekiq/blob/main/Changes.md#708), nor the more recent `sidekiq` [v7.2.0](https://github.com/sidekiq/sidekiq/blob/main/Changes.md#720) releases; they are similar but unrelated, distinct vulnerabilities in adjacent projects.\n\nNote #1: The admin web UI for `sidekiq-unique-jobs` is not protected by any authorization constraint in the default configuration. Auth constraints must be configured by the programmer. It is recommended and expected that users will configure authorization constrains on the \"admin\" UI. This is not specifically related to the vulnerability but may make users who fail to constrain their \"admin\" UI even more vulnerable.\n\nNote #2: Most users of the library will not have configured the UI on a sandboxed subdomain, making all their cookies, localStorage data and session secrets [vulnerable to exposure](https://liveoverflow.com/do-not-use-alert-1-in-xss/). The purpose of a sandboxed subdomain is expressly to prevent leaking sensitive data through XSS attacks.\n\nXSS Fix PR: https://github.com/mhenrixon/sidekiq-unique-jobs/pull/829\n\n### PoC\n\n**XSS**\n\nUse a string like:\n```\n%22%3E%3Cimg/src/onerror=alert(document.domain)%3E\n```\nas the value for one of the parameters that are handled without escaping.\nReference: https://liveoverflow.com/do-not-use-alert-1-in-xss/\n\n1. Visit [/sidekiq/changelogs](http://localhost:3000/sidekiq/changelogs) - with a crafted query string like one of the following:\n a. Screenshot: \n b. `filter` is XSS vulnerable: `?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E`\n c. `count` is vulnerable to triggering an application error (status 500), potentially allowing resource exhaustion `?count=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E`\n 1. Screenshot: \n2. Visit [/sidekiq/locks](http://localhost:3000/sidekiq/locks) - with a crafted query string like one of the following:\n a. Screenshot: \n b. `filter` is XSS vulnerable: `?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E`\n c. `count` is vulnerable to triggering an application error (status 500), potentially allowing resource exhaustion `?count=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E`\n 1. Screenshot: \n3. Visit [/sidekiq/expiring_locks](http://localhost:3000/sidekiq/expiring_locks) - with a crafted query string like one of the following: \n a. Screenshot: \n b. `filter` is XSS vulnerable: `?filter=%22%3E%3Cimg/src/onerror=alert(document.domain)%3E`\n\n### Impact\n\nThis is a vulnerability of critical severity, which impacts many thousands of sites, since `sidekiq-unique-jobs` is widely deployed across the industry, with multiple attack vectors.",
"id": "GHSA-cmh9-rx85-xj38",
"modified": "2024-02-20T16:40:10Z",
"published": "2024-02-13T18:34:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mhenrixon/sidekiq-unique-jobs/security/advisories/GHSA-cmh9-rx85-xj38"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25122"
},
{
"type": "WEB",
"url": "https://github.com/mhenrixon/sidekiq-unique-jobs/commit/cd09ba6108f98973b6649a6149790c3d4502b4cc"
},
{
"type": "WEB",
"url": "https://github.com/mhenrixon/sidekiq-unique-jobs/commit/ec3afd920c1b55843c72f748a87baac7f8be82ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/mhenrixon/sidekiq-unique-jobs"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/sidekiq-unique-jobs/CVE-2024-25122.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "XSS sidekiq-unique-jobs UI server vulnerability"
}
GHSA-CP9M-FGRV-J66X
Vulnerability from github – Published: 2025-05-07 18:30 – Updated: 2025-07-11 15:31A vulnerability in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker with privilege level 15 to elevate privileges to root on the underlying operating system of an affected device.
This vulnerability is due to insufficient input validation when processing specific configuration commands. An attacker could exploit this vulnerability by including crafted input in specific configuration commands. A successful exploit could allow the attacker to elevate privileges to root on the underlying operating system of an affected device. The security impact rating (SIR) of this advisory has been raised to High because an attacker could gain access to the underlying operating system of the affected device and perform potentially undetected actions.
Note: The attacker must have privileges to enter configuration mode on the affected device. This is usually referred to as privilege level 15.
{
"affected": [],
"aliases": [
"CVE-2025-20200"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-07T18:15:40Z",
"severity": "MODERATE"
},
"details": "A vulnerability\u00a0in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker with privilege level 15 to elevate privileges to root on the underlying operating system of an affected device.\n\n This vulnerability is due to insufficient input validation when processing specific configuration commands. An attacker could exploit this vulnerability by including crafted input in specific configuration commands. A successful exploit could allow the attacker to elevate privileges to root on the underlying operating system of an affected device. The security impact rating (SIR) of this advisory has been raised to High because an attacker could gain access to the underlying operating system of the affected device and perform potentially undetected actions.\n\n Note: The attacker must have privileges to enter configuration mode on the affected device. This is usually referred to as privilege level 15.",
"id": "GHSA-cp9m-fgrv-j66x",
"modified": "2025-07-11T15:31:31Z",
"published": "2025-05-07T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20200"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-privesc-su7scvdp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CPFH-Q3V8-WJ73
Vulnerability from github – Published: 2026-02-11 18:31 – Updated: 2026-02-11 18:31A denial-of-service (DoS) vulnerability in the Advanced DNS Security (ADNS) feature of Palo Alto Networks PAN-OS® software enables an unauthenticated attacker to initiate system reboots using a maliciously crafted packet. Repeated attempts to initiate a reboot causes the firewall to enter maintenance mode.
Cloud NGFW and Prisma Access® are not impacted by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2026-0229"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T18:16:07Z",
"severity": "MODERATE"
},
"details": "A denial-of-service (DoS) vulnerability in the Advanced DNS Security (ADNS) feature of Palo Alto Networks PAN-OS\u00ae software enables an unauthenticated attacker to initiate system reboots using a maliciously crafted packet. Repeated attempts to initiate a reboot causes the firewall to enter maintenance mode.\n\nCloud NGFW and Prisma Access\u00ae are not impacted by this vulnerability.",
"id": "GHSA-cpfh-q3v8-wj73",
"modified": "2026-02-11T18:31:31Z",
"published": "2026-02-11T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0229"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2026-0229"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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:Y/R:U/V:D/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-CQ54-MJWX-5PJW
Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2022-05-24 22:01Sylabs Singularity 3.5.x and 3.6.x, and SingularityPRO before 3.5-8, has an Incorrect Check of a Function's Return Value.
{
"affected": [],
"aliases": [
"CVE-2021-33622"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-15T20:15:00Z",
"severity": "CRITICAL"
},
"details": "Sylabs Singularity 3.5.x and 3.6.x, and SingularityPRO before 3.5-8, has an Incorrect Check of a Function\u0027s Return Value.",
"id": "GHSA-cq54-mjwx-5pjw",
"modified": "2022-05-24T22:01:39Z",
"published": "2022-05-24T22:01:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33622"
},
{
"type": "WEB",
"url": "https://medium.com/sylabs"
},
{
"type": "WEB",
"url": "https://support.sylabs.io/support/solutions/articles/42000087130-3-5-8-security-release-cve-2021-33622-"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CQMJ-92XF-R6R9
Vulnerability from github – Published: 2023-05-23 19:55 – Updated: 2024-11-18 16:26Impact
A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.
TypeError: Cannot convert object to primitive value
at Socket.emit (node:events:507:25)
at .../node_modules/socket.io/lib/socket.js:531:14
Patches
A fix has been released today (2023/05/22):
- https://github.com/socketio/socket.io-parser/commit/3b78117bf6ba7e99d7a5cfc1ba54d0477554a7f3, included in
socket.io-parser@4.2.3 - https://github.com/socketio/socket.io-parser/commit/2dc3c92622dad113b8676be06f23b1ed46b02ced, included in
socket.io-parser@3.4.3
Another fix has been released for the 3.3.x branch:
- https://github.com/socketio/socket.io-parser/commit/ee006607495eca4ec7262ad080dd3a91439a5ba4, included in `socket.io-parser@3.3.4
socket.io version |
socket.io-parser version |
Needs minor update? |
|---|---|---|
4.5.2...latest |
~4.2.0 (ref) |
npm audit fix should be sufficient |
4.1.3...4.5.1 |
~4.1.1 (ref) |
Please upgrade to socket.io@4.6.x |
3.0.5...4.1.2 |
~4.0.3 (ref) |
Please upgrade to socket.io@4.6.x |
3.0.0...3.0.4 |
~4.0.1 (ref) |
Please upgrade to socket.io@4.6.x |
2.3.0...2.5.0 |
~3.4.0 (ref) |
npm audit fix should be sufficient |
Workarounds
There is no known workaround except upgrading to a safe version.
For more information
If you have any questions or comments about this advisory:
- Open a discussion here
Thanks to @rafax00 for the responsible disclosure.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.4"
},
{
"fixed": "4.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-32695"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-23T19:55:13Z",
"nvd_published_at": "2023-05-27T16:15:09Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.\n\n```\nTypeError: Cannot convert object to primitive value\n at Socket.emit (node:events:507:25)\n at .../node_modules/socket.io/lib/socket.js:531:14\n```\n\n### Patches\n\nA fix has been released today (2023/05/22):\n\n- https://github.com/socketio/socket.io-parser/commit/3b78117bf6ba7e99d7a5cfc1ba54d0477554a7f3, included in `socket.io-parser@4.2.3`\n- https://github.com/socketio/socket.io-parser/commit/2dc3c92622dad113b8676be06f23b1ed46b02ced, included in `socket.io-parser@3.4.3`\n\n\nAnother fix has been released for the `3.3.x` branch:\n\n- https://github.com/socketio/socket.io-parser/commit/ee006607495eca4ec7262ad080dd3a91439a5ba4, included in `socket.io-parser@3.3.4\n\n| `socket.io` version | `socket.io-parser` version | Needs minor update? |\n|---------------------|---------------------------------------------------------------------------------------------------------|--------------------------------------|\n| `4.5.2...latest` | `~4.2.0` ([ref](https://github.com/socketio/socket.io/commit/9890b036cf942f6b6ad2afeb6a8361c32cd5d528)) | `npm audit fix` should be sufficient |\n| `4.1.3...4.5.1` | `~4.1.1` ([ref](https://github.com/socketio/socket.io/commit/7c44893d7878cd5bba1eff43150c3e664f88fb57)) | Please upgrade to `socket.io@4.6.x` |\n| `3.0.5...4.1.2` | `~4.0.3` ([ref](https://github.com/socketio/socket.io/commit/752dfe3b1e5fecda53dae899b4a39e6fed5a1a17)) | Please upgrade to `socket.io@4.6.x` |\n| `3.0.0...3.0.4` | `~4.0.1` ([ref](https://github.com/socketio/socket.io/commit/1af3267e3f5f7884214cf2ca4d5282d620092fb0)) | Please upgrade to `socket.io@4.6.x` |\n| `2.3.0...2.5.0` | `~3.4.0` ([ref](https://github.com/socketio/socket.io/commit/cf39362014f5ff13a17168b74772c43920d6e4fd)) | `npm audit fix` should be sufficient |\n\n\n### Workarounds\n\nThere is no known workaround except upgrading to a safe version.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Open a discussion [here](https://github.com/socketio/socket.io/discussions)\n\nThanks to [@rafax00](https://github.com/rafax00) for the responsible disclosure.\n",
"id": "GHSA-cqmj-92xf-r6r9",
"modified": "2024-11-18T16:26:29Z",
"published": "2023-05-23T19:55:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/security/advisories/GHSA-cqmj-92xf-r6r9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32695"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/commit/1c220ddbf45ea4b44bc8dbf6f9ae245f672ba1b9"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/commit/2dc3c92622dad113b8676be06f23b1ed46b02ced"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/commit/3b78117bf6ba7e99d7a5cfc1ba54d0477554a7f3"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/commit/ee006607495eca4ec7262ad080dd3a91439a5ba4"
},
{
"type": "PACKAGE",
"url": "https://github.com/socketio/socket.io-parser"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io-parser/releases/tag/4.2.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Insufficient validation when decoding a Socket.IO packet"
}
GHSA-CR5G-9FRG-Q8M8
Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-03-24 21:31Incorrect boundary conditions in the Audio/Video component. This vulnerability affects Firefox < 149 and Firefox ESR < 140.9.
{
"affected": [],
"aliases": [
"CVE-2026-4714"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T13:16:07Z",
"severity": "HIGH"
},
"details": "Incorrect boundary conditions in the Audio/Video component. This vulnerability affects Firefox \u003c 149 and Firefox ESR \u003c 140.9.",
"id": "GHSA-cr5g-9frg-q8m8",
"modified": "2026-03-24T21:31:22Z",
"published": "2026-03-24T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4714"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2018126"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
},
{
"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"
}
],
"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"
}
]
}
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.