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.

7209 vulnerabilities reference this CWE, most recent first.

GHSA-JQ9F-GM9W-RWM9

Vulnerability from github – Published: 2026-02-05 21:46 – Updated: 2026-02-06 19:07
VLAI
Summary
OpenFGA Improper Policy Enforcement
Details

Impact

OpenFGA v1.8.5 to v1.11.2 ( openfga-0.2.22 <= Helm chart <= openfga-0.2.51, v.1.8.5 <= docker <= v.1.11.2) are vulnerable to improper policy enforcement when certain Check calls are executed.

Affected Users

Users are affected by this vulnerability if all of the following preconditions are met: - OpenFGA v1.8.5 to v1.11.2 is being used - The model has a relation directly assignable by a type bound public access and assignable by type bound non-public access - A tuple is assigned for the relation that is a type bound public access - A tuple is assigned for the same object with the same relation that is not type bound public access - A tuple is assigned for a different object that has an object ID lexicographically larger with the same user and relation which is not type bound public access

Fix

Upgrade to v1.11.3. This upgrade is backwards compatible.

Workaround

None

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.5"
            },
            {
              "fixed": "1.11.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-05T21:46:41Z",
    "nvd_published_at": "2026-02-06T18:15:58Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nOpenFGA v1.8.5 to v1.11.2 ( openfga-0.2.22 \u003c= Helm chart \u003c= openfga-0.2.51, v.1.8.5 \u003c= docker \u003c= v.1.11.2) are vulnerable to improper policy enforcement when certain Check calls are executed.\n\n\n### Affected Users\nUsers are affected by this vulnerability if all of the following preconditions are met:\n- OpenFGA v1.8.5 to v1.11.2 is being used\n- The model has a relation directly assignable by a [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and assignable by type bound non-public access\n- A tuple is assigned for the relation that is a type bound public access\n- A tuple is assigned for the same object with the same relation that is not type bound public access\n- A tuple is assigned for a different object that has an object ID lexicographically larger with the same user and relation which is not type bound public access\n\n\n### Fix\nUpgrade to v1.11.3. This upgrade is backwards compatible.\n\n### Workaround\nNone",
  "id": "GHSA-jq9f-gm9w-rwm9",
  "modified": "2026-02-06T19:07:06Z",
  "published": "2026-02-05T21:46:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-jq9f-gm9w-rwm9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24851"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/commit/1bb5eddf4a3d2fc718aab7914b8f9a1200d2f7ee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/releases/tag/v1.11.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenFGA Improper Policy Enforcement"
}

GHSA-JQF5-5C3V-WJ97

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

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Due to improper verification of permissions, an unauthorized user can access a private repository within a public project.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13303"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-15T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Due to improper verification of permissions, an unauthorized user can access a private repository within a public project.",
  "id": "GHSA-jqf5-5c3v-wj97",
  "modified": "2022-05-24T17:28:16Z",
  "published": "2022-05-24T17:28:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13303"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/962231"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13303.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/238887"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JQH7-3F4J-WVMX

Vulnerability from github – Published: 2026-10-12 15:32 – Updated: 2026-10-12 15:32
VLAI
Details

jshERP through 3.6 contains an incorrect authorization vulnerability in GET /supplier/exportExcel that allows authenticated users to bypass role data scope restrictions enforced by /supplier/list. Attackers restricted to personal or department data can export every supplier, customer and member record, exposing contacts, phone numbers, tax numbers, bank accounts and balances.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-109182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-12T13:17:31Z",
    "severity": "MODERATE"
  },
  "details": "jshERP through 3.6 contains an incorrect authorization vulnerability in GET /supplier/exportExcel that allows authenticated users to bypass role data scope restrictions enforced by /supplier/list. Attackers restricted to personal or department data can export every supplier, customer and member record, exposing contacts, phone numbers, tax numbers, bank accounts and balances.",
  "id": "GHSA-jqh7-3f4j-wvmx",
  "modified": "2026-10-12T15:32:14Z",
  "published": "2026-10-12T15:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109182"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/jshERP/poc_supplier_partner_scope_bypass.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jishenghua/jshERP/blob/8f28e7c2fe54d54de3621a414f5df1833dc5a55f/jshERP-boot/src/main/java/com/jsh/erp/controller/SupplierController.java#L488-L501"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jishenghua/jshERP/blob/8f28e7c2fe54d54de3621a414f5df1833dc5a55f/jshERP-boot/src/main/java/com/jsh/erp/service/SupplierService.java#L400-L408"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jishenghua/jshERP/blob/8f28e7c2fe54d54de3621a414f5df1833dc5a55f/jshERP-boot/src/main/java/com/jsh/erp/service/SupplierService.java#L92-L96"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/jsherp-through-3.6-incorrect-authorization-via-supplier-exportexcel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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"
    }
  ]
}

