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.

5622 vulnerabilities reference this CWE, most recent first.

GHSA-C9QQ-2XC2-VWCC

Vulnerability from github – Published: 2025-01-21 18:31 – Updated: 2025-01-21 18:31
VLAI
Details

In JetBrains TeamCity before 2024.12.1 improper access control allowed to see Projects’ names in the agent pool

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-24460"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T18:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains TeamCity before 2024.12.1 improper access control allowed to see Projects\u2019 names in the agent pool",
  "id": "GHSA-c9qq-2xc2-vwcc",
  "modified": "2025-01-21T18:31:08Z",
  "published": "2025-01-21T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24460"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "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"
    }
  ]
}

GHSA-C9W5-QP6M-M395

Vulnerability from github – Published: 2026-05-28 18:30 – Updated: 2026-07-09 23:32
VLAI
Summary
Casdoor: GetTokenExchangeToken bypass through lack of cross-organization JWT signature check
Details

Casdoor versions 2.362.0 and earlier contain a vulnerability enabling cross-organization token exchange. The GetTokenExchangeToken function in object/token_oauth.go validates JWT signatures but does not verify that the token's user belongs to the same organization as the target application. This can result in privilege escalation across organizational boundaries.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/casdoor/casdoor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.387.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-9094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T23:32:36Z",
    "nvd_published_at": "2026-05-28T17:16:34Z",
    "severity": "CRITICAL"
  },
  "details": "Casdoor versions 2.362.0 and earlier contain a vulnerability enabling cross-organization token exchange. The GetTokenExchangeToken function in object/token_oauth.go validates JWT signatures but does not verify that the token\u0027s user belongs to the same organization as the target application. This can result in privilege escalation across organizational boundaries.",
  "id": "GHSA-c9w5-qp6m-m395",
  "modified": "2026-07-09T23:32:36Z",
  "published": "2026-05-28T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9094"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casdoor/casdoor/commit/d92b8568686d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/casdoor/casdoor"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/780781"
    }
  ],
  "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"
    }
  ],
  "summary": "Casdoor: GetTokenExchangeToken bypass through lack of cross-organization JWT signature check"
}

GHSA-C9XJ-QGPM-MJ78

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

The Zephyr Project Manager plugin for WordPress is vulnerable to limited privilege escalation in all versions up to, and including, 3.3.101. This is due to the plugin not properly checking a users capabilities before allowing them to enable access to the plugin's settings through the update_user_access() function. This makes it possible for authenticated attackers, with subscriber-level access and above, to grant themselves full access to the plugin's settings.

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": [],
  "aliases": [
    "CVE-2024-7624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-15T03:15:05Z",
    "severity": "HIGH"
  },
  "details": "The Zephyr Project Manager plugin for WordPress is vulnerable to limited privilege escalation in all versions up to, and including, 3.3.101. This is due to the plugin not properly checking a users capabilities before allowing them to enable access to the plugin\u0027s settings through the update_user_access() function. This makes it possible for authenticated attackers, with subscriber-level access and above, to grant themselves full access to the plugin\u0027s settings.",
  "id": "GHSA-c9xj-qgpm-mj78",
  "modified": "2024-08-15T03:30:28Z",
  "published": "2024-08-15T03:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7624"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zephyr-project-manager/trunk/includes/Base/AjaxHandler.php?rev=3111536#L2464"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3134404"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b9ef344d-cd56-43f9-b185-de83a92800de?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-CC3P-6VJW-W26P

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

A security misconfiguration exists in Combodo iTop, which can expose sensitive information.

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-2020-12780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-10T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A security misconfiguration exists in Combodo iTop, which can expose sensitive information.",
  "id": "GHSA-cc3p-6vjw-w26p",
  "modified": "2022-05-24T17:25:10Z",
  "published": "2022-05-24T17:25:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Combodo/iTop/security/advisories/GHSA-97cw-cjxc-9x78"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12780"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-3836-47d6c-1.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-CC3W-R3W8-HFH7

Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2025-02-10 21:02
VLAI
Summary
Magento Improper Authorization vulnerability in the customers module
Details

