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.

5660 vulnerabilities reference this CWE, most recent first.

GHSA-667W-MMH7-MRR4

Vulnerability from github – Published: 2026-03-10 18:16 – Updated: 2026-03-10 18:45
VLAI
Summary
StudioCMS has Privilege Escalation via Insecure API Token Generation
Details

Summary

The /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation.

Details

The API token generation endpoint accepts a user parameter in the request body that specifies which user the token should be created for. The server-side logic authenticates the session (via auth_session cookie) but does not verify that the authenticated user matches the target user ID nor checks if the caller has sufficient privileges to perform this action on behalf of another user. This is a classic BOLA vulnerability: the authorization check is limited to "is the user logged in?" instead of "is this user authorized to perform this action on this specific resource?"

Vulnerable Code

The following is the server-side handler for the POST /studiocms_api/dashboard/api-tokens endpoint: File: packages/studiocms/frontend/pages/studiocms_api/dashboard/api-tokens.ts (lines 16–57) Version: studiocms@0.3.0

POST: (ctx) =>
    genLogger('studiocms/routes/api/dashboard/api-tokens.POST')(function* () {
        const sdk = yield* SDKCore;

        // Check if demo mode is enabled
        if (developerConfig.demoMode !== false) {
            return apiResponseLogger(403, 'Demo mode is enabled, this action is not allowed.');
        }

        // Get user data
        const userData = ctx.locals.StudioCMS.security?.userSessionData;       // [1]

        // Check if user is logged in
        if (!userData?.isLoggedIn) {                                            // [2]
            return apiResponseLogger(403, 'Unauthorized');
        }

        // Check if user has permission
        const isAuthorized = ctx.locals.StudioCMS.security?.userPermissionLevel.isEditor;  // [3]
        if (!isAuthorized) {
            return apiResponseLogger(403, 'Unauthorized');
        }

        // Get Json Data
        const jsonData = yield* readAPIContextJson<{
            description: string;
            user: string;                                                       // [4]
        }>(ctx);

        // Validate form data
        if (!jsonData.description) {
            return apiResponseLogger(400, 'Invalid form data, description is required');
        }

        if (!jsonData.user) {
            return apiResponseLogger(400, 'Invalid form data, user is required');
        }

        // [5] jsonData.user passed directly — no check against userData
        const newToken = yield* sdk.REST_API.tokens.new(jsonData.user, jsonData.description);

        return createJsonResponse({ token: newToken.key });                     // [6]
    }),

