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.

7132 vulnerabilities reference this CWE, most recent first.

GHSA-GV5W-HFX8-8CWQ

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

Impact

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

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

Affected component

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

Patches

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

Workarounds

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

References

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

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

GHSA-GV6H-VWG4-8MWR

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

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

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

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

GHSA-GV74-J8M3-FG5F

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

Am I affected?

You are affected if all of the following are true:

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

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

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

Fix:

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

Summary

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

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

Details

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

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

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

Patches

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

Workarounds

If you cannot upgrade immediately:

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

Impact

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

Credit

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

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

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

GHSA-GV7W-JH8G-VR73

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

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

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.portal.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.4.0-ga1"
            },
            {
              "fixed": "7.4.3.110"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62259"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T10:44:39Z",
    "nvd_published_at": "2025-10-27T23:15:38Z",
    "severity": "MODERATE"
  },
  "details": "Liferay Portal 7.4.0 through 7.4.3.109, and older unsupported versions, and Liferay DXP 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not limit access to APIs before a user has verified their email address, which allows remote users to access and edit content via the API.",
  "id": "GHSA-gv7w-jh8g-vr73",
  "modified": "2025-10-29T10:44:39Z",
  "published": "2025-10-28T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62259"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-62259"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Liferay Portal Does Not Limit Access to APIs Before Email Verification"
}

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-GVR7-J885-XJ8M

Vulnerability from github – Published: 2026-09-03 15:32 – Updated: 2026-09-03 15:32
VLAI
Details

Dell PowerProtect Data Manager, versions 20.2.0.0 and below, contain an Incorrect Authorization vulnerability in the REST API. A low privileged remote attacker could potentially exploit this vulnerability, leading to Protection mechanism bypass.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-74769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T13:06:07Z",
    "severity": "MODERATE"
  },
  "details": "Dell PowerProtect Data Manager, versions 20.2.0.0 and below, contain an Incorrect Authorization vulnerability in the REST API. A low privileged remote attacker could potentially exploit this vulnerability, leading to Protection mechanism bypass.",
  "id": "GHSA-gvr7-j885-xj8m",
  "modified": "2026-09-03T15:32:11Z",
  "published": "2026-09-03T15:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74769"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000501452/dsa-2026-368-security-update-for-dell-powerprotect-data-manager-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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