Magento versions 2.4.2 (and earlier), 2.4.1-p1 (and earlier) and 2.3.6-p1 (and earlier) are vulnerable to an Improper Authorization vulnerability in the customers module. Successful exploitation could allow a low-privileged user to modify customer data. Access to the admin console is required for successful exploitation.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2-p1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-28567"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-11T19:50:56Z",
    "nvd_published_at": "2021-09-08T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Magento versions 2.4.2 (and earlier), 2.4.1-p1 (and earlier) and 2.3.6-p1 (and earlier) are vulnerable to an Improper Authorization vulnerability in the customers module. Successful exploitation could allow a low-privileged user to modify customer data. Access to the admin console is required for successful exploitation.",
  "id": "GHSA-cc3w-r3w8-hfh7",
  "modified": "2025-02-10T21:02:33Z",
  "published": "2022-05-24T19:13:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28567"
    },
    {
      "type": "WEB",
      "url": "https://github.com/magento/magento2/commit/1bd5cb8c065e44779526c0b044ce19b884707695"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb21-30.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento Improper Authorization vulnerability in the customers module"
}

GHSA-CC7P-2J3X-X7XF

Vulnerability from github – Published: 2026-03-16 18:44 – Updated: 2026-03-17 15:23
VLAI
Summary
Craft CMS Vulnerable to Privilege Escalation/Bypass through UsersController->actionImpersonateWithToken()
Details

Summary

A low-privilege user (or an unauthenticated user who has been sent a shared URL) can escalate their privileges to admin by abusing UsersController->actionImpersonateWithToken.

Affected users should update to Craft 4.17.6 and 5.9.12 to mitigate the issue.

Details

This vulnerability allows any low-privilege user to escalate their privileges and become an admin, or, in extreme circumstances, unprivileged users to do the same.

Therefore, this vulnerability affects Craft Pro and Team more than Craft Solo.

Specifically, an attacker who possesses a valid “preview token” can then append &action=users/impersonate-with-token&userId=1&prevUserId=1 to the preview URL to hijack the request into the impersonation endpoint, logging in as any user (including admin) without authentication. Getting the preview token is easy, and all an editor would have to do is create a single article, click “Preview”, and then recover this token.

Here’s what happens:

  1. The action re-dispatch in actionPreview() passes $skipSpecialHandling=true to handleRequest(), bypassing all security guards, and passes $checkToken=false to checkIfActionRequest(), which allows an attacker-controlled action query parameter to override the dispatch target.
  2. The requireToken() guard on actionImpersonateWithToken() only checks a boolean (_hadToken) that was set when the preview token was initially resolved. It does not verify that the token was intended for the impersonation action, and so any valid token from any route satisfies the check.
  3. actionImpersonateWithToken is listed in $allowAnonymous and performs no authorization beyond requireToken(), so no prior authentication is required.

PoC

The PoC achieves full admin takeover on the latest Craft CMS 5.9.10. Spawn a local version of Craft. Then, you’ll want to log in and create a valid setup:

  1. Log in at http://host:18895/admin
  2. Go to Settings,  Sections, New Section (name: "Blog", type: "Channel")
  3. Under Site Settings, set URI Format to blog/{slug}
  4. Then go to Entries, New Entry, Blog, and give it any title

Next, obtain a preview token

  1. Open the saved entry in the editor
  2. Click the Preview button
  3. A preview pane opens with the entry rendered in an iframe
  4. Right-click inside the preview pane and Inspect Element
  5. Find the element; its src contains the tokenized URL: http://host:18895/blog/title?x-craft-live-preview=...&token=XXXXXXXX
  6. Copy the token= value

Finally, execute the exploit:

1. Open a new incognito/private browser window   2. Navigate to: http://host:18895/?token=XXXXXXXX&action=users/impersonate-with-token&userId=1&prevUserId=1   3. You may see a 404. This is expected.

To verify the exploit, in the same incognito tab, navigate to http://host:18895/admin. You should land on the admin dashboard, logged in as admin, without ever entering credentials.

Impact

