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.
6921 vulnerabilities reference this CWE, most recent first.
GHSA-9QF2-26P9-2Q2Q
Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-28 21:31A WebFlux application using functional endpoints and deployed with DispatcherServlet may be vulnerable to a header predicate bypass in a pre-flight request. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.5.RELEASE - 5.2.25.RELEASE
{
"affected": [],
"aliases": [
"CVE-2026-47892"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-27T06:17:20Z",
"severity": "CRITICAL"
},
"details": "A WebFlux application using functional endpoints and deployed with DispatcherServlet may be vulnerable to a header predicate bypass in a pre-flight request.\nSpring Framework 7.0.0 - 7.0.8\nSpring Framework 6.2.0 - 6.2.19\nSpring Framework 6.1.0 - 6.1.28\nSpring Framework 6.0.0 - 6.0.30\nSpring Framework 5.3.0 - 5.3.49\nSpring Framework 5.2.5.RELEASE - 5.2.25.RELEASE",
"id": "GHSA-9qf2-26p9-2q2q",
"modified": "2026-08-28T21:31:06Z",
"published": "2026-08-27T06:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47892"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-47892"
}
],
"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-9QMQ-3C39-M5F9
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-17 15:31A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27. An app may be able to modify a file it only had permission to read.
{
"affected": [],
"aliases": [
"CVE-2026-43785"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:11Z",
"severity": "MODERATE"
},
"details": "A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27. An app may be able to modify a file it only had permission to read.",
"id": "GHSA-9qmq-3c39-m5f9",
"modified": "2026-09-17T15:31:36Z",
"published": "2026-09-14T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43785"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149034"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149035"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149036"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149038"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149042"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149043"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9QX4-4584-P9H2
Vulnerability from github – Published: 2026-08-10 21:32 – Updated: 2026-08-10 21:32Cachet through 2.4.1 contains a server-side template injection vulnerability in incident template rendering that allows authenticated users to execute arbitrary PHP code. Attackers can create malicious incident templates with Blade directives or Twig filters that execute system commands when incidents are created, achieving remote code execution as the web server process.
{
"affected": [],
"aliases": [
"CVE-2026-69118"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T20:17:32Z",
"severity": "HIGH"
},
"details": "Cachet through 2.4.1 contains a server-side template injection vulnerability in incident template rendering that allows authenticated users to execute arbitrary PHP code. Attackers can create malicious incident templates with Blade directives or Twig filters that execute system commands when incidents are created, achieving remote code execution as the web server process.",
"id": "GHSA-9qx4-4584-p9h2",
"modified": "2026-08-10T21:32:04Z",
"published": "2026-08-10T21:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69118"
},
{
"type": "WEB",
"url": "https://github.com/cachethq/cachet/issues/4621"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/cachet-authenticated-server-side-template-injection-rce"
}
],
"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:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-9QX4-M255-P25G
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-04-04 00:24The BrowseProjects.jspa resource in Jira before version 7.13.2, and from version 8.0.0 before version 8.0.2 allows remote attackers to see information for archived projects through a missing authorisation check.
{
"affected": [],
"aliases": [
"CVE-2019-3399"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-30T16:29:00Z",
"severity": "HIGH"
},
"details": "The BrowseProjects.jspa resource in Jira before version 7.13.2, and from version 8.0.0 before version 8.0.2 allows remote attackers to see information for archived projects through a missing authorisation check.",
"id": "GHSA-9qx4-m255-p25g",
"modified": "2024-04-04T00:24:25Z",
"published": "2022-05-24T16:44:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3399"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JRASERVER-69246"
}
],
"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-9R5X-FJV3-Q6H4
Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2024-05-21 14:35Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.
Original Description
NATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/jwt/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.3-0.20210314221642-a826c77dc9d2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-12T20:34:10Z",
"nvd_published_at": "2021-03-16T20:15:00Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.\n\n## Original Description\nNATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.",
"id": "GHSA-9r5x-fjv3-q6h4",
"modified": "2024-05-21T14:35:21Z",
"published": "2022-02-15T01:57:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3127"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/jwt/pull/149"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/jwt/pull/149/commits/a826c77dc9d2671c961b75ceefdb439c41029866"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/nats-server/commit/423b79440c80c863de9f4e20548504e6c5d5e403"
},
{
"type": "WEB",
"url": "https://advisories.nats.io/CVE/CVE-2021-3127.txt"
},
{
"type": "PACKAGE",
"url": "https://github.com/nats-io/jwt"
}
],
"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"
}
],
"summary": "Duplicate Advisory: Incorrect Access Control in github.com/nats-io/jwt and github.com/nats-io/nats-server/v2",
"withdrawn": "2024-05-21T14:35:21Z"
}
GHSA-9R5X-WG6M-X2RC
Vulnerability from github – Published: 2026-06-16 23:40 – Updated: 2026-06-16 23:40Summary
Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token>:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.
Details
Root cause: services/auth/basic.go accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:
// services/auth/basic.go
if uid != 0 {
store.GetData()["LoginMethod"] = OAuth2TokenMethodName
store.GetData()["IsApiToken"] = true // scope is NOT set
return u, nil
}
The scope enforcement middleware in routers/api/v1/api.go exits early when ApiTokenScope is absent:
// routers/api/v1/api.go — tokenRequiresScopes
scope, scopeExists := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
if ctx.Data["IsApiToken"] != true || !scopeExists {
return //<- exits without checking scope, all actions permitted
}
When a token arrives via Bearer, ApiTokenScope is populated and scope checks apply normally. When the same token arrives via Basic auth, ApiTokenScope is never set, so tokenRequiresScopes returns immediately and no scope is enforced.
Suggested fix: When an OAuth2 access token is accepted in services/auth/basic.go, populate ApiTokenScope in the request context identically to the Bearer-token OAuth2 path.
PoC
- Create an OAuth2 application in Gitea.
- Authorize it as a normal user with scope
read:useronly. - Take the resulting access token and call a write endpoint both ways:
Bearer | correctly blocked:
Authorization: Bearer <token>
PATCH /api/v1/user/settings -> 403 Forbidden
Basic | bypass:
Authorization: Basic base64(<token>:x-oauth-basic)
PATCH /api/v1/user/settings -> 200 OK
All verified bypass endpoints using a read:user-only token:
| Endpoint | Bearer | Basic |
|---|---|---|
PATCH /api/v1/user/settings |
403 | 200 |
POST /api/v1/user/emails |
403 | 200 |
POST /api/v1/user/repos |
403 | 200 |
PATCH /api/v1/repos/{owner}/{repo} |
403 | 200 |
DELETE /api/v1/repos/{owner}/{repo} |
403 | 200 |
The bypass respects the user's normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.
Impact
Any OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:
- Modify the victim's profile and settings
- Add attacker-controlled email addresses to the victim's account
- Create repositories as the victim
- Modify or delete the victim's private repositories
The entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.
{
"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-28699"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T23:40:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nGitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only `read:user` can use the same token as `Authorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)` and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.\n\n### Details\n\n**Root cause:** `services/auth/basic.go` accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:\n\n```go\n// services/auth/basic.go\nif uid != 0 {\n store.GetData()[\"LoginMethod\"] = OAuth2TokenMethodName\n store.GetData()[\"IsApiToken\"] = true // scope is NOT set\n return u, nil\n}\n```\n\nThe scope enforcement middleware in `routers/api/v1/api.go` exits early when `ApiTokenScope` is absent:\n\n```go\n// routers/api/v1/api.go \u2014 tokenRequiresScopes\nscope, scopeExists := ctx.Data[\"ApiTokenScope\"].(auth_model.AccessTokenScope)\nif ctx.Data[\"IsApiToken\"] != true || !scopeExists {\n return //\u003c- exits without checking scope, all actions permitted\n}\n```\n\nWhen a token arrives via Bearer, `ApiTokenScope` is populated and scope checks apply normally. When the same token arrives via Basic auth, `ApiTokenScope` is never set, so `tokenRequiresScopes` returns immediately and no scope is enforced.\n\n**Suggested fix:** When an OAuth2 access token is accepted in `services/auth/basic.go`, populate `ApiTokenScope` in the request context identically to the Bearer-token OAuth2 path.\n\n### PoC\n\n1. Create an OAuth2 application in Gitea.\n2. Authorize it as a normal user with scope `read:user` only.\n3. Take the resulting access token and call a write endpoint both ways:\n\n**Bearer | correctly blocked:**\n```\nAuthorization: Bearer \u003ctoken\u003e\nPATCH /api/v1/user/settings -\u003e 403 Forbidden\n```\n\n**Basic | bypass:**\n```\nAuthorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)\nPATCH /api/v1/user/settings -\u003e 200 OK\n```\n\n**All verified bypass endpoints using a `read:user`-only token:**\n\n| Endpoint | Bearer | Basic |\n|---|---|---|\n| `PATCH /api/v1/user/settings` | 403 | 200 |\n| `POST /api/v1/user/emails` | 403 | 200 |\n| `POST /api/v1/user/repos` | 403 | 200 |\n| `PATCH /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n| `DELETE /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n\nThe bypass respects the user\u0027s normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.\n\n### Impact\n\nAny OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:\n\n- Modify the victim\u0027s profile and settings\n- Add attacker-controlled email addresses to the victim\u0027s account\n- Create repositories as the victim\n- Modify or delete the victim\u0027s private repositories\n\nThe entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.",
"id": "GHSA-9r5x-wg6m-x2rc",
"modified": "2026-06-16T23:40:34Z",
"published": "2026-06-16T23:40:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-9r5x-wg6m-x2rc"
},
{
"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: OAuth2 access token scope enforcement bypass via HTTP Basic authentication"
}
GHSA-9R69-X87G-5765
Vulnerability from github – Published: 2026-06-15 15:31 – Updated: 2026-06-15 15:31WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.
{
"affected": [],
"aliases": [
"CVE-2016-20075"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T14:16:30Z",
"severity": "HIGH"
},
"details": "WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.",
"id": "GHSA-9r69-x87g-5765",
"modified": "2026-06-15T15:31:32Z",
"published": "2026-06-15T15:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20075"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40012"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/wordpress-ultimate-product-catalog-arbitrary-file-upload-rce"
},
{
"type": "WEB",
"url": "http://www.EtoileWebDesign.com"
}
],
"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:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-9R83-7XQ3-VJRP
Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30OpenClaw (npm package 'openclaw') before 2026.8.1 fails to revoke memory tool access when an operator hot-disables memory configuration. Existing memory_search and memory_get tool instances retain the enabled configuration captured at creation time because the execution-time resolver treats explicit disablement like an unavailable configuration snapshot and restores the stale authority. As a result, during an already-running agent turn the model can continue searching and reading durable memory after the operator revoked that access, for the remainder of that run. Exploitation requires memory to be disabled while a previously created memory tool remains active. The issue is fixed in 2026.8.1.
{
"affected": [],
"aliases": [
"CVE-2026-100539"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-26T03:16:59Z",
"severity": "LOW"
},
"details": "OpenClaw (npm package \u0027openclaw\u0027) before 2026.8.1 fails to revoke memory tool access when an operator hot-disables memory configuration. Existing memory_search and memory_get tool instances retain the enabled configuration captured at creation time because the execution-time resolver treats explicit disablement like an unavailable configuration snapshot and restores the stale authority. As a result, during an already-running agent turn the model can continue searching and reading durable memory after the operator revoked that access, for the remainder of that run. Exploitation requires memory to be disabled while a previously created memory tool remains active. The issue is fixed in 2026.8.1.",
"id": "GHSA-9r83-7xq3-vjrp",
"modified": "2026-09-26T03:30:24Z",
"published": "2026-09-26T03:30:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-chr6-w4m5-57fv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100539"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-before-2026.8.1-memory-access-control-bypass"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-9R89-C96G-GF22
Vulnerability from github – Published: 2023-02-18 00:31 – Updated: 2023-02-28 21:30TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.
{
"affected": [],
"aliases": [
"CVE-2023-23064"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-17T22:15:00Z",
"severity": "CRITICAL"
},
"details": "TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.",
"id": "GHSA-9r89-c96g-gf22",
"modified": "2023-02-28T21:30:16Z",
"published": "2023-02-18T00:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23064"
},
{
"type": "WEB",
"url": "https://github.com/shellpei/TOTOLINK-Unauthorized/blob/main/CVE-2023-23064"
}
],
"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-9R8R-X3VG-6XH4
Vulnerability from github – Published: 2026-05-15 21:31 – Updated: 2026-06-09 00:01Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.
Original Description
phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpMyFAQ/phpMyFAQ"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpMyFAQ"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T20:53:52Z",
"nvd_published_at": "2026-05-15T19:17:01Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.\n\n### Original Description\nphpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.",
"id": "GHSA-9r8r-x3vg-6xh4",
"modified": "2026-06-09T00:01:42Z",
"published": "2026-05-15T21:31:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-jrc5-w569-h7h5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45009"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/phpmyfaq-insufficient-authorization-check-in-admin-api-endpoints"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check",
"withdrawn": "2026-06-09T00:01:42Z"
}
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.