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.
7986 vulnerabilities reference this CWE, most recent first.
GHSA-XMFH-3CCG-C9FX
Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-09-22 14:38Mattermost versions 11.7.x <= 11.7.0, 10.11.x <= 10.11.17 fail to validate bot targets when demoting users to guests which allows a lower-privileged administrator to degrade arbitrary bot accounts via the standard demote-user API.. Mattermost Advisory ID: MMSA-2026-00669
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.7.0"
},
{
"fixed": "11.7.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"11.7.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20260518160100-9bd77d3fc4d2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-8823"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:38:49Z",
"nvd_published_at": "2026-06-22T16:16:42Z",
"severity": "LOW"
},
"details": "Mattermost versions 11.7.x \u003c= 11.7.0, 10.11.x \u003c= 10.11.17 fail to validate bot targets when demoting users to guests which allows a lower-privileged administrator to degrade arbitrary bot accounts via the standard demote-user API.. Mattermost Advisory ID: MMSA-2026-00669",
"id": "GHSA-xmfh-3ccg-c9fx",
"modified": "2026-09-22T14:38:50Z",
"published": "2026-06-22T18:34:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8823"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/pull/36487"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/7972fc53f5c0b0175879a9737308a87b42db1f0b"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/9bd77d3fc4d2af3f7f0259a205174e76a1a276e1"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/c9bf3609fb9a3e5c2de94c50742c9b91fd723e3d"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/d9a55e394cd5bc15edb49e9606bec8fec03ac4c6"
},
{
"type": "WEB",
"url": "https://docs.mattermost.com/security-guide/security-updates"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/releases/tag/v10.11.18"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/releases/tag/v11.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Mattermost has an Incorrect Authorization issue"
}
GHSA-XMGX-JXPR-F2G8
Vulnerability from github – Published: 2026-11-03 21:32 – Updated: 2026-11-03 21:32Incorrect authorization in History in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-121159"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-03T21:17:23Z",
"severity": null
},
"details": "Incorrect authorization in History in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-xmgx-jxpr-f2g8",
"modified": "2026-11-03T21:32:25Z",
"published": "2026-11-03T21:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-121159"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/562957377"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XMHM-4533-HMHQ
Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-05-24 17:49Insufficient policy enforcement in extensions in Google Chrome prior to 90.0.4430.93 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension.
{
"affected": [],
"aliases": [
"CVE-2021-21228"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-30T21:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in extensions in Google Chrome prior to 90.0.4430.93 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension.",
"id": "GHSA-xmhm-4533-hmhq",
"modified": "2022-05-24T17:49:22Z",
"published": "2022-05-24T17:49:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21228"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop_26.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1139156"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EAJ42L4JFPBJATCZ7MOZQTUDGV4OEHHG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U3GZ42MYPGD35V652ZPVPYYS7A7LVXVY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VUZBGKGVZADNA3I24NVG7HAYYUTOSN5A"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202104-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4911"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XMM3-954R-XWWW
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53There is a Factory Reset Protection (FRP) bypass vulnerability on several smartphones. The system does not sufficiently verify the permission, an attacker uses a data cable to connect the smartphone to another smartphone and then perform a series of specific operations. Successful exploit could allow the attacker bypass the FRP protection.
{
"affected": [],
"aliases": [
"CVE-2018-7988"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-27T22:29:00Z",
"severity": "MODERATE"
},
"details": "There is a Factory Reset Protection (FRP) bypass vulnerability on several smartphones. The system does not sufficiently verify the permission, an attacker uses a data cable to connect the smartphone to another smartphone and then perform a series of specific operations. Successful exploit could allow the attacker bypass the FRP protection.",
"id": "GHSA-xmm3-954r-xwww",
"modified": "2022-05-13T01:53:28Z",
"published": "2022-05-13T01:53:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7988"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20181114-01-smartphone-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XMPX-2MHF-XQ2J
Vulnerability from github – Published: 2025-01-28 00:32 – Updated: 2025-11-03 21:32An authentication issue was addressed with improved state management. This issue is fixed in iOS 18.3 and iPadOS 18.3. An attacker with physical access to an unlocked device may be able to access Photos while the app is locked.
{
"affected": [],
"aliases": [
"CVE-2025-24141"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-27T22:15:18Z",
"severity": "LOW"
},
"details": "An authentication issue was addressed with improved state management. This issue is fixed in iOS 18.3 and iPadOS 18.3. An attacker with physical access to an unlocked device may be able to access Photos while the app is locked.",
"id": "GHSA-xmpx-2mhf-xq2j",
"modified": "2025-11-03T21:32:28Z",
"published": "2025-01-28T00:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24141"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122066"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jan/13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XMRJ-C495-VFVX
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-10-22 12:00A vulnerability in the fabric infrastructure file system access control of Cisco Nexus 9000 Series Fabric Switches in Application Centric Infrastructure (ACI) mode could allow an authenticated, local attacker to read arbitrary files on an affected system. This vulnerability is due to improper access control. An attacker with Administrator privileges could exploit this vulnerability by executing a specific vulnerable command on an affected device. A successful exploit could allow the attacker to read arbitrary files on the file system of the affected device.
{
"affected": [],
"aliases": [
"CVE-2021-1583"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-25T20:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the fabric infrastructure file system access control of Cisco Nexus 9000 Series Fabric Switches in Application Centric Infrastructure (ACI) mode could allow an authenticated, local attacker to read arbitrary files on an affected system. This vulnerability is due to improper access control. An attacker with Administrator privileges could exploit this vulnerability by executing a specific vulnerable command on an affected device. A successful exploit could allow the attacker to read arbitrary files on the file system of the affected device.",
"id": "GHSA-xmrj-c495-vfvx",
"modified": "2022-10-22T12:00:30Z",
"published": "2022-05-24T19:12:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1583"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-naci-afr-UtjfO2D7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XP38-X25M-8FPQ
Vulnerability from github – Published: 2025-07-05 00:30 – Updated: 2025-07-05 00:30The agent in Quest KACE Systems Management Appliance (SMA) before 14.0.97 and 14.1.x before 14.1.19 potentially allows privilege escalation on managed systems.
{
"affected": [],
"aliases": [
"CVE-2025-26850"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-05T00:15:22Z",
"severity": "CRITICAL"
},
"details": "The agent in Quest KACE Systems Management Appliance (SMA) before 14.0.97 and 14.1.x before 14.1.19 potentially allows privilege escalation on managed systems.",
"id": "GHSA-xp38-x25m-8fpq",
"modified": "2025-07-05T00:30:23Z",
"published": "2025-07-05T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26850"
},
{
"type": "WEB",
"url": "https://support.quest.com/kb/4378559/quest-response-to-kace-sma-agent-vulnerability-cve-2025-26850"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XP3C-3JW3-4VCR
Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36Impact
When a policy operator has written capabilities = ["deny"] on a path with a trailing wildcard but allowed a broader list operation (e.g., a deny on secrets/metadata/restricted/* but allowed list on secrets/metadata/*), OpenBao would incorrectly allow the operation. This did not impact other operation types.
Patches
This has been patched in OpenBao v2.6.0.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openbao/openbao"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260713133043-f58d848c139e"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/openbao/openbao"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"last_affected": "1.1.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63131"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:36:56Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\n\nWhen a policy operator has written `capabilities = [\"deny\"]` on a path with a trailing wildcard but allowed a broader list operation (e.g., a `deny` on `secrets/metadata/restricted/*` but allowed `list` on `secrets/metadata/*`), OpenBao would incorrectly allow the operation. This did not impact other operation types.\n\n## Patches\n\nThis has been patched in OpenBao v2.6.0.",
"id": "GHSA-xp3c-3jw3-4vcr",
"modified": "2026-09-22T20:36:56Z",
"published": "2026-09-22T20:36:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/security/advisories/GHSA-xp3c-3jw3-4vcr"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/pull/3389"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/pull/3474"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/commit/2e9625d6cebe4639d051ef53dd6ce7c49914ae6a"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/commit/f58d848c139e5ba71aa63103fcfe101972b999fc"
},
{
"type": "WEB",
"url": "https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#203"
},
{
"type": "PACKAGE",
"url": "https://github.com/openbao/openbao"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/releases/tag/v2.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenBao Skips Stricter Deny Policy for LIST operations"
}
GHSA-XP3Q-R38W-VGQM
Vulnerability from github – Published: 2026-10-23 18:29 – Updated: 2026-10-23 18:29Relationship to GHSA-hgfg-j9pg-43xw
That advisory concerned the administrator's live UI layout, and commit 63c7d5474 resolved it by removing FilterUILayoutByPublishIgnore and nulling Conf.UILayout for readers. That fix is correct and complete for the live layout.
This report concerns a different endpoint, a different filter function and a different storage backing. /api/storage/getLocalStorage reads data/storage/local.json rather than Conf.UILayout, and its filter FilterLocalStorageByPublishAccess was not touched by that commit. The consequence is that the same serialized tab objects the earlier fix withheld continue to be served, from the closed-tab history rather than the live layout.
Summary
Three routes, /api/storage/getLocalStorage, getLocalStorageVal and getLocalStorageVals, are registered with CheckAuth only and are reachable by the publish RoleReader token and anonymously when Publish.Auth.Enable is false. All three call model.GetLocalStorage() and then, for read-only roles, FilterLocalStorageByPublishAccess.
That filter begins by assigning the administrator's entire storage map to its return value and then removes three specific fields. Everything else in the map is returned unmodified. A single unauthenticated POST with an empty body returns the administrator's recently closed tabs with their document titles and identifiers, their current search keywords and the paths those searches cover, the expanded private paths in their file tree, and per-document identifiers from several other keys.
Details
Routes. kernel/api/router.go:87-89 on master, the same block on the development branch:
ginServer.Handle("POST", "/api/storage/getLocalStorage", model.CheckAuth, getLocalStorage)
ginServer.Handle("POST", "/api/storage/getLocalStorageVal", model.CheckAuth, getLocalStorageVal)
ginServer.Handle("POST", "/api/storage/getLocalStorageVals", model.CheckAuth, getLocalStorageVals)
No CheckAdminRole, no CheckReadonly.
The filter is an allowlist inverted into a blocklist. kernel/model/publish_access.go:911 on master and :1481 on the development branch, byte-identical on both:
func FilterLocalStorageByPublishAccess(publishAccess PublishAccess, localStorage map[string]any) (ret map[string]any) {
ret = localStorage // the entire administrator map
publishIgnore := GetInvisiblePublishAccess(publishAccess)
// clears local-searchkeys["keys"]
// clears local-searchasset["k"] and ["keys"]
// blanks local-docinfo["id"], only when bt != nil, visible tier only, no password check
return
}
local.json holds roughly thirty keys. Three are sanitized. The rest are returned as stored.
What survives. Taking the client's own list of keys it round-trips through this endpoint (app/src/protyle/util/compatibility.ts:563), the notable survivors are:
local-closed-tabs. Up toSIZE_UNDOentries, each produced bylayoutToJSON(item, tabJSON)atapp/src/layout/Wnd.ts:779. This is the same serializer that produced the data in the earlier advisory: tab title,docIcon,rootId,notebookId,blockId,mode,action, and for a Search tab the entire config object. Unfiltered.local-searchdata. The live document-search configuration, includingk(the search text),r(replace text),hPath,idPath(the paths the search was scoped to) andtypes. Note the filter clears the search history array and the asset-search keyword, but leaves the document-search keyword itself. The project's own standard is applied to two of the three related fields.local-filespaths.IFilesPath[]of{notebookId, openPaths[]}, the expanded private notebook and folder paths in the file-tree dock.local-fileposition,local-outline,local-zoom. Keyed by document or block identifier, so each discloses private document identifiers.local-move-path.{keys[], k}, the move-document dialog's path history and last keyword.local-recent-docs,local-history,local-flashcard,local-dailynoteid,local-layouts.
The asymmetry is visible in the function signature. In the same file, kernel/api/storage.go:
| Handler | Filter | Receives *gin.Context |
|---|---|---|
getCriteria |
FilterCriteriaByPublishAccess(c, ...) |
yes |
getRecentDocs |
FilterRecentDocsByPublishAccess(c, ...) |
yes |
getLocalStorage / Val / Vals |
FilterLocalStorageByPublishAccess(publishAccess, data) |
no |
The two sibling filters take the request context and can therefore call CheckPublishAuthCookie to evaluate the password tier. FilterLocalStorageByPublishAccess does not receive the context, so it cannot perform that check at all. The visible-only limitation is fixed in the parameter list rather than in the body.
Separately, local-recent-docs passes through this endpoint unfiltered, which bypasses the dedicated FilterRecentDocsByPublishAccess that guards the same data on getRecentDocs.
Note on a prior assessment. getLocalStorage appears on lists of endpoints considered correctly filtered, on the basis that it calls a Filter*ByPublishAccess function. That observation is accurate and this report does not contradict it. The filter is called. What it does is assign the whole map and remove three fields.
No persistence side effect. The in-place mutations the filter performs do not corrupt the administrator's stored state, because GetLocalStorage re-reads and unmarshals storage/local.json on each call (kernel/model/storage.go:82), so the map is per-request. This is noted to pre-empt the concern rather than as part of the finding.
Proof of Concept
Precondition: publish mode enabled (default port 6808), anonymous when Publish.Auth.Enable is false, otherwise any publish reader account. An administrator who has used the client normally, closing some document tabs and running a search.
POST http://127.0.0.1:6808/api/storage/getLocalStorage
{}
→ 200. The returned map includes, among others:
local-closed-tabs entries carrying title, docIcon, rootId, notebookId,
blockId for recently closed documents, including
documents the reader has no publish access to
local-searchdata k, r, hPath, idPath for the administrator's current
document search
local-filespaths notebookId and openPaths for expanded private folders
local-fileposition keys are private document identifiers
getLocalStorageVal returns any single key by name, so a caller who only wants the closed-tab history can request it directly.
For contrast, requesting the same underlying data through the sibling endpoint shows the filtering that is applied elsewhere:
POST http://127.0.0.1:6808/api/storage/getRecentDocs
{}
→ 200, filtered by FilterRecentDocsByPublishAccess
while local-recent-docs inside the storage response is not.
Impact
An anonymous reader in publish mode, or any publish RoleReader, obtains the administrator's working context: the titles and identifiers of documents they recently had open, what they have been searching for and where, which private folders they have expanded, and per-document identifiers across several other keys. Titles and search keywords are author-written text and routinely describe the subject of the documents they refer to.
The document and notebook identifiers disclosed here are also the input required by identifier-to-path and path-to-content resolution, so the value is not limited to the metadata itself.
No document bodies are returned, and nothing is written. Confidentiality only.
Suggested fix
Invert the filter into an actual allowlist. Return only the keys a publish reader needs to render published content, which is a short list along the lines of local-images, local-emojis, local-pdftheme, local-fontstyles and the theme and zoom preferences, and drop everything else by default. New keys added in future then default to withheld rather than exposed.
Additionally, pass *gin.Context into FilterLocalStorageByPublishAccess so that any retained per-document entry can be gated with the full CheckBlockIdAccessableByPublishAccess including the password tier, matching the sibling filters in the same file.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260729005258-4daee87d4152"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T18:29:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Relationship to GHSA-hgfg-j9pg-43xw\n\nThat advisory concerned the administrator\u0027s live UI layout, and commit `63c7d5474` resolved it by removing `FilterUILayoutByPublishIgnore` and nulling `Conf.UILayout` for readers. That fix is correct and complete for the live layout.\n\nThis report concerns a different endpoint, a different filter function and a different storage backing. `/api/storage/getLocalStorage` reads `data/storage/local.json` rather than `Conf.UILayout`, and its filter `FilterLocalStorageByPublishAccess` was not touched by that commit. The consequence is that the same serialized tab objects the earlier fix withheld continue to be served, from the closed-tab history rather than the live layout.\n\n### Summary\n\nThree routes, `/api/storage/getLocalStorage`, `getLocalStorageVal` and `getLocalStorageVals`, are registered with `CheckAuth` only and are reachable by the publish `RoleReader` token and anonymously when `Publish.Auth.Enable` is `false`. All three call `model.GetLocalStorage()` and then, for read-only roles, `FilterLocalStorageByPublishAccess`.\n\nThat filter begins by assigning the administrator\u0027s entire storage map to its return value and then removes three specific fields. Everything else in the map is returned unmodified. A single unauthenticated POST with an empty body returns the administrator\u0027s recently closed tabs with their document titles and identifiers, their current search keywords and the paths those searches cover, the expanded private paths in their file tree, and per-document identifiers from several other keys.\n\n### Details\n\n**Routes.** `kernel/api/router.go:87-89` on master, the same block on the development branch:\n\n```go\nginServer.Handle(\"POST\", \"/api/storage/getLocalStorage\", model.CheckAuth, getLocalStorage)\nginServer.Handle(\"POST\", \"/api/storage/getLocalStorageVal\", model.CheckAuth, getLocalStorageVal)\nginServer.Handle(\"POST\", \"/api/storage/getLocalStorageVals\", model.CheckAuth, getLocalStorageVals)\n```\n\nNo `CheckAdminRole`, no `CheckReadonly`.\n\n**The filter is an allowlist inverted into a blocklist.** `kernel/model/publish_access.go:911` on master and `:1481` on the development branch, byte-identical on both:\n\n```go\nfunc FilterLocalStorageByPublishAccess(publishAccess PublishAccess, localStorage map[string]any) (ret map[string]any) {\n ret = localStorage // the entire administrator map\n publishIgnore := GetInvisiblePublishAccess(publishAccess)\n // clears local-searchkeys[\"keys\"]\n // clears local-searchasset[\"k\"] and [\"keys\"]\n // blanks local-docinfo[\"id\"], only when bt != nil, visible tier only, no password check\n return\n}\n```\n\n`local.json` holds roughly thirty keys. Three are sanitized. The rest are returned as stored.\n\n**What survives.** Taking the client\u0027s own list of keys it round-trips through this endpoint (`app/src/protyle/util/compatibility.ts:563`), the notable survivors are:\n\n- `local-closed-tabs`. Up to `SIZE_UNDO` entries, each produced by `layoutToJSON(item, tabJSON)` at `app/src/layout/Wnd.ts:779`. This is the same serializer that produced the data in the earlier advisory: tab title, `docIcon`, `rootId`, `notebookId`, `blockId`, `mode`, `action`, and for a Search tab the entire config object. Unfiltered.\n- `local-searchdata`. The live document-search configuration, including `k` (the search text), `r` (replace text), `hPath`, `idPath` (the paths the search was scoped to) and `types`. Note the filter clears the search *history* array and the *asset*-search keyword, but leaves the document-search keyword itself. The project\u0027s own standard is applied to two of the three related fields.\n- `local-filespaths`. `IFilesPath[]` of `{notebookId, openPaths[]}`, the expanded private notebook and folder paths in the file-tree dock.\n- `local-fileposition`, `local-outline`, `local-zoom`. Keyed by document or block identifier, so each discloses private document identifiers.\n- `local-move-path`. `{keys[], k}`, the move-document dialog\u0027s path history and last keyword.\n- `local-recent-docs`, `local-history`, `local-flashcard`, `local-dailynoteid`, `local-layouts`.\n\n**The asymmetry is visible in the function signature.** In the same file, `kernel/api/storage.go`:\n\n| Handler | Filter | Receives `*gin.Context` |\n|---|---|---|\n| `getCriteria` | `FilterCriteriaByPublishAccess(c, ...)` | yes |\n| `getRecentDocs` | `FilterRecentDocsByPublishAccess(c, ...)` | yes |\n| `getLocalStorage` / `Val` / `Vals` | `FilterLocalStorageByPublishAccess(publishAccess, data)` | no |\n\nThe two sibling filters take the request context and can therefore call `CheckPublishAuthCookie` to evaluate the password tier. `FilterLocalStorageByPublishAccess` does not receive the context, so it cannot perform that check at all. The visible-only limitation is fixed in the parameter list rather than in the body.\n\nSeparately, `local-recent-docs` passes through this endpoint unfiltered, which bypasses the dedicated `FilterRecentDocsByPublishAccess` that guards the same data on `getRecentDocs`.\n\n**Note on a prior assessment.** `getLocalStorage` appears on lists of endpoints considered correctly filtered, on the basis that it calls a `Filter*ByPublishAccess` function. That observation is accurate and this report does not contradict it. The filter is called. What it does is assign the whole map and remove three fields.\n\n**No persistence side effect.** The in-place mutations the filter performs do not corrupt the administrator\u0027s stored state, because `GetLocalStorage` re-reads and unmarshals `storage/local.json` on each call (`kernel/model/storage.go:82`), so the map is per-request. This is noted to pre-empt the concern rather than as part of the finding.\n\n### Proof of Concept\n\nPrecondition: publish mode enabled (default port 6808), anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. An administrator who has used the client normally, closing some document tabs and running a search.\n\n```\nPOST http://127.0.0.1:6808/api/storage/getLocalStorage\n{}\n\n\u2192 200. The returned map includes, among others:\n local-closed-tabs entries carrying title, docIcon, rootId, notebookId,\n blockId for recently closed documents, including\n documents the reader has no publish access to\n local-searchdata k, r, hPath, idPath for the administrator\u0027s current\n document search\n local-filespaths notebookId and openPaths for expanded private folders\n local-fileposition keys are private document identifiers\n```\n\n`getLocalStorageVal` returns any single key by name, so a caller who only wants the closed-tab history can request it directly.\n\nFor contrast, requesting the same underlying data through the sibling endpoint shows the filtering that is applied elsewhere:\n\n```\nPOST http://127.0.0.1:6808/api/storage/getRecentDocs\n{}\n\n\u2192 200, filtered by FilterRecentDocsByPublishAccess\n```\n\nwhile `local-recent-docs` inside the storage response is not.\n\n### Impact\n\nAn anonymous reader in publish mode, or any publish `RoleReader`, obtains the administrator\u0027s working context: the titles and identifiers of documents they recently had open, what they have been searching for and where, which private folders they have expanded, and per-document identifiers across several other keys. Titles and search keywords are author-written text and routinely describe the subject of the documents they refer to.\n\nThe document and notebook identifiers disclosed here are also the input required by identifier-to-path and path-to-content resolution, so the value is not limited to the metadata itself.\n\nNo document bodies are returned, and nothing is written. Confidentiality only.\n\n### Suggested fix\n\nInvert the filter into an actual allowlist. Return only the keys a publish reader needs to render published content, which is a short list along the lines of `local-images`, `local-emojis`, `local-pdftheme`, `local-fontstyles` and the theme and zoom preferences, and drop everything else by default. New keys added in future then default to withheld rather than exposed.\n\nAdditionally, pass `*gin.Context` into `FilterLocalStorageByPublishAccess` so that any retained per-document entry can be gated with the full `CheckBlockIdAccessableByPublishAccess` including the password tier, matching the sibling filters in the same file.",
"id": "GHSA-xp3q-r38w-vgqm",
"modified": "2026-10-23T18:29:45Z",
"published": "2026-10-23T18:29:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-xp3q-r38w-vgqm"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/4daee87d41521d119979f2edda67e87f2be7b6ef"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.7.4-alpha.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: The publish filter for local storage returns the administrator\u0027s entire storage map with only three keys sanitized"
}
GHSA-XP42-838X-6M32
Vulnerability from github – Published: 2025-03-04 06:30 – Updated: 2025-03-04 06:30During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the VAPIX Device Configuration framework that could lead to an incorrect user privilege level in the VAPIX service account D-Bus API.
{
"affected": [],
"aliases": [
"CVE-2025-0360"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-04T06:15:30Z",
"severity": "HIGH"
},
"details": "During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the VAPIX Device Configuration framework that could lead to an incorrect user privilege level in the VAPIX service account D-Bus API.",
"id": "GHSA-xp42-838x-6m32",
"modified": "2025-03-04T06:30:34Z",
"published": "2025-03-04T06:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0360"
},
{
"type": "WEB",
"url": "https://www.axis.com/dam/public/b1/fe/46/cve-2025-0360pdf-en-US-466887.pdf"
}
],
"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.