Privilege escalation; everyone is impacted.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.17.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.17.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.9.11"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T18:44:20Z",
    "nvd_published_at": "2026-03-16T20:16:19Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA low-privilege user (or an unauthenticated user who has been sent a shared URL) can escalate their privileges to admin by abusing `UsersController-\u003eactionImpersonateWithToken`.\n\nAffected users should update to Craft 4.17.6 and 5.9.12 to mitigate the issue.\n\n### Details\nThis vulnerability allows any low-privilege user to escalate their privileges and become an admin, or, in extreme circumstances, unprivileged users to do the same.\n\nTherefore, this vulnerability affects Craft Pro and Team more than Craft Solo.\n\nSpecifically, an attacker who possesses a valid \u201cpreview token\u201d can then append `\u0026action=users/impersonate-with-token\u0026userId=1\u0026prevUserId=1` to the preview URL to hijack the request\u00a0into the impersonation endpoint, logging in as any user (including admin) without authentication. Getting the preview token is easy, and all an editor would have to do is create a single article, click \u201cPreview\u201d, and then recover this token.\n\nHere\u2019s what happens:\n\n1. The action re-dispatch in `actionPreview()` passes `$skipSpecialHandling=true` to `handleRequest()`, bypassing all security guards, and passes `$checkToken=false` to `checkIfActionRequest()`, which allows an attacker-controlled action query parameter to override the dispatch target.\n2. The `requireToken()` guard on `actionImpersonateWithToken()` only checks a boolean (`_hadToken`) that was set when the preview token was initially resolved. It does not verify that the token was intended for the impersonation action, and so any valid token from any route satisfies the check.\n3. `actionImpersonateWithToken` is listed in `$allowAnonymous` and performs no authorization beyond `requireToken()`, so no prior authentication is required.\n\n### PoC\n\nThe PoC achieves full admin takeover on the latest Craft CMS 5.9.10. Spawn a local version of Craft. Then, you\u2019ll want to log in and create a valid setup:\n\n1. Log in at http://host:18895/admin\n2. Go to Settings,\u00a0 Sections, New Section (name: \"Blog\", type: \"Channel\")\n3. Under Site Settings, set URI Format to blog/{slug}\n4. Then go to Entries, New Entry, Blog, and give it any title\n\nNext, obtain a preview token\n\n1. Open the saved entry in the editor\n2. Click the Preview button\n3. A preview pane opens with the entry rendered in an iframe\n4. Right-click inside the preview pane and Inspect Element\n5. Find the \u003ciframe\u003e element; its src contains the tokenized URL: `http://host:18895/blog/title?x-craft-live-preview=...\u0026token=XXXXXXXX`\n6. Copy the `token=` value\n\nFinally, execute the exploit:\n\n\u00a0 1. Open a new incognito/private browser window\n\u00a0 2. Navigate to: `http://host:18895/?token=XXXXXXXX\u0026action=users/impersonate-with-token\u0026userId=1\u0026prevUserId=1`\n\u00a0 3. You may see a 404.  This is expected.\n\nTo verify the exploit, in the same incognito tab, navigate to\u00a0`http://host:18895/admin`.\u00a0You should land on the admin dashboard, logged in as admin, without ever entering credentials.\n\n### Impact\n\nPrivilege escalation; everyone is impacted.",
  "id": "GHSA-cc7p-2j3x-x7xf",
  "modified": "2026-03-17T15:23:51Z",
  "published": "2026-03-16T18:44:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-cc7p-2j3x-x7xf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32267"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/6301e217c5f15617d939c432cb770db50af14b33"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS Vulnerable to Privilege Escalation/Bypass through UsersController-\u003eactionImpersonateWithToken()"
}

GHSA-CC8W-R4QH-3V65

Vulnerability from github – Published: 2026-06-16 23:38 – Updated: 2026-06-16 23:38
VLAI
Summary
Gitea: Git Smart HTTP Skips Repository Token Scopes for Bearer Tokens
Details

Summary

