Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14816 vulnerabilities reference this CWE, most recent first.

GHSA-C2M8-4GCG-V22G

Vulnerability from github – Published: 2026-05-29 23:01 – Updated: 2026-05-29 23:01
VLAI
Summary
praisonai-platform: Any workspace member can promote themselves or others to owner via PATCH /workspaces/{id}/members/{user_id}
Details

Summary

Type: Vertical privilege escalation. The PATCH /workspaces/{workspace_id}/members/{user_id} endpoint is gated by require_workspace_member(workspace_id), which defaults to min_role="member" and is never overridden by the route. The handler then calls MemberService.update_role(workspace_id, user_id, body.role) which sets the target member's role to whatever the request body specifies, with no check that the caller has owner-or-admin privilege, no check that the new role is not higher than the caller's own, and no check that the caller is not silently promoting themselves. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 115-127; services/member_service.py, lines 55-69; api/deps.py, lines 54-73. Root cause: require_workspace_member exists with a min_role parameter (deps.py:58) but FastAPI's Depends(require_workspace_member) cannot pass arguments, so every route uses the default "member". The route then passes the URL-supplied user_id and the body-supplied role directly to MemberService.update_role, which contains zero permission checks: it loads the member by composite key and assigns member.role = new_role. A user with the lowest possible privilege ("member") thus sets their own role to "owner" with one HTTP PATCH, completing a member-to-owner privilege escalation in a single request.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 115-127.

@router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse)
async def update_member_role(
    workspace_id: str,
    user_id: str,
    body: MemberUpdate,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"; no role gate
    session: AsyncSession = Depends(get_db),
):
    member_svc = MemberService(session)
    member = await member_svc.update_role(workspace_id, user_id, body.role)  # <-- writes any role to any member
    if member is None:
        raise HTTPException(status_code=404, detail="Member not found")
    return MemberResponse.model_validate(member)

File 2: src/praisonai-platform/praisonai_platform/services/member_service.py, lines 55-69.

async def update_role(
    self,
    workspace_id: str,
    user_id: str,
    new_role: str,
) -> Optional[Member]:
    """Update a member's role."""
    if new_role not in VALID_ROLES:                                  # only validates the *value*, not the *caller's right*
        raise ValueError(f"Invalid role: {new_role}. Must be one of {VALID_ROLES}")
    member = await self.get(workspace_id, user_id)
    if member is None:
        return None
    member.role = new_role                                           # <-- BUG: no caller-role check, no target-vs-caller hierarchy check
    await self._session.flush()
    return member

File 3: src/praisonai-platform/praisonai_platform/api/deps.py, lines 54-73.

async def require_workspace_member(
    workspace_id: str,
    user: AuthIdentity = Depends(get_current_user),
    session: AsyncSession = Depends(get_db),
    min_role: str = "member",                                        # <-- default that no route overrides
) -> AuthIdentity:
    member_svc = MemberService(session)
    has = await member_svc.has_role(workspace_id, user.id, min_role)
    if not has:
        raise HTTPException(status_code=403, detail="Not a member of this workspace or insufficient role")
    user.workspace_id = workspace_id
    return user

Why it's wrong: require_workspace_member was clearly designed to be tunable per-route — the min_role parameter is right there — but Depends(require_workspace_member) in FastAPI cannot pass arguments to a dependency, so every route resolves to the default "member". The author's intent is also evident in MemberService.has_role (member_service.py:80-96), which implements an owner > admin > member hierarchy that this endpoint should be enforcing. The endpoint uses none of it. The VALID_ROLES = {"owner", "admin", "member"} enum check (member_service.py:62) only validates the new role string is recognised, not that the caller has the right to assign it. As a result, a member can write {"role": "owner"} to their own membership row and become owner in one PATCH.