GHSA-JQH9-6GQV-P52M

Vulnerability from github – Published: 2026-08-29 00:30 – Updated: 2026-08-29 00:30
VLAI
Details

The getgrav/grav-plugin-api plugin before 1.0.18 does not enforce API-key scope in the requireNotSuperTarget() function in UsersController.php across seven sensitive user-management endpoints. The check uses isSuperAdmin() on the acting account rather than verifying whether the specific API key carries super authority (via isSuperWithinScope()). As a result, an API key scoped below full super authority but belonging to a super-admin account can act against other super-admin accounts—disabling their 2FA, deleting their avatar, minting new API keys under their identity, or deleting their existing API keys.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-80203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-26T11:16:39Z",
    "severity": "CRITICAL"
  },
  "details": "The getgrav/grav-plugin-api plugin before 1.0.18 does not enforce API-key scope in the requireNotSuperTarget() function in UsersController.php across seven sensitive user-management endpoints. The check uses isSuperAdmin() on the acting account rather than verifying whether the specific API key carries super authority (via isSuperWithinScope()). As a result, an API key scoped below full super authority but belonging to a super-admin account can act against other super-admin accounts\u2014disabling their 2FA, deleting their avatar, minting new API keys under their identity, or deleting their existing API keys.",
  "id": "GHSA-jqh9-6gqv-p52m",
  "modified": "2026-08-29T00:30:56Z",
  "published": "2026-08-29T00:30:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-94q7-vrqr-cx5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80203"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-before-1.0.18-authentication-bypass-via-scoped-api-key"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-JQPF-VJ28-9V7R

Vulnerability from github – Published: 2026-03-19 03:30 – Updated: 2026-03-20 13:55
Withdrawn 2026-03-20 VLAI
Summary
Duplicate Advisory: Synology Chat dmPolicy=allowlist failed open on empty allowedUserIds, allowing unauthorized agent dispatch
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-gw85-xp4q-5gp9. This link is maintained to preserve external references.

Original Description

OpenClaw versions 2026.2.22 and 2026.2.23 contain an authorization bypass vulnerability in the synology-chat channel plugin where dmPolicy set to allowlist with empty allowedUserIds fails open. Attackers with Synology sender access can bypass authorization checks and trigger unauthorized agent dispatch and downstream tool actions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.2.22"
            },
            {
              "last_affected": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T13:55:52Z",
    "nvd_published_at": "2026-03-19T02:16:05Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-gw85-xp4q-5gp9. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw versions 2026.2.22 and 2026.2.23 contain an authorization bypass vulnerability in the synology-chat channel plugin where dmPolicy set to allowlist with empty allowedUserIds fails open. Attackers with Synology sender access can bypass authorization checks and trigger unauthorized agent dispatch and downstream tool actions.",
  "id": "GHSA-jqpf-vj28-9v7r",
  "modified": "2026-03-20T13:55:52Z",
  "published": "2026-03-19T03:30:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gw85-xp4q-5gp9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31998"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0ee30361b8f6ef3f110f3a7b001da6dd3df96bb5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/7655c0cb3a47d0647cbbf5284e177f90b4b82ddb"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-in-synology-chat-plugin-via-empty-alloweduserids"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:L/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": "Duplicate Advisory: Synology Chat dmPolicy=allowlist failed open on empty allowedUserIds, allowing unauthorized agent dispatch",
  "withdrawn": "2026-03-20T13:55:52Z"
}

GHSA-JQQW-X8W5-V4HH

Vulnerability from github – Published: 2025-05-22 15:34 – Updated: 2025-05-22 15:34
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions from 18.0 before 18.0.1. In certain circumstances, a user with limited permissions could access Job Data via a crafted GraphQL query.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-1110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1220",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-22T14:16:02Z",
    "severity": "LOW"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 18.0 before 18.0.1. In certain circumstances, a user with limited permissions could access Job Data via a crafted GraphQL query.",
  "id": "GHSA-jqqw-x8w5-v4hh",
  "modified": "2025-05-22T15:34:50Z",
  "published": "2025-05-22T15:34:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1110"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2972576"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/517693"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JQXP-VJX4-H9PV

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