Gitea v1.26.1 enforces repository-scoped access-token permissions on repository operations. In the Git Smart HTTP path, however, this check runs only when the token is presented via HTTP Basic authentication — CheckRepoScopedToken() returns early unless ctx.IsBasicAuth is true — so the same token sent as Authorization: Bearer <token> bypasses the scope check entirely.

As a result, a PAT or OAuth2 token presented as a Bearer credential can clone or fetch private repositories without the read:repository scope, and likewise reach the Git push without write:repository.

Details

Git Smart HTTP routes allow both Basic auth and OAuth2/Bearer auth:

// routers/web/web.go
addOwnerRepoGitHTTPRouters(
    m,
    repo.HTTPGitEnabledHandler,
    webAuth.AllowBasic,
    webAuth.AllowOAuth2,
    repo.CorsHandler(),
    optSignInFromAnyOrigin,
    context.UserAssignmentWeb(),
)

The Git HTTP authorization path calls CheckRepoScopedToken() before falling through to normal repository RBAC:

// routers/web/repo/githttp.go
if askAuth {
    if !ctx.IsSigned {
        ctx.HTTPError(http.StatusUnauthorized)
        return nil
    }

    context.CheckRepoScopedToken(ctx, repo, auth_model.GetScopeLevelFromAccessMode(accessMode))
    if ctx.Written() {
        return nil
    }

    // normal repository RBAC follows
}

However, CheckRepoScopedToken() only enforces token scopes for Basic-authenticated requests:

// services/context/permission.go
func CheckRepoScopedToken(ctx *Context, repo *repo_model.Repository, level auth_model.AccessTokenScopeLevel) {
    if !ctx.IsBasicAuth || ctx.Data["IsApiToken"] != true {
        return
    }

    scope, ok := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
    if ok {
        requiredScopes := auth_model.GetRequiredScopes(level, auth_model.AccessTokenScopeCategoryRepository)
        // public-only and required repository scope checks follow
    }
}

The Bearer/OAuth2 auth path still records the token scope:

// services/auth/oauth2.go
accessTokenScope, uid := GetOAuthAccessTokenScopeAndUserID(ctx, tokenSHA)
if uid != 0 {
    store.GetData()["IsApiToken"] = true
    store.GetData()["ApiTokenScope"] = accessTokenScope
}

Bearer PATs also set IsApiToken=true and ApiTokenScope, but ctx.IsBasicAuth remains false because the selected auth method is OAuth2/Bearer rather than Basic. The scope is therefore available but ignored.

PoC

This test creates a token for user2 with only read:notification, then requests Git Smart HTTP refs for user2/repo2, which is private. The same token is rejected over Basic auth, but succeeds over Bearer auth.

func TestPOCGitSmartHTTPBearerTokenBypassesRepositoryScope(t *testing.T) {
    defer tests.PrepareTestEnv(t)()

    repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: 2, OwnerName: "user2", Name: "repo2"})
    assert.True(t, repo.IsPrivate)

    session := loginUser(t, "user2")
    token := getTokenForLoggedInUser(t, session, auth_model.AccessTokenScopeReadNotification)
    url := "/user2/repo2/info/refs?service=git-upload-pack"

    basicReq := NewRequest(t, "GET", url)
    basicReq.SetBasicAuth(token, "x-oauth-basic")
    MakeRequest(t, basicReq, http.StatusForbidden)

    bearerReq := NewRequest(t, "GET", url).AddTokenAuth(token)
    resp := MakeRequest(t, bearerReq, http.StatusOK)
    assert.Contains(t, resp.Body.String(), "refs/heads/master")
}

Impact

Any Gitea instance exposing Git Smart HTTP is affected when users use PATs or OAuth2 tokens as Bearer tokens. The attacker still needs a token for a user who has normal repository RBAC, so this does not grant access to repositories the token owner could not otherwise access.