Analysis The authorization logic has three distinct flaws: 1. Insufficient permission gate [1][2][3]: The handler retrieves the session from ctx.locals.StudioCMS.security and only verifies that isEditor is true. This means any user with editor privileges or above passes the gate. 2. Missing object-level authorization [4][5]: The user field from the JSON payload (line 54) is passed directly to sdk.REST_API.tokens.new() without any comparison against userData (the authenticated caller's identity from the session at [1]). There is no check such as jsonData.user === userData.id. This allows any authenticated user to specify an arbitrary target UUID and generate a token for that account. 3. No target role validation [5]: Even if cross-user token generation were an intended feature, there is no check to prevent a lower-privileged user from generating tokens for higher-privileged accounts (admin, owner).

PoC

Environment The following user roles were identified in the application: User ID | Role 2450bf33-0135-4142-80be-9854f9a5e9f1 | owner eacee42e-ae7e-4e9e-945b-68e26696ece4 | admin 2d93a386-e9cb-451e-a811-d8a34bfdf4da | admin 39b3e7d3-5eb0-48e1-abdc-ce95a57b212c | editor a1585423-9ade-426e-a713-9c81ed035463 | visitor

Step 1 — Generate an API Token for the Owner (as Editor) An authenticated Editor sends the following request, specifying the owner user ID in the body:

POST /studiocms_api/dashboard/api-tokens HTTP/1.1
Host: <target>
Cookie: auth_session=<editor_session_cookie>
Content-Type: application/json
Content-Length: 74

{
  "user": "2450bf33-0135-4142-80be-9854f9a5e9f1",
  "description": "pwn"
}

Result: The server returns a valid JWT token bound to the owner account.

Step 2 — Use the Token to Access the API as Owner

curl -H "Authorization: Bearer <owner_jwt_token>" http://<target>/studiocms_api/rest/v1/users

Result: The attacker now has full API access with owner privileges, including the ability to list all users, modify content, and manage the application.

Impact

  • Privilege Escalation: Any authenticated user (above visitor) can escalate to owner level access.
  • Full API Access: The generated token grants unrestricted access to all REST API endpoints with the impersonated user's permissions.
  • Account Takeover: An attacker can impersonate any user in the system by specifying their UUID.
  • Data Breach: Access to user listings, content management, and potentially sensitive configuration data.
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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "studiocms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-10T18:16:41Z",
    "nvd_published_at": "2026-03-10T18:18:54Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nThe /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation.\n\n## Details\nThe API token generation endpoint accepts a user parameter in the request body that specifies which user the token should be created for. The server-side logic authenticates the session (via auth_session cookie) but does not verify that the authenticated user matches the target user ID nor checks if the caller has sufficient privileges to perform this action on behalf of another user.\nThis is a classic BOLA vulnerability: the authorization check is limited to \"is the user logged in?\" instead of \"is this user authorized to perform this action on this specific resource?\"\n\n#### Vulnerable Code\nThe following is the server-side handler for the POST /studiocms_api/dashboard/api-tokens endpoint:\n**File:** packages/studiocms/frontend/pages/studiocms_api/dashboard/api-tokens.ts (lines 16\u201357)\n**Version:** studiocms@0.3.0\n```\nPOST: (ctx) =\u003e\n    genLogger(\u0027studiocms/routes/api/dashboard/api-tokens.POST\u0027)(function* () {\n        const sdk = yield* SDKCore;\n\n        // Check if demo mode is enabled\n        if (developerConfig.demoMode !== false) {\n            return apiResponseLogger(403, \u0027Demo mode is enabled, this action is not allowed.\u0027);\n        }\n\n        // Get user data\n        const userData = ctx.locals.StudioCMS.security?.userSessionData;       // [1]\n\n        // Check if user is logged in\n        if (!userData?.isLoggedIn) {                                            // [2]\n            return apiResponseLogger(403, \u0027Unauthorized\u0027);\n        }\n\n        // Check if user has permission\n        const isAuthorized = ctx.locals.StudioCMS.security?.userPermissionLevel.isEditor;  // [3]\n        if (!isAuthorized) {\n            return apiResponseLogger(403, \u0027Unauthorized\u0027);\n        }\n\n        // Get Json Data\n        const jsonData = yield* readAPIContextJson\u003c{\n            description: string;\n            user: string;                                                       // [4]\n        }\u003e(ctx);\n\n        // Validate form data\n        if (!jsonData.description) {\n            return apiResponseLogger(400, \u0027Invalid form data, description is required\u0027);\n        }\n\n        if (!jsonData.user) {\n            return apiResponseLogger(400, \u0027Invalid form data, user is required\u0027);\n        }\n\n        // [5] jsonData.user passed directly \u2014 no check against userData\n        const newToken = yield* sdk.REST_API.tokens.new(jsonData.user, jsonData.description);\n\n        return createJsonResponse({ token: newToken.key });                     // [6]\n    }),\n```\n**Analysis**\nThe authorization logic has three distinct flaws:\n1. **Insufficient permission gate [1][2][3]:** The handler retrieves the session from ctx.locals.StudioCMS.security and only verifies that isEditor is true. This means any user with editor privileges or above passes the gate. \n2. **Missing object-level authorization [4][5]:** The user field from the JSON payload (line 54) is passed directly to sdk.REST_API.tokens.new() without any comparison against userData (the authenticated caller\u0027s identity from the session at [1]). There is no check such as jsonData.user === userData.id. This allows any authenticated user to specify an arbitrary target UUID and generate a token for that account.\n3. **No target role validation [5]:** Even if cross-user token generation were an intended feature, there is no check to prevent a lower-privileged user from generating tokens for higher-privileged accounts (admin, owner).\n\n## PoC\n**Environment**\nThe following user roles were identified in the application:\n*User ID | Role*\n2450bf33-0135-4142-80be-9854f9a5e9f1 | owner\neacee42e-ae7e-4e9e-945b-68e26696ece4 | admin\n2d93a386-e9cb-451e-a811-d8a34bfdf4da | admin\n39b3e7d3-5eb0-48e1-abdc-ce95a57b212c | editor\na1585423-9ade-426e-a713-9c81ed035463 | visitor\n\n**Step 1 \u2014 Generate an API Token for the Owner (as Editor)**\nAn authenticated Editor sends the following request, specifying the owner user ID in the body:\n```\nPOST /studiocms_api/dashboard/api-tokens HTTP/1.1\nHost: \u003ctarget\u003e\nCookie: auth_session=\u003ceditor_session_cookie\u003e\nContent-Type: application/json\nContent-Length: 74\n\n{\n  \"user\": \"2450bf33-0135-4142-80be-9854f9a5e9f1\",\n  \"description\": \"pwn\"\n}\n```\n**Result:** The server returns a valid JWT token bound to the owner account.\n\n**Step 2 \u2014 Use the Token to Access the API as Owner**\n```\ncurl -H \"Authorization: Bearer \u003cowner_jwt_token\u003e\" http://\u003ctarget\u003e/studiocms_api/rest/v1/users\n```\n**Result:** The attacker now has full API access with owner privileges, including the ability to list all users, modify content, and manage the application.\n\n## Impact\n- **Privilege Escalation:** Any authenticated user (above visitor) can escalate to owner level access.\n- **Full API Access:** The generated token grants unrestricted access to all REST API endpoints with the impersonated user\u0027s permissions.\n- **Account Takeover:** An attacker can impersonate any user in the system by specifying their UUID.\n- **Data Breach:** Access to user listings, content management, and potentially sensitive configuration data.",
  "id": "GHSA-667w-mmh7-mrr4",
  "modified": "2026-03-10T18:45:47Z",
  "published": "2026-03-10T18:16:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-667w-mmh7-mrr4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30944"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/commit/9eec9c3b45523b635cfe16d55aa55afabacbebe3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/commit/f4a209fc090c90195e2419fff47b48a46eab7441"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withstudiocms/studiocms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms%400.4.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.0"
    }
  ],
  "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"
    }
  ],
  "summary": "StudioCMS has Privilege Escalation via Insecure API Token Generation"
}

