Common Weakness Enumeration

CWE-754

Allowed-with-Review

Improper Check for Unusual or Exceptional Conditions

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

974 vulnerabilities reference this CWE, most recent first.

GHSA-C4C3-7FPV-J4Q5

Vulnerability from github – Published: 2026-09-08 18:16 – Updated: 2026-09-08 18:16
VLAI
Summary
Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext
Details

Summary

A fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route's mTLS requirement.

Details

In io.netty.handler.ssl.SslClientHelloHandler#decode the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires:

if (handshakeLength == -1) {
    if (readerIndex + 4 > endOffset) {
        // Need more data to read HandshakeType and handshakeLength (4 bytes)
        return;
    }

When the first record's payload is < 4 bytes, handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSL_RECORD_HEADER_LENGTH + 1); leads to IndexOutOfBoundsException. That is caught by the generic catch (Exception) block, which calls select(ctx, null) - this is the default SslContext. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate.

Impact

SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when: - mTLS is enforced solely via per-SNI SslContext (clientAuth=REQUIRE) - the default/fallback SslContext is permissive (clientAuth=NONE/OPTIONAL) - no secondary peer-certificate verification exists at the application layer.

Severity
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.16.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.17.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.136.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.137.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-75595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-475",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T18:16:14Z",
    "nvd_published_at": "2026-08-19T21:17:37Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nA fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route\u0027s mTLS requirement.\n\n### Details\nIn `io.netty.handler.ssl.SslClientHelloHandler#decode` the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires:\n\n```java\nif (handshakeLength == -1) {\n    if (readerIndex + 4 \u003e endOffset) {\n        // Need more data to read HandshakeType and handshakeLength (4 bytes)\n        return;\n    }\n```\n\nWhen the first record\u0027s payload is \u003c 4 bytes, `handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSL_RECORD_HEADER_LENGTH + 1);` leads to `IndexOutOfBoundsException `. That is caught by the generic `catch (Exception)` block, which calls `select(ctx, null)` - this is the default `SslContext`. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate.\n\n### Impact\nSNI routing bypass. Escalates to an unauthenticated mTLS bypass only when:\n- mTLS is enforced solely via per-SNI SslContext (clientAuth=REQUIRE)\n- the default/fallback SslContext is permissive (clientAuth=NONE/OPTIONAL)\n- no secondary peer-certificate verification exists at the application layer.",
  "id": "GHSA-c4c3-7fpv-j4q5",
  "modified": "2026-09-08T18:16:14Z",
  "published": "2026-09-08T18:16:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-c4c3-7fpv-j4q5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75595"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/17213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/17217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.137.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.17.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext"
}

GHSA-C5J5-Q67X-GPCC

Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2026-02-02 18:31
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in Brocade Fabric OS before 9.2.2.a could allow an authenticated, network-based attacker to cause a Denial-of-Service (DoS). The vulnerability is encountered when supportsave is invoked remotely, using ssh command or SANnav inline ssh, and the corresponding ssh session is terminated with Control C (^c ) before supportsave completion. This issue affects Brocade Fabric OS 9.0.0 through 9.2.2

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
6.8 (Medium)
CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-4663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-08T18:15:39Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Check for Unusual or \nExceptional Conditions vulnerability in Brocade Fabric OS before 9.2.2.a\n could allow an authenticated, network-based attacker to cause a \nDenial-of-Service (DoS).\nThe\n vulnerability is encountered when supportsave is invoked remotely, \nusing ssh command or SANnav inline ssh, and the corresponding ssh \nsession is terminated with Control C (^c ) before supportsave \ncompletion.\nThis issue affects Brocade Fabric OS 9.0.0 through 9.2.2",
  "id": "GHSA-c5j5-q67x-gpcc",
  "modified": "2026-02-02T18:31:28Z",
  "published": "2025-07-08T18:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4663"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/35815"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:H/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-C5PQ-FR2G-9JPF

Vulnerability from github – Published: 2026-09-17 17:04 – Updated: 2026-09-17 17:04
VLAI
Summary
RabbitMQ amqp091-go: Protocol Desynchronization and Frame Injection via Integer Overflow in readLongstr
Details

Summary

