CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
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.
6551 vulnerabilities reference this CWE, most recent first.
GHSA-VG7P-2967-P5P3
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41An issue was discovered on FiberHome HG6245D devices through RP2613. It is possible to bypass authentication by sending the decoded value of the GgpoZWxwCmxpc3QKd2hvCg== string to the telnet server.
{
"affected": [],
"aliases": [
"CVE-2021-27177"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-10T19:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on FiberHome HG6245D devices through RP2613. It is possible to bypass authentication by sending the decoded value of the GgpoZWxwCmxpc3QKd2hvCg== string to the telnet server.",
"id": "GHSA-vg7p-2967-p5p3",
"modified": "2022-05-24T17:41:52Z",
"published": "2022-05-24T17:41:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27177"
},
{
"type": "WEB",
"url": "https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0day-vulnerabilities.html#telnet-cli-auth-bypass"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VG85-GMCC-WRQW
Vulnerability from github – Published: 2024-09-27 00:31 – Updated: 2024-09-27 00:31Information disclosure in Gitlab EE/CE affecting all versions from 15.6 prior to 17.2.8, 17.3 prior to 17.3.4, and 17.4 prior to 17.4.1 in specific conditions it was possible to disclose to an unauthorised user the path of a private project."
{
"affected": [],
"aliases": [
"CVE-2024-8974"
],
"database_specific": {
"cwe_ids": [
"CWE-684",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-26T23:15:03Z",
"severity": "LOW"
},
"details": "Information disclosure in Gitlab EE/CE affecting all versions from 15.6 prior to 17.2.8, 17.3 prior to 17.3.4, and 17.4 prior to 17.4.1 in specific conditions it was possible to disclose to an unauthorised user the path of a private project.\"",
"id": "GHSA-vg85-gmcc-wrqw",
"modified": "2024-09-27T00:31:05Z",
"published": "2024-09-27T00:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8974"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/482843"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VG8Q-6F88-6VRH
Vulnerability from github – Published: 2022-05-13 01:40 – Updated: 2022-05-13 01:40GitLab Community and Enterprise Editions before 10.1.6, 10.2.6, and 10.3.4 are vulnerable to an authorization bypass issue in the Projects::MergeRequests::CreationsController component resulting in an attacker to see every project name and their respective namespace on a GitLab instance.
{
"affected": [],
"aliases": [
"CVE-2017-0920"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-22T15:29:00Z",
"severity": "MODERATE"
},
"details": "GitLab Community and Enterprise Editions before 10.1.6, 10.2.6, and 10.3.4 are vulnerable to an authorization bypass issue in the Projects::MergeRequests::CreationsController component resulting in an attacker to see every project name and their respective namespace on a GitLab instance.",
"id": "GHSA-vg8q-6f88-6vrh",
"modified": "2022-05-13T01:40:53Z",
"published": "2022-05-13T01:40:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0920"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/301336"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/2018/01/16/gitlab-10-dot-3-dot-4-released"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4206"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VG95-5P98-2464
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-07-13 00:01An issue has been discovered in GitLab affecting all versions starting from 13.4. Improper access control allows unauthorized users to access details on analytic pages.
{
"affected": [],
"aliases": [
"CVE-2021-22180"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-26T20:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab affecting all versions starting from 13.4. Improper access control allows unauthorized users to access details on analytic pages.",
"id": "GHSA-vg95-5p98-2464",
"modified": "2022-07-13T00:01:08Z",
"published": "2022-05-24T17:45:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22180"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1064645"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22180.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/295662"
}
],
"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-VGC6-7RQ7-5J57
Vulnerability from github – Published: 2021-12-29 00:00 – Updated: 2021-12-29 00:00PI Vision could disclose information to a user with insufficient privileges for an AF attribute that is the child of another attribute and is configured as a Limits property.
{
"affected": [],
"aliases": [
"CVE-2021-3090"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-28T19:15:00Z",
"severity": null
},
"details": "PI Vision could disclose information to a user with insufficient privileges for an AF attribute that is the child of another attribute and is configured as a Limits property.",
"id": "GHSA-vgc6-7rq7-5j57",
"modified": "2021-12-29T00:00:44Z",
"published": "2021-12-29T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3090"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-313-05"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VGFW-CGXJ-F63C
Vulnerability from github – Published: 2024-11-25 18:33 – Updated: 2024-11-25 18:33The application Sensei Mac Cleaner contains a local privilege escalation vulnerability, allowing an attacker to perform multiple operations as the root user. These operations include arbitrary file deletion and writing, loading and unloading daemons, manipulating file permissions, and loading extensions, among other actions.
The vulnerable module org.cindori.SenseiHelper can be contacted via XPC. While the module performs client validation, it relies on the client's PID obtained through the public processIdentifier property of the NSXPCConnection class. This approach makes the module susceptible to a PID Reuse Attack, enabling an attacker to impersonate a legitimate client and send crafted XPC messages to invoke arbitrary methods exposed by the HelperProtocol interface.
{
"affected": [],
"aliases": [
"CVE-2024-7915"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-25T18:15:14Z",
"severity": "HIGH"
},
"details": "The application Sensei Mac Cleaner contains a local privilege escalation vulnerability, allowing an attacker to perform multiple operations as the root\u00a0user. These operations include arbitrary file deletion and writing, loading and unloading daemons, manipulating file permissions, and loading extensions, among other actions.\n\n\nThe vulnerable module\u00a0org.cindori.SenseiHelper\u00a0can be contacted via XPC. While the module performs client validation, it relies on the client\u0027s PID\u00a0obtained through the public processIdentifier\u00a0property of the NSXPCConnection\u00a0class. This approach makes the module susceptible to a PID Reuse Attack, enabling an attacker to impersonate a legitimate client and send crafted XPC messages to invoke arbitrary methods exposed by the HelperProtocol\u00a0interface.",
"id": "GHSA-vgfw-cgxj-f63c",
"modified": "2024-11-25T18:33:26Z",
"published": "2024-11-25T18:33:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7915"
},
{
"type": "WEB",
"url": "https://pentraze.com/vulnerability-reports"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VGH6-QCG3-P3MF
Vulnerability from github – Published: 2023-07-07 15:30 – Updated: 2024-04-04 05:50Zoho ManageEngine ServiceDesk Plus before 14202, ServiceDesk Plus MSP before 14300, and SupportCenter Plus before 14300 have a privilege escalation vulnerability in the Release module that allows unprivileged users to access the Reminders of a release ticket and make modifications.
{
"affected": [],
"aliases": [
"CVE-2023-34197"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-07T13:15:09Z",
"severity": "MODERATE"
},
"details": "Zoho ManageEngine ServiceDesk Plus before 14202, ServiceDesk Plus MSP before 14300, and SupportCenter Plus before 14300 have a privilege escalation vulnerability in the Release module that allows unprivileged users to access the Reminders of a release ticket and make modifications.",
"id": "GHSA-vgh6-qcg3-p3mf",
"modified": "2024-04-04T05:50:25Z",
"published": "2023-07-07T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34197"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/service-desk/CVE-2023-34197.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VGJ4-345G-JCF8
Vulnerability from github – Published: 2026-07-20 21:15 – Updated: 2026-07-20 21:15Summary
Cloudreve's OAuth access tokens can bypass OAuth scope enforcement.
This does not appear to be the intended design. The documentation describes OAuth client permissions/scopes, the API
has an insufficient-scope error code, and the code comments say RequiredScopes(...) should verify scopes when a
token has scopes, while skipping checks only for non-scoped session-based authentication.
However, OAuth access tokens are issued without the OAuth client_id claim. Later, the JWT verifier only loads scopes
into the request context when claims.ClientID != "". Because the OAuth access token has no client_id, its scopes
are not loaded, and RequiredScopes(...) treats the request like a non-scoped first-party/session token and skips
scope checks.
As a result, a low-scope OAuth access token, for example one granted only openid, can call APIs requiring higher
scopes such as file, share, workflow, user setting, WebDAV account, and potentially admin scopes when the authorizing
user is an administrator.
## Why this seems unintended
Cloudreve appears to have an explicit OAuth scope model:
- The official docs describe OAuth client permissions/scopes and require the authorization request to include requested scopes.
- The API error code list includes an OAuth insufficient-scope error.
RequiredScopes(...)is used across sensitive API groups such as files, shares, workflows, user settings, WebDAV devices, and admin APIs.- The middleware comment says scope checks are skipped only when
hasScopesis false, for example session-based authentication. - Default OAuth clients created during migration explicitly list scopes such as
Files.Write,Workflow.Write, andShares.Write.
This suggests the intended design is:
- First-party/session tokens may be non-scoped and skip OAuth scope checks.
- OAuth access tokens should carry scope metadata and be checked against RequiredScopes(...).
The current implementation makes OAuth access tokens fall into the first category by mistake.
## Affected code
In the OAuth authorization code exchange, Cloudreve passes both ClientID and Scopes into token issuance:
```go token, err := tokenAuth.Issue(c, &auth.IssueTokenArgs{ User: user, ClientID: s.ClientID, Scopes: authCode.Scopes, RefreshTTLOverride: refreshTTLOverride, })
Location:
- service/oauth/oauth.go
In Issue(...), the access token includes Scopes but does not include ClientID:
accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{ TokenType: TokenTypeAccess, RegisteredClaims: jwt.RegisteredClaims{ Subject: uidEncoded, NotBefore: jwt.NewNumericDate(issueDate), ExpiresAt: jwt.NewNumericDate(accessTokenExpired), }, Scopes: args.Scopes, }).SignedString(t.secret)
By contrast, the refresh token does include both:
Scopes: args.Scopes, ClientID: args.ClientID,
Location:
- pkg/auth/jwt.go
During request authentication, scopes are only inserted into request context if ClientID is present:
if claims.ClientID != "" { util.WithValue(c, ScopeContextKey{}, claims.Scopes) }
Location:
- pkg/auth/jwt.go
Then CheckScope(...) skips scope enforcement if no scopes are present in context:
hasScopes, tokenScopes := GetScopesFromContext(c) if !hasScopes { return nil }
Location:
- pkg/auth/jwt.go
RequiredScopes(...) relies on this check:
if err := auth.CheckScope(c, requiredScopes...); err != nil { c.JSON(200, serializer.Err(c, err)) c.Abort() return }
Location:
- middleware/auth.go
Sensitive route groups protected by RequiredScopes(...) include:
- Files: Files.Read / Files.Write
- Shares: Shares.Read / Shares.Write
- Workflows: Workflow.Read / Workflow.Write
- User settings and security info
- WebDAV device/account management
- Admin APIs: Admin.Read / Admin.Write
Location:
- routers/router.go
## Reproduction steps
- Create or use an OAuth client with a low-privilege scope, for example only openid.
- Complete the OAuth authorization code flow for a normal user with:
scope=openid
- Exchange the authorization code via:
POST /api/v4/session/oauth/token
- Decode the returned access token.
Expected token metadata should preserve enough OAuth client/scope context for later enforcement.
Actual behavior:
- The access token contains the requested scopes.
-
The access token does not contain client_id.
-
Use the returned token as a bearer token:
Authorization: Bearer
- Call an API that requires a scope not granted to the OAuth app, for example an endpoint requiring Files.Read, Files.Write, UserInfo.Write, or DavAccount.Write.
Expected result:
- The request should fail with an insufficient-scope error.
Actual result:
- The scope check is skipped because no scopes were inserted into the request context.
- The request is processed as that user.
If the authorizing user is an administrator, the same issue can affect admin APIs requiring Admin.Read or Admin.Write, because the request still runs as the admin user and the admin identity check can pass while the OAuth scope check is skipped.
## Impact
This is not an anonymous authentication bypass. The attacker still needs a valid OAuth access token for a real user.
The impact is an OAuth consent/scope boundary bypass:
- A third-party OAuth app can request a minimal scope such as openid.
- After the user authorizes it, the app receives an access token.
- That token can be used as a broader bearer token for the same user's Cloudreve account, despite not being granted the required scopes.
For normal users, this may allow access to or modification of files, shares, workflows, user settings, and WebDAV account/device settings depending on available APIs.
For administrator users, it may allow access to admin-scoped functionality without the OAuth app being granted Admin.Read or Admin.Write.
## Suggested fix
- Include ClientID: args.ClientID in access token claims when issuing OAuth access tokens:
accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{ TokenType: TokenTypeAccess, RegisteredClaims: jwt.RegisteredClaims{ Subject: uidEncoded, NotBefore: jwt.NewNumericDate(issueDate), ExpiresAt: jwt.NewNumericDate(accessTokenExpired), }, Scopes: args.Scopes, ClientID: args.ClientID, }).SignedString(t.secret)
- Consider making scope handling fail closed for OAuth tokens with malformed or inconsistent OAuth metadata.
- Add regression tests for an OAuth access token granted only openid attempting to call APIs requiring:
- Files.Read
- Files.Write
- UserInfo.Write
- DavAccount.Write
- Admin.Read
- Admin.Write
Each should fail with an insufficient-scope error unless the corresponding scope was granted.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-20260114075425-bc6845bd742c"
},
{
"fixed": "4.0.0-20260606015557-ed20843dc3df"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54560"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T21:15:20Z",
"nvd_published_at": "2026-07-15T15:16:44Z",
"severity": "HIGH"
},
"details": "## Summary\n\n Cloudreve\u0027s OAuth access tokens can bypass OAuth scope enforcement.\n\n This does not appear to be the intended design. The documentation describes OAuth client permissions/scopes, the API\n has an insufficient-scope error code, and the code comments say `RequiredScopes(...)` should verify scopes when a\n token has scopes, while skipping checks only for non-scoped session-based authentication.\n\n However, OAuth access tokens are issued without the OAuth `client_id` claim. Later, the JWT verifier only loads scopes\n into the request context when `claims.ClientID != \"\"`. Because the OAuth access token has no `client_id`, its scopes\n are not loaded, and `RequiredScopes(...)` treats the request like a non-scoped first-party/session token and skips\n scope checks.\n\n As a result, a low-scope OAuth access token, for example one granted only `openid`, can call APIs requiring higher\n scopes such as file, share, workflow, user setting, WebDAV account, and potentially admin scopes when the authorizing\n user is an administrator.\n\n ## Why this seems unintended\n\n Cloudreve appears to have an explicit OAuth scope model:\n\n 1. The official docs describe OAuth client permissions/scopes and require the authorization request to include\n requested scopes.\n 2. The API error code list includes an OAuth insufficient-scope error.\n 3. `RequiredScopes(...)` is used across sensitive API groups such as files, shares, workflows, user settings, WebDAV\n devices, and admin APIs.\n 4. The middleware comment says scope checks are skipped only when `hasScopes` is false, for example session-based\n authentication.\n 5. Default OAuth clients created during migration explicitly list scopes such as `Files.Write`, `Workflow.Write`, and\n `Shares.Write`.\n\n This suggests the intended design is:\n - First-party/session tokens may be non-scoped and skip OAuth scope checks.\n - OAuth access tokens should carry scope metadata and be checked against `RequiredScopes(...)`.\n\n The current implementation makes OAuth access tokens fall into the first category by mistake.\n\n ## Affected code\n\n In the OAuth authorization code exchange, Cloudreve passes both `ClientID` and `Scopes` into token issuance:\n\n ```go\n token, err := tokenAuth.Issue(c, \u0026auth.IssueTokenArgs{\n User: user,\n ClientID: s.ClientID,\n Scopes: authCode.Scopes,\n RefreshTTLOverride: refreshTTLOverride,\n })\n\n Location:\n\n - service/oauth/oauth.go\n\n In Issue(...), the access token includes Scopes but does not include ClientID:\n\n accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{\n TokenType: TokenTypeAccess,\n RegisteredClaims: jwt.RegisteredClaims{\n Subject: uidEncoded,\n NotBefore: jwt.NewNumericDate(issueDate),\n ExpiresAt: jwt.NewNumericDate(accessTokenExpired),\n },\n Scopes: args.Scopes,\n }).SignedString(t.secret)\n\n By contrast, the refresh token does include both:\n\n Scopes: args.Scopes,\n ClientID: args.ClientID,\n\n Location:\n\n - pkg/auth/jwt.go\n\n During request authentication, scopes are only inserted into request context if ClientID is present:\n\n if claims.ClientID != \"\" {\n util.WithValue(c, ScopeContextKey{}, claims.Scopes)\n }\n\n Location:\n\n - pkg/auth/jwt.go\n\n Then CheckScope(...) skips scope enforcement if no scopes are present in context:\n\n hasScopes, tokenScopes := GetScopesFromContext(c)\n if !hasScopes {\n return nil\n }\n\n Location:\n\n - pkg/auth/jwt.go\n\n RequiredScopes(...) relies on this check:\n\n if err := auth.CheckScope(c, requiredScopes...); err != nil {\n c.JSON(200, serializer.Err(c, err))\n c.Abort()\n return\n }\n\n Location:\n\n - middleware/auth.go\n\n Sensitive route groups protected by RequiredScopes(...) include:\n\n - Files: Files.Read / Files.Write\n - Shares: Shares.Read / Shares.Write\n - Workflows: Workflow.Read / Workflow.Write\n - User settings and security info\n - WebDAV device/account management\n - Admin APIs: Admin.Read / Admin.Write\n\n Location:\n\n - routers/router.go\n\n ## Reproduction steps\n\n 1. Create or use an OAuth client with a low-privilege scope, for example only openid.\n 2. Complete the OAuth authorization code flow for a normal user with:\n\n scope=openid\n\n 3. Exchange the authorization code via:\n\n POST /api/v4/session/oauth/token\n\n 4. Decode the returned access token.\n\n Expected token metadata should preserve enough OAuth client/scope context for later enforcement.\n\n Actual behavior:\n\n - The access token contains the requested scopes.\n - The access token does not contain client_id.\n\n 5. Use the returned token as a bearer token:\n\n Authorization: Bearer \u003caccess_token\u003e\n\n 6. Call an API that requires a scope not granted to the OAuth app, for example an endpoint requiring Files.Read,\n Files.Write, UserInfo.Write, or DavAccount.Write.\n\n Expected result:\n\n - The request should fail with an insufficient-scope error.\n\n Actual result:\n\n - The scope check is skipped because no scopes were inserted into the request context.\n - The request is processed as that user.\n\n If the authorizing user is an administrator, the same issue can affect admin APIs requiring Admin.Read or Admin.Write,\n because the request still runs as the admin user and the admin identity check can pass while the OAuth scope check is\n skipped.\n\n ## Impact\n\n This is not an anonymous authentication bypass. The attacker still needs a valid OAuth access token for a real user.\n\n The impact is an OAuth consent/scope boundary bypass:\n\n - A third-party OAuth app can request a minimal scope such as openid.\n - After the user authorizes it, the app receives an access token.\n - That token can be used as a broader bearer token for the same user\u0027s Cloudreve account, despite not being granted\n the required scopes.\n\n For normal users, this may allow access to or modification of files, shares, workflows, user settings, and WebDAV\n account/device settings depending on available APIs.\n\n For administrator users, it may allow access to admin-scoped functionality without the OAuth app being granted\n Admin.Read or Admin.Write.\n\n ## Suggested fix\n\n 1. Include ClientID: args.ClientID in access token claims when issuing OAuth access tokens:\n\n accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{\n TokenType: TokenTypeAccess,\n RegisteredClaims: jwt.RegisteredClaims{\n Subject: uidEncoded,\n NotBefore: jwt.NewNumericDate(issueDate),\n ExpiresAt: jwt.NewNumericDate(accessTokenExpired),\n },\n Scopes: args.Scopes,\n ClientID: args.ClientID,\n }).SignedString(t.secret)\n\n 2. Consider making scope handling fail closed for OAuth tokens with malformed or inconsistent OAuth metadata.\n 3. Add regression tests for an OAuth access token granted only openid attempting to call APIs requiring:\n - Files.Read\n - Files.Write\n - UserInfo.Write\n - DavAccount.Write\n - Admin.Read\n - Admin.Write\n\n Each should fail with an insufficient-scope error unless the corresponding scope was granted.",
"id": "GHSA-vgj4-345g-jcf8",
"modified": "2026-07-20T21:15:20Z",
"published": "2026-07-20T21:15:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-vgj4-345g-jcf8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54560"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/ed20843dc3df20a25fcaf6b538647e11c4d68d87"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.16.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Cloudreve: OAuth access tokens bypass scope enforcement due to missing client_id claim"
}
GHSA-VGMV-8XJC-6RCH
Vulnerability from github – Published: 2026-08-20 18:38 – Updated: 2026-08-20 18:38Summary
Backpack CRUD's list and read operations correctly apply any query scopes
registered via addClause() / addBaseClause() (e.g. tenant isolation, user
ownership). However, the Update, Delete, and Reorder operations
bypassed these scopes, fetching records directly from the unscoped model query.
An authenticated user who knows or can guess a record's primary key could therefore update, delete, or reorder records that should be invisible to them — a classic IDOR on write paths.
Applications that rely on addBaseClause for row-level access control
(multi-tenancy, per-user data isolation) are affected.
Impact
Any Backpack CRUD panel that uses addBaseClause or addClause to restrict
which rows a user may access is affected on its write operations.
An authenticated low-privilege user can modify or delete records belonging to
other tenants / users.
Patches
Apply the fixed release for your major version:
- v6: upgrade to 6.8.14 or later
- v7: upgrade to 7.0.38 or later
The fix ensures Update, Delete, and Reorder all resolve records through the same scoped query used by the read side.
Workarounds
If you cannot upgrade immediately, add explicit Gate / Policy checks in your
CrudController's update(), destroy(), and reorder() methods to verify
the authenticated user is permitted to act on the resolved record.
Credits
Reported by Vishal Shukla (@shukla304).
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "backpack/crud"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.8.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "backpack/crud"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.38"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54180"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:38:46Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nBackpack CRUD\u0027s list and read operations correctly apply any query scopes\nregistered via `addClause()` / `addBaseClause()` (e.g. tenant isolation, user\nownership). However, the **Update**, **Delete**, and **Reorder** operations\nbypassed these scopes, fetching records directly from the unscoped model query.\n\nAn authenticated user who knows or can guess a record\u0027s primary key could\ntherefore update, delete, or reorder records that should be invisible to them \u2014\na classic IDOR on write paths.\n\nApplications that rely on `addBaseClause` for row-level access control\n(multi-tenancy, per-user data isolation) are affected.\n\n## Impact\n\nAny Backpack CRUD panel that uses `addBaseClause` or `addClause` to restrict\nwhich rows a user may access is affected on its write operations.\nAn authenticated low-privilege user can modify or delete records belonging to\nother tenants / users.\n\n## Patches\n\nApply the fixed release for your major version:\n\n- **v6**: upgrade to **6.8.14** or later\n- **v7**: upgrade to **7.0.38** or later\n\nThe fix ensures Update, Delete, and Reorder all resolve records through the same\nscoped query used by the read side.\n\n## Workarounds\n\nIf you cannot upgrade immediately, add explicit `Gate` / `Policy` checks in your\n`CrudController`\u0027s `update()`, `destroy()`, and `reorder()` methods to verify\nthe authenticated user is permitted to act on the resolved record.\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304)).",
"id": "GHSA-vgmv-8xjc-6rch",
"modified": "2026-08-20T18:38:46Z",
"published": "2026-08-20T18:38:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Laravel-Backpack/CRUD/security/advisories/GHSA-vgmv-8xjc-6rch"
},
{
"type": "PACKAGE",
"url": "https://github.com/Laravel-Backpack/CRUD"
},
{
"type": "WEB",
"url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/6.8.14"
},
{
"type": "WEB",
"url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/7.0.38"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Laravel Backpack CRUD: CRUD panel query scopes are not enforced on Update, Delete, and Reorder (cross-tenant IDOR)"
}
GHSA-VGMW-9CWW-QQ99
Vulnerability from github – Published: 2022-01-31 00:00 – Updated: 2024-11-18 16:26calibreweb prior to version 0.6.16 contains an Incorrect Authorization vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "calibreweb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-0273"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-02-07T21:14:46Z",
"nvd_published_at": "2022-01-30T14:15:00Z",
"severity": "HIGH"
},
"details": "calibreweb prior to version 0.6.16 contains an Incorrect Authorization vulnerability.",
"id": "GHSA-vgmw-9cww-qq99",
"modified": "2024-11-18T16:26:18Z",
"published": "2022-01-31T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0273"
},
{
"type": "WEB",
"url": "https://github.com/janeczku/calibre-web/commit/0c0313f375bed7b035c8c0482bbb09599e16bfcf"
},
{
"type": "PACKAGE",
"url": "https://github.com/janeczku/calibre-web"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/calibreweb/PYSEC-2022-22.yaml"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/8f27686f-d698-4ab6-8ef0-899125792f13"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Incorrect Authorization in calibreweb"
}
Mitigation
- 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
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
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
- 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
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.