Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

7128 vulnerabilities reference this CWE, most recent first.

GHSA-GRJ4-G57C-9XMV

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2024-04-23 23:38
VLAI
Summary
Moodle Bypass email verification secret when confirming account registration
Details

When creating a user account, it was possible to verify the account without having access to the verification email link/secret in moodle before 3.10.2, 3.9.5, 3.8.8, 3.5.17.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5"
            },
            {
              "fixed": "3.5.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8"
            },
            {
              "fixed": "3.8.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9"
            },
            {
              "fixed": "3.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10"
            },
            {
              "fixed": "3.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-20282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-23T23:38:11Z",
    "nvd_published_at": "2021-03-15T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "When creating a user account, it was possible to verify the account without having access to the verification email link/secret in moodle before 3.10.2, 3.9.5, 3.8.8, 3.5.17.",
  "id": "GHSA-grj4-g57c-9xmv",
  "modified": "2024-04-23T23:38:11Z",
  "published": "2022-05-24T17:44:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20282"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1939046"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AFSNJ7XHVTC52RSRX2GBQFF3VEEAY2MS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UFH5DDMU5TZ3JT4Q52WMRAHACA5MHIMT"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=419653"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle Bypass email verification secret when confirming account registration"
}

GHSA-GRR4-6QXM-23QC

Vulnerability from github – Published: 2024-09-04 06:30 – Updated: 2024-09-04 06:30
VLAI
Details

Incorrect authorization in CocktailbarService prior to SMR Sep-2024 Release 1 allows local attackers to access privileged APIs related to Edge panel.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-34650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T06:15:14Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in CocktailbarService prior to SMR Sep-2024 Release 1 allows local attackers to access privileged APIs related to Edge panel.",
  "id": "GHSA-grr4-6qxm-23qc",
  "modified": "2024-09-04T06:30:41Z",
  "published": "2024-09-04T06:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34650"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=09"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GRVM-GCQF-GH8Q

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2023-10-19 18:34
VLAI
Summary
Xen Orchestra Mishandles Authorization
Details

Xen Orchestra (with xo-web through 5.80.0 and xo-server through 5.84.0) mishandles authorization, as demonstrated by modified WebSocket resourceSet.getAll data is which the attacker changes the permission field from none to admin. The attacker gains access to data sets such as VMs, Backups, Audit, Users, and Groups.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "xo-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.80.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "xo-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.84.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-36383"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-19T18:34:45Z",
    "nvd_published_at": "2021-07-12T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Xen Orchestra (with xo-web through 5.80.0 and xo-server through 5.84.0) mishandles authorization, as demonstrated by modified WebSocket `resourceSet.getAll` data is which the attacker changes the permission field from none to admin. The attacker gains access to data sets such as VMs, Backups, Audit, Users, and Groups.",
  "id": "GHSA-grvm-gcqf-gh8q",
  "modified": "2023-10-19T18:34:45Z",
  "published": "2022-05-24T19:07:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36383"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vatesfr/xen-orchestra/issues/5712"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vatesfr/xen-orchestra"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Xen Orchestra Mishandles Authorization"
}

GHSA-GRVV-H2F9-7V9C

Vulnerability from github – Published: 2022-08-30 19:54 – Updated: 2022-08-30 19:54
VLAI
Summary
gomatrixserverlib and Dendrite vulnerable to incorrect parsing of the event default power level in event auth
Details

Impact

The power level parsing within gomatrixserverlib was failing to parse the "events_default" key of the m.room.power_levels event, defaulting the event default power level to zero in all cases.

In rooms where the "events_default" power level had been changed, this could result in events either being incorrectly authorised or rejected by Dendrite servers.

Patches

gomatrixserverlib contains a fix as of commit 723fd49 and Dendrite 0.9.3 has been updated accordingly.

Workarounds