GHSA-668G-WR24-468V

Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-05-18 09:31
VLAI
Details

Mattermost Plugins versions <=11.5 11.1.5 10.13.11 11.3.4.0 fail to have API-level checks on which groups the user can create issues or attach comments to which allows a user that is member of multiple groups to create issues to a locked group via direct API requests. Mattermost Advisory ID: MMSA-2026-00602

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-2026-6341"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-18T08:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost Plugins versions \u003c=11.5 11.1.5 10.13.11 11.3.4.0 fail to have API-level checks on which groups the user can create issues or attach comments to which allows a user that is member of multiple groups to create issues to a locked group via direct API requests. Mattermost Advisory ID: MMSA-2026-00602",
  "id": "GHSA-668g-wr24-468v",
  "modified": "2026-05-18T09:31:48Z",
  "published": "2026-05-18T09:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6341"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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-668Q-R655-W2WJ

Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32
VLAI
Details

Animate is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction. Scope is changed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T20:17:08Z",
    "severity": "HIGH"
  },
  "details": "Animate is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploit depends on conditions beyond the attacker\u0027s control. Exploitation of this issue does not require user interaction. Scope is changed.",
  "id": "GHSA-668q-r655-w2wj",
  "modified": "2026-07-14T21:32:19Z",
  "published": "2026-07-14T21:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48349"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/animate/apsb26-83.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-668X-35FF-63G9

Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-07-13 00:01
VLAI
Details

