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.
5678 vulnerabilities reference this CWE, most recent first.
GHSA-3PMR-X3J2-FF44
Vulnerability from github – Published: 2022-07-06 00:00 – Updated: 2022-07-12 00:00In OpenCTI through 5.2.4, a broken access control vulnerability has been identified in the profile endpoint. An attacker can abuse the identified vulnerability in order to arbitrarily change their registered e-mail address as well as their API key, even though such action is not possible through the interface, legitimately.
{
"affected": [],
"aliases": [
"CVE-2022-30290"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-05T13:15:00Z",
"severity": "HIGH"
},
"details": "In OpenCTI through 5.2.4, a broken access control vulnerability has been identified in the profile endpoint. An attacker can abuse the identified vulnerability in order to arbitrarily change their registered e-mail address as well as their API key, even though such action is not possible through the interface, legitimately.",
"id": "GHSA-3pmr-x3j2-ff44",
"modified": "2022-07-12T00:00:57Z",
"published": "2022-07-06T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30290"
},
{
"type": "WEB",
"url": "https://github.com/OpenCTI-Platform/opencti/releases"
},
{
"type": "WEB",
"url": "https://www.enisa.europa.eu/topics/threat-risk-management/vulnerability-disclosure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3PWW-VCVM-3GMJ
Vulnerability from github – Published: 2026-07-21 20:30 – Updated: 2026-07-21 20:30Summary
A Gitea personal access token (PAT) restricted to a non-repository scope (e.g. read:issue) can read the commit history of any private repository the token owner can access, via the repository RSS/Atom feed endpoints. The same token is correctly denied (403) on /raw, /media, /archive, and the contents API. It leaks commit SHAs, full commit messages (which frequently contain secrets and internal context), and committer name + email.
Details
Gitea enforces PAT scope on repository-content endpoints via checkDownloadTokenScope() (added in PR #37698, extended to the archive endpoint by the CVE-2026-20706 fix in 1.26.2). The RSS/Atom feed handlers were never included: they (a) opt into PAT auth via webAuth.AllowBasic, (b) serve private-repo content, but (c) never call checkDownloadTokenScope().
Affected handlers (all carry AllowBasic, none call the scope check):
- RenderBranchFeedRSS/Atom - routers/web/feed/render.go (last 10 commits: SHA, title, full message, committer name + email)
- ShowFileFeed - routers/web/feed/file.go (per-file commit history)
- repo activity feed /{owner}/{repo}.rss / .atom
- TagsListFeedRSS/Atom, ReleasesFeedRSS/Atom - routers/web/repo/release.go
Root cause: routers/web/web.go registers the feed routes with webAuth.AllowBasic so a PAT authenticates, but the unit-permission middleware only checks the user's access, not the token's scope. checkDownloadTokenScope (routers/web/repo/download.go and the archive Download in repo.go) exists to close exactly that gap and is absent from the feed handlers. Same class as the recently fixed download/archive bypasses (GHSA-cr4g-f395-h25h / CVE-2026-20706); the feeds are the surface those fixes missed.
PoC
Tested on gitea/gitea:1.26.2-rootless, confirmed present at main HEAD (9608cc2, 2026-06-13).
1. User carol owns private repo carol/priv with a commit (message: "add confidential secret").
2. Create a PAT scoped to issues only, no repository scope:
curl -u carol:PASS -X POST $HOST/api/v1/users/carol/tokens -d '{"name":"t","scopes":["read:issue"]}'
3. Scope-enforcing sibling correctly denies it:
curl -u carol:$TOK $HOST/carol/priv/raw/branch/main/secret.txt -> 403
4. The feed leaks private data with the same token:
curl -u carol:$TOK $HOST/carol/priv/rss/branch/main -> 200, returns
<description>add confidential secret ... this commit message itself is sensitive</description>
| Auth (same read:issue token) | /raw/branch/main/secret.txt | /rss/branch/main |
|---|---|---|
| anonymous | - | 404 (private repo hidden) |
| invalid token | - | 401 |
| read:issue token (no repo scope) | 403 (scope enforced) | 200 + private commit data |
| full-scope token | 200 | 200 (legitimate) |
Impact
PATs are routinely issued narrowly and handed to third-party bots, CI jobs, or chat integrations that are meant to have no code access. This bypass lets such a token exfiltrate private-repository commit history (messages often hold secrets, ticket refs, internal context) and committer emails for every repository the owner can read. Confidentiality only; no integrity or availability impact. Preconditions: a valid PAT of any non-repository scope owned by a user with read access to the target private repo, and feeds enabled (Other.EnableFeed, default ON).
Suggested fix: call checkDownloadTokenScope(ctx) at the start of each feed handler (mirroring download.go). Longer-term, enforce repository token scope in a single route-group middleware wherever AllowBasic / AllowOAuth2 is set on a repo-content route, so the next added endpoint cannot miss it.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.26.2"
},
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27761"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:30:11Z",
"nvd_published_at": "2026-07-03T21:16:58Z",
"severity": "MODERATE"
},
"details": "### Summary\nA Gitea personal access token (PAT) restricted to a non-repository scope (e.g. `read:issue`) can read the commit history of any private repository the token owner can access, via the repository RSS/Atom feed endpoints. The same token is correctly denied (403) on `/raw`, `/media`, `/archive`, and the contents API. It leaks commit SHAs, full commit messages (which frequently contain secrets and internal context), and committer name + email.\n\n### Details\nGitea enforces PAT scope on repository-content endpoints via `checkDownloadTokenScope()` (added in PR #37698, extended to the archive endpoint by the CVE-2026-20706 fix in 1.26.2). The RSS/Atom feed handlers were never included: they (a) opt into PAT auth via `webAuth.AllowBasic`, (b) serve private-repo content, but (c) never call `checkDownloadTokenScope()`.\n\nAffected handlers (all carry `AllowBasic`, none call the scope check):\n- `RenderBranchFeedRSS/Atom` - `routers/web/feed/render.go` (last 10 commits: SHA, title, full message, committer name + email)\n- `ShowFileFeed` - `routers/web/feed/file.go` (per-file commit history)\n- repo activity feed `/{owner}/{repo}.rss` / `.atom`\n- `TagsListFeedRSS/Atom`, `ReleasesFeedRSS/Atom` - `routers/web/repo/release.go`\n\nRoot cause: `routers/web/web.go` registers the feed routes with `webAuth.AllowBasic` so a PAT authenticates, but the unit-permission middleware only checks the user\u0027s access, not the token\u0027s scope. `checkDownloadTokenScope` (`routers/web/repo/download.go` and the archive `Download` in `repo.go`) exists to close exactly that gap and is absent from the feed handlers. Same class as the recently fixed download/archive bypasses (GHSA-cr4g-f395-h25h / CVE-2026-20706); the feeds are the surface those fixes missed.\n\n### PoC\nTested on `gitea/gitea:1.26.2-rootless`, confirmed present at `main` HEAD (9608cc2, 2026-06-13).\n1. User `carol` owns private repo `carol/priv` with a commit (message: \"add confidential secret\").\n2. Create a PAT scoped to issues only, no repository scope:\n `curl -u carol:PASS -X POST $HOST/api/v1/users/carol/tokens -d \u0027{\"name\":\"t\",\"scopes\":[\"read:issue\"]}\u0027`\n3. Scope-enforcing sibling correctly denies it:\n `curl -u carol:$TOK $HOST/carol/priv/raw/branch/main/secret.txt` -\u003e 403\n4. The feed leaks private data with the same token:\n `curl -u carol:$TOK $HOST/carol/priv/rss/branch/main` -\u003e 200, returns\n `\u003cdescription\u003eadd confidential secret ... this commit message itself is sensitive\u003c/description\u003e`\n\n| Auth (same read:issue token) | /raw/branch/main/secret.txt | /rss/branch/main |\n|---|---|---|\n| anonymous | - | 404 (private repo hidden) |\n| invalid token | - | 401 |\n| read:issue token (no repo scope) | 403 (scope enforced) | 200 + private commit data |\n| full-scope token | 200 | 200 (legitimate) |\n\n### Impact\nPATs are routinely issued narrowly and handed to third-party bots, CI jobs, or chat integrations that are meant to have no code access. This bypass lets such a token exfiltrate private-repository commit history (messages often hold secrets, ticket refs, internal context) and committer emails for every repository the owner can read. Confidentiality only; no integrity or availability impact. Preconditions: a valid PAT of any non-repository scope owned by a user with read access to the target private repo, and feeds enabled (`Other.EnableFeed`, default ON).\n\nSuggested fix: call `checkDownloadTokenScope(ctx)` at the start of each feed handler (mirroring `download.go`). Longer-term, enforce repository token scope in a single route-group middleware wherever `AllowBasic` / `AllowOAuth2` is set on a repo-content route, so the next added endpoint cannot miss it.",
"id": "GHSA-3pww-vcvm-3gmj",
"modified": "2026-07-21T20:30:11Z",
"published": "2026-07-21T20:30:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-3pww-vcvm-3gmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27761"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38147"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/9e84deb969aff5c1115c2984e41250f28c78451f"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.3"
}
],
"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"
}
],
"summary": "Gitea: API access token scope enforcement bypass on repository RSS/Atom feed endpoints leaks private repository commit data"
}
GHSA-3PX7-C4J3-576R
Vulnerability from github – Published: 2025-06-02 12:30 – Updated: 2025-06-05 01:04A security vulnerability in the /apis/dashboard.grafana.app/* endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1).
Impact:
-
Viewers can view all dashboards/folders regardless of permissions
-
Editors can view/edit/delete all dashboards/folders regardless of permissions
-
Editors can create dashboards in any folder regardless of permissions
-
Anonymous users with viewer/editor roles are similarly affected
Organization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/grafana/grafana"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20250114093457-36d6fad421fb"
},
{
"fixed": "0.0.0-20250521183405-c7a690348df7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-3260"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-05T01:03:59Z",
"nvd_published_at": "2025-06-02T10:15:21Z",
"severity": "HIGH"
},
"details": "A security vulnerability in the /apis/dashboard.grafana.app/* endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1).\n\nImpact:\n\n- Viewers can view all dashboards/folders regardless of permissions\n\n- Editors can view/edit/delete all dashboards/folders regardless of permissions\n\n- Editors can create dashboards in any folder regardless of permissions\n\n- Anonymous users with viewer/editor roles are similarly affected\n\nOrganization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.",
"id": "GHSA-3px7-c4j3-576r",
"modified": "2025-06-05T01:04:00Z",
"published": "2025-06-02T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3260"
},
{
"type": "PACKAGE",
"url": "https://github.com/grafana/grafana"
},
{
"type": "WEB",
"url": "https://github.com/grafana/grafana/blob/be8d153dc33734caba4f617ff571d18253e68fa0/CHANGELOG.md#1161-2025-04-23"
},
{
"type": "WEB",
"url": "https://grafana.com/blog/2025/04/22/grafana-security-release-medium-and-high-severity-fixes-for-cve-2025-3260-cve-2025-2703-cve-2025-3454"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/CVE-2025-3260"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Grafana vulnerable to authenticated users bypassing dashboard, folder permissions"
}
GHSA-3PX8-7PJ4-M3R5
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05Information exposure vulnerability in Gear S Plugin prior to version 2.2.05.20122441 allows unstrusted applications to access connected BT device information.
{
"affected": [],
"aliases": [
"CVE-2021-25406"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T15:15:00Z",
"severity": "MODERATE"
},
"details": "Information exposure vulnerability in Gear S Plugin prior to version 2.2.05.20122441 allows unstrusted applications to access connected BT device information.",
"id": "GHSA-3px8-7pj4-m3r5",
"modified": "2022-05-24T19:05:08Z",
"published": "2022-05-24T19:05:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25406"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=5"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3Q29-6C6H-84HH
Vulnerability from github – Published: 2022-07-15 00:00 – Updated: 2022-07-26 00:01The Guest account feature in Mattermost version 6.7.0 and earlier fails to properly restrict the permissions, which allows a guest user to fetch a list of all public channels in the team, in spite of not being part of those channels.
{
"affected": [],
"aliases": [
"CVE-2022-2408"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-668",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-14T18:15:00Z",
"severity": "MODERATE"
},
"details": "The Guest account feature in Mattermost version 6.7.0 and earlier fails to properly restrict the permissions, which allows a guest user to fetch a list of all public channels in the team, in spite of not being part of those channels.",
"id": "GHSA-3q29-6c6h-84hh",
"modified": "2022-07-26T00:01:03Z",
"published": "2022-07-15T00:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2408"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3Q2P-72CJ-682C
Vulnerability from github – Published: 2026-06-12 21:07 – Updated: 2026-07-21 14:45Summary
This is similar vulnrability of CVE-2026-0035, which was fixed in Android MediaProvider with high severity. In the original Java issue, MediaStore.createWriteRequest() accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.
filebrowser/filebrowser has the analogous issue in Go. POST /api/share/<path> accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through GET /api/public/dl/<hash>.
Details
The vulnerable create path is:
http/share.gosharePostHandler()- route:
POST /api/share/<path>
sharePostHandler() only checks that the caller is authenticated and has share/download permissions. It then builds a share.Link directly from r.URL.Path and saves it:
s = &share.Link{
Path: r.URL.Path,
Hash: str,
Expire: expire,
UserID: d.user.ID,
PasswordHash: string(hash),
Token: token,
}
if err := d.store.Share.Save(s); err != nil {
return http.StatusInternalServerError, err
}
There is no Stat, Exists, or equivalent check before the public share record is committed.
The vulnerable consume path is:
http/public.gowithHashFile()- routes:
GET /api/public/share/<hash>,GET /api/public/dl/<hash>
Each public request loads the saved share by hash and then resolves link.Path against the owner's current filesystem state:
file, err := files.NewFileInfo(&files.FileOptions{
Fs: d.user.Fs,
Path: link.Path,
...
})
This means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.
PoC
The PoC below starts from external HTTP input only.
- Authenticate to File Browser.
- Confirm
/future4.txtdoes not exist. - Create a public share for
/future4.txtanyway. - Confirm the public share returns
404. - Upload a file to
/future4.txt. - Reuse the same public share URL and read the file content.
Reproduction commands:
TOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \
-H 'Content-Type: application/json' \
-d '{"username":"admin","password":"Password123!"}')
curl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \
-H "X-Auth: $TOKEN" \
-H 'Content-Type: application/json' \
-d '{}'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
curl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \
-H "X-Auth: $TOKEN" \
--data-binary 'fourth-secret'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
Impact
An authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.
Reference
Original CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.6"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54096"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-668",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T21:07:55Z",
"nvd_published_at": "2026-06-25T19:16:41Z",
"severity": "HIGH"
},
"details": "### Summary\nThis is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.\n\n`filebrowser/filebrowser` has the analogous issue in Go. `POST /api/share/\u003cpath\u003e` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/\u003chash\u003e`.\n\n### Details\nThe vulnerable create path is:\n\n- `http/share.go`\n- `sharePostHandler()`\n- route: `POST /api/share/\u003cpath\u003e`\n\n`sharePostHandler()` only checks that the caller is authenticated and has share/download permissions. It then builds a `share.Link` directly from `r.URL.Path` and saves it:\n\n```go\ns = \u0026share.Link{\n Path: r.URL.Path,\n Hash: str,\n Expire: expire,\n UserID: d.user.ID,\n PasswordHash: string(hash),\n Token: token,\n}\n\nif err := d.store.Share.Save(s); err != nil {\n return http.StatusInternalServerError, err\n}\n```\n\nThere is no `Stat`, `Exists`, or equivalent check before the public share record is committed.\n\nThe vulnerable consume path is:\n\n- `http/public.go`\n- `withHashFile()`\n- routes: `GET /api/public/share/\u003chash\u003e`, `GET /api/public/dl/\u003chash\u003e`\n\nEach public request loads the saved share by hash and then resolves `link.Path` against the owner\u0027s current filesystem state:\n\n```go\nfile, err := files.NewFileInfo(\u0026files.FileOptions{\n Fs: d.user.Fs,\n Path: link.Path,\n ...\n})\n```\n\nThis means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.\n\n\n### PoC\nThe PoC below starts from external HTTP input only.\n\n1. Authenticate to File Browser.\n2. Confirm `/future4.txt` does not exist.\n3. Create a public share for `/future4.txt` anyway.\n4. Confirm the public share returns `404`.\n5. Upload a file to `/future4.txt`.\n6. Reuse the same public share URL and read the file content.\n\nReproduction commands:\n\n```bash\nTOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"admin\",\"password\":\"Password123!\"}\u0027)\n\ncurl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{}\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n\ncurl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n --data-binary \u0027fourth-secret\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n```\n\n\n### Impact\nAn authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.\n\n### Reference\n\nOriginal CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035",
"id": "GHSA-3q2p-72cj-682c",
"modified": "2026-07-21T14:45:00Z",
"published": "2026-06-12T21:07:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3q2p-72cj-682c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54096"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/166583db632e088e9f0adce30aec43bb9d9019f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path"
}
GHSA-3Q3M-HFJX-W733
Vulnerability from github – Published: 2024-11-01 06:30 – Updated: 2024-11-01 06:30Sysmac Studio provided by OMRON Corporation contains an incorrect authorization vulnerability. If this vulnerability is exploited, an attacker may access the program which is protected by Data Protection function.
{
"affected": [],
"aliases": [
"CVE-2024-49501"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T05:15:06Z",
"severity": "MODERATE"
},
"details": "Sysmac Studio provided by OMRON Corporation contains an incorrect authorization vulnerability. If this vulnerability is exploited, an attacker may access the program which is protected by Data Protection function.",
"id": "GHSA-3q3m-hfjx-w733",
"modified": "2024-11-01T06:30:35Z",
"published": "2024-11-01T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49501"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU95685374"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/en/OMSR-2024-006_en.pdf"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/ja/OMSR-2024-006_ja.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3Q79-GJF7-RWWF
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-10-25 19:00ZStack is open source IaaS(infrastructure as a service) software aiming to automate datacenters, managing resources of compute, storage, and networking all by APIs. Affected versions of ZStack REST API are vulnerable to post-authentication Remote Code Execution (RCE) via bypass of the Groovy shell sandbox. The REST API exposes the GET zstack/v1/batch-queries?script endpoint which is backed up by the BatchQueryAction class. Messages are represented by the APIBatchQueryMsg, dispatched to the QueryFacadeImpl facade and handled by the BatchQuery class. The HTTP request parameter script is mapped to the APIBatchQueryMsg.script property and evaluated as a Groovy script in BatchQuery.query the evaluation of the user-controlled Groovy script is sandboxed by SandboxTransformer which will apply the restrictions defined in the registered (sandbox.register()) GroovyInterceptor. Even though the sandbox heavily restricts the receiver types to a small set of allowed types, the sandbox is non effective at controlling any code placed in Java annotations and therefore vulnerable to meta-programming escapes. This issue leads to post-authenticated remote code execution. For more details see the referenced GHSL-2021-065. This issue is patched in versions 3.8.21, 3.10.8, and 4.1.0.
{
"affected": [],
"aliases": [
"CVE-2021-32829"
],
"database_specific": {
"cwe_ids": [
"CWE-863",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-17T16:15:00Z",
"severity": "CRITICAL"
},
"details": "ZStack is open source IaaS(infrastructure as a service) software aiming to automate datacenters, managing resources of compute, storage, and networking all by APIs. Affected versions of ZStack REST API are vulnerable to post-authentication Remote Code Execution (RCE) via bypass of the Groovy shell sandbox. The REST API exposes the GET zstack/v1/batch-queries?script endpoint which is backed up by the BatchQueryAction class. Messages are represented by the APIBatchQueryMsg, dispatched to the QueryFacadeImpl facade and handled by the BatchQuery class. The HTTP request parameter script is mapped to the APIBatchQueryMsg.script property and evaluated as a Groovy script in BatchQuery.query the evaluation of the user-controlled Groovy script is sandboxed by SandboxTransformer which will apply the restrictions defined in the registered (sandbox.register()) GroovyInterceptor. Even though the sandbox heavily restricts the receiver types to a small set of allowed types, the sandbox is non effective at controlling any code placed in Java annotations and therefore vulnerable to meta-programming escapes. This issue leads to post-authenticated remote code execution. For more details see the referenced GHSL-2021-065. This issue is patched in versions 3.8.21, 3.10.8, and 4.1.0.",
"id": "GHSA-3q79-gjf7-rwwf",
"modified": "2022-10-25T19:00:31Z",
"published": "2022-05-24T19:11:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zstackio/zstack/security/advisories/GHSA-6xgq-7rqg-x3q5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32829"
},
{
"type": "WEB",
"url": "https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2021-065-zstack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3Q9F-2CP9-WP8V
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-07-13 00:00Improper access control in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0151"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-17T20:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-3q9f-2cp9-wp8v",
"modified": "2022-07-13T00:00:58Z",
"published": "2022-05-24T19:20:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0151"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00540.html"
}
],
"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-3QHG-XWPV-HRWG
Vulnerability from github – Published: 2022-03-19 00:00 – Updated: 2022-03-29 00:01This issue was addressed with improved checks. This issue is fixed in watchOS 8.5, iOS 15.4 and iPadOS 15.4. A user may be able to bypass the Emergency SOS passcode prompt.
{
"affected": [],
"aliases": [
"CVE-2022-22618"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-18T18:15:00Z",
"severity": "HIGH"
},
"details": "This issue was addressed with improved checks. This issue is fixed in watchOS 8.5, iOS 15.4 and iPadOS 15.4. A user may be able to bypass the Emergency SOS passcode prompt.",
"id": "GHSA-3qhg-xwpv-hrwg",
"modified": "2022-03-29T00:01:33Z",
"published": "2022-03-19T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22618"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213182"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213193"
}
],
"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"
}
]
}
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.