Exploit Chain

  1. Attacker registers an account and joins (or is invited to) any workspace W as a "member" (the lowest privilege tier — typically anyone can be added by an owner during onboarding, or self-joins via an invite link). State: attacker has a JWT, is a Member(workspace_id=W, user_id=attacker, role="member").
  2. Attacker sends PATCH /workspaces/W/members/<attacker_user_id> with Authorization: Bearer <attacker_jwt> and body {"role": "owner"}. State: control flow enters update_member_role.
  3. require_workspace_member(W, attacker) runs. Its default min_role="member" is satisfied because the attacker is a member. The dependency returns the attacker's identity. State: route handler proceeds with no further role gate.
  4. MemberService.update_role(W, attacker, "owner") runs. VALID_ROLES accepts "owner". self.get(W, attacker) returns the attacker's existing member row. The next line, member.role = "owner", mutates the attacker's role in place. await self._session.flush() commits. State: attacker is now Member(workspace_id=W, user_id=attacker, role="owner").
  5. Attacker re-issues GET /auth/me (or any owner-gated endpoint) and is now treated as workspace owner. State: full administrative control of the workspace, including the ability to add/remove members, change settings, delete the workspace, and exfiltrate everything via the agent/issue/project/comment IDORs that were filed as separate advisories.
  6. Final state: starting from the lowest workspace privilege, the attacker holds owner of the workspace within one HTTP request. The same primitive also lets the attacker DEMOTE the legitimate owner by sending PATCH /workspaces/W/members/<owner_user_id> with {"role": "member"} — owner lockout in two requests total.

Security Impact

Severity: sec-critical. CVSS 9.1: network attack, low complexity, low privileges (the lowest tier on the platform), no user interaction, scope changed (the privilege boundary the attacker crosses is the workspace owner, a different security principal), high confidentiality and integrity (full workspace control), no availability claim (the attacker can also DELETE the workspace via the companion delete_workspace advisory, but that is a separate finding). Attacker capability: with one workspace-member token plus one PATCH request, the attacker becomes workspace owner. From there: add/remove any user as owner, change every workspace setting (including the settings JSON blob), demote the legitimate owner to "member", or chain into the companion delete_workspace advisory to wipe the workspace entirely. In multi-tenant SaaS deployments where any signup yields a member-level account in some default workspace, this is effectively pre-auth. Preconditions: praisonai-platform is deployed multi-tenant (more than one workspace exists OR the deployment grants member access on signup); the attacker has any membership token in the target workspace. Differential: source-inspection-verified end-to-end. The asymmetry between require_workspace_member's min_role parameter (which exists, defaults to "member", and is never overridden) and MemberService.has_role's clearly tiered owner > admin > member hierarchy (which exists but is never invoked with anything but the default) is the smoking gun. With the suggested fix below, the route resolves with min_role="owner", the attacker's member-level token fails the gate at the dependency, and the privilege escalation never reaches the service layer.

Suggested Fix

The fix has two parts. First, the route must resolve require_workspace_member with min_role="owner" (or at least "admin"). Second, MemberService.update_role should refuse to set a target's role higher than the caller's own role, so that an admin cannot accidentally produce another owner.

--- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
+++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
@@ -115,11 +115,16 @@
+def _require_owner(workspace_id: str, user, session):
+    return require_workspace_member(workspace_id, user, session, min_role="owner")
+
 @router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse)
 async def update_member_role(
     workspace_id: str,
     user_id: str,
     body: MemberUpdate,
-    user: AuthIdentity = Depends(require_workspace_member),
+    user: AuthIdentity = Depends(_require_owner),
     session: AsyncSession = Depends(get_db),
 ):
     member_svc = MemberService(session)
+    if not await member_svc.has_role(workspace_id, user.id, "owner"):
+        raise HTTPException(status_code=403, detail="Only owners can change member roles")
     member = await member_svc.update_role(workspace_id, user_id, body.role)

Defence-in-depth in the service layer:

--- a/src/praisonai-platform/praisonai_platform/services/member_service.py
+++ b/src/praisonai-platform/praisonai_platform/services/member_service.py
@@ -55,7 +55,7 @@
-    async def update_role(self, workspace_id: str, user_id: str, new_role: str) -> Optional[Member]:
+    async def update_role(self, workspace_id: str, caller_id: str, user_id: str, new_role: str) -> Optional[Member]:
         """Update a member's role."""
+        if not await self.has_role(workspace_id, caller_id, "owner"):
+            raise PermissionError("Only owners can update member roles")
         if new_role not in VALID_ROLES:
             raise ValueError(...)

