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.
6554 vulnerabilities reference this CWE, most recent first.
GHSA-W8GR-F976-PQPF
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47Improper authorization involving a fuse in TrustZone in snapdragon automobile, snapdragon mobile and snapdragon wear in versions MDM9206, MDM9607, MSM8996AU, SD 210/SD 212/SD 205, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 439 / SD 429, SD 450, SD 615/16/SD 415, SD 625, SD 632, SD 636, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SDA660, SDM439, SDM630, SDM660, SDX24, Snapdragon_High_Med_2016.
{
"affected": [],
"aliases": [
"CVE-2017-8276"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-18T22:29:00Z",
"severity": "HIGH"
},
"details": "Improper authorization involving a fuse in TrustZone in snapdragon automobile, snapdragon mobile and snapdragon wear in versions MDM9206, MDM9607, MSM8996AU, SD 210/SD 212/SD 205, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 439 / SD 429, SD 450, SD 615/16/SD 415, SD 625, SD 632, SD 636, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SDA660, SDM439, SDM630, SDM660, SDX24, Snapdragon_High_Med_2016.",
"id": "GHSA-w8gr-f976-pqpf",
"modified": "2022-05-13T01:47:26Z",
"published": "2022-05-13T01:47:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8276"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106128"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W8GV-53R7-FPH6
Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-11-03 21:32Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
{
"affected": [],
"aliases": [
"CVE-2025-21567"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T21:15:23Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).",
"id": "GHSA-w8gv-53r7-fph6",
"modified": "2025-11-03T21:32:22Z",
"published": "2025-01-21T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21567"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250124-0014"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2025.html"
}
],
"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-W8PX-4RP9-9F6W
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13The shareinfo controller in the ownCloud Server before 10.8.0 allows an attacker to bypass the permission checks for upload only shares and list metadata about the share.
{
"affected": [],
"aliases": [
"CVE-2021-35949"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-07T19:15:00Z",
"severity": "MODERATE"
},
"details": "The shareinfo controller in the ownCloud Server before 10.8.0 allows an attacker to bypass the permission checks for upload only shares and list metadata about the share.",
"id": "GHSA-w8px-4rp9-9f6w",
"modified": "2022-05-24T19:13:08Z",
"published": "2022-05-24T19:13:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35949"
},
{
"type": "WEB",
"url": "https://doc.owncloud.com/server/admin_manual/release_notes.html"
},
{
"type": "WEB",
"url": "https://owncloud.com/security-advisories/cve-2021-35949"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W8WF-3QVJ-6XQF
Vulnerability from github – Published: 2026-09-03 17:33 – Updated: 2026-09-03 17:33Summary
Feishu permission tools could ignore per-account disablement. In affected versions, a lower-trust caller or configured input path could perform actions that should have required a stronger authorization or policy check.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
Impact
When the affected feature is enabled and reachable, this could perform actions that should have required a stronger authorization or policy check. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
Patched Versions
The first stable patched version is 2026.6.9.
Mitigations
Upgrade to a patched OpenClaw release when one is listed. Before upgrading, restrict the affected feature to trusted operators or disable it when it is not needed. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2026.6.9-beta.1"
},
"package": {
"ecosystem": "npm",
"name": "@openclaw/feishu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.6.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T17:33:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nFeishu permission tools could ignore per-account disablement. In affected versions, a lower-trust caller or configured input path could perform actions that should have required a stronger authorization or policy check.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could perform actions that should have required a stronger authorization or policy check. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.6.9`.\n\n### Mitigations\n\nUpgrade to a patched OpenClaw release when one is listed. Before upgrading, restrict the affected feature to trusted operators or disable it when it is not needed. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
"id": "GHSA-w8wf-3qvj-6xqf",
"modified": "2026-09-03T17:33:19Z",
"published": "2026-09-03T17:33:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w8wf-3qvj-6xqf"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/pull/93363"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/d4f11d3005a56abc709ebc8e715972593ebed96e"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.6.9-beta.1"
}
],
"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": "OpenClaw Feishu permission tools could ignore per-account disablement"
}
GHSA-W8WJ-7HCM-8QPR
Vulnerability from github – Published: 2024-10-11 21:31 – Updated: 2024-10-15 21:30An issue in BURG-WCHTER KG de.burgwachter.keyapp.app 4.5.0 allows a remote attacker to obtain sensitve information via the firmware update process.
{
"affected": [],
"aliases": [
"CVE-2024-48769"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T20:15:05Z",
"severity": "CRITICAL"
},
"details": "An issue in BURG-WCHTER KG de.burgwachter.keyapp.app 4.5.0 allows a remote attacker to obtain sensitve information via the firmware update process.",
"id": "GHSA-w8wj-7hcm-8qpr",
"modified": "2024-10-15T21:30:37Z",
"published": "2024-10-11T21:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48769"
},
{
"type": "WEB",
"url": "https://github.com/HankJames/Vul-Reports/blob/main/FirmwareLeakage/de.burgwachter.keyapp.app/de.burgwachter.keyapp.md"
},
{
"type": "WEB",
"url": "http://burg-wchter.com"
},
{
"type": "WEB",
"url": "http://deburgwachterkeyappapp.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W8X7-H2PX-XMQ8
Vulnerability from github – Published: 2026-07-24 20:49 – Updated: 2026-07-24 20:49Summary
When an authenticated recipient of a single-file share opens the file event stream (GET /api/v4/file/events?uri=<share-root>), Cloudreve validates the URI by listing it and then subscribes the caller to parent.ID(). For a single-file share, the share navigator resolves the bare share-root URI to the owner-side parent folder of the shared file (not the file), while the visible listing is filtered down to just the shared file. The event hub then keys topics by numeric file ID only and, on each file change, fans the event out to subscribers of every ancestor topic, filtering only the client ID that caused the event — never the subscriber's share scope.
Consequently, a recipient of one shared file can receive Server-Sent Events (type, sibling path/name, rename target, hashed file ID) for other files and subfolders in the owner's parent folder that were never shared. Contents are not disclosed; file-activity metadata is.
Details
Root cause (verified at 26b6b10)
1. Events route — authenticated, feature-flagged, no share-scope check (routers/router.go):
file := v4.Group("file"); file.Use(middleware.RequiredScopes(types.ScopeFilesRead))
file.GET("events",
middleware.LoginRequired(),
middleware.IsFunctionEnabled(func(c *gin.Context) bool { return dep.SettingProvider().EventHubEnabled(c) }),
controllers.FromQuery[explorer.ExplorerEventService](...), controllers.HandleExplorerEventsPush)
EventHubEnabled defaults true (inventory/setting.go: "fs_event_push_enabled":"1").
2. Service subscribes to the listed parent's ID (service/explorer/events.go):
parent, _, err := m.List(c, uri, &manager.ListArgs{Page:0, PageSize:1}) // also runs share validity/password
...
rx, resumed, err := eventHub.Subscribe(c, parent.ID(), requestInfo.ClientID)
3. Single-file share Root swaps the share root to the owner parent (share_navigator.go):
n.shareRoot = newFile(nil, share.Edges.File)
...
if n.shareRoot.Type() == types.FileTypeFile {
n.singleFileShare = true
n.shareRoot = n.shareRoot.Parent // <-- owner-side parent folder
}
4. To returns that parent for the bare root URI (share_navigator.go):
elements := path.Elements()
if len(elements) == 1 && n.singleFileShare { return latestSharedSingleFile(...) } // only when URI names the file
...
return current // current == shareRoot == owner parent folder
The bare root share URI has zero path elements (URI.Elements() returns nil for path /), so the len(elements)==1 guard is skipped and To returns the parent folder. dbfs.List returns that as parent, so parent.ID() is the owner parent folder's real ID.
5. Children masks the broader parent — for singleFileShare it returns only []*File{sharedFile}, so the recipient's listing shows just the shared file even though the subscribed topic is the whole parent.
6. Publication fans out to ancestor topics with only a client-ID filter (dbfs/events.go):
func (f *DBFS) getEligibleSubscriber(ctx, file, checkParentPerm) []foundSubscriber {
roots := file.Ancestors()
for _, root := range roots {
subscribers := f.eventHub.GetSubscribers(ctx, root.Model.ID)
subscribers = lo.Filter(subscribers, func(s eventhub.Subscriber, _ int) bool {
return !(requestInfo != nil && s.ID() == requestInfo.ClientID) // ONLY exclude the causing client
})
...
}
}
// emit*: From: subscriber.relativePath(file) // owner-side path of the changed sibling
relativePath trims the changed file's owner path by the subscribed root's owner path, yielding the sibling's name (e.g. /Secret-Plan.pdf). No check that the subscriber is authorized for the changed file or within their share scope.
Validation performed
Independent validation against commit 26b6b10 in a clean sandbox.
Source-verified (static): all of (1)–(6) confirmed verbatim, including the negative direction (an explicit …/shared.txt URI resolves to the file, and oss/qiniu-style flows are irrelevant here).
Dynamic (control-flow executed): the full binary is not buildable offline (modules behind an unreachable proxy, embedded frontend, DB/eventhub). The reseacher ran two harnesses:
- A net/url-based check of the linchpin — the bare root share URI yields 0 path elements (so To returns the parent), while …/shared.txt yields 1 (returns the file). This is the subtle point on which the whole finding turns, and it holds.
- A model of Root/To/getEligibleSubscriber/relativePath driving the end-to-end flow:
[1] single-file share root URI -> m.List parent = "docs" (id 10), NOT shared.txt (id 11) -> subscribed to owner parent
[2] owner renames /docs/Secret-Plan.pdf -> client 'attacker' receives: from="/Secret-Plan.pdf" file_id=12 (topic 10)
[3] CONTROL: event caused by attacker's own client id -> suppressed (the only filter)
[4] CONTROL: explicit URI 'shared.txt' -> resolves to file (id 11) -> no sibling events
Steps to reproduce
- Owner shares a single file
shared.txtfrom/docs, which also containsSecret-Plan.pdf. - Recipient (logged-in,
Files.Read, with the share password if any) opens the event stream on the share root:GET /api/v4/file/events?uri=cloudreve%3A%2F%2F<share-id>%40share Cookie: cloudreve-session=<recipient-session> X-Cr-Client-Id: <uuid> Accept: text/event-stream - Owner creates/renames/modifies/moves/deletes
Secret-Plan.pdf. - The recipient's stream receives, e.g.:
event: event data: {"type":"rename","file_id":"<hashed>","from":"/Secret-Plan.pdf","to":"/Secret-Plan-v2.pdf"}
Expected: the recipient only receives events for the shared file. Actual: the recipient receives activity events for unshared siblings in the owner's parent folder.
Impact
A single-file share recipient gains a real-time feed of file-activity metadata for the owner's parent folder — sibling names, operation types, and rename targets they were never granted access to. No file contents are exposed.
Remediation
- For single-file shares, subscribe to the shared file's ID, or reject event subscriptions on the single-file share root view.
- Store an authorization scope (navigator/share root) per subscriber and publish only events whose path stays within that scope.
- Incorporate user/share scope into topic keys, not just file ID + client ID.
- On subscriber reactivation, re-verify the requester still matches the subscriber and is authorized for the topic.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260613030215-0b00dd308f13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.0.0-20250225100611-da4e44b77af4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55499"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T20:49:02Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n \nWhen an authenticated recipient of a **single-file** share opens the file event stream (`GET /api/v4/file/events?uri=\u003cshare-root\u003e`), Cloudreve validates the URI by listing it and then subscribes the caller to `parent.ID()`. For a single-file share, the share navigator resolves the bare share-root URI to the **owner-side parent folder** of the shared file (not the file), while the visible listing is filtered down to just the shared file. The event hub then keys topics by numeric file ID only and, on each file change, fans the event out to subscribers of **every ancestor topic**, filtering only the client ID that caused the event \u2014 never the subscriber\u0027s share scope.\n \nConsequently, a recipient of one shared file can receive Server-Sent Events (type, sibling path/name, rename target, hashed file ID) for other files and subfolders in the owner\u0027s parent folder that were never shared. Contents are not disclosed; file-activity metadata is.\n\n### Details\n## Root cause (verified at `26b6b10`)\n \n**1. Events route \u2014 authenticated, feature-flagged, no share-scope check** (`routers/router.go`):\n```go\nfile := v4.Group(\"file\"); file.Use(middleware.RequiredScopes(types.ScopeFilesRead))\nfile.GET(\"events\",\n middleware.LoginRequired(),\n middleware.IsFunctionEnabled(func(c *gin.Context) bool { return dep.SettingProvider().EventHubEnabled(c) }),\n controllers.FromQuery[explorer.ExplorerEventService](...), controllers.HandleExplorerEventsPush)\n```\n`EventHubEnabled` defaults `true` (`inventory/setting.go: \"fs_event_push_enabled\":\"1\"`).\n \n**2. Service subscribes to the listed parent\u0027s ID** (`service/explorer/events.go`):\n```go\nparent, _, err := m.List(c, uri, \u0026manager.ListArgs{Page:0, PageSize:1}) // also runs share validity/password\n...\nrx, resumed, err := eventHub.Subscribe(c, parent.ID(), requestInfo.ClientID)\n```\n \n**3. Single-file share `Root` swaps the share root to the owner parent** (`share_navigator.go`):\n```go\nn.shareRoot = newFile(nil, share.Edges.File)\n...\nif n.shareRoot.Type() == types.FileTypeFile {\n n.singleFileShare = true\n n.shareRoot = n.shareRoot.Parent // \u003c-- owner-side parent folder\n}\n```\n \n**4. `To` returns that parent for the bare root URI** (`share_navigator.go`):\n```go\nelements := path.Elements()\nif len(elements) == 1 \u0026\u0026 n.singleFileShare { return latestSharedSingleFile(...) } // only when URI names the file\n...\nreturn current // current == shareRoot == owner parent folder\n```\nThe bare root share URI has **zero** path elements (`URI.Elements()` returns nil for path `/`), so the `len(elements)==1` guard is skipped and `To` returns the parent folder. `dbfs.List` returns that as `parent`, so `parent.ID()` is the owner parent folder\u0027s real ID.\n \n**5. `Children` masks the broader parent** \u2014 for `singleFileShare` it returns only `[]*File{sharedFile}`, so the recipient\u0027s listing shows just the shared file even though the subscribed topic is the whole parent.\n \n**6. Publication fans out to ancestor topics with only a client-ID filter** (`dbfs/events.go`):\n```go\nfunc (f *DBFS) getEligibleSubscriber(ctx, file, checkParentPerm) []foundSubscriber {\n roots := file.Ancestors()\n for _, root := range roots {\n subscribers := f.eventHub.GetSubscribers(ctx, root.Model.ID)\n subscribers = lo.Filter(subscribers, func(s eventhub.Subscriber, _ int) bool {\n return !(requestInfo != nil \u0026\u0026 s.ID() == requestInfo.ClientID) // ONLY exclude the causing client\n })\n ...\n }\n}\n// emit*: From: subscriber.relativePath(file) // owner-side path of the changed sibling\n```\n`relativePath` trims the changed file\u0027s owner path by the subscribed root\u0027s owner path, yielding the sibling\u0027s name (e.g. `/Secret-Plan.pdf`). No check that the subscriber is authorized for the changed file or within their share scope.\n \n## Validation performed\n \nIndependent validation against commit `26b6b10` in a clean sandbox.\n \n**Source-verified (static):** all of (1)\u2013(6) confirmed verbatim, including the negative direction (an explicit `\u2026/shared.txt` URI resolves to the file, and `oss`/`qiniu`-style flows are irrelevant here).\n \n**Dynamic (control-flow executed):** the full binary is not buildable offline (modules behind an unreachable proxy, embedded frontend, DB/eventhub). The reseacher ran two harnesses:\n- A `net/url`-based check of the linchpin \u2014 the bare root share URI yields `0` path elements (so `To` returns the parent), while `\u2026/shared.txt` yields `1` (returns the file). This is the subtle point on which the whole finding turns, and it holds.\n- A model of `Root`/`To`/`getEligibleSubscriber`/`relativePath` driving the end-to-end flow:\n```\n[1] single-file share root URI -\u003e m.List parent = \"docs\" (id 10), NOT shared.txt (id 11) -\u003e subscribed to owner parent\n[2] owner renames /docs/Secret-Plan.pdf -\u003e client \u0027attacker\u0027 receives: from=\"/Secret-Plan.pdf\" file_id=12 (topic 10)\n[3] CONTROL: event caused by attacker\u0027s own client id -\u003e suppressed (the only filter)\n[4] CONTROL: explicit URI \u0027shared.txt\u0027 -\u003e resolves to file (id 11) -\u003e no sibling events\n```\n\n## Steps to reproduce\n \n1. Owner shares a single file `shared.txt` from `/docs`, which also contains `Secret-Plan.pdf`.\n2. Recipient (logged-in, `Files.Read`, with the share password if any) opens the event stream on the share root:\n ```\n GET /api/v4/file/events?uri=cloudreve%3A%2F%2F\u003cshare-id\u003e%40share\n Cookie: cloudreve-session=\u003crecipient-session\u003e\n X-Cr-Client-Id: \u003cuuid\u003e\n Accept: text/event-stream\n ```\n3. Owner creates/renames/modifies/moves/deletes `Secret-Plan.pdf`.\n4. The recipient\u0027s stream receives, e.g.:\n ```\n event: event\n data: {\"type\":\"rename\",\"file_id\":\"\u003chashed\u003e\",\"from\":\"/Secret-Plan.pdf\",\"to\":\"/Secret-Plan-v2.pdf\"}\n ```\n \n**Expected:** the recipient only receives events for the shared file.\n**Actual:** the recipient receives activity events for unshared siblings in the owner\u0027s parent folder.\n \n## Impact\n \nA single-file share recipient gains a real-time feed of file-activity metadata for the owner\u0027s parent folder \u2014 sibling names, operation types, and rename targets they were never granted access to. No file contents are exposed.\n \n## Remediation\n \n- For single-file shares, subscribe to the shared file\u0027s ID, or reject event subscriptions on the single-file share root view.\n- Store an authorization scope (navigator/share root) per subscriber and publish only events whose path stays within that scope.\n- Incorporate user/share scope into topic keys, not just file ID + client ID.\n- On subscriber reactivation, re-verify the requester still matches the subscriber and is authorized for the topic.",
"id": "GHSA-w8x7-h2px-xmq8",
"modified": "2026-07-24T20:49:02Z",
"published": "2026-07-24T20:49:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-w8x7-h2px-xmq8"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/0b00dd308f132d6e6e8476857ef79f4865600bbc"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.17.0"
}
],
"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": "Cloudreve: Broken Access Control in file event stream: a single-file share recipient is subscribed to the owner\u0027s parent folder and receives activity events for unshared siblings"
}
GHSA-W927-CCXX-QVRJ
Vulnerability from github – Published: 2026-03-11 18:30 – Updated: 2026-03-11 18:30GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.1 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that, under certain conditions, could have allowed an authenticated user to access previous pipeline job information on projects with repository and CI/CD disabled due to improper authorization checks.
{
"affected": [],
"aliases": [
"CVE-2025-12555"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T17:16:50Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.1 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that, under certain conditions, could have allowed an authenticated user to access previous pipeline job information on projects with repository and CI/CD disabled due to improper authorization checks.",
"id": "GHSA-w927-ccxx-qvrj",
"modified": "2026-03-11T18:30:32Z",
"published": "2026-03-11T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12555"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3354642"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/03/11/patch-release-gitlab-18-9-2-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/579126"
}
],
"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-W942-J9R6-HR6R
Vulnerability from github – Published: 2026-04-23 21:24 – Updated: 2026-04-27 16:35TL;DR
This vulnerability affects all Kirby sites where users have the permission to create pages (pages.create permission is enabled) but not the permission to change the status of pages (pages.changeStatus permission is disabled). This can be due to configuration in the user blueprint(s), via options in the page blueprint(s) or via a combination of both settings.
Users' Kirby sites are not affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.
Introduction
An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.
The effects of an authorization bypass can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.
Impact
Kirby's user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (site/blueprints/users/...). It is also possible to customize the permissions for each target model in the model blueprints (such as in site/blueprints/pages/...) using the options feature. The permissions and options together control the authorization of user actions.
For pages, Kirby provides the pages.create and pages.changeStatus permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the changeStatus permission didn't take effect on page creation.
New pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the isDraft flag when creating a new page. This allowed authenticated attackers with the pages.create permission to immediately create published pages, bypassing the normal editorial workflow.
Patches
The problem has been patched in Kirby 4.9.0 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, Kirby has added a check to the page creation rules that ensures that users without the pages.changeStatus permission cannot create published pages, only page drafts.
Credits
Kirby thanks @offset for responsibly reporting the identified issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40099"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:24:58Z",
"nvd_published_at": "2026-04-24T01:16:12Z",
"severity": "MODERATE"
},
"details": "### TL;DR\n\nThis vulnerability affects all Kirby sites where users have the permission to create pages (`pages.create` permission is enabled) but not the permission to change the status of pages (`pages.changeStatus` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the page blueprint(s) or via a combination of both settings.\n\nUsers\u0027 Kirby sites are *not* affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.\n\n----\n\n### Introduction\n\nAn authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.\n\nThe effects of an authorization bypass can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.\n\n### Impact\n\nKirby\u0027s user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.\n\nFor pages, Kirby provides the `pages.create` and `pages.changeStatus` permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the `changeStatus` permission didn\u0027t take effect on page creation.\n\nNew pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the `isDraft` flag when creating a new page. This allowed authenticated attackers with the `pages.create` permission to immediately create published pages, bypassing the normal editorial workflow.\n\n### Patches\n\nThe problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn all of the mentioned releases, Kirby has added a check to the page creation rules that ensures that users without the `pages.changeStatus` permission cannot create published pages, only page drafts.\n\n### Credits\n\nKirby thanks @offset for responsibly reporting the identified issue.",
"id": "GHSA-w942-j9r6-hr6r",
"modified": "2026-04-27T16:35:48Z",
"published": "2026-04-23T21:24:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/security/advisories/GHSA-w942-j9r6-hr6r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40099"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkirby/kirby"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/4.9.0"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/5.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kirby\u0027s page creation API bypasses the changeStatus permission check via unfiltered isDraft parameter"
}
GHSA-W94X-H737-F6H9
Vulnerability from github – Published: 2023-03-29 21:30 – Updated: 2023-04-05 15:30This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within the httpd service. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-15854.
{
"affected": [],
"aliases": [
"CVE-2022-27642"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-29T19:15:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within the httpd service. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-15854.",
"id": "GHSA-w94x-h737-f6h9",
"modified": "2023-04-05T15:30:23Z",
"published": "2023-03-29T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27642"
},
{
"type": "WEB",
"url": "https://kb.netgear.com/000064723/Security-Advisory-for-Multiple-Vulnerabilities-on-Multiple-Products-PSV-2021-0327"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-518"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W95P-H69M-853R
Vulnerability from github – Published: 2026-08-05 21:31 – Updated: 2026-08-06 15:32Incorrect authorization in the aggregation pipeline tool in Amazon AWS Labs DocumentDB MCP Server before 1.0.12 might allow an authenticated MCP client to perform inappropriate write operations on the connected database via write-capable aggregation pipeline stages that bypass the read-only mode enforcement logic.
To remediate this issue, users should upgrade to version 1.0.12 or later.
{
"affected": [],
"aliases": [
"CVE-2026-18954"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T20:17:08Z",
"severity": "MODERATE"
},
"details": "Incorrect authorization in the aggregation pipeline tool in Amazon AWS Labs DocumentDB MCP Server before 1.0.12 might allow an authenticated MCP client to perform inappropriate write operations on the connected database via write-capable aggregation pipeline stages that bypass the read-only mode enforcement logic.\n\n\n\nTo remediate this issue, users should upgrade to version 1.0.12 or later.",
"id": "GHSA-w95p-h69m-853r",
"modified": "2026-08-06T15:32:34Z",
"published": "2026-08-05T21:31:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/awslabs/mcp/security/advisories/GHSA-j694-4m5j-w8hc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18954"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/security/security-bulletins/2026-076-aws"
},
{
"type": "WEB",
"url": "https://github.com/awslabs/mcp/releases/tag/2026.04.20260408085348"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/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"
}
]
}
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.