Improper access control vulnerability in RCS call prior to SMR Dec-2022 Release 1 allows local attackers to access RCS incoming call number.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-39903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-08T16:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper access control vulnerability in RCS call prior to SMR Dec-2022 Release 1 allows local attackers to access RCS incoming call number.",
  "id": "GHSA-jqxp-vjx4-h9pv",
  "modified": "2022-12-12T18:30:29Z",
  "published": "2022-12-08T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39903"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JR5R-25MV-WFHM

Vulnerability from github – Published: 2022-07-21 00:00 – Updated: 2022-07-28 00:00
VLAI
Details

An access control issue in Wavlink WN533A8 M33A8.V5030.190716 allows attackers to obtain usernames and passwords via view-source:http://IP_ADDRESS/sysinit.shtml?r=52300 and searching for [logincheck(user);].

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-34046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-20T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An access control issue in Wavlink WN533A8 M33A8.V5030.190716 allows attackers to obtain usernames and passwords via view-source:http://IP_ADDRESS/sysinit.shtml?r=52300 and searching for [logincheck(user);].",
  "id": "GHSA-jr5r-25mv-wfhm",
  "modified": "2022-07-28T00:00:41Z",
  "published": "2022-07-21T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34046"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/18ECQEqZ296LDzZ0wErgqnNfen1jCn0mG/view?usp=sharing"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/167890/Wavlink-WN533A8-Password-Disclosure.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JR5X-6H83-WRXF

Vulnerability from github – Published: 2026-07-21 20:40 – Updated: 2026-07-21 20:40
VLAI
Summary
Gitea: REST API exposes organization membership of private organizations to public
Details

Summary

The endpoint "/orgs/{org}/public_members/{username}" + GET exposes organization membership of public members in a private organization.