The companion endpoints add_member, remove_member, delete_workspace, and update_workspace exhibit the same Depends(require_workspace_member) default-min-role pattern and are filed as their own advisories so each gets a separate CVE.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T23:01:59Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n**Type:** Vertical privilege escalation. The `PATCH /workspaces/{workspace_id}/members/{user_id}` endpoint is gated by `require_workspace_member(workspace_id)`, which defaults to `min_role=\"member\"` and is never overridden by the route. The handler then calls `MemberService.update_role(workspace_id, user_id, body.role)` which sets the target member\u0027s role to whatever the request body specifies, with no check that the caller has owner-or-admin privilege, no check that the new role is not higher than the caller\u0027s own, and no check that the caller is not silently promoting themselves.\n**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127; `services/member_service.py`, lines 55-69; `api/deps.py`, lines 54-73.\n**Root cause:** `require_workspace_member` exists with a `min_role` parameter (deps.py:58) but FastAPI\u0027s `Depends(require_workspace_member)` cannot pass arguments, so every route uses the default `\"member\"`. The route then passes the URL-supplied `user_id` and the body-supplied `role` directly to `MemberService.update_role`, which contains zero permission checks: it loads the member by composite key and assigns `member.role = new_role`. A user with the lowest possible privilege (\"member\") thus sets their own role to \"owner\" with one HTTP PATCH, completing a member-to-owner privilege escalation in a single request.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127.\n\n```python\n@router.patch(\"/{workspace_id}/members/{user_id}\", response_model=MemberResponse)\nasync def update_member_role(\n    workspace_id: str,\n    user_id: str,\n    body: MemberUpdate,\n    user: AuthIdentity = Depends(require_workspace_member),         # \u003c-- BUG: defaults to min_role=\"member\"; no role gate\n    session: AsyncSession = Depends(get_db),\n):\n    member_svc = MemberService(session)\n    member = await member_svc.update_role(workspace_id, user_id, body.role)  # \u003c-- writes any role to any member\n    if member is None:\n        raise HTTPException(status_code=404, detail=\"Member not found\")\n    return MemberResponse.model_validate(member)\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/services/member_service.py`, lines 55-69.\n\n```python\nasync def update_role(\n    self,\n    workspace_id: str,\n    user_id: str,\n    new_role: str,\n) -\u003e Optional[Member]:\n    \"\"\"Update a member\u0027s role.\"\"\"\n    if new_role not in VALID_ROLES:                                  # only validates the *value*, not the *caller\u0027s right*\n        raise ValueError(f\"Invalid role: {new_role}. Must be one of {VALID_ROLES}\")\n    member = await self.get(workspace_id, user_id)\n    if member is None:\n        return None\n    member.role = new_role                                           # \u003c-- BUG: no caller-role check, no target-vs-caller hierarchy check\n    await self._session.flush()\n    return member\n```\n\n**File 3:** `src/praisonai-platform/praisonai_platform/api/deps.py`, lines 54-73.\n\n```python\nasync def require_workspace_member(\n    workspace_id: str,\n    user: AuthIdentity = Depends(get_current_user),\n    session: AsyncSession = Depends(get_db),\n    min_role: str = \"member\",                                        # \u003c-- default that no route overrides\n) -\u003e AuthIdentity:\n    member_svc = MemberService(session)\n    has = await member_svc.has_role(workspace_id, user.id, min_role)\n    if not has:\n        raise HTTPException(status_code=403, detail=\"Not a member of this workspace or insufficient role\")\n    user.workspace_id = workspace_id\n    return user\n```\n\n**Why it\u0027s wrong:** `require_workspace_member` was clearly designed to be tunable per-route \u2014 the `min_role` parameter is right there \u2014 but `Depends(require_workspace_member)` in FastAPI cannot pass arguments to a dependency, so every route resolves to the default `\"member\"`. The author\u0027s intent is also evident in `MemberService.has_role` (member_service.py:80-96), which implements an `owner \u003e admin \u003e member` hierarchy that this endpoint should be enforcing. The endpoint uses none of it. The `VALID_ROLES = {\"owner\", \"admin\", \"member\"}` enum check (member_service.py:62) only validates the *new role string is recognised*, not that the *caller has the right to assign it*. As a result, a member can write `{\"role\": \"owner\"}` to their own membership row and become owner in one PATCH.\n\n## Exploit Chain\n\n1. Attacker registers an account and joins (or is invited to) any workspace `W` as a \"member\" (the lowest privilege tier \u2014 typically anyone can be added by an owner during onboarding, or self-joins via an invite link). State: attacker has a JWT, is a `Member(workspace_id=W, user_id=attacker, role=\"member\")`.\n2. Attacker sends `PATCH /workspaces/W/members/\u003cattacker_user_id\u003e` with `Authorization: Bearer \u003cattacker_jwt\u003e` and body `{\"role\": \"owner\"}`. State: control flow enters `update_member_role`.\n3. `require_workspace_member(W, attacker)` runs. Its default `min_role=\"member\"` is satisfied because the attacker is a member. The dependency returns the attacker\u0027s identity. State: route handler proceeds with no further role gate.\n4. `MemberService.update_role(W, attacker, \"owner\")` runs. `VALID_ROLES` accepts `\"owner\"`. `self.get(W, attacker)` returns the attacker\u0027s existing member row. The next line, `member.role = \"owner\"`, mutates the attacker\u0027s role in place. `await self._session.flush()` commits. State: attacker is now `Member(workspace_id=W, user_id=attacker, role=\"owner\")`.\n5. Attacker re-issues `GET /auth/me` (or any owner-gated endpoint) and is now treated as workspace owner. State: full administrative control of the workspace, including the ability to add/remove members, change settings, delete the workspace, and exfiltrate everything via the agent/issue/project/comment IDORs that were filed as separate advisories.\n6. Final state: starting from the lowest workspace privilege, the attacker holds owner of the workspace within one HTTP request. The same primitive also lets the attacker DEMOTE the legitimate owner by sending `PATCH /workspaces/W/members/\u003cowner_user_id\u003e` with `{\"role\": \"member\"}` \u2014 owner lockout in two requests total.\n\n## Security Impact\n\n**Severity:** sec-critical. CVSS 9.1: network attack, low complexity, low privileges (the lowest tier on the platform), no user interaction, scope changed (the privilege boundary the attacker crosses is the workspace owner, a different security principal), high confidentiality and integrity (full workspace control), no availability claim (the attacker can also DELETE the workspace via the companion `delete_workspace` advisory, but that is a separate finding).\n**Attacker capability:** with one workspace-member token plus one PATCH request, the attacker becomes workspace owner. From there: add/remove any user as owner, change every workspace setting (including the `settings` JSON blob), demote the legitimate owner to \"member\", or chain into the companion `delete_workspace` advisory to wipe the workspace entirely. In multi-tenant SaaS deployments where any signup yields a member-level account in some default workspace, this is effectively pre-auth.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant (more than one workspace exists OR the deployment grants member access on signup); the attacker has any membership token in the target workspace.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `require_workspace_member`\u0027s `min_role` parameter (which exists, defaults to \"member\", and is never overridden) and `MemberService.has_role`\u0027s clearly tiered `owner \u003e admin \u003e member` hierarchy (which exists but is never invoked with anything but the default) is the smoking gun. With the suggested fix below, the route resolves with `min_role=\"owner\"`, the attacker\u0027s member-level token fails the gate at the dependency, and the privilege escalation never reaches the service layer.\n\n## Suggested Fix\n\nThe fix has two parts. First, the route must resolve `require_workspace_member` with `min_role=\"owner\"` (or at least `\"admin\"`). Second, `MemberService.update_role` should refuse to set a target\u0027s role higher than the caller\u0027s own role, so that an admin cannot accidentally produce another owner.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py\n+++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py\n@@ -115,11 +115,16 @@\n+def _require_owner(workspace_id: str, user, session):\n+    return require_workspace_member(workspace_id, user, session, min_role=\"owner\")\n+\n @router.patch(\"/{workspace_id}/members/{user_id}\", response_model=MemberResponse)\n async def update_member_role(\n     workspace_id: str,\n     user_id: str,\n     body: MemberUpdate,\n-    user: AuthIdentity = Depends(require_workspace_member),\n+    user: AuthIdentity = Depends(_require_owner),\n     session: AsyncSession = Depends(get_db),\n ):\n     member_svc = MemberService(session)\n+    if not await member_svc.has_role(workspace_id, user.id, \"owner\"):\n+        raise HTTPException(status_code=403, detail=\"Only owners can change member roles\")\n     member = await member_svc.update_role(workspace_id, user_id, body.role)\n```\n\nDefence-in-depth in the service layer:\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/member_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/member_service.py\n@@ -55,7 +55,7 @@\n-    async def update_role(self, workspace_id: str, user_id: str, new_role: str) -\u003e Optional[Member]:\n+    async def update_role(self, workspace_id: str, caller_id: str, user_id: str, new_role: str) -\u003e Optional[Member]:\n         \"\"\"Update a member\u0027s role.\"\"\"\n+        if not await self.has_role(workspace_id, caller_id, \"owner\"):\n+            raise PermissionError(\"Only owners can update member roles\")\n         if new_role not in VALID_ROLES:\n             raise ValueError(...)\n```\n\nThe companion endpoints `add_member`, `remove_member`, `delete_workspace`, and `update_workspace` exhibit the same `Depends(require_workspace_member)` default-min-role pattern and are filed as their own advisories so each gets a separate CVE.",
  "id": "GHSA-c2m8-4gcg-v22g",
  "modified": "2026-05-29T23:01:59Z",
  "published": "2026-05-29T23:01:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-c2m8-4gcg-v22g"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Any workspace member can promote themselves or others to owner via PATCH /workspaces/{id}/members/{user_id}"
}