The vulnerability breaks the access-token scope boundary. A token intended only for unrelated scopes, such as read:notification, can clone or fetch private repository contents over Git Smart HTTP. The same root cause can affect write flows because git-receive-pack also calls the same repository scope check before normal write RBAC.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.26.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:38:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nGitea v1.26.1 enforces repository-scoped access-token permissions on repository operations. In the Git Smart HTTP path, however, this check runs only when the token is presented via HTTP Basic authentication \u2014 `CheckRepoScopedToken()` returns early unless `ctx.IsBasicAuth` is true \u2014 so the same token sent as `Authorization: Bearer \u003ctoken\u003e` bypasses the scope check entirely.\n\nAs a result, a PAT or OAuth2 token presented as a Bearer credential can clone or fetch private repositories without the `read:repository` scope, and likewise reach the Git push without `write:repository`.\n\n### Details\nGit Smart HTTP routes allow both Basic auth and OAuth2/Bearer auth:\n\n```go\n// routers/web/web.go\naddOwnerRepoGitHTTPRouters(\n\tm,\n\trepo.HTTPGitEnabledHandler,\n\twebAuth.AllowBasic,\n\twebAuth.AllowOAuth2,\n\trepo.CorsHandler(),\n\toptSignInFromAnyOrigin,\n\tcontext.UserAssignmentWeb(),\n)\n```\n\nThe Git HTTP authorization path calls `CheckRepoScopedToken()` before falling through to normal repository RBAC:\n\n```go\n// routers/web/repo/githttp.go\nif askAuth {\n\tif !ctx.IsSigned {\n\t\tctx.HTTPError(http.StatusUnauthorized)\n\t\treturn nil\n\t}\n\n\tcontext.CheckRepoScopedToken(ctx, repo, auth_model.GetScopeLevelFromAccessMode(accessMode))\n\tif ctx.Written() {\n\t\treturn nil\n\t}\n\n\t// normal repository RBAC follows\n}\n```\n\nHowever, `CheckRepoScopedToken()` only enforces token scopes for Basic-authenticated requests:\n\n```go\n// services/context/permission.go\nfunc CheckRepoScopedToken(ctx *Context, repo *repo_model.Repository, level auth_model.AccessTokenScopeLevel) {\n\tif !ctx.IsBasicAuth || ctx.Data[\"IsApiToken\"] != true {\n\t\treturn\n\t}\n\n\tscope, ok := ctx.Data[\"ApiTokenScope\"].(auth_model.AccessTokenScope)\n\tif ok {\n\t\trequiredScopes := auth_model.GetRequiredScopes(level, auth_model.AccessTokenScopeCategoryRepository)\n\t\t// public-only and required repository scope checks follow\n\t}\n}\n```\n\nThe Bearer/OAuth2 auth path still records the token scope:\n\n```go\n// services/auth/oauth2.go\naccessTokenScope, uid := GetOAuthAccessTokenScopeAndUserID(ctx, tokenSHA)\nif uid != 0 {\n\tstore.GetData()[\"IsApiToken\"] = true\n\tstore.GetData()[\"ApiTokenScope\"] = accessTokenScope\n}\n```\n\nBearer PATs also set `IsApiToken=true` and `ApiTokenScope`, but `ctx.IsBasicAuth` remains false because the selected auth method is OAuth2/Bearer rather than Basic. The scope is therefore available but ignored.\n\n### PoC\nThis test creates a token for `user2` with only `read:notification`, then requests Git Smart HTTP refs for `user2/repo2`, which is private. The same token is rejected over Basic auth, but succeeds over Bearer auth.\n\n```go\nfunc TestPOCGitSmartHTTPBearerTokenBypassesRepositoryScope(t *testing.T) {\n\tdefer tests.PrepareTestEnv(t)()\n\n\trepo := unittest.AssertExistsAndLoadBean(t, \u0026repo_model.Repository{ID: 2, OwnerName: \"user2\", Name: \"repo2\"})\n\tassert.True(t, repo.IsPrivate)\n\n\tsession := loginUser(t, \"user2\")\n\ttoken := getTokenForLoggedInUser(t, session, auth_model.AccessTokenScopeReadNotification)\n\turl := \"/user2/repo2/info/refs?service=git-upload-pack\"\n\n\tbasicReq := NewRequest(t, \"GET\", url)\n\tbasicReq.SetBasicAuth(token, \"x-oauth-basic\")\n\tMakeRequest(t, basicReq, http.StatusForbidden)\n\n\tbearerReq := NewRequest(t, \"GET\", url).AddTokenAuth(token)\n\tresp := MakeRequest(t, bearerReq, http.StatusOK)\n\tassert.Contains(t, resp.Body.String(), \"refs/heads/master\")\n}\n```\n\n### Impact\nAny Gitea instance exposing Git Smart HTTP is affected when users use PATs or OAuth2 tokens as Bearer tokens. The attacker still needs a token for a user who has normal repository RBAC, so this does not grant access to repositories the token owner could not otherwise access.\n\nThe vulnerability breaks the access-token scope boundary. A token intended only for unrelated scopes, such as `read:notification`, can clone or fetch private repository contents over Git Smart HTTP. The same root cause can affect write flows because `git-receive-pack` also calls the same repository scope check before normal write RBAC.",
  "id": "GHSA-cc8w-r4qh-3v65",
  "modified": "2026-06-16T23:38:12Z",
  "published": "2026-06-16T23:38:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-cc8w-r4qh-3v65"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    }
  ],
  "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": "Gitea: Git Smart HTTP Skips Repository Token Scopes for Bearer Tokens"
}