Disclosure of sensitive information to an unauthorized user vulnerability in Buffalo broadband routers (BHR-4GRV firmware Ver.1.99 and prior, DWR-HP-G300NH firmware Ver.1.83 and prior, HW-450HP-ZWE firmware Ver.1.99 and prior, WHR-300HP firmware Ver.1.99 and prior, WHR-300 firmware Ver.1.99 and prior, WHR-G301N firmware Ver.1.86 and prior, WHR-HP-G300N firmware Ver.1.99 and prior, WHR-HP-GN firmware Ver.1.86 and prior, WPL-05G300 firmware Ver.1.87 and prior, WZR-450HP-CWT firmware Ver.1.99 and prior, WZR-450HP-UB firmware Ver.1.99 and prior, WZR-HP-AG300H firmware Ver.1.75 and prior, WZR-HP-G300NH firmware Ver.1.83 and prior, WZR-HP-G301NH firmware Ver.1.83 and prior, WZR-HP-G302H firmware Ver.1.85 and prior, WZR-HP-G450H firmware Ver.1.89 and prior, WZR-300HP firmware Ver.1.99 and prior, WZR-450HP firmware Ver.1.99 and prior, WZR-600DHP firmware Ver.1.99 and prior, WZR-D1100H firmware Ver.1.99 and prior, FS-HP-G300N firmware Ver.3.32 and prior, FS-600DHP firmware Ver.3.38 and prior, FS-R600DHP firmware Ver.3.39 and prior, and FS-G300N firmware Ver.3.13 and prior) allows remote unauthenticated attackers to obtain information such as configuration via unspecified vectors.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-3511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-28T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Disclosure of sensitive information to an unauthorized user vulnerability in Buffalo broadband routers (BHR-4GRV firmware Ver.1.99 and prior, DWR-HP-G300NH firmware Ver.1.83 and prior, HW-450HP-ZWE firmware Ver.1.99 and prior, WHR-300HP firmware Ver.1.99 and prior, WHR-300 firmware Ver.1.99 and prior, WHR-G301N firmware Ver.1.86 and prior, WHR-HP-G300N firmware Ver.1.99 and prior, WHR-HP-GN firmware Ver.1.86 and prior, WPL-05G300 firmware Ver.1.87 and prior, WZR-450HP-CWT firmware Ver.1.99 and prior, WZR-450HP-UB firmware Ver.1.99 and prior, WZR-HP-AG300H firmware Ver.1.75 and prior, WZR-HP-G300NH firmware Ver.1.83 and prior, WZR-HP-G301NH firmware Ver.1.83 and prior, WZR-HP-G302H firmware Ver.1.85 and prior, WZR-HP-G450H firmware Ver.1.89 and prior, WZR-300HP firmware Ver.1.99 and prior, WZR-450HP firmware Ver.1.99 and prior, WZR-600DHP firmware Ver.1.99 and prior, WZR-D1100H firmware Ver.1.99 and prior, FS-HP-G300N firmware Ver.3.32 and prior, FS-600DHP firmware Ver.3.38 and prior, FS-R600DHP firmware Ver.3.39 and prior, and FS-G300N firmware Ver.3.13 and prior) allows remote unauthenticated attackers to obtain information such as configuration via unspecified vectors.",
  "id": "GHSA-668x-35ff-63g9",
  "modified": "2022-07-13T00:01:27Z",
  "published": "2022-05-24T17:49:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3511"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU99235714/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.buffalo.jp/news/detail/20210427-01.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-66C6-XH5V-573Q

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