Matrix rooms where the "events_default" power level has not been changed from the default of zero are not vulnerable.

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/matrix-org/dendrite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/matrix-org/gomatrixserverlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20220815091947-723fd495dde8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-30T19:54:34Z",
    "nvd_published_at": "2022-08-19T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe power level parsing within gomatrixserverlib was failing to parse the `\"events_default\"` key of the `m.room.power_levels` event, defaulting the event default power level to zero in all cases.\n\nIn rooms where the `\"events_default\"` power level had been changed, this could result in events either being incorrectly authorised or rejected by Dendrite servers.\n\n### Patches\n\ngomatrixserverlib contains a fix as of commit `723fd49` and Dendrite 0.9.3 has been updated accordingly.\n\n### Workarounds\n\nMatrix rooms where the `\"events_default\"` power level has not been changed from the default of zero are not vulnerable.\n\n### For more information\n\nIf you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).",
  "id": "GHSA-grvv-h2f9-7v9c",
  "modified": "2022-08-30T19:54:34Z",
  "published": "2022-08-30T19:54:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/gomatrixserverlib/security/advisories/GHSA-grvv-h2f9-7v9c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36009"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/gomatrixserverlib/commit/723fd495dde835d078b9f2074b6b62c06dea4575"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/gomatrixserverlib"
    },
    {
      "type": "WEB",
      "url": "https://matrix.org/docs/guides/moderation/#power-levels"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-0952"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gomatrixserverlib and Dendrite vulnerable to incorrect parsing of the event default power level in event auth"
}

GHSA-GV37-7GXX-PJ8G

Vulnerability from github – Published: 2023-03-22 06:30 – Updated: 2023-03-24 21:30
VLAI
Details

A vulnerability in the web-based management interface of ClearPass Policy Manager allows an attacker with read-only privileges to perform actions that change the state of the ClearPass Policy Manager instance. Successful exploitation of this vulnerability allows an attacker to complete state-changing actions in the web-based management interface that should not be allowed by their current level of authorization on the platform.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-25594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-22T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the web-based management interface of ClearPass Policy Manager allows an attacker with read-only privileges to perform actions that change the state of the ClearPass Policy Manager instance. Successful exploitation of this vulnerability allows an attacker to complete state-changing actions in the web-based management interface that should not be allowed by their current level of authorization on the platform.",
  "id": "GHSA-gv37-7gxx-pj8g",
  "modified": "2023-03-24T21:30:53Z",
  "published": "2023-03-22T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25594"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2023-003.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GV46-4XFQ-JV58

Vulnerability from github – Published: 2026-03-02 23:24 – Updated: 2026-03-06 01:05
VLAI
Summary
OpenClaw Vulnerable to Remote Code Execution via Node Invoke Approval Bypass in Gateway
Details

Summary

A remote code execution (RCE) vulnerability in the gateway-to-node invocation path allowed an authenticated gateway client to bypass node-host exec approvals by injecting internal control fields into node.invoke parameters.

Affected Component

  • Gateway method: node.invoke for node command system.run
  • Node host runner: exec approval gating for system.run

Impact

If an attacker can authenticate to a gateway (for example via a leaked/shared gateway token or a paired device token with operator.write), they could execute arbitrary commands on connected node hosts that support system.run. This can lead to full compromise of developer workstations, CI runners, and servers running the node host.

Technical Details

The gateway forwarded user-controlled params to node hosts without sanitizing internal approval fields. The node host treated params.approved === true and/or params.approvalDecision as sufficient to skip the approval workflow.

Fix

Patched in OpenClaw 2026.2.14.

  • Commits:
  • 318379cdb8d045da0009b0051bd0e712e5c65e2d
  • a7af646fdab124a7536998db6bd6ad567d2b06b0
  • c1594627421f95b6bc4ad7c606657dc75b5ad0ce
  • 0af76f5f0e93540efbdf054895216c398692afcd
  • Gateway strips untrusted approval control fields from system.run user input.
  • Gateway only re-attaches approval flags when params.runId references a valid exec.approval.request record and the request context matches. Approval IDs are bound to the requesting device identity (stable across reconnects), preventing replay by other clients.
  • Gateway forwards only an allowlisted set of system.run parameters, preventing future control-field smuggling.

Mitigations

  • Upgrade to 2026.2.14 or later.
  • Restrict access to the gateway (do not expose it to untrusted networks/users).
  • Rotate gateway credentials if you suspect token/password exposure.
  • Disable remote command execution on nodes by blocking system.run at the gateway (gateway.nodes.denyCommands) and/or by configuring node exec security to deny.

Credits

