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.
7172 vulnerabilities reference this CWE, most recent first.
GHSA-475V-6WXG-C2RX
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50In Webgalamb through 7.0, system/ajax.php functionality is supposed to be available only to the administrator. However, by using one of the bgsend, atment_sddd1xGz, or xls_bgimport query parameters, most of these methods become available to unauthenticated users.
{
"affected": [],
"aliases": [
"CVE-2018-19515"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-21T16:00:00Z",
"severity": "CRITICAL"
},
"details": "In Webgalamb through 7.0, system/ajax.php functionality is supposed to be available only to the administrator. However, by using one of the bgsend, atment_sddd1xGz, or xls_bgimport query parameters, most of these methods become available to unauthenticated users.",
"id": "GHSA-475v-6wxg-c2rx",
"modified": "2022-05-13T01:50:52Z",
"published": "2022-05-13T01:50:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19515"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2019/Jan/15"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/151017/Webgalamb-Information-Disclosure-XSS-CSRF-SQL-Injection.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-476V-WP49-P58Q
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-08 15:32Incorrect authorization in Actor in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially bypass site isolation via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-106199"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T19:17:46Z",
"severity": "HIGH"
},
"details": "Incorrect authorization in Actor in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially bypass site isolation via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-476v-wp49-p58q",
"modified": "2026-10-08T15:32:47Z",
"published": "2026-10-06T21:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106199"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/517703787"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4782-6X7J-Q79Q
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14An incorrect permission check in the admin backend in gvfs before version 1.39.4 was found that allows reading and modify arbitrary files by privileged users without asking for password when no authentication agent is running. This vulnerability can be exploited by malicious programs running under privileges of users belonging to the wheel group to further escalate its privileges by modifying system files without user's knowledge. Successful exploitation requires uncommon system configuration.
{
"affected": [],
"aliases": [
"CVE-2019-3827"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-25T18:29:00Z",
"severity": "HIGH"
},
"details": "An incorrect permission check in the admin backend in gvfs before version 1.39.4 was found that allows reading and modify arbitrary files by privileged users without asking for password when no authentication agent is running. This vulnerability can be exploited by malicious programs running under privileges of users belonging to the wheel group to further escalate its privileges by modifying system files without user\u0027s knowledge. Successful exploitation requires uncommon system configuration.",
"id": "GHSA-4782-6x7j-q79q",
"modified": "2022-05-13T01:14:27Z",
"published": "2022-05-13T01:14:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3827"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1517"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2145"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3827"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/gvfs/merge_requests/31"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-47C3-M797-88V2
Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-06 18:30Improper Authorization vulnerability in Apache Answer.
This issue affects Apache Answer: through 2.0.1.
Any authenticated user can reject arbitrary pending edit-revisions without review permission due to a missing authorization check on the reject operation. Users are recommended to upgrade to version 2.0.2, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-50749"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T16:16:57Z",
"severity": "MODERATE"
},
"details": "Improper Authorization vulnerability in Apache Answer.\n\nThis issue affects Apache Answer: through 2.0.1.\n\nAny authenticated user can reject arbitrary pending edit-revisions without review permission due to a missing authorization check on the reject operation.\nUsers are recommended to upgrade to version 2.0.2, which fixes the issue.",
"id": "GHSA-47c3-m797-88v2",
"modified": "2026-08-06T18:30:36Z",
"published": "2026-08-05T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50749"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ogk461yr4w9o95k15bkjxk2kpbkrbnln"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/05/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-47C7-QRM7-MQW7
Vulnerability from github – Published: 2026-07-06 20:16 – Updated: 2026-07-06 20:16The id utility in uutils coreutils miscalculates the groups= section of its output. The implementation uses a user's real GID instead of their effective GID to compute the group list, leading to potentially divergent output compared to GNU coreutils. Because many scripts and automated processes rely on the output of id to make security-critical access-control or permission decisions, this discrepancy can lead to unauthorized access or security misconfigurations.
Zellic finding 3.72. Reported in the Zellic uutils coreutils Program Security Assessment (for Canonical, Jan 2026), audited commit 3a07ffc5a9bd4c283e75afa548ba1f1957bad242.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "uu_id"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35370"
],
"database_specific": {
"cwe_ids": [
"CWE-273",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:16:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The id utility in uutils coreutils miscalculates the groups= section of its output. The implementation uses a user\u0027s real GID instead of their effective GID to compute the group list, leading to potentially divergent output compared to GNU coreutils. Because many scripts and automated processes rely on the output of id to make security-critical access-control or permission decisions, this discrepancy can lead to unauthorized access or security misconfigurations.\n\n---\n_Zellic finding 3.72. Reported in the Zellic *uutils coreutils Program Security Assessment* (for Canonical, Jan 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`._",
"id": "GHSA-47c7-qrm7-mqw7",
"modified": "2026-07-06T20:16:46Z",
"published": "2026-07-06T20:16:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/security/advisories/GHSA-47c7-qrm7-mqw7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35370"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/issues/10006"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "id: groups= computed from real GID instead of effective GID"
}
GHSA-47PJ-3JCM-6WHG
Vulnerability from github – Published: 2026-08-06 19:03 – Updated: 2026-08-06 19:03Summary
The Postgres and SQLite stores persist hierarchical namespaces as a dot-joined string (("memories", "alice") becomes memories.alice) and scoped reads by matching that string with LIKE '<path>%'. Because LIKE has no notion of the . separator, a scoped search or list_namespaces also matched sibling namespaces whose flattened form shares leading characters.
Applications commonly use the namespace as a tenant boundary. Where they do, a read scoped to one namespace could return items belonging to another, without any crafted input — an ordinary scoped request was sufficient.
We have no evidence of this behavior being exploited in the wild.
Affected users / systems
You may be affected if you:
- use
PostgresStore/AsyncPostgresStoreorSqliteStore/AsyncSqliteStore, and - rely on the namespace to separate data between users or tenants, and
- have namespace labels where one is a prefix of another (
1and12,aliceandalice2), or labels containing_or%
Applications whose namespace labels are fixed-length identifiers such as UUIDs, containing no _ or %, are not affected — no such label can be a prefix of another. InMemoryStore compares namespaces element-wise and is not affected.
Three distinct cases were possible:
- Sibling namespaces. A read scoped to
("foo",)also returned items under("foobar",)and("foo2",). - Unescaped pattern metacharacters.
_and%are legal namespace labels — only.is rejected — but were interpolated into the match pattern unescaped, so("user_1",)also matched("userX1",). - Suffix conditions.
list_namespaces(suffix=("alice",))also matched the sibling leafusers.malice.
This is not SQL injection. Values were passed as bound parameters and never interpolated into statement text; the bound value was itself a LIKE pattern whose metacharacters were not neutralized.
Impact
- Confidentiality: disclosure of stored items belonging to namespaces outside the caller's intended scope, where namespaces are used as a tenant or user boundary.
- No integrity or availability impact.
get,put, anddeletecompare namespaces with=and were never affected; the issue is limited to read paths.
Patches / mitigation
Prefix scoping now matches the namespace exactly or requires the . separator before any remainder, pattern metacharacters in labels are escaped, and list_namespaces uses segment-aware matching for both prefix and suffix conditions.
On SQLite, the descendant match moved from LIKE to GLOB. LIKE is case-insensitive for ASCII in SQLite, so scoped reads previously matched namespaces differing only in case, while get/put/delete treated them as distinct. Search now agrees with them.
Upgrade to langgraph-checkpoint-postgres 3.1.1 or langgraph-checkpoint-sqlite 3.1.1.
Compatibility
* in a list_namespaces match path now spans exactly one namespace segment. This restores the documented behavior — NamespacePath documents ("cache", "*", "v1") as "any cache category with v1 version" — and matches InMemoryStore. Multi-segment matching was an artifact of translating * into a SQL % wildcard, the same mechanism responsible for this issue, and could not be preserved while fixing it.
Callers relying on the previous behavior can express "match at any depth" by combining both match conditions, which are ANDed:
list_namespaces(prefix=["uid"], suffix=["alice"])
Applications whose namespace labels cannot be prefixes of one another see no behavioral change.
Operational guidance
- Prefer fixed-length namespace labels such as UUIDs, so no label can be a prefix of another.
- Where labels are user-supplied, validate them at the boundary rather than relying on scoping alone.
LangSmith / hosted deployments note
Unlike previous store advisories, this issue does reach hosted deployments. LangSmith deployments default to LANGGRAPH_STORE_BACKEND=python, which uses AsyncPostgresStore from checkpoint-postgres. Deployments configured with LANGGRAPH_STORE_BACKEND=grpc use a separate implementation that received an equivalent fix.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-checkpoint-postgres"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-checkpoint-sqlite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71433"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T19:03:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Postgres and SQLite stores persist hierarchical namespaces as a dot-joined string (`(\"memories\", \"alice\")` becomes `memories.alice`) and scoped reads by matching that string with `LIKE \u0027\u003cpath\u003e%\u0027`. Because `LIKE` has no notion of the `.` separator, a scoped `search` or `list_namespaces` also matched sibling namespaces whose flattened form shares leading characters.\n\nApplications commonly use the namespace as a tenant boundary. Where they do, a read scoped to one namespace could return items belonging to another, without any crafted input \u2014 an ordinary scoped request was sufficient.\n\nWe have no evidence of this behavior being exploited in the wild.\n\n## Affected users / systems\n\nYou may be affected if you:\n\n- use `PostgresStore`/`AsyncPostgresStore` or `SqliteStore`/`AsyncSqliteStore`, and\n- rely on the namespace to separate data between users or tenants, and\n- have namespace labels where one is a prefix of another (`1` and `12`, `alice` and `alice2`), or labels containing `_` or `%`\n\nApplications whose namespace labels are fixed-length identifiers such as UUIDs, containing no `_` or `%`, are not affected \u2014 no such label can be a prefix of another. `InMemoryStore` compares namespaces element-wise and is not affected.\n\nThree distinct cases were possible:\n\n- **Sibling namespaces.** A read scoped to `(\"foo\",)` also returned items under `(\"foobar\",)` and `(\"foo2\",)`.\n- **Unescaped pattern metacharacters.** `_` and `%` are legal namespace labels \u2014 only `.` is rejected \u2014 but were interpolated into the match pattern unescaped, so `(\"user_1\",)` also matched `(\"userX1\",)`.\n- **Suffix conditions.** `list_namespaces(suffix=(\"alice\",))` also matched the sibling leaf `users.malice`.\n\nThis is not SQL injection. Values were passed as bound parameters and never interpolated into statement text; the bound value *was itself* a `LIKE` pattern whose metacharacters were not neutralized.\n\n## Impact\n\n- Confidentiality: disclosure of stored items belonging to namespaces outside the caller\u0027s intended scope, where namespaces are used as a tenant or user boundary.\n- No integrity or availability impact. `get`, `put`, and `delete` compare namespaces with `=` and were never affected; the issue is limited to read paths.\n\n## Patches / mitigation\n\nPrefix scoping now matches the namespace exactly or requires the `.` separator before any remainder, pattern metacharacters in labels are escaped, and `list_namespaces` uses segment-aware matching for both prefix and suffix conditions.\n\nOn SQLite, the descendant match moved from `LIKE` to `GLOB`. `LIKE` is case-insensitive for ASCII in SQLite, so scoped reads previously matched namespaces differing only in case, while `get`/`put`/`delete` treated them as distinct. Search now agrees with them.\n\nUpgrade to `langgraph-checkpoint-postgres` 3.1.1 or `langgraph-checkpoint-sqlite` 3.1.1.\n\n## Compatibility\n\n`*` in a `list_namespaces` match path now spans exactly one namespace segment. This restores the documented behavior \u2014 `NamespacePath` documents `(\"cache\", \"*\", \"v1\")` as \"any cache category with v1 version\" \u2014 and matches `InMemoryStore`. Multi-segment matching was an artifact of translating `*` into a SQL `%` wildcard, the same mechanism responsible for this issue, and could not be preserved while fixing it.\n\nCallers relying on the previous behavior can express \"match at any depth\" by combining both match conditions, which are ANDed:\n\n```python\nlist_namespaces(prefix=[\"uid\"], suffix=[\"alice\"])\n```\n\nApplications whose namespace labels cannot be prefixes of one another see no behavioral change.\n\n## Operational guidance\n\n- Prefer fixed-length namespace labels such as UUIDs, so no label can be a prefix of another.\n- Where labels are user-supplied, validate them at the boundary rather than relying on scoping alone.\n\n## LangSmith / hosted deployments note\n\nUnlike previous store advisories, this issue does reach hosted deployments. LangSmith deployments default to `LANGGRAPH_STORE_BACKEND=python`, which uses `AsyncPostgresStore` from `checkpoint-postgres`. Deployments configured with `LANGGRAPH_STORE_BACKEND=grpc` use a separate implementation that received an equivalent fix.",
"id": "GHSA-47pj-3jcm-6whg",
"modified": "2026-08-06T19:03:12Z",
"published": "2026-08-06T19:03:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/security/advisories/GHSA-47pj-3jcm-6whg"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/pull/8478"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/commit/66ebe1a0da921e73f0f9f879ba105d314c079f7c"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langgraph"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/releases/tag/checkpointpostgres%3D%3D3.1.1"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/releases/tag/checkpointsqlite%3D%3D3.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "LangGraph: Namespace prefix matching crosses segment boundaries in Postgres and SQLite stores"
}
GHSA-47W6-GWP4-W6VC
Vulnerability from github – Published: 2026-07-24 21:49 – Updated: 2026-08-13 18:16Impact
Edit permission lacks ownership check, so another developer could alter metadata that is later trusted by nodes.
Worst they could do is update the image or image tag. If that is not noted, another image is approved than the one actually under review
Patches
No
Workarounds
No
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vantage6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73652"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:49:36Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nEdit permission lacks ownership check, so another developer could alter metadata that is later trusted by nodes. \n\nWorst they could do is update the image or image tag. If that is not noted, another image is approved than the one actually under review\n\n### Patches\nNo\n\n### Workarounds\nNo",
"id": "GHSA-47w6-gwp4-w6vc",
"modified": "2026-08-13T18:16:03Z",
"published": "2026-07-24T21:49:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vantage6/vantage6/security/advisories/GHSA-47w6-gwp4-w6vc"
},
{
"type": "PACKAGE",
"url": "https://github.com/vantage6/vantage6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "vantage6: Algorithm developer can edit another developer\u0027s algorithm that is pending / under review"
}
GHSA-47WC-GH7X-58G7
Vulnerability from github – Published: 2024-06-12 09:30 – Updated: 2024-06-12 09:30Dell Client Platform contains an incorrect authorization vulnerability. An attacker with physical access to the system could potentially exploit this vulnerability by bypassing BIOS authorization to modify settings in the BIOS.
{
"affected": [],
"aliases": [
"CVE-2024-0160"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-12T07:15:50Z",
"severity": "MODERATE"
},
"details": "Dell Client Platform contains an incorrect authorization vulnerability. An attacker with physical access to the system could potentially exploit this vulnerability by bypassing BIOS authorization to modify settings in the BIOS.",
"id": "GHSA-47wc-gh7x-58g7",
"modified": "2024-06-12T09:30:47Z",
"published": "2024-06-12T09:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0160"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000224763/dsa-2024-122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-47X5-RF97-8GGR
Vulnerability from github – Published: 2026-09-12 00:31 – Updated: 2026-10-03 00:31The application's role-authorization lookup defaults to granting access when a request handler's name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table.
{
"affected": [],
"aliases": [
"CVE-2026-90450"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T22:16:47Z",
"severity": "MODERATE"
},
"details": "The application\u0027s role-authorization lookup defaults to granting access when a request handler\u0027s name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table.",
"id": "GHSA-47x5-rf97-8ggr",
"modified": "2026-10-03T00:31:12Z",
"published": "2026-09-12T00:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90450"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2026/icsa-26-254-01.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-254-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4824-PG37-XWX7
Vulnerability from github – Published: 2026-09-09 15:35 – Updated: 2026-09-09 15:35snipe-it versions before 8.7.0 fail to enforce per-instance FMCS scoping in asset audit endpoints, relying solely on query-layer filtering instead of policy-layer authorization checks. Attackers with valid sessions and assets.audit permissions could write audit log entries against cross-company assets if the query-layer scope were bypassed or refactored.
{
"affected": [],
"aliases": [
"CVE-2026-86752"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T14:17:24Z",
"severity": "MODERATE"
},
"details": "snipe-it versions before 8.7.0 fail to enforce per-instance FMCS scoping in asset audit endpoints, relying solely on query-layer filtering instead of policy-layer authorization checks. Attackers with valid sessions and assets.audit permissions could write audit log entries against cross-company assets if the query-layer scope were bypassed or refactored.",
"id": "GHSA-4824-pg37-xwx7",
"modified": "2026-09-09T15:35:13Z",
"published": "2026-09-09T15:35:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-q745-gx2m-xj93"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86752"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/snipe-it-before-8.7.0-authorization-bypass-via-asset-audit-endpoints"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/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.