GHSA-C2M9-HPP2-J675

Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in Wiser Notify WiserNotify Social Proof allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WiserNotify Social Proof: from n/a through 2.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-13T15:15:23Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Wiser Notify WiserNotify Social Proof allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WiserNotify Social Proof: from n/a through 2.5.",
  "id": "GHSA-c2m9-hpp2-j675",
  "modified": "2026-04-28T21:35:26Z",
  "published": "2024-12-13T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41690"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wiser-notify/vulnerability/wordpress-wisernotify-social-proof-plugin-2-5-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-C2QP-GP7H-J46P

Vulnerability from github – Published: 2022-05-24 17:13 – Updated: 2023-05-23 15:30
VLAI
Details

The Rank Math plugin through 1.0.40.2 for WordPress allows unauthenticated remote attackers to update arbitrary WordPress metadata, including the ability to escalate or revoke administrative privileges for existing users via the unsecured rankmath/v1/updateMeta REST API endpoint.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-11514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-07T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Rank Math plugin through 1.0.40.2 for WordPress allows unauthenticated remote attackers to update arbitrary WordPress metadata, including the ability to escalate or revoke administrative privileges for existing users via the unsecured rankmath/v1/updateMeta REST API endpoint.",
  "id": "GHSA-c2qp-gp7h-j46p",
  "modified": "2023-05-23T15:30:25Z",
  "published": "2022-05-24T17:13:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11514"
    },
    {
      "type": "WEB",
      "url": "https://rankmath.com/changelog"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/seo-by-rank-math/#developers"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/blog/2020/03/critical-vulnerabilities-affecting-over-200000-sites-patched-in-rank-math-seo-plugin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2R4-2V2X-5WFJ

Vulnerability from github – Published: 2025-04-04 18:31 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in Dimitri Grassi Salon booking system allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Salon booking system: from n/a through 10.10.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-32220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-04T16:15:31Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Dimitri Grassi Salon booking system allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Salon booking system: from n/a through 10.10.7.",
  "id": "GHSA-c2r4-2v2x-5wfj",
  "modified": "2026-04-28T21:35:34Z",
  "published": "2025-04-04T18:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32220"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/salon-booking-system/vulnerability/wordpress-salon-booking-system-plugin-10-10-7-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2RP-3H56-JMQG

Vulnerability from github – Published: 2025-11-27 03:30 – Updated: 2025-11-27 03:30
VLAI
Details

The Reuters Direct plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'logoff' action in all versions up to, and including, 3.0.0. This makes it possible for unauthenticated attackers to reset the plugin's settings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-27T03:15:57Z",
    "severity": "MODERATE"
  },
  "details": "The Reuters Direct plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027logoff\u0027 action in all versions up to, and including, 3.0.0. This makes it possible for unauthenticated attackers to reset the plugin\u0027s settings.",
  "id": "GHSA-c2rp-3h56-jmqg",
  "modified": "2025-11-27T03:30:26Z",
  "published": "2025-11-27T03:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12579"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/reuters-direct"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4360f293-201c-40c1-9603-931d72cc79bc?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-C2V9-7FF7-Q3P4

Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-23 12:32
VLAI
Details

