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.

5703 vulnerabilities reference this CWE, most recent first.

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-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"
}

GHSA-GV86-WF87-753X

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

The Stylish Price List WordPress plugin before 6.9.0 does not perform capability checks in its spl_upload_ser_img AJAX action (available to both unauthenticated and authenticated users), which could allow unauthenticated users to upload images.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-24757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-01T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Stylish Price List WordPress plugin before 6.9.0 does not perform capability checks in its spl_upload_ser_img AJAX action (available to both unauthenticated and authenticated users), which could allow unauthenticated users to upload images.",
  "id": "GHSA-gv86-wf87-753x",
  "modified": "2022-05-24T19:19:19Z",
  "published": "2022-05-24T19:19:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24757"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/352a9e05-2d5f-4bf7-8da9-85621fb15d91"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GVG4-JHMR-6J23

Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-06-01 15:19
VLAI
Summary
Mattermost doesn't check if {{team_id}} was being changed when updating playbooks
Details

Mattermost versions 11.5.x <= 11.5.1, 10.11.x <= 10.11.13 fail to check if {{team_id}} was being changed when updating playbooks, allowing users with only {{Manage Playbook Configurations}} permission to change a playbook's team, bypassing manage members restriction via PUT api. Mattermost Advisory ID: MMSA-2025-00552

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.5.0"
            },
            {
              "fixed": "11.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0"
            },
            {
              "fixed": "10.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-plugin-playbooks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.41.1-0.20260213020129-e1d6ec2c94e6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-01T15:19:14Z",
    "nvd_published_at": "2026-05-18T09:16:22Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 11.5.x \u003c= 11.5.1, 10.11.x \u003c= 10.11.13 fail to check if {{team_id}} was being changed when updating playbooks, allowing users with only {{Manage Playbook Configurations}} permission to change a playbook\u0027s team, bypassing manage members restriction via PUT api. Mattermost Advisory ID: MMSA-2025-00552",
  "id": "GHSA-gvg4-jhmr-6j23",
  "modified": "2026-06-01T15:19:14Z",
  "published": "2026-05-18T09:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost-plugin-playbooks/commit/e1d6ec2c94e695fb74e0c0c11c0d45e028bb96f3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost doesn\u0027t check if {{team_id}} was being changed when updating playbooks"
}

GHSA-GVVP-XFG4-2FR6

Vulnerability from github – Published: 2026-02-27 09:30 – Updated: 2026-02-27 09:30
VLAI
Details

n authorization flaw in Foreman's GraphQL API allows low-privileged users to access metadata beyond their assigned permissions. Unlike the REST API, which correctly enforces access controls, the GraphQL endpoint does not apply proper filtering, leading to an authorization bypass.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-9572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-27T08:17:06Z",
    "severity": "MODERATE"
  },
  "details": "n authorization flaw in Foreman\u0027s GraphQL API allows low-privileged users to access metadata beyond their assigned permissions. Unlike the REST API, which correctly enforces access controls, the GraphQL endpoint does not apply proper filtering, leading to an authorization bypass.",
  "id": "GHSA-gvvp-xfg4-2fr6",
  "modified": "2026-02-27T09:30:29Z",
  "published": "2026-02-27T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9572"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21886"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21893"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21894"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21897"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-9572"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2391715"
    },
    {
      "type": "WEB",
      "url": "https://theforeman.org/security.html#2025-9572"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GVVQ-CMX9-RV3J

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

Insufficient access control in the firmware for the Intel(R) 700-series of Ethernet Controllers before version 8.0 may allow a privileged user to potentially enable denial of service via local access.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-24493"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-17T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient access control in the firmware for the Intel(R) 700-series of Ethernet Controllers before version 8.0 may allow a privileged user to potentially enable denial of service via local access.",
  "id": "GHSA-gvvq-cmx9-rv3j",
  "modified": "2022-05-24T17:42:29Z",
  "published": "2022-05-24T17:42:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24493"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00456.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GW29-86RQ-2225

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

An issue found in Facemoji Emoji Keyboard v.2.9.1.2 for Android allows unauthorized apps to cause escalation of privilege attacks by manipulating the component.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-29752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-09T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "An issue found in Facemoji Emoji Keyboard v.2.9.1.2 for Android allows unauthorized apps to cause escalation of privilege attacks by manipulating the component.",
  "id": "GHSA-gw29-86rq-2225",
  "modified": "2024-04-04T04:42:44Z",
  "published": "2023-06-09T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29752"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LianKee/SO-CVEs/blob/main/CVEs/CVE-2023-29752/CVE%20detailed.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "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.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list