PoC

  1. Spin up the nightly container of Gitea.
  2. Perform the default installation.
  3. Register a new user (let's call this user "user1").
  4. Create a new organization with "private" visibility. We will refer to this organization as "user1org".
  5. Make the user "user1" inside the organization visible.
  6. Log out and register a new user ("user2").
  7. Create an access token for "user2" with full access to the API.
  8. Use the endpoint "/orgs/{org}/public_members/{username}" + GET with the correct username of "user1", organization name, and access token of "user2" to query whether "user1" is a member of the organization. The following curl command demonstrates the usage:

curl -X 'GET' \ 'http://localhost:4700/api/v1/orgs/user1org/public_members/user1' \ -H 'accept: application/json' \ -H 'authorization: token '

  1. You will receive status code 204, which leaks the organization membership.

Impact

The vulnerability discloses organization membership. An information that is not accessible via the web app (the organization is hidden, and therefore, the organization membership on the user's profile page is also hidden).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gitea.dev"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58417"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:40:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe endpoint  \"/orgs/{org}/public_members/{username}\" + GET exposes organization membership of public members in a private organization.\n\n### PoC\n\n1. Spin up the nightly container of Gitea.\n2. Perform the default installation.\n3. Register a new user (let\u0027s call this user \"user1\").\n4. Create a new organization with \"private\" visibility. We will refer to this organization as \"user1org\".\n5. Make the user \"user1\" inside the organization visible.\n6. Log out and register a new user (\"user2\").\n7. Create an access token for \"user2\" with full access to the API.\n8. Use the endpoint \"/orgs/{org}/public_members/{username}\" + GET with the correct username of \"user1\", organization name, and access token of \"user2\" to query whether \"user1\" is a member of the organization. The following curl command demonstrates the usage:\n\ncurl -X \u0027GET\u0027 \\\n  \u0027http://localhost:4700/api/v1/orgs/user1org/public_members/user1\u0027 \\\n  -H \u0027accept: application/json\u0027 \\\n  -H \u0027authorization: token \u003cuser2-token\u003e\u0027\n\n9. You will receive status code 204, which leaks the organization membership.\n\n### Impact\n\nThe vulnerability discloses organization membership. An information that is not accessible via the web app (the organization is hidden, and therefore, the organization membership on the user\u0027s profile page is also hidden).",
  "id": "GHSA-jr5x-6h83-wrxf",
  "modified": "2026-07-21T20:40:55Z",
  "published": "2026-07-21T20:40:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-jr5x-6h83-wrxf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38145"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/685b62c60fc595e3612a85f0895471876db56292"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: REST API exposes organization membership of private organizations to public"
}

GHSA-JR6P-8PJJ-MFX6

Vulnerability from github – Published: 2026-07-31 16:53 – Updated: 2026-07-31 16:53
VLAI
Summary
Capsule has an incomplete fix of CVE-2026-22872: TenantResource RawItems and Generators still allow cluster-scoped resource creation (cross-tenant privilege escalation)
Details

Summary

CVE-2026-22872 (GHSA-qjjm-7j9w-pw72) reported that a Tenant Owner could create cluster-scoped resources (e.g. ClusterRole, ValidatingWebhookConfiguration) through a TenantResource, because the controller applies them with its cluster-admin ServiceAccount and SetNamespace is ineffective for cluster-scoped kinds. The v0.13.0 fix added a cluster-scope rejection guard, but only on the NamespacedItems selection path (ResourceReference.LoadResources -> IsNamespacedGVK, error "cluster-scoped kind ... is not allowed"). The RawItems create path — the exact vector the original advisory named — and the Generators path were not given this guard. The vulnerability therefore persists in all releases v0.13.0 through v0.13.7 and on trunk HEAD (8d89d6865d).

Details

TenantResource reconcile flow: - internal/controllers/resources/namespaced.go reconcile() obtains the apply client via loadClient(); by default (impersonation off, no Spec.ServiceAccount) this is the manager client whose SA is bound to cluster-admin (charts/capsule/templates/rbac.yaml:488-501, {fullname}-manager-rolebinding -> roleRef cluster-admin). - Collector.Collect() (collect.go) processes spec.RawItems via handleRawItem and spec.Generators via handleGeneratorItem.

handleRawItem (collect.go:406-425, trunk HEAD — byte-identical to v0.13.0):

tmplString := tpl.FastTemplate(string(item.Raw), opts.Iterator.FastContext)
obj := &unstructured.Unstructured{}
unstructured.UnstructuredJSONScheme.Decode([]byte(tmplString), nil, obj)
if ns != nil { obj.SetNamespace(ns.Name) }   // ONLY mitigation
return obj, nil                                // NO IsNamespacedGVK / allowClusterScoped guard

handleGeneratorItem (collect.go:382-404) is the same: it only SetNamespaces on rendered objects.

The accumulated objects flow to pkg/api/processor/processor_func.go Reconcile() -> Apply() -> clt.PatchApply(ctx, c, obj, ...) (line 167/378) with no scope check at any point.

By contrast, CollectNamespacedItems (collect.go:308) calls item.LoadResources(..., allowClusterScoped=false), and pkg/template/reference.go:105-107 enforces:

if !allowClusterScoped && !isNamespaced {
    return nil, fmt.Errorf("cluster-scoped kind %s/%s is not allowed", ...)
}

So the guard the fix added is real, but it sits on a different (selection) path than the one the CVE described (RawItems create path). For cluster-scoped kinds, SetNamespace is ignored by the Kubernetes API server, so the object is created cluster-wide by the cluster-admin client.

Parent-fix diff confirmation: in v0.12.4 the RawItems handler in processor.go was the vulnerable code (obj.SetNamespace(ns.Name) then createOrUpdate via r.client). v0.13.0 refactored this into collect.go handleRawItem but left it without the new guard.

Proof of Concept

A self-contained in-process Go test (incompletefix_poc_test.go), run against trunk HEAD with go1.26.4, proves the asymmetry: - TestRawItemPath_NoClusterScopeGuard: feeds a ClusterRole rawItem to handleRawItem -> object returned unchanged, no rejection (PASS). - TestNamespacedItemsPath_HasClusterScopeGuard: feeds the same ClusterRole kind to LoadResources(allowClusterScoped=false) -> rejected with "cluster-scoped kind rbac.authorization.k8s.io/v1/ClusterRole is not allowed" (PASS).

VULNERABLE: RawItems path accepted cluster-scoped rbac.authorization.k8s.io/v1/ClusterRole;
            metadata.namespace="tenant-ns" (ignored by API server for cluster-scoped kinds)
GUARDED:    NamespacedItems path correctly rejected cluster-scoped kind:
            cluster-scoped kind rbac.authorization.k8s.io/v1/ClusterRole is not allowed

End-to-end (cluster) reproduction: 1. Deploy capsule (default Helm) with rbac.resources.create=true (the opt-in that exposes TenantResources to tenant owners; the configuration the original CVE applies to). 2. As a Tenant Owner, create in a tenant namespace: yaml apiVersion: capsule.clastix.io/v1beta2 kind: TenantResource metadata: {name: pwn, namespace: <tenant-ns>} spec: resources: - namespaceSelector: {matchLabels: {capsule.clastix.io/tenant: <tenant>}} rawItems: - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: {name: tenant-escalation} rules: [{apiGroups: ["*"], resources: ["*"], verbs: ["*"]}] 3. Observe the cluster-scoped ClusterRole tenant-escalation is created by the cluster-admin controller, despite the tenant owner lacking cluster RBAC to create it. Swap in ValidatingWebhookConfiguration to intercept/exfiltrate cluster-wide Secrets.

Impact

A Tenant Owner (namespace-scoped) escalates to cluster-admin-equivalent privileges and can compromise all tenants and the cluster control plane. Identical impact to CVE-2026-22872; the v0.13.0 remediation does not close the RawItems/Generators vector.

Remediation

Apply the same IsNamespacedGVK / allowClusterScoped rejection inside handleRawItem and handleGeneratorItem — or centrally in Collector.AddToAccumulation / processor.Apply — so the create path enforces the same cluster-scope policy as the selection path. (GlobalTenantResource shares the path but is not a privesc — cluster-admin-only to create.)

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.13.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcapsule/capsule"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13.0"
            },
            {
              "fixed": "0.13.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-65835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T16:53:42Z",
    "nvd_published_at": "2026-07-30T20:18:13Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nCVE-2026-22872 (GHSA-qjjm-7j9w-pw72) reported that a Tenant Owner could create cluster-scoped resources\n(e.g. `ClusterRole`, `ValidatingWebhookConfiguration`) through a `TenantResource`, because the controller\napplies them with its cluster-admin ServiceAccount and `SetNamespace` is ineffective for cluster-scoped\nkinds. The v0.13.0 fix added a cluster-scope rejection guard, but **only on the NamespacedItems selection\npath** (`ResourceReference.LoadResources` -\u003e `IsNamespacedGVK`, error `\"cluster-scoped kind ... is not\nallowed\"`). The **RawItems create path \u2014 the exact vector the original advisory named \u2014 and the Generators\npath were not given this guard.** The vulnerability therefore persists in all releases **v0.13.0 through\nv0.13.7** and on trunk HEAD (`8d89d6865d`).\n\n### Details\nTenantResource reconcile flow:\n- `internal/controllers/resources/namespaced.go` `reconcile()` obtains the apply client via `loadClient()`;\n  by default (impersonation off, no `Spec.ServiceAccount`) this is the manager client whose SA is bound to\n  cluster-admin (`charts/capsule/templates/rbac.yaml:488-501`, `{fullname}-manager-rolebinding` -\u003e\n  roleRef cluster-admin).\n- `Collector.Collect()` (`collect.go`) processes `spec.RawItems` via `handleRawItem` and `spec.Generators`\n  via `handleGeneratorItem`.\n\n`handleRawItem` (`collect.go:406-425`, trunk HEAD \u2014 byte-identical to v0.13.0):\n```go\ntmplString := tpl.FastTemplate(string(item.Raw), opts.Iterator.FastContext)\nobj := \u0026unstructured.Unstructured{}\nunstructured.UnstructuredJSONScheme.Decode([]byte(tmplString), nil, obj)\nif ns != nil { obj.SetNamespace(ns.Name) }   // ONLY mitigation\nreturn obj, nil                                // NO IsNamespacedGVK / allowClusterScoped guard\n```\n`handleGeneratorItem` (`collect.go:382-404`) is the same: it only `SetNamespace`s on rendered objects.\n\nThe accumulated objects flow to `pkg/api/processor/processor_func.go` `Reconcile()` -\u003e `Apply()` -\u003e\n`clt.PatchApply(ctx, c, obj, ...)` (line 167/378) with **no scope check at any point**.\n\nBy contrast, `CollectNamespacedItems` (`collect.go:308`) calls `item.LoadResources(..., allowClusterScoped=false)`,\nand `pkg/template/reference.go:105-107` enforces:\n```go\nif !allowClusterScoped \u0026\u0026 !isNamespaced {\n    return nil, fmt.Errorf(\"cluster-scoped kind %s/%s is not allowed\", ...)\n}\n```\nSo the guard the fix added is real, but it sits on a different (selection) path than the one the CVE\ndescribed (RawItems create path). For cluster-scoped kinds, `SetNamespace` is ignored by the Kubernetes API\nserver, so the object is created cluster-wide by the cluster-admin client.\n\n**Parent-fix diff confirmation:** in v0.12.4 the RawItems handler in `processor.go` was the vulnerable code\n(`obj.SetNamespace(ns.Name)` then `createOrUpdate` via `r.client`). v0.13.0 refactored this into\n`collect.go` `handleRawItem` but left it without the new guard.\n\n### Proof of Concept\nA self-contained in-process Go test (`incompletefix_poc_test.go`), run against trunk HEAD with go1.26.4,\nproves the asymmetry:\n- `TestRawItemPath_NoClusterScopeGuard`: feeds a `ClusterRole` rawItem to `handleRawItem` -\u003e object returned\n  unchanged, no rejection (PASS).\n- `TestNamespacedItemsPath_HasClusterScopeGuard`: feeds the same `ClusterRole` kind to\n  `LoadResources(allowClusterScoped=false)` -\u003e rejected with\n  `\"cluster-scoped kind rbac.authorization.k8s.io/v1/ClusterRole is not allowed\"` (PASS).\n\n```\nVULNERABLE: RawItems path accepted cluster-scoped rbac.authorization.k8s.io/v1/ClusterRole;\n            metadata.namespace=\"tenant-ns\" (ignored by API server for cluster-scoped kinds)\nGUARDED:    NamespacedItems path correctly rejected cluster-scoped kind:\n            cluster-scoped kind rbac.authorization.k8s.io/v1/ClusterRole is not allowed\n```\n\nEnd-to-end (cluster) reproduction:\n1. Deploy capsule (default Helm) with `rbac.resources.create=true` (the opt-in that exposes TenantResources\n   to tenant owners; the configuration the original CVE applies to).\n2. As a Tenant Owner, create in a tenant namespace:\n   ```yaml\n   apiVersion: capsule.clastix.io/v1beta2\n   kind: TenantResource\n   metadata: {name: pwn, namespace: \u003ctenant-ns\u003e}\n   spec:\n     resources:\n       - namespaceSelector: {matchLabels: {capsule.clastix.io/tenant: \u003ctenant\u003e}}\n         rawItems:\n           - apiVersion: rbac.authorization.k8s.io/v1\n             kind: ClusterRole\n             metadata: {name: tenant-escalation}\n             rules: [{apiGroups: [\"*\"], resources: [\"*\"], verbs: [\"*\"]}]\n   ```\n3. Observe the cluster-scoped ClusterRole `tenant-escalation` is created by the cluster-admin controller,\n   despite the tenant owner lacking cluster RBAC to create it. Swap in `ValidatingWebhookConfiguration`\n   to intercept/exfiltrate cluster-wide Secrets.\n\n### Impact\nA Tenant Owner (namespace-scoped) escalates to cluster-admin-equivalent privileges and can compromise all\ntenants and the cluster control plane. Identical impact to CVE-2026-22872; the v0.13.0 remediation does not\nclose the RawItems/Generators vector.\n\n### Remediation\nApply the same `IsNamespacedGVK` / `allowClusterScoped` rejection inside `handleRawItem` and\n`handleGeneratorItem` \u2014 or centrally in `Collector.AddToAccumulation` / `processor.Apply` \u2014 so the create\npath enforces the same cluster-scope policy as the selection path. (`GlobalTenantResource` shares the path\nbut is not a privesc \u2014 cluster-admin-only to create.)",
  "id": "GHSA-jr6p-8pjj-mfx6",
  "modified": "2026-07-31T16:53:42Z",
  "published": "2026-07-31T16:53:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-jr6p-8pjj-mfx6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65835"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/projectcapsule/capsule"
    },
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Capsule has an incomplete fix of CVE-2026-22872: TenantResource RawItems and Generators still allow cluster-scoped resource creation (cross-tenant privilege escalation)"
}
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