Improper Authorization vulnerability of Pepperl+Fuchs P+F Comtrol RocketLinx ES7510-XT, ES8509-XT, ES8510-XT, ES9528-XTv2, ES7506, ES7510, ES7528, ES8508, ES8508F, ES8510, ES8510-XTE, ES9528/ES9528-XT (all versions) and ICRL-M-8RJ45/4SFP-G-DIN, ICRL-M-16RJ45/4CP-G-DIN FW 1.2.3 and below has an active TFTP-Service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-12504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863",
      "CWE-912"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-15T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Authorization vulnerability of Pepperl+Fuchs P+F Comtrol RocketLinx ES7510-XT, ES8509-XT, ES8510-XT, ES9528-XTv2, ES7506, ES7510, ES7528, ES8508, ES8508F, ES8510, ES8510-XTE, ES9528/ES9528-XT (all versions) and ICRL-M-8RJ45/4SFP-G-DIN, ICRL-M-16RJ45/4CP-G-DIN FW 1.2.3 and below has an active TFTP-Service.",
  "id": "GHSA-66c6-xh5v-573q",
  "modified": "2022-05-24T17:30:44Z",
  "published": "2022-05-24T17:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12504"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.com/de-de/advisories/vde-2020-040"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.com/en-us/advisories/vde-2020-053"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/vulnerability-lab/advisory/multiple-critical-vulnerabilities-in-korenix-technology-westermo-pepperl-fuchs"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/162903/Korenix-CSRF-Backdoor-Accounts-Command-Injection-Missing-Authentication.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/165875/Korenix-Technology-JetWave-CSRF-Command-Injection-Missing-Authentication.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Jun/0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-66M4-5JJR-2RG5

Vulnerability from github – Published: 2026-07-21 20:11 – Updated: 2026-07-21 20:11
VLAI
Summary
Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content
Details

Affected product

Gitea — services/repository/collaboration.go (DeleteCollaboration) + webhook delivery

Summary

When a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing after the collaborator's access is revoked. Gitea's revocation cleanup DeleteCollaboration removes the collaboration record, recalculates accesses, drops watches, and unassigns issues — but it does not remove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still has repo access. The former collaborator therefore receives the full payload (issue/comment bodies, commit data) of all future repository events at their controlled endpoint, indefinitely and invisibly.

Affected code

  • services/repository/collaboration.go → DeleteCollaboration() — cleans watches/assignees only; no webhook cleanup.
  • Webhook delivery path — fires on repo events without re-validating the creator's current access.

Steps to reproduce

Using the provided reproduction materials: 1. Attacker (admin collaborator) creates a webhook → revoke access. 2. Control: GET /api/v1/repos/admin/wh-repo (attacker) → 404. 3. GET .../hooks → webhook still active=true. 4. Admin creates a new issue after revocation → the catcher receives action:"opened", issue.title:"CRITICAL SECRET: …", issue.body (sentinel private key), repository.private:true. (Runtime-confirmed on gitea/gitea:1.25.4. Catcher is an internal sentinel listener; the payload is a planted sentinel, not real data; nothing is sent to any external/metadata endpoint.)

Impact

Authenticated former admin-collaborator → ongoing real-time exfiltration of private content created after revocation; invisible to the owner; scope crosses from the application boundary to data the user should no longer access.

Suggested remediation

  1. On revocation, delete/disable webhooks created by the removed collaborator (or hand them to the owner).
  2. Re-validate the creator's current repo access before each webhook delivery.
  3. At minimum, warn admins on revocation if the user created webhooks.

Credit