OpenClaw thanks @222n5 for reporting this issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-441",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T23:24:54Z",
    "nvd_published_at": "2026-03-05T22:16:19Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA remote code execution (RCE) vulnerability in the gateway-to-node invocation path allowed an authenticated gateway client to bypass node-host exec approvals by injecting internal control fields into `node.invoke` parameters.\n\n### Affected Component\n\n- Gateway method: `node.invoke` for node command `system.run`\n- Node host runner: exec approval gating for `system.run`\n\n### Impact\n\nIf an attacker can authenticate to a gateway (for example via a leaked/shared gateway token or a paired device token with `operator.write`), they could execute arbitrary commands on connected node hosts that support `system.run`. This can lead to full compromise of developer workstations, CI runners, and servers running the node host.\n\n### Technical Details\n\nThe gateway forwarded user-controlled `params` to node hosts without sanitizing internal approval fields. The node host treated `params.approved === true` and/or `params.approvalDecision` as sufficient to skip the approval workflow.\n\n### Fix\n\nPatched in **OpenClaw `2026.2.14`**.\n\n- Commits:\n  - `318379cdb8d045da0009b0051bd0e712e5c65e2d`\n  - `a7af646fdab124a7536998db6bd6ad567d2b06b0`\n  - `c1594627421f95b6bc4ad7c606657dc75b5ad0ce`\n  - `0af76f5f0e93540efbdf054895216c398692afcd`\n- Gateway strips untrusted approval control fields from `system.run` user input.\n- Gateway only re-attaches approval flags when `params.runId` references a valid `exec.approval.request` record and the request context matches. Approval IDs are bound to the requesting device identity (stable across reconnects), preventing replay by other clients.\n- Gateway forwards only an allowlisted set of `system.run` parameters, preventing future control-field smuggling.\n\n### Mitigations\n\n- Upgrade to `2026.2.14` or later.\n- Restrict access to the gateway (do not expose it to untrusted networks/users).\n- Rotate gateway credentials if you suspect token/password exposure.\n- Disable remote command execution on nodes by blocking `system.run` at the gateway (`gateway.nodes.denyCommands`) and/or by configuring node exec security to `deny`.\n\n### Credits\n\nOpenClaw thanks @222n5 for reporting this issue.",
  "id": "GHSA-gv46-4xfq-jv58",
  "modified": "2026-03-06T01:05:53Z",
  "published": "2026-03-02T23:24:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gv46-4xfq-jv58"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28466"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0af76f5f0e93540efbdf054895216c398692afcd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/318379cdb8d045da0009b0051bd0e712e5c65e2d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a7af646fdab124a7536998db6bd6ad567d2b06b0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c1594627421f95b6bc4ad7c606657dc75b5ad0ce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-remote-code-execution-via-node-invoke-approval-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw Vulnerable to Remote Code Execution via Node Invoke Approval Bypass in Gateway"
}

GHSA-GV5W-HFX8-8CWQ

Vulnerability from github – Published: 2026-09-02 23:42 – Updated: 2026-09-02 23:42
VLAI
Summary
SeaweedFS: Filer JWT allowed_prefixes literal prefix match allows cross-tenant access to sibling paths
Details

Impact

When a filer JWT restricts a token to a set of path prefixes via allowed_prefixes, the authorization check used a literal byte-prefix match (strings.HasPrefix). A token scoped to /tenant1 therefore also authorized requests to sibling paths such as /tenant1234, /tenant1-old, and /tenant1backup.

In a multi-tenant deployment this lets the holder of one tenant's token access another tenant's data. Because allowed_prefixes gates both read and write tokens, the impact covers cross-tenant reads and writes. A valid scoped token is required, so this is an authorization bypass rather than a fully unauthenticated flaw.

Affected component

  • weed/server/filer_server_handlers.go (JWT allowed_prefixes authorization check)

Patches

Fixed in 4.24. The check now matches on /-separated path components after path.Clean normalisation, so /tenant1 authorizes only /tenant1 and its descendants — not /tenant1234 or other sibling paths.

Workarounds

Where feasible, choose prefix names that are not string-prefixes of one another (e.g. keep a trailing separator convention). Upgrade to 4.24.