A critical stream desynchronization vulnerability has been identified in the AMQP wire-protocol parser. When parsing a long string (readLongstr) within a table field, providing a length that exceeds the maximum signed 32-bit integer (2^31 - 1, or roughly 2.1 GiB) triggers an improper error-handling condition. The parser abruptly aborts the read and returns a success status ("",nil) without consuming the specified bytes from the underlying network buffer. This causes all subsequent read operations to become misaligned. The parser interprets arbitrary offsets within the remaining payload bytes as valid AMQP frame headers, leading to potential Remote Code Execution (RCE), data injection, or complete connection hijacking.

Vulnerability Details

The vulnerability exists within the bounds-checking logic of the readLongstr function:

// read.go:113-114 — silent no-op return, bytes left in stream
if length > (^uint32(0) >> 1) {
    return  // returns "", nil, does NOT consume `length` bytes
}

When length evaluates to a value greater than 0x7FFFFFFF:

  1. The function executes a silent return statement.
  2. Because Go utilizes named or zero-value initialization for unassigned return registers, this yields "", nil (indicating a successful read of an empty string).
  3. The Critical Failure: The reader's cursor is not advanced by length bytes. The malformed payload remains sitting in the TCP/buffer stream.

Impact

As readTable continues iterating over the stream under the assumption that the string was successfully parsed, the byte alignment is entirely broken.

  • Parser Desynchronization: Future AMQP frame headers are read from arbitrary offsets inside the attacker-controlled message payload.
  • Payload Reinterpretation: A malicious actor can carefully craft the trailing bytes of the initial payload to perfectly mimic valid AMQP frames (e.g., connection.close, channel.open, or message publishing frames), forcing the client/server to execute unintended actions.
Severity
9.5 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rabbitmq/amqp091-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77411"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:04:25Z",
    "nvd_published_at": "2026-09-16T15:17:50Z",
    "severity": "CRITICAL"
  },
  "details": "**Summary**\n\nA critical stream desynchronization vulnerability has been identified in the AMQP wire-protocol parser. When parsing a long string (`readLongstr`) within a table field, providing a length that exceeds the maximum signed 32-bit integer (`2^31 - 1`, or roughly `2.1` GiB) triggers an improper error-handling condition. The parser abruptly aborts the read and returns a success status (`\"\",nil`) without consuming the specified bytes from the underlying network buffer. This causes all subsequent read operations to become misaligned. The parser interprets arbitrary offsets within the remaining payload bytes as valid AMQP frame headers, leading to potential Remote Code Execution (RCE), data injection, or complete connection hijacking.\n\n**Vulnerability Details**\n\nThe vulnerability exists within the bounds-checking logic of the readLongstr function:\n```go\n// read.go:113-114 \u2014 silent no-op return, bytes left in stream\nif length \u003e (^uint32(0) \u003e\u003e 1) {\n    return  // returns \"\", nil, does NOT consume `length` bytes\n}\n```\nWhen `length` evaluates to a value greater than `0x7FFFFFFF`:\n\n1. The function executes a silent `return` statement.\n2. Because Go utilizes named or zero-value initialization for unassigned return registers, this yields `\"\", nil` (indicating a successful read of an empty string).\n3. The Critical Failure: The reader\u0027s cursor is not advanced by `length` bytes. The malformed payload remains sitting in the TCP/buffer stream.\n\n**Impact**\n\nAs `readTable` continues iterating over the stream under the assumption that the string was successfully parsed, the byte alignment is entirely broken.\n\n- Parser Desynchronization: Future AMQP frame headers are read from arbitrary offsets inside the attacker-controlled message payload.\n- Payload Reinterpretation: A malicious actor can carefully craft the trailing bytes of the initial payload to perfectly mimic valid AMQP frames (e.g., `connection.close`, `channel.open`, or message publishing frames), forcing the client/server to execute unintended actions.",
  "id": "GHSA-c5pq-fr2g-9jpf",
  "modified": "2026-09-17T17:04:25Z",
  "published": "2026-09-17T17:04:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-c5pq-fr2g-9jpf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77411"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/pull/347"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/commit/143c1ace5fa7344cee135e5c7d22970f0de68282"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/amqp091-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RabbitMQ amqp091-go: Protocol Desynchronization and Frame Injection via Integer Overflow in readLongstr"
}

