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-C7XM-R6VJ-8VG6
Vulnerability from github – Published: 2026-04-29 21:53 – Updated: 2026-05-08 20:13Summary
Role::stopMembership() does not verify whether removing a user from the administrator role leaves zero administrators. The deprecated Membership::stopMembership() contains this safety check, but the current code path bypasses it. Any administrator can remove the last remaining other administrator, locking the entire system out of administrative access. The exploit does not require concurrent requests; sequential removals produce the same result.
Details
Role::stopMembership() in src/Roles/Entity/Role.php stops a user's membership in a role without verifying whether the action leaves the administrator role with zero members:
// src/Roles/Entity/Role.php - Role::stopMembership()
public function stopMembership(int $userId): bool
{
// No check for minimum administrator count
// Directly updates membership end date
}
The deprecated Membership::stopMembership() contains this safety check and raises SYS_MUST_HAVE_ADMINISTRATOR when the removal would leave no admins, but current code paths no longer call this method.
Role::setMembership() includes a guard that prevents a user from removing their own administrator membership:
if ($userId === $gCurrentUserId) {
// Prevents self-removal from admin role
}
This guard does not prevent an administrator from removing the last other administrator. Consider a system with exactly two administrators (Admin A and Admin B):
- Admin A removes Admin B from the administrator role. The self-removal check passes (Admin A is not removing themselves). No minimum-count check runs. Admin B loses admin access.
- Admin A is now the sole administrator. Admin A cannot remove themselves (self-removal guard), but the system is one compromised account away from total lockout.
- If Admin A and Admin B each send a removal request for the other (sequentially or concurrently), both succeed. The system has zero administrators.
The core bug is the missing minimum-administrator check in Role::stopMembership(), not timing. Sequential requests reproduce the issue just as concurrent ones do.
Proof of Concept
Requirements: two active administrator accounts (Admin A and Admin B) with valid sessions.
import requests
BASE = "https://admidio.example.com"
session_a = requests.Session()
session_b = requests.Session()
# Authenticate both sessions (login step omitted for brevity)
# Step 1: Admin A removes Admin B (sequential, no race needed)
resp1 = session_a.post(f"{BASE}/modules/profile/profile_function.php", data={
"mode": "stop_membership",
"user_uuid": ADMIN_B_UUID,
"role_uuid": ADMIN_ROLE_UUID
})
print(f"Admin A removes Admin B: {resp1.status_code}") # 200
# Step 2: Admin B removes Admin A (Admin B's session is still valid)
resp2 = session_b.post(f"{BASE}/modules/profile/profile_function.php", data={
"mode": "stop_membership",
"user_uuid": ADMIN_A_UUID,
"role_uuid": ADMIN_ROLE_UUID
})
print(f"Admin B removes Admin A: {resp2.status_code}") # 200
# The system now has 0 administrators.
After both requests complete, no users remain in the administrator role. The administrative interface becomes inaccessible. Recovery requires direct database manipulation to reassign the administrator role.
Impact
Two colluding or compromised administrator accounts lock out all administrative access to the Admidio installation. Recovery demands direct database access, which may not be available on shared hosting environments. The attack does not require precise timing because Role::stopMembership() performs no minimum-admin-count check at all.
Recommended Fix
Add a minimum-administrator-count check to Role::stopMembership(). Before stopping a membership in the administrator role, query the current count of active members. If stopping this membership would leave zero administrators, reject the request with SYS_MUST_HAVE_ADMINISTRATOR. This mirrors the check already present in the deprecated Membership::stopMembership() method.
Found by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41662"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T21:53:20Z",
"nvd_published_at": "2026-05-07T04:16:30Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`Role::stopMembership()` does not verify whether removing a user from the administrator role leaves zero administrators. The deprecated `Membership::stopMembership()` contains this safety check, but the current code path bypasses it. Any administrator can remove the last remaining other administrator, locking the entire system out of administrative access. The exploit does not require concurrent requests; sequential removals produce the same result.\n\n## Details\n\n`Role::stopMembership()` in `src/Roles/Entity/Role.php` stops a user\u0027s membership in a role without verifying whether the action leaves the administrator role with zero members:\n\n```php\n// src/Roles/Entity/Role.php - Role::stopMembership()\npublic function stopMembership(int $userId): bool\n{\n // No check for minimum administrator count\n // Directly updates membership end date\n}\n```\n\nThe deprecated `Membership::stopMembership()` contains this safety check and raises `SYS_MUST_HAVE_ADMINISTRATOR` when the removal would leave no admins, but current code paths no longer call this method.\n\n`Role::setMembership()` includes a guard that prevents a user from removing their own administrator membership:\n\n```php\nif ($userId === $gCurrentUserId) {\n // Prevents self-removal from admin role\n}\n```\n\nThis guard does not prevent an administrator from removing the last other administrator. Consider a system with exactly two administrators (Admin A and Admin B):\n\n1. Admin A removes Admin B from the administrator role. The self-removal check passes (Admin A is not removing themselves). No minimum-count check runs. Admin B loses admin access.\n2. Admin A is now the sole administrator. Admin A cannot remove themselves (self-removal guard), but the system is one compromised account away from total lockout.\n3. If Admin A and Admin B each send a removal request for the other (sequentially or concurrently), both succeed. The system has zero administrators.\n\nThe core bug is the missing minimum-administrator check in `Role::stopMembership()`, not timing. Sequential requests reproduce the issue just as concurrent ones do.\n\n## Proof of Concept\n\nRequirements: two active administrator accounts (Admin A and Admin B) with valid sessions.\n\n```python\nimport requests\n\nBASE = \"https://admidio.example.com\"\n\nsession_a = requests.Session()\nsession_b = requests.Session()\n\n# Authenticate both sessions (login step omitted for brevity)\n\n# Step 1: Admin A removes Admin B (sequential, no race needed)\nresp1 = session_a.post(f\"{BASE}/modules/profile/profile_function.php\", data={\n \"mode\": \"stop_membership\",\n \"user_uuid\": ADMIN_B_UUID,\n \"role_uuid\": ADMIN_ROLE_UUID\n})\nprint(f\"Admin A removes Admin B: {resp1.status_code}\") # 200\n\n# Step 2: Admin B removes Admin A (Admin B\u0027s session is still valid)\nresp2 = session_b.post(f\"{BASE}/modules/profile/profile_function.php\", data={\n \"mode\": \"stop_membership\",\n \"user_uuid\": ADMIN_A_UUID,\n \"role_uuid\": ADMIN_ROLE_UUID\n})\nprint(f\"Admin B removes Admin A: {resp2.status_code}\") # 200\n\n# The system now has 0 administrators.\n```\n\nAfter both requests complete, no users remain in the administrator role. The administrative interface becomes inaccessible. Recovery requires direct database manipulation to reassign the administrator role.\n\n## Impact\n\nTwo colluding or compromised administrator accounts lock out all administrative access to the Admidio installation. Recovery demands direct database access, which may not be available on shared hosting environments. The attack does not require precise timing because `Role::stopMembership()` performs no minimum-admin-count check at all.\n\n## Recommended Fix\n\nAdd a minimum-administrator-count check to `Role::stopMembership()`. Before stopping a membership in the administrator role, query the current count of active members. If stopping this membership would leave zero administrators, reject the request with `SYS_MUST_HAVE_ADMINISTRATOR`. This mirrors the check already present in the deprecated `Membership::stopMembership()` method.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-c7xm-r6vj-8vg6",
"modified": "2026-05-08T20:13:55Z",
"published": "2026-04-29T21:53:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-c7xm-r6vj-8vg6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41662"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Admidio Missing Minimum Administrator Check in Role Membership Removal"
}
GHSA-C89J-8VXW-RQ2X
Vulnerability from github – Published: 2025-10-11 12:30 – Updated: 2025-10-16 15:30Vulnerability of improper exception handling in the print module. Successful exploitation of this vulnerability may affect availability.
{
"affected": [],
"aliases": [
"CVE-2025-58289"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-11T10:15:43Z",
"severity": "MODERATE"
},
"details": "Vulnerability of improper exception handling in the print module.\u00a0Successful exploitation of this vulnerability may affect availability.",
"id": "GHSA-c89j-8vxw-rq2x",
"modified": "2025-10-16T15:30:28Z",
"published": "2025-10-11T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58289"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C8C4-RJGC-XF4X
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2025-09-22 21:30A denial-of-service vulnerability exists in the Rockwell Automation PowerFlex® 600T. If the device is overloaded with requests, it will become unavailable. The device may require a power cycle to recover it if it does not re-establish a connection after it stops receiving requests.
{
"affected": [],
"aliases": [
"CVE-2024-9124"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T17:15:56Z",
"severity": "HIGH"
},
"details": "A denial-of-service vulnerability exists in the Rockwell Automation PowerFlex\u00ae 600T. If the device is overloaded with requests, it will become unavailable. The device may require a power cycle to recover it if it does not re-establish a connection after it stops receiving requests.",
"id": "GHSA-c8c4-rjgc-xf4x",
"modified": "2025-09-22T21:30:15Z",
"published": "2024-10-08T18:33:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9124"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1705.html"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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-C8W6-X74F-VMG3
Vulnerability from github – Published: 2026-07-02 19:37 – Updated: 2026-07-02 19:37Am I affected
You are affected if:
- You run
zebradup to and includingv4.4.1. - Your
zebrad.tomlsetsrpc.listen_addrto a TCP address (RPC server is enabled). - An attacker can authenticate to the RPC endpoint. With the default
enable_cookie_auth = true, this requires the attacker to read the.cookiefile (typically local access). Withenable_cookie_auth = false, any network client reaching the RPC port can trigger it.
Summary
The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.
Details
zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.
At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.
The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.
Patches
zebra-rpc 8.0.0 and zebrad 4.5.0.
Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.
Workarounds
- Disable the RPC server by removing
rpc.listen_addrfromzebrad.toml. - Ensure
enable_cookie_auth = true(the default) and restrict filesystem access to the.cookiefile. - Place a reverse proxy in front of the RPC port that rejects
z_listunifiedreceiverscalls with untrusted address parameters.
Impact
A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.
Credit
Reported by @robustfengbin via a private GitHub Security Advisory submission.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.0"
},
"package": {
"ecosystem": "crates.io",
"name": "zebra-rpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.4.1"
},
"package": {
"ecosystem": "crates.io",
"name": "zebrad"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-248",
"CWE-617",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T19:37:58Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your `zebrad.toml` sets `rpc.listen_addr` to a TCP address (RPC server is enabled).\n3. An attacker can authenticate to the RPC endpoint. With the default `enable_cookie_auth = true`, this requires the attacker to read the `.cookie` file (typically local access). With `enable_cookie_auth = false`, any network client reaching the RPC port can trigger it.\n\n### Summary\n\nThe `z_listunifiedreceivers` RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (`sapling_crypto::PaymentAddress::from_bytes` returns `None` for non-subgroup Jubjub points). The handler calls `.expect(\"using data already decoded as valid\")` on the fallible result. Because Zebra\u0027s release profile sets `panic = \"abort\"`, the panic terminates the entire node process, not just the RPC task.\n\n### Details\n\n`zcash_address::unified::Encoding::decode` validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded `pk_d` is a valid Jubjub subgroup point or that the diversifier produces a valid `g_d` preimage.\n\nAt `zebra-rpc/src/methods.rs:2893`, the handler calls `Address::try_from_sapling(network, data)`, which delegates to `sapling_crypto::PaymentAddress::from_bytes`. When `from_bytes` returns `None` (most random 32-byte strings fail the subgroup check), the `.expect()` fires and the process aborts.\n\nThe same crate already handles this correctly in `try_from_unified` at `zebra-chain/src/primitives/address.rs:99-110`, which returns `Err` when `from_bytes` fails. The vulnerable code path bypasses this validated route.\n\n### Patches\n\nzebra-rpc 8.0.0 and zebrad 4.5.0.\n\nReplace `.expect()` with `.map_err(|e| ErrorObject::owned(...))` for proper error propagation, or route through the existing `try_from_unified` path which already handles this case correctly.\n\n### Workarounds\n\n- Disable the RPC server by removing `rpc.listen_addr` from `zebrad.toml`.\n- Ensure `enable_cookie_auth = true` (the default) and restrict filesystem access to the `.cookie` file.\n- Place a reverse proxy in front of the RPC port that rejects `z_listunifiedreceivers` calls with untrusted address parameters.\n\n### Impact\n\nA single authenticated RPC request terminates the `zebrad` process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using `lightwalletd` backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to `zebrad` may be exposed if the forwarding path passes through `z_listunifiedreceivers`.\n\n### Credit\n\nReported by `@robustfengbin` via a private GitHub Security Advisory submission.",
"id": "GHSA-c8w6-x74f-vmg3",
"modified": "2026-07-02T19:37:58Z",
"published": "2026-07-02T19:37:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-c8w6-x74f-vmg3"
},
{
"type": "PACKAGE",
"url": "https://github.com/ZcashFoundation/zebra"
},
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/Cargo.toml#L305"
},
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-rpc/src/methods.rs#L2867-L2914"
}
],
"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": "zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers"
}
GHSA-C93V-4QMP-8W98
Vulnerability from github – Published: 2025-03-12 21:31 – Updated: 2025-03-12 21:31A Denial of Service (DoS) vulnerability in Palo Alto Networks PAN-OS software causes the firewall to unexpectedly reboot when processing a specially crafted LLDP frame sent by an unauthenticated adjacent attacker. Repeated attempts to initiate this condition causes the firewall to enter maintenance mode.
This issue does not apply to Cloud NGFWs or Prisma Access software.
{
"affected": [],
"aliases": [
"CVE-2025-0116"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T19:15:37Z",
"severity": "MODERATE"
},
"details": "A Denial of Service (DoS) vulnerability in Palo Alto Networks PAN-OS software causes the firewall to unexpectedly reboot when processing a specially crafted LLDP frame sent by an unauthenticated adjacent attacker. Repeated attempts to initiate this condition causes the firewall to enter maintenance mode.\n\nThis issue does not apply to Cloud NGFWs or Prisma Access software.",
"id": "GHSA-c93v-4qmp-8w98",
"modified": "2025-03-12T21:31:29Z",
"published": "2025-03-12T21:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0116"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2025-0116"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/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:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-C948-477J-77C3
Vulnerability from github – Published: 2023-12-15 18:30 – Updated: 2023-12-15 18:30A denial of service vulnerability exists in all Silicon Labs Z-Wave controller and endpoint devices running Z-Wave SDK v7.20.3 (Gecko SDK v4.3.3) and earlier. This attack can be carried out only by devices on the network sending a stream of packets to the device.
{
"affected": [],
"aliases": [
"CVE-2023-5310"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-15T16:15:46Z",
"severity": "MODERATE"
},
"details": "\nA denial of service vulnerability exists in all Silicon Labs Z-Wave controller and endpoint devices running Z-Wave SDK v7.20.3 (Gecko SDK v4.3.3) and earlier. This attack can be carried out only by devices on the network sending a stream of packets to the device.\n\n",
"id": "GHSA-c948-477j-77c3",
"modified": "2023-12-15T18:30:28Z",
"published": "2023-12-15T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5310"
},
{
"type": "WEB",
"url": "https://github.com/SiliconLabs/gecko_sdk/releases"
},
{
"type": "WEB",
"url": "https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm0000005E7EIAU?%20operationContext=S1"
}
],
"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"
}
]
}
GHSA-C96H-CXX6-RMG9
Vulnerability from github – Published: 2024-05-18 00:30 – Updated: 2025-03-27 18:40In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tor-circmgr"
},
"ranges": [
{
"events": [
{
"introduced": "0.18.0"
},
{
"fixed": "0.18.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.18.0"
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "arti"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.2"
},
{
"fixed": "1.2.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.2.2"
]
}
],
"aliases": [
"CVE-2024-35313"
],
"database_specific": {
"cwe_ids": [
"CWE-130",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-20T16:37:19Z",
"nvd_published_at": "2024-05-17T22:15:07Z",
"severity": "MODERATE"
},
"details": "In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.",
"id": "GHSA-c96h-cxx6-rmg9",
"modified": "2025-03-27T18:40:05Z",
"published": "2024-05-18T00:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35313"
},
{
"type": "PACKAGE",
"url": "https://gitlab.torproject.org/tpo/core/arti"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md#arti-123-15-may-2024"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/commit/1a89d5c9659d799a84dd3ff00fae530f5c8ba280"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/issues/1400"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/issues/1409"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0339.html"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0340.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tor path lengths too short when \"full Vanguards\" configured"
}
GHSA-C9QP-272Q-MVF9
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
virtio_pmem: Check device status before requesting flush
If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang.
So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.
{
"affected": [],
"aliases": [
"CVE-2024-50184"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-08T06:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_pmem: Check device status before requesting flush\n\nIf a pmem device is in a bad status, the driver side could wait for\nhost ack forever in virtio_pmem_flush(), causing the system to hang.\n\nSo add a status check in the beginning of virtio_pmem_flush() to return\nearly if the device is not activated.",
"id": "GHSA-c9qp-272q-mvf9",
"modified": "2025-11-04T00:31:57Z",
"published": "2024-11-08T06:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50"
},
{
"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-CC72-WC5X-7WMJ
Vulnerability from github – Published: 2025-02-14 18:30 – Updated: 2025-02-14 18:30Mattermost versions 9.11.x <= 9.11.6 fail to filter out DMs from the deleted channels endpoint which allows an attacker to infer user IDs and other metadata from deleted DMs if someone had manually marked DMs as deleted in the database.
{
"affected": [],
"aliases": [
"CVE-2025-0503"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-14T18:15:23Z",
"severity": "LOW"
},
"details": "Mattermost versions 9.11.x \u003c= 9.11.6 fail to filter out DMs from the deleted channels endpoint which allows an attacker to infer user IDs and other metadata from deleted DMs if someone had manually marked DMs as deleted in the database.",
"id": "GHSA-cc72-wc5x-7wmj",
"modified": "2025-02-14T18:30:53Z",
"published": "2025-02-14T18:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0503"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CCPP-J37G-5J85
Vulnerability from github – Published: 2025-12-16 06:30 – Updated: 2025-12-16 06:30CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. When the Video Download feature is in a specific communication state, the product's resources may be consumed abnormally.
{
"affected": [],
"aliases": [
"CVE-2025-66357"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T05:16:14Z",
"severity": "MODERATE"
},
"details": "CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. When the Video Download feature is in a specific communication state, the product\u0027s resources may be consumed abnormally.",
"id": "GHSA-ccpp-j37g-5j85",
"modified": "2025-12-16T06:30:19Z",
"published": "2025-12-16T06:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66357"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU92827367"
},
{
"type": "WEB",
"url": "https://www.inaba.co.jp/files/chocomini_vulnerability_newly_identified.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/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:X/U:X",
"type": "CVSS_V4"
}
]
}
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.