References

  • Reported by Kadir Arslan (https://github.com/KadirArslan)
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/seaweedfs/seaweedfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260512171048-05ed5c9ae8a2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-72921"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T23:42:05Z",
    "nvd_published_at": "2026-08-11T15:17:38Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nWhen a filer JWT restricts a token to a set of path prefixes via `allowed_prefixes`, the authorization check used a literal byte-prefix match (`strings.HasPrefix`). A token scoped to `/tenant1` therefore also authorized requests to sibling paths such as `/tenant1234`, `/tenant1-old`, and `/tenant1backup`.\n\nIn a multi-tenant deployment this lets the holder of one tenant\u0027s token access another tenant\u0027s data. Because `allowed_prefixes` gates both read and write tokens, the impact covers cross-tenant reads and writes. A valid scoped token is required, so this is an authorization bypass rather than a fully unauthenticated flaw.\n\n### Affected component\n- `weed/server/filer_server_handlers.go` (JWT `allowed_prefixes` authorization check)\n\n### Patches\nFixed in **4.24**. The check now matches on `/`-separated path components after `path.Clean` normalisation, so `/tenant1` authorizes only `/tenant1` and its descendants \u2014 not `/tenant1234` or other sibling paths.\n\n### Workarounds\nWhere feasible, choose prefix names that are not string-prefixes of one another (e.g. keep a trailing separator convention). Upgrade to 4.24.\n\n### References\n- Reported by Kadir Arslan (https://github.com/KadirArslan)",
  "id": "GHSA-gv5w-hfx8-8cwq",
  "modified": "2026-09-02T23:42:05Z",
  "published": "2026-09-02T23:42:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/security/advisories/GHSA-gv5w-hfx8-8cwq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72921"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/pull/9439"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/commit/05ed5c9ae8a2a45101b52b61d02f170d20d587ff"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/seaweedfs/seaweedfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/releases/tag/4.24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SeaweedFS: Filer JWT allowed_prefixes literal prefix match allows cross-tenant access to sibling paths"
}

GHSA-GV6H-VWG4-8MWR

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.2 SP4). Affected applications do not properly validate license restrictions against the database, allowing direct modification of the system_ticketinfo table to bypass license limitations without proper enforcement checks. This could allow with database access to circumvent licensing restrictions by directly modifying database values and potentially enabling unauthorized use beyond the permitted scope.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-40819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:46Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SINEMA Remote Connect Server (All versions \u003c V3.2 SP4). Affected applications do not properly validate license restrictions against the database, allowing direct modification of the system_ticketinfo table to bypass license limitations without proper enforcement checks. This could allow with database access to circumvent licensing restrictions by directly modifying database values and potentially enabling unauthorized use beyond the permitted scope.",
  "id": "GHSA-gv6h-vwg4-8mwr",
  "modified": "2025-12-09T18:30:36Z",
  "published": "2025-12-09T18:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40819"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-626856.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GV74-J8M3-FG5F

Vulnerability from github – Published: 2026-07-20 21:06 – Updated: 2026-07-20 21:06
VLAI
Summary
@better-auth/sso: SSO provider may allow registration for any org member without a checking their role
Details

Am I affected?

You are affected if all of the following are true:

  • You depend on @better-auth/sso at any version in >= 1.2.10, < 1.6.11, or any current next pre-release.
  • You enable both sso() and organization() plugins.
  • providersLimit is at its default (10) or any non-zero value, so SSO provider registration is enabled for authenticated users.
  • An organization has non-admin members, or your application can add users to organizations as regular members.

You are at the highest risk if any of these also hold:

  • Organization membership can be obtained without a direct admin decision, such as through open invitations, self-serve onboarding, public team joins, or SCIM bulk imports.
  • organizationProvisioning.defaultRole or organizationProvisioning.getRole returns admin or higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org.
  • domainVerification.enabled is false (the default). The malicious provider is immediately usable.

Fix:

  1. Upgrade to @better-auth/sso@1.6.11 or later.
  2. If you cannot upgrade, see workarounds below.

Summary

The SSO plugin's POST /sso/register endpoint lets any member of an organization attach a new SSO provider to that organization. It checks that the caller has a membership row, but it does not check whether the caller has an administrative role for the organization.

This creates an authorization mismatch for the same resource. Other org-linked SSO provider management endpoints treat those providers as admin-managed: list, get, update, and delete require the caller to be an organization owner or admin. The create path is less restrictive, so a regular member can attach an attacker-controlled OIDC or SAML identity provider to an organization they do not administer. After registration, downstream organization provisioning can add IdP-asserted users from /sso/callback/{providerId} into the target organization, defaulting to role member.

