Common Weakness Enumeration

CWE-269

Discouraged

Improper Privilege Management

Abstraction: Class · Status: Draft

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

5455 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-C2PF-5922-6C68

Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06
VLAI
Details

There is an Incorrect Privilege Assignment Vulnerability in Huawei Smartphone. Successful exploitation of this vulnerability may affect service confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22326"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-30T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is an Incorrect Privilege Assignment Vulnerability in Huawei Smartphone. Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-c2pf-5922-6c68",
  "modified": "2022-05-24T19:06:37Z",
  "published": "2022-05-24T19:06:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22326"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2021/5"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/cn/docs/security/update/security-bulletins-202107-0000001123874808"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C2Q4-MFPF-X8WH

Vulnerability from github – Published: 2024-07-10 18:32 – Updated: 2025-10-14 18:30
VLAI
Details

Vulnerability in Jaspersoft JasperReport Servers.This issue affects JasperReport Servers: from 8.0.4 through 9.0.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-10T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in Jaspersoft JasperReport Servers.This issue affects JasperReport Servers: from 8.0.4 through 9.0.0.",
  "id": "GHSA-c2q4-mfpf-x8wh",
  "modified": "2025-10-14T18:30:26Z",
  "published": "2024-07-10T18:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3325"
    },
    {
      "type": "WEB",
      "url": "https://community.jaspersoft.com/advisories/jaspersoft-security-advisory-july-9-2024-jasperreports-server-cve-2024-3325-r4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/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-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-C2VR-2C89-PH88

Vulnerability from github – Published: 2018-09-18 13:49 – Updated: 2021-09-16 20:54
VLAI
Summary
Downloads Resources over HTTP in node-bsdiff-android
Details

Affected versions of node-bsdiff-android insecurely download resources over HTTP.

In scenarios where an attacker has a privileged network position, they can modify or read such resources at will. While the exact severity of impact for a vulnerability like this is highly variable and depends on the behavior of the package itself, it ranges from being able to read sensitive information all the way up to and including remote code execution.

Recommendation

No patch is currently available for this vulnerability, and the package has not seen an update since 2014.

The best mitigation is currently to avoid using this package, using a different package if available.

Alternatively, the risk of exploitation can be reduced by ensuring that this package is not installed while connected to a public network. If the package is installed on a private network, the only people who can exploit this vulnerability are those who have compromised your network or those who have privileged access to your ISP, such as Nation State Actors or Rogue ISP Employees.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "node-bsdiff-android"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-10641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-311"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:30:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Affected versions of `node-bsdiff-android` insecurely download resources over HTTP. \n\nIn scenarios where an attacker has a privileged network position, they can modify or read such resources at will. While the exact severity of impact for a vulnerability like this is highly variable and depends on the behavior of the package itself, it ranges from being able to read sensitive information all the way up to and including remote code execution.\n\n\n## Recommendation\n\nNo patch is currently available for this vulnerability, and the package has not seen an update since 2014.\n\nThe best mitigation is currently to avoid using this package, using a different package if available. \n\nAlternatively, the risk of exploitation can be reduced by ensuring that this package is not installed while connected to a public network. If the package is installed on a private network, the only people who can exploit this vulnerability are those who have compromised your network or those who have privileged access to your ISP, such as Nation State Actors or Rogue ISP Employees.",
  "id": "GHSA-c2vr-2c89-ph88",
  "modified": "2021-09-16T20:54:14Z",
  "published": "2018-09-18T13:49:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10641"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-c2vr-2c89-ph88"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/arthur-zhang/node-bsdiff-android"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/234"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Downloads Resources over HTTP in node-bsdiff-android"
}

GHSA-C2W5-XJ35-QMX4

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

An elevation of privilege vulnerability exists in the way that the Windows Credential Picker handles objects in memory, aka 'Windows Credential Picker Elevation of Privilege Vulnerability'.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-14T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An elevation of privilege vulnerability exists in the way that the Windows Credential Picker handles objects in memory, aka \u0027Windows Credential Picker Elevation of Privilege Vulnerability\u0027.",
  "id": "GHSA-c2w5-xj35-qmx4",
  "modified": "2022-05-24T17:23:02Z",
  "published": "2022-05-24T17:23:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1385"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1385"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C2WX-2CHW-3QFV

Vulnerability from github – Published: 2024-09-17 00:31 – Updated: 2025-11-04 18:31
VLAI
Details

This issue was addressed through improved state management. This issue is fixed in iOS 18 and iPadOS 18. An app may gain unauthorized access to Local Network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-44147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-17T00:15:50Z",
    "severity": "HIGH"
  },
  "details": "This issue was addressed through improved state management. This issue is fixed in iOS 18 and iPadOS 18. An app may gain unauthorized access to Local Network.",
  "id": "GHSA-c2wx-2chw-3qfv",
  "modified": "2025-11-04T18:31:22Z",
  "published": "2024-09-17T00:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44147"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121250"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Sep/32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2XJ-XC27-698R

Vulnerability from github – Published: 2023-10-03 00:30 – Updated: 2024-04-04 08:01
VLAI
Details

A flaw exists in VASA which allows users with access to a vSphere/ESXi VMware admin on a FlashArray to gain root access through privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-36628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-03T00:15:10Z",
    "severity": "HIGH"
  },
  "details": "A flaw exists in VASA which allows users with access to a vSphere/ESXi VMware admin on a FlashArray to gain root access through privilege escalation.\n",
  "id": "GHSA-c2xj-xc27-698r",
  "modified": "2024-04-04T08:01:43Z",
  "published": "2023-10-03T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36628"
    },
    {
      "type": "WEB",
      "url": "https://support.purestorage.com/Pure_Storage_Technical_Services/Field_Bulletins/Security_Bulletins/Security_Bulletin_for_Privilege_Escalation_in_VASA_CVE-2023-36628"
    }
  ],
  "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-C2XM-XV33-Q796

Vulnerability from github – Published: 2025-12-02 15:30 – Updated: 2025-12-02 21:31
VLAI
Details

Entrust nShield Connect XC, nShield 5c, and nShield HSMi through 13.6.11, or 13.7, allow a physically proximate attacker to escalate privileges by editing the Legacy GRUB bootloader configuration to start a root shell upon boot of the host OS. This is called F06.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T15:15:55Z",
    "severity": "HIGH"
  },
  "details": "Entrust nShield Connect XC, nShield 5c, and nShield HSMi through 13.6.11, or 13.7, allow a physically proximate attacker to escalate privileges by editing the Legacy GRUB bootloader configuration to start a root shell upon boot of the host OS. This is called F06.",
  "id": "GHSA-c2xm-xv33-q796",
  "modified": "2025-12-02T21:31:28Z",
  "published": "2025-12-02T15:30:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/google/security-research/security/advisories/GHSA-6q4x-m86j-gfwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59697"
    },
    {
      "type": "WEB",
      "url": "https://www.entrust.com/use-case/why-use-an-hsm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C39C-4H5F-9JHH

Vulnerability from github – Published: 2024-08-08 12:30 – Updated: 2024-08-08 12:30
VLAI
Details

Access permission verification vulnerability in the Notepad module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42036"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-285"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-08T10:15:07Z",
    "severity": "LOW"
  },
  "details": "Access permission verification vulnerability in the Notepad module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-c39c-4h5f-9jhh",
  "modified": "2024-08-08T12:30:34Z",
  "published": "2024-08-08T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42036"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-1
Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-48
Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Mitigation MIT-49
Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CAPEC-122: Privilege Abuse

An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

CAPEC-233: Privilege Escalation

An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.

CAPEC-58: Restful Privilege Elevation

An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.