GHSA-CC99-WHM5-MMQ3

Vulnerability from github – Published: 2022-08-27 00:00 – Updated: 2022-11-28 21:05
VLAI
Summary
Openstack Keystone Incorrect Authorization vulnerability
Details

A flaw was found in openstack-keystone, only the first 72 characters of an application secret are verified allowing attackers bypass some password complexity which administrators may be counting on. The highest threat from this vulnerability is to data confidentiality and integrity. A patch is available.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "21.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T21:08:51Z",
    "nvd_published_at": "2022-08-26T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in openstack-keystone, only the first 72 characters of an application secret are verified allowing attackers bypass some password complexity which administrators may be counting on. The highest threat from this vulnerability is to data confidentiality and integrity. A [patch](https://opendev.org/openstack/keystone/commit/7859ed26003858ebfd9a5e866b43f1a6a9e83dca) is available.",
  "id": "GHSA-cc99-whm5-mmq3",
  "modified": "2022-11-28T21:05:48Z",
  "published": "2022-08-27T00:00:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3563"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3563"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ossa/+bug/1901891"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1962908"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/01/msg00007.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://opendev.org/openstack/keystone"
    },
    {
      "type": "WEB",
      "url": "https://opendev.org/openstack/keystone/commit/7859ed26003858ebfd9a5e866b43f1a6a9e83dca"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/c/openstack/keystone/+/803641"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/c/openstack/keystone/+/828595"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/c/openstack/keystone/+/856489"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2021-3563"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Openstack Keystone Incorrect Authorization vulnerability"
}

GHSA-CCCH-F948-2H8C

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