Details

This issue does not rely on a separate documentation statement that only admins may create SSO connections. The issue is that Better Auth already enforces an admin boundary for org-linked SSO provider management, but registerSSOProvider does not enforce the same boundary when the provider is first created.

The list, get, update, and delete endpoints in providers.ts gate org-linked SSO providers via isOrgAdmin, which accepts owner or admin. The create path in sso.ts performs only a membership lookup and never inspects member.role. As a result, the endpoint allows a low-privilege organization member to create a provider record that they would not be allowed to view, update, or delete through the companion provider-management endpoints.

The fix introduces a shared hasOrgAdminRole(member) helper (refactored out of isOrgAdmin) and adds the admin check to the registration handler so that registration matches the protections on the read and mutation paths.

Patches

Fixed in @better-auth/sso@1.6.11. When organizationId is supplied and the organization plugin is enabled, the registerSSOProvider handler now requires the caller to hold the owner or admin role on the target organization. This makes provider creation match the existing protection on the get, update, and delete endpoints.

Workarounds

If you cannot upgrade immediately:

  • Disable user-driven SSO registration entirely: set sso({ providersLimit: 0 }). Registration throws FORBIDDEN before the membership gate. Trade-off: admins also lose self-serve provider creation; provisioning has to go through server-side auth.api.registerSSOProvider({ headers: serverAdminHeaders, body }) calls.
  • Disable SSO-driven org provisioning: set sso({ organizationProvisioning: { disabled: true } }). The malicious provider can still be registered, but the SSO callback no longer adds users to the org automatically. Trade-off: legitimate SSO-driven onboarding stops.
  • Custom before hook on /sso/register that asserts the caller's role on body.organizationId is owner or admin. This duplicates the patch shape in user code.
  • Audit existing rows: list ssoProvider rows where organizationId IS NOT NULL, cross-reference each userId with member.role for that organization, and remove provider rows whose creator is not currently owner or admin. Removing the provider does not auto-remove members it created, so cleanup is two-step.

Impact

  • Unauthorized provider configuration within an organization tenant: a regular member writes an SSO provider record on an organization they do not administer.
  • Unauthorized organization membership creation: subsequent SSO callbacks can add IdP-asserted users to the target organization at the configured default role.
  • Admin creation when configured: if organizationProvisioning.defaultRole is admin, or organizationProvisioning.getRole returns admin, the issue can create admin-grade users in the target organization without owner consent.

Credit

