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.
6275 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-W978-MMPV-HPHG
Vulnerability from github – Published: 2022-04-21 01:57 – Updated: 2024-02-28 01:10IcedTea6 before 1.7.4 does not properly check property access, which allows unsigned apps to read and write arbitrary files.
{
"affected": [],
"aliases": [
"CVE-2010-2548"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-31T21:15:00Z",
"severity": "CRITICAL"
},
"details": "IcedTea6 before 1.7.4 does not properly check property access, which allows unsigned apps to read and write arbitrary files.",
"id": "GHSA-w978-mmpv-hphg",
"modified": "2024-02-28T01:10:51Z",
"published": "2022-04-21T01:57:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2548"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2548"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2010-2548"
},
{
"type": "WEB",
"url": "http://blog.fuseyism.com/index.php/2010/07/28/icedtea6-174-released"
}
],
"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-W9GQ-8Q35-3JCC
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2023-12-06 15:10An improper authorization vulnerability exists in Jenkins Subversion Plugin version 2.10.2 and earlier in SubversionStatus.java and SubversionRepositoryStatus.java that allows an attacker with network access to obtain a list of nodes and users. As of version 2.10.3, the class handling requests to /subversion/ no longer extends the class handling requests to the …/search/ sub-path, therefore any such requests will fail.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.10.2"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:subversion"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.10.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000111"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-07T18:15:59Z",
"nvd_published_at": "2018-03-13T13:29:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization vulnerability exists in Jenkins Subversion Plugin version 2.10.2 and earlier in `SubversionStatus.java` and `SubversionRepositoryStatus.java` that allows an attacker with network access to obtain a list of nodes and users. As of version 2.10.3, the class handling requests to /subversion/ no longer extends the class handling requests to the \u2026/search/ sub-path, therefore any such requests will fail.",
"id": "GHSA-w9gq-8q35-3jcc",
"modified": "2023-12-06T15:10:51Z",
"published": "2022-05-13T01:48:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000111"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/subversion-plugin/commit/25f6afbb02a5863f363b0a2f664ac717ace743b4"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/subversion-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-02-26/#SECURITY-724"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Subversion Plugin Incorrect Authorization vulnerability"
}
GHSA-W9JG-GVGR-354M
Vulnerability from github – Published: 2021-07-02 18:33 – Updated: 2022-03-30 21:15Spring Security versions 5.5.x prior to 5.5.1, 5.4.x prior to 5.4.7, 5.3.x prior to 5.3.10 and 5.2.x prior to 5.2.11 are susceptible to a Denial-of-Service (DoS) attack via the initiation of the Authorization Request in an OAuth 2.0 Client Web and WebFlux application. A malicious user or attacker can send multiple requests initiating the Authorization Request for the Authorization Code Grant, which has the potential of exhausting system resources using a single session or multiple sessions.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.0"
},
{
"fixed": "5.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.3.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"fixed": "5.3.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.2.10"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.2.0"
},
{
"fixed": "5.2.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-client"
},
"ranges": [
{
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-client"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.0"
},
{
"fixed": "5.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.3.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-client"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"fixed": "5.3.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.2.10"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-client"
},
"ranges": [
{
"events": [
{
"introduced": "5.2.0"
},
{
"fixed": "5.2.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-22119"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-30T17:30:10Z",
"nvd_published_at": "2021-06-29T17:15:00Z",
"severity": "HIGH"
},
"details": "Spring Security versions 5.5.x prior to 5.5.1, 5.4.x prior to 5.4.7, 5.3.x prior to 5.3.10 and 5.2.x prior to 5.2.11 are susceptible to a Denial-of-Service (DoS) attack via the initiation of the Authorization Request in an OAuth 2.0 Client Web and WebFlux application. A malicious user or attacker can send multiple requests initiating the Authorization Request for the Authorization Code Grant, which has the potential of exhausting system resources using a single session or multiple sessions.",
"id": "GHSA-w9jg-gvgr-354m",
"modified": "2022-03-30T21:15:14Z",
"published": "2021-07-02T18:33:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22119"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/pull/9513"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-security"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r08a449010786e0bcffa4b5781b04fcb55d6eafa62cb79b8347680aad@%3Cissues.nifi.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r163b3e4e39803882f5be05ee8606b2b9812920e196daa2a82997ce14@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3868207b967f926819fe3aa8d33f1666429be589bb4a62104a49f4e3@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r390783b3b1c59b978131ac08390bf77fbb3863270cbde59d5b0f5fde@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r89aa1b48a827f5641310305214547f1d6b2101971a49b624737c497f@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra53677224fe4f04c2599abc88032076faa18dc84b329cdeba85d4cfc@%3Cpluto-scm.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://tanzu.vmware.com/security/cve-2021-22119"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Resource Exhaustion in Spring Security"
}
GHSA-W9MJ-GFRM-HJ5X
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-hpgw-ww76-c68r. This link is maintained to preserve external references.
Original Description
phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/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-06-09T00:01:24Z",
"nvd_published_at": "2026-05-15T19:17:03Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-hpgw-ww76-c68r. This link is maintained to preserve external references.\n\n### Original Description\nphpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.",
"id": "GHSA-w9mj-gfrm-hj5x",
"modified": "2026-06-09T00:01:24Z",
"published": "2026-05-15T21:31:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-hpgw-ww76-c68r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46362"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/phpmyfaq-authorization-bypass-in-admin-pages-via-non-terminating-permission-check"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"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/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 has an Authorization Bypass in All Admin Pages Due to Non-Terminating Permission Check",
"withdrawn": "2026-06-09T00:01:24Z"
}
GHSA-W9VH-HV5G-7WMR
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-09-11 21:32An issue in Dromara SaToken version 1.3.50RC and before when using Spring dynamic controllers, a specially crafted request may cause an authentication bypass.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "cn.dev33:sa-token-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.36.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43961"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-27T19:49:44Z",
"nvd_published_at": "2023-10-25T18:17:32Z",
"severity": "HIGH"
},
"details": "An issue in Dromara SaToken version 1.3.50RC and before when using Spring dynamic controllers, a specially crafted request may cause an authentication bypass.",
"id": "GHSA-w9vh-hv5g-7wmr",
"modified": "2024-09-11T21:32:36Z",
"published": "2023-10-25T18:32:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43961"
},
{
"type": "WEB",
"url": "https://github.com/dromara/Sa-Token/issues/511"
},
{
"type": "PACKAGE",
"url": "https://github.com/dromara/Sa-Token"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "SaToken authentication bypass vulnerability"
}
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.