Unauthenticated Broken Access Control in Civi Framework <= 2.2.0 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-65525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-23T12:18:45Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Broken Access Control in Civi Framework \u003c= 2.2.0 versions.",
  "id": "GHSA-c2v9-7ff7-q3p4",
  "modified": "2026-07-23T12:32:29Z",
  "published": "2026-07-23T12:32:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65525"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/civi-framework/vulnerability/wordpress-civi-framework-plugin-2-2-0-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-C2VP-W3G2-V2M5

Vulnerability from github – Published: 2023-01-10 00:30 – Updated: 2023-01-13 09:30
VLAI
Details

The Royal Elementor Addons WordPress plugin before 1.3.56 does not have authorization and CSRF checks when deleting a template and does not ensure that the post to be deleted is a template. This could allow any authenticated users, such as subscribers, to delete arbitrary posts assuming they know the related slug.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4102"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-09T23:15:00Z",
    "severity": "LOW"
  },
  "details": "The Royal Elementor Addons WordPress plugin before 1.3.56 does not have authorization and CSRF checks when deleting a template and does not ensure that the post to be deleted is a template. This could allow any authenticated users, such as subscribers, to delete arbitrary posts assuming they know the related slug.",
  "id": "GHSA-c2vp-w3g2-v2m5",
  "modified": "2023-01-13T09:30:26Z",
  "published": "2023-01-10T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4102"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/c177f763-0bb5-4734-ba2e-7ba816578937"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2WP-6856-C9G7