Reported by @Nadav0077. The same finding was previously raised in public issue #9133 (2026-04-12).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/sso"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.10"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:06:17Z",
    "nvd_published_at": "2026-07-15T18:16:47Z",
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nYou are affected if all of the following are true:\n\n- You depend on `@better-auth/sso` at any version in `\u003e= 1.2.10, \u003c 1.6.11`, or any current `next` pre-release.\n- You enable both `sso()` and `organization()` plugins.\n- `providersLimit` is at its default (`10`) or any non-zero value, so SSO provider registration is enabled for authenticated users.\n- An organization has non-admin members, or your application can add users to organizations as regular members.\n\nYou are at the highest risk if any of these also hold:\n\n- Organization membership can be obtained without a direct admin decision, such as through open invitations, self-serve onboarding, public team joins, or SCIM bulk imports.\n- `organizationProvisioning.defaultRole` or `organizationProvisioning.getRole` returns `admin` or higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org.\n- `domainVerification.enabled` is `false` (the default). The malicious provider is immediately usable.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If you cannot upgrade, see workarounds below.\n\n### Summary\n\nThe SSO plugin\u0027s `POST /sso/register` endpoint lets any member of an organization attach a new SSO provider to that organization. It checks that the caller has a membership row, but it does not check whether the caller has an administrative role for the organization.\n\nThis creates an authorization mismatch for the same resource. Other org-linked SSO provider management endpoints treat those providers as admin-managed: list, get, update, and delete require the caller to be an organization `owner` or `admin`. The create path is less restrictive, so a regular member can attach an attacker-controlled OIDC or SAML identity provider to an organization they do not administer. After registration, downstream organization provisioning can add IdP-asserted users from `/sso/callback/{providerId}` into the target organization, defaulting to role `member`.\n\n### Details\n\nThis issue does not rely on a separate documentation statement that only admins may create SSO connections. The issue is that Better Auth already enforces an admin boundary for org-linked SSO provider management, but `registerSSOProvider` does not enforce the same boundary when the provider is first created.\n\nThe list, get, update, and delete endpoints in `providers.ts` gate org-linked SSO providers via `isOrgAdmin`, which accepts `owner` or `admin`. The create path in `sso.ts` performs only a membership lookup and never inspects `member.role`. As a result, the endpoint allows a low-privilege organization member to create a provider record that they would not be allowed to view, update, or delete through the companion provider-management endpoints.\n\nThe fix introduces a shared `hasOrgAdminRole(member)` helper (refactored out of `isOrgAdmin`) and adds the admin check to the registration handler so that registration matches the protections on the read and mutation paths.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. When `organizationId` is supplied and the `organization` plugin is enabled, the `registerSSOProvider` handler now requires the caller to hold the `owner` or `admin` role on the target organization. This makes provider creation match the existing protection on the get, update, and delete endpoints.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Disable user-driven SSO registration entirely**: set `sso({ providersLimit: 0 })`. Registration throws `FORBIDDEN` before the membership gate. Trade-off: admins also lose self-serve provider creation; provisioning has to go through server-side `auth.api.registerSSOProvider({ headers: serverAdminHeaders, body })` calls.\n- **Disable SSO-driven org provisioning**: set `sso({ organizationProvisioning: { disabled: true } })`. The malicious provider can still be registered, but the SSO callback no longer adds users to the org automatically. Trade-off: legitimate SSO-driven onboarding stops.\n- **Custom `before` hook on `/sso/register`** that asserts the caller\u0027s role on `body.organizationId` is `owner` or `admin`. This duplicates the patch shape in user code.\n- **Audit existing rows**: list `ssoProvider` rows where `organizationId IS NOT NULL`, cross-reference each `userId` with `member.role` for that organization, and remove provider rows whose creator is not currently `owner` or `admin`. Removing the provider does not auto-remove members it created, so cleanup is two-step.\n\n### Impact\n\n- **Unauthorized provider configuration within an organization tenant**: a regular member writes an SSO provider record on an organization they do not administer.\n- **Unauthorized organization membership creation**: subsequent SSO callbacks can add IdP-asserted users to the target organization at the configured default role.\n- **Admin creation when configured**: if `organizationProvisioning.defaultRole` is `admin`, or `organizationProvisioning.getRole` returns `admin`, the issue can create admin-grade users in the target organization without owner consent.\n\n### Credit\n\nReported by @Nadav0077. The same finding was previously raised in public issue [#9133](https://github.com/better-auth/better-auth/issues/9133) (2026-04-12).",
  "id": "GHSA-gv74-j8m3-fg5f",
  "modified": "2026-07-20T21:06:17Z",
  "published": "2026-07-20T21:06:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-gv74-j8m3-fg5f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53515"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/issues/9133"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/pull/9220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/commit/86765f1597378f5c3deed1b80ca91faac0a6bf00"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@better-auth/sso: SSO provider may allow registration for any org member without a checking their role"
}

GHSA-GV7W-JH8G-VR73

Vulnerability from github – Published: 2025-10-28 00:31 – Updated: 2025-10-29 10:44
VLAI
Summary
Liferay Portal Does Not Limit Access to APIs Before Email Verification
Details

Liferay Portal 7.4.0 through 7.4.3.109, and older unsupported versions, and Liferay DXP 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not limit access to APIs before a user has verified their email address, which allows remote users to access and edit content via the API.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.portal.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.4.0-ga1"
            },
            {
              "fixed": "7.4.3.110"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62259"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T10:44:39Z",
    "nvd_published_at": "2025-10-27T23:15:38Z",
    "severity": "MODERATE"
  },
  "details": "Liferay Portal 7.4.0 through 7.4.3.109, and older unsupported versions, and Liferay DXP 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not limit access to APIs before a user has verified their email address, which allows remote users to access and edit content via the API.",
  "id": "GHSA-gv7w-jh8g-vr73",
  "modified": "2025-10-29T10:44:39Z",
  "published": "2025-10-28T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62259"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-62259"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Liferay Portal Does Not Limit Access to APIs Before Email Verification"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list