Telegram Desktop through 2.1.13 allows a spoofed file type to bypass the Dangerous File Type Execution protection mechanism, as demonstrated by use of the chat window with a filename that lacks an extension.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-17448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-11T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Telegram Desktop through 2.1.13 allows a spoofed file type to bypass the Dangerous File Type Execution protection mechanism, as demonstrated by use of the chat window with a filename that lacks an extension.",
  "id": "GHSA-ccch-f948-2h8c",
  "modified": "2022-05-24T17:25:19Z",
  "published": "2022-05-24T17:25:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/VijayT007/Vulnerability-Database/blob/master/Telegram-CVE-2020-17448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/telegramdesktop/tdesktop/releases/tag/v2.2.0"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202101-34"
    },
    {
      "type": "WEB",
      "url": "https://telegram.org"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CCG8-46R6-9QGJ

Vulnerability from github – Published: 2026-03-03 19:16 – Updated: 2026-03-30 13:46
VLAI
Summary
OpenClaw's dispatch-wrapper depth-cap mismatch can bypass shell-wrapper approval gating in system.run allowlist mode
Details

Summary

A wrapper-depth parsing mismatch in system.run allowed nested transparent dispatch wrappers (for example repeated /usr/bin/env) to suppress shell-wrapper detection while still matching allowlist resolution. In security=allowlist + ask=on-miss, this could bypass the expected approval prompt for shell execution.

Severity / Trust Model

OpenClaw’s documented model treats authenticated gateway callers as trusted operators and exec approvals as operator guardrails. This issue is still a real approval-boundary bypass and is triaged as Medium in that model.

Technical Details

  • Dispatch-wrapper unwrapping stopped at MAX_DISPATCH_WRAPPER_DEPTH.
  • Shell-wrapper extraction could return non-wrapper once depth was exhausted.
  • Allowlist resolution could still succeed on partially unwrapped argv beginning with /usr/bin/env.
  • Result: nested wrapper chains could execute /bin/sh -c ... without fresh approval in allowlist + ask=on-miss.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published version at triage time: 2026.2.23
  • Vulnerable versions: <= 2026.2.23
  • Patched versions (planned next release): >= 2026.2.24

Fix Commit(s)

  • 57c9a18180c8b14885bbd95474cbb17ff2d03f0b

Verification

  • Added regression coverage for depth-overflow wrapper chains at resolution and system.run invocation layers.
  • Reproduced previous PoC behavior before fix, then confirmed denial after fix with SYSTEM_RUN_DENIED: approval required.

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.24) so once npm publish is complete, advisory publication can proceed without additional version edits.

OpenClaw thanks @tdjackey for reporting.

Publication Update (2026-02-25)

openclaw@2026.2.24 is published on npm and contains the fix commit(s) listed above. This advisory now marks >= 2026.2.24 as patched.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.23"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T19:16:48Z",
    "nvd_published_at": "2026-03-19T22:16:36Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA wrapper-depth parsing mismatch in `system.run` allowed nested transparent dispatch wrappers (for example repeated `/usr/bin/env`) to suppress shell-wrapper detection while still matching allowlist resolution. In `security=allowlist` + `ask=on-miss`, this could bypass the expected approval prompt for shell execution.\n\n### Severity / Trust Model\nOpenClaw\u2019s documented model treats authenticated gateway callers as trusted operators and exec approvals as operator guardrails. This issue is still a real approval-boundary bypass and is triaged as **Medium** in that model.\n\n### Technical Details\n- Dispatch-wrapper unwrapping stopped at `MAX_DISPATCH_WRAPPER_DEPTH`.\n- Shell-wrapper extraction could return non-wrapper once depth was exhausted.\n- Allowlist resolution could still succeed on partially unwrapped argv beginning with `/usr/bin/env`.\n- Result: nested wrapper chains could execute `/bin/sh -c ...` without fresh approval in `allowlist` + `ask=on-miss`.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published version at triage time: `2026.2.23`\n- Vulnerable versions: `\u003c= 2026.2.23`\n- Patched versions (planned next release): `\u003e= 2026.2.24`\n\n### Fix Commit(s)\n- `57c9a18180c8b14885bbd95474cbb17ff2d03f0b`\n\n### Verification\n- Added regression coverage for depth-overflow wrapper chains at resolution and `system.run` invocation layers.\n- Reproduced previous PoC behavior before fix, then confirmed denial after fix with `SYSTEM_RUN_DENIED: approval required`.\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.24`) so once npm publish is complete, advisory publication can proceed without additional version edits.\n\nOpenClaw thanks @tdjackey for reporting.\n\n\n### Publication Update (2026-02-25)\n`openclaw@2026.2.24` is published on npm and contains the fix commit(s) listed above. This advisory now marks `\u003e= 2026.2.24` as patched.",
  "id": "GHSA-ccg8-46r6-9qgj",
  "modified": "2026-03-30T13:46:28Z",
  "published": "2026-03-03T19:16:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-ccg8-46r6-9qgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32023"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/57c9a18180c8b14885bbd95474cbb17ff2d03f0b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-gating-bypass-via-dispatch-wrapper-depth-cap-mismatch-in-system-run"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s dispatch-wrapper depth-cap mismatch can bypass shell-wrapper approval gating in system.run allowlist mode"
}
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