GHSA-C6H8-W7QX-QJ83

Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41
VLAI
Details

In loadAnimation of WindowContainer.java, there is a possible way to keep displaying a malicious app while a target app is brought to the foreground. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-8.1 Android-9Android ID: A-145728687

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-10T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "In loadAnimation of WindowContainer.java, there is a possible way to keep displaying a malicious app while a target app is brought to the foreground. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-8.1 Android-9Android ID: A-145728687",
  "id": "GHSA-c6h8-w7qx-qj83",
  "modified": "2022-05-24T17:41:45Z",
  "published": "2022-05-24T17:41:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0339"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2021-02-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C7PV-J8XR-MMHJ

Vulnerability from github – Published: 2026-04-23 18:33 – Updated: 2026-04-23 18:33
VLAI
Details

An unauthenticated remote attacker is able to exhaust all available TCP connections in the CODESYS EtherNet/IP adapter stack, preventing legitimate clients from establishing new connections.

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-35225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-23T15:37:23Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated remote attacker is able to exhaust all available TCP connections in the CODESYS EtherNet/IP adapter stack, preventing legitimate clients from establishing new connections.",
  "id": "GHSA-c7pv-j8xr-mmhj",
  "modified": "2026-04-23T18:33:03Z",
  "published": "2026-04-23T18:33:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35225"
    },
    {
      "type": "WEB",
      "url": "https://codesys.csaf-tp.certvde.com/.well-known/csaf/white/2026/advisory2026-04_vde-2026-040.json"
    },
    {
      "type": "WEB",
      "url": "https://www.certvde.com/en/advisories/VDE-2026-040"
    }
  ],
  "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: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-C7XM-PC9F-6XW4

Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2022-11-29 15:30
VLAI
Details

Incorrect pointer checks within the NvmExpressDxe driver can allow tampering with SMRAM and OS memory Incorrect pointer checks within the NvmExpressDxe driver can allow tampering with SMRAM and OS memory. This issue was discovered by Insyde during security review. Fixed in: Kernel 5.1: Version 05.17.23 Kernel 5.2: Version 05.27.23 Kernel 5.3: Version 05.36.23 Kernel 5.4: Version 05.44.23 Kernel 5.5: Version 05.52.23 https://www.insyde.com/security-pledge/SA-2022061

Severity
8.2 (High)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-29278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-15T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Incorrect pointer checks within the NvmExpressDxe driver can allow tampering with SMRAM and OS memory Incorrect pointer checks within the NvmExpressDxe driver can allow tampering with SMRAM and OS memory. This issue was discovered by Insyde during security review. Fixed in: Kernel 5.1: Version 05.17.23 Kernel 5.2: Version 05.27.23 Kernel 5.3: Version 05.36.23 Kernel 5.4: Version 05.44.23 Kernel 5.5: Version 05.52.23 https://www.insyde.com/security-pledge/SA-2022061",
  "id": "GHSA-c7xm-pc9f-6xw4",
  "modified": "2022-11-29T15:30:25Z",
  "published": "2022-11-16T12:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29278"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge/SA-2022061"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C7XM-R6VJ-8VG6

Vulnerability from github – Published: 2026-04-29 21:53 – Updated: 2026-05-08 20:13
VLAI
Summary
Admidio Missing Minimum Administrator Check in Role Membership Removal
Details

Summary

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):

  1. 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.
  2. 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.
  3. 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

Severity
5.2 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

Vulnerability of improper exception handling in the print module. Successful exploitation of this vulnerability may affect availability.

Severity
5.9 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

A 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.

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
8.2 (High)
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
Show details on source website
To clipboard 

{
  "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:37
VLAI
Summary
zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers
Details

Am I affected

You are affected if:

  1. You run zebrad up to and including v4.4.1.
  2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
  3. 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.

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_addr from zebrad.toml.
  • Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
  • Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls 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.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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"
}
Mitigation MIT-3
Requirements

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
Implementation

Check the results of all functions that return a value and verify that the value is expected.

Mitigation
Implementation

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
Implementation
  • 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
Implementation

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
Architecture and Design Implementation

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
Architecture and Design

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.

← Back to the CWE list