Vulnerability from github – Published: 2025-02-17 00:31 – Updated: 2026-04-01 18:33
VLAI
Details

Missing Authorization vulnerability in enituretechnology LTL Freight Quotes – Worldwide Express Edition allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects LTL Freight Quotes – Worldwide Express Edition: from n/a through 5.0.20.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-22291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-16T23:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in enituretechnology LTL Freight Quotes \u2013 Worldwide Express Edition allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects LTL Freight Quotes \u2013 Worldwide Express Edition: from n/a through 5.0.20.",
  "id": "GHSA-c2wp-6856-c9g7",
  "modified": "2026-04-01T18:33:40Z",
  "published": "2025-02-17T00:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22291"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/ltl-freight-quotes-worldwide-express-edition/vulnerability/wordpress-ltl-freight-quotes-worldwide-express-edition-plugin-5-0-20-arbitrary-content-deletion-vulnerability?_s_id=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-C2X9-J4MV-GGW3

Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-23 15:34
VLAI
Details

Missing Authorization vulnerability in Kishor Khambu WP Custom Widget area allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Custom Widget area: from n/a through 1.2.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45045"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-02T12:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Kishor Khambu WP Custom Widget area allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Custom Widget area: from n/a through 1.2.5.",
  "id": "GHSA-c2x9-j4mv-ggw3",
  "modified": "2026-04-23T15:34:12Z",
  "published": "2025-01-02T12:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45045"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-custom-widget-area/vulnerability/wordpress-wp-custom-widget-area-plugin-1-2-5-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2XG-F2C9-GVPR

Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2026-04-01 18:32
VLAI
Details

Missing Authorization vulnerability in WPTaskForce WPCargo Track & Trace allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCargo Track & Trace: from n/a through 7.0.6.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-13T15:15:31Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in WPTaskForce WPCargo Track \u0026 Trace allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCargo Track \u0026 Trace: from n/a through 7.0.6.",
  "id": "GHSA-c2xg-f2c9-gvpr",
  "modified": "2026-04-01T18:32:43Z",
  "published": "2024-12-13T15:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54271"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wpcargo/vulnerability/wordpress-wpcargo-track-trace-plugin-7-0-6-settings-change-vulnerability?_s_id=cve"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

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.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.