Reported as part of an incomplete-patch / authorization-residue measurement study (responsible disclosure).

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A: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-58440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:11:36Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Affected product\nGitea \u2014 `services/repository/collaboration.go` (`DeleteCollaboration`) + webhook delivery\n\n## Summary\nWhen a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing\nafter the collaborator\u0027s access is revoked. Gitea\u0027s revocation cleanup `DeleteCollaboration` removes the\ncollaboration record, recalculates accesses, drops watches, and unassigns issues \u2014 but it does **not**\nremove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still\nhas repo access. The former collaborator therefore receives the full payload (issue/comment bodies, commit\ndata) of all future repository events at their controlled endpoint, indefinitely and invisibly.\n\n## Affected code\n- `services/repository/collaboration.go` \u2192 `DeleteCollaboration()` \u2014 cleans watches/assignees only; no\n  webhook cleanup.\n- Webhook delivery path \u2014 fires on repo events without re-validating the creator\u0027s current access.\n\n## Steps to reproduce\nUsing the provided reproduction materials:\n1. Attacker (admin collaborator) creates a webhook \u2192 revoke access.\n2. Control: `GET /api/v1/repos/admin/wh-repo` (attacker) \u2192 **404**.\n3. `GET .../hooks` \u2192 webhook still `active=true`.\n4. Admin creates a new issue **after** revocation \u2192 the catcher receives `action:\"opened\"`,\n   `issue.title:\"CRITICAL SECRET: \u2026\"`, `issue.body` (sentinel private key), `repository.private:true`.\n(Runtime-confirmed on `gitea/gitea:1.25.4`. Catcher is an internal sentinel listener; the payload is a\nplanted sentinel, not real data; nothing is sent to any external/metadata endpoint.)\n\n## Impact\nAuthenticated former admin-collaborator \u2192 ongoing real-time exfiltration of private content created after\nrevocation; invisible to the owner; scope crosses from the application boundary to data the user should no\nlonger access.\n\n## Suggested remediation\n1. On revocation, delete/disable webhooks created by the removed collaborator (or hand them to the owner).\n2. Re-validate the creator\u0027s current repo access before each webhook delivery.\n3. At minimum, warn admins on revocation if the user created webhooks.\n\n## Credit\nReported as part of an incomplete-patch / authorization-residue measurement study (responsible disclosure).",
  "id": "GHSA-66m4-5jjr-2rg5",
  "modified": "2026-07-21T20:11:36Z",
  "published": "2026-07-21T20:11:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-66m4-5jjr-2rg5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
    },
    {
      "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:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked \u2192 ongoing real-time exfiltration of private repo content"
}

GHSA-66M8-64XR-MVH7

Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-07-13 00:01
VLAI
Details

IBM Cognos Analytics 10.0 and 11.1 is susceptible to a weakness in the implementation of the System Appearance configuration setting. An attacker could potentially bypass business logic to modify the appearance and behavior of the application. IBM X-Force ID: 196770.

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-2021-20461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-30T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics 10.0 and 11.1 is susceptible to a weakness in the implementation of the System Appearance configuration setting. An attacker could potentially bypass business logic to modify the appearance and behavior of the application. IBM X-Force ID: 196770.",
  "id": "GHSA-66m8-64xr-mvh7",
  "modified": "2022-07-13T00:01:04Z",
  "published": "2022-05-24T19:06:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20461"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/196770"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210720-0007"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6466729"
    }
  ],
  "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-66MM-FRQR-R7X4

Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2022-05-13 01:17
VLAI
Details

A vulnerability in the web framework of the Cisco Digital Network Architecture Center (DNA Center) could allow an unauthenticated, remote attacker to communicate with the Kong API server without restriction. The vulnerability is due to an overly permissive Cross Origin Resource Sharing (CORS) policy. An attacker could exploit this vulnerability by convincing a user to follow a malicious link. An exploit could allow the attacker to communicate with the API and exfiltrate sensitive information. Cisco Bug IDs: CSCvh99208.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-0269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-19T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the web framework of the Cisco Digital Network Architecture Center (DNA Center) could allow an unauthenticated, remote attacker to communicate with the Kong API server without restriction. The vulnerability is due to an overly permissive Cross Origin Resource Sharing (CORS) policy. An attacker could exploit this vulnerability by convincing a user to follow a malicious link. An exploit could allow the attacker to communicate with the API and exfiltrate sensitive information. Cisco Bug IDs: CSCvh99208.",
  "id": "GHSA-66mm-frqr-r7x4",
  "modified": "2022-05-13T01:17:27Z",
  "published": "2022-05-13T01:17:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0269"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-dna1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103950"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-66MP-9RFW-XG5X

Vulnerability from github – Published: 2023-02-27 21:30 – Updated: 2023-03-08 18:30
VLAI
Details

A permissions issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.2. An app may be able to access user-sensitive data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-27T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A permissions issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.2. An app may be able to access user-sensitive data.",
  "id": "GHSA-66mp-9rfw-xg5x",
  "modified": "2023-03-08T18:30:26Z",
  "published": "2023-02-27T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23506"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213605"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-66QC-59Q2-VV7V

Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-50085"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-15T20:15:44Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).",
  "id": "GHSA-66qc-59q2-vv7v",
  "modified": "2025-07-15T21:31:41Z",
  "published": "2025-07-15T21:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50085"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/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