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.
5517 vulnerabilities reference this CWE, most recent first.
GHSA-XFXC-C47W-9432
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19An improper access control flaw in GitLab CE/EE since version 13.9 exposes private email address of Issue and Merge Requests assignee to Webhook data consumers
{
"affected": [],
"aliases": [
"CVE-2021-39911"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-05T00:15:00Z",
"severity": "MODERATE"
},
"details": "An improper access control flaw in GitLab CE/EE since version 13.9 exposes private email address of Issue and Merge Requests assignee to Webhook data consumers",
"id": "GHSA-xfxc-c47w-9432",
"modified": "2022-05-24T19:19:53Z",
"published": "2022-05-24T19:19:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39911"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39911.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/297470"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XG2H-39GR-H327
Vulnerability from github – Published: 2025-03-11 15:31 – Updated: 2025-03-11 15:31An incorrect authorization vulnerability [CWE-863] in FortiSandbox 4.4.0 through 4.4.6 may allow a low priviledged administrator to execute elevated CLI commands via the GUI console menu.
{
"affected": [],
"aliases": [
"CVE-2024-45328"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-11T15:15:41Z",
"severity": "HIGH"
},
"details": "An incorrect authorization vulnerability [CWE-863] in FortiSandbox 4.4.0 through 4.4.6 may allow a low priviledged administrator to execute elevated CLI commands via the GUI console menu.",
"id": "GHSA-xg2h-39gr-h327",
"modified": "2025-03-11T15:31:01Z",
"published": "2025-03-11T15:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45328"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-261"
}
],
"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"
}
]
}
GHSA-XG2Q-62G2-CVCM
Vulnerability from github – Published: 2026-03-12 16:38 – Updated: 2026-03-24 21:11Summary
The OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.
Details
When an authorization code is created, StoreCode at internal/service/oidc_service.go:305-322 correctly stores the ClientID alongside the code hash in the database (line 316).
During token exchange at internal/controller/oidc_controller.go:267-309, the handler retrieves the code entry at line 268 and validates the redirect_uri at line 291, but never compares entry.ClientID against the requesting client's ID (creds.ClientID). The code proceeds directly to GenerateAccessToken at line 299.
The developers clearly intended this check to exist, the refresh token flow at internal/service/oidc_service.go:508-510 has the exact guard: if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }. It was simply omitted from the authorization code grant.
The entry.ClientID field is stored in the database but never read during authorization code exchange.
PoC
Prerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A's redirect (via referrer leak, browser history, log access, etc.).
Step 1 — Log in as a normal user:
curl -c cookies.txt -X POST http://localhost:3000/api/user/login \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"admin123"}'
Step 2 — Authorize with Client A:
curl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \
-H "Content-Type: application/json" \
-d '{"client_id":"client-a-id","redirect_uri":"http://localhost:8080/callback","response_type":"code","scope":"openid","state":"test"}'
Extract the code parameter from the redirect_uri in the response.
Step 3 — Exchange Client A's code using Client B's credentials:
curl -X POST http://localhost:3000/api/oidc/token \
-u "client-b-id:client-b-secret" \
-d "grant_type=authorization_code&code=<CODE_FROM_STEP_2>&redirect_uri=http://localhost:8080/callback"
The server returns a valid access_token, id_token, and refresh_token. Client B has obtained tokens for a user who only authorized Client A.
Impact
A malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client's authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/steveiliop56/tinyauth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.1-20260311144920-9eb2d33064b7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32245"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T16:38:42Z",
"nvd_published_at": "2026-03-12T19:16:19Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client\u0027s authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.\n\n### Details\n\nWhen an authorization code is created, `StoreCode` at `internal/service/oidc_service.go:305-322` correctly stores the `ClientID` alongside the code hash in the database (line 316).\n\nDuring token exchange at `internal/controller/oidc_controller.go:267-309`, the handler retrieves the code entry at line 268 and validates the `redirect_uri` at line 291, but never compares `entry.ClientID` against the requesting client\u0027s ID (`creds.ClientID`). The code proceeds directly to `GenerateAccessToken` at line 299.\n\nThe developers clearly intended this check to exist, the refresh token flow at `internal/service/oidc_service.go:508-510` has the exact guard: `if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }`. It was simply omitted from the authorization code grant.\n\nThe `entry.ClientID` field is stored in the database but never read during authorization code exchange.\n\n### PoC\n\nPrerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A\u0027s redirect (via referrer leak, browser history, log access, etc.).\n\nStep 1 \u2014 Log in as a normal user:\n\n```\ncurl -c cookies.txt -X POST http://localhost:3000/api/user/login \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"username\":\"admin\",\"password\":\"admin123\"}\u0027\n```\n\nStep 2 \u2014 Authorize with Client A:\n\n```\ncurl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"client_id\":\"client-a-id\",\"redirect_uri\":\"http://localhost:8080/callback\",\"response_type\":\"code\",\"scope\":\"openid\",\"state\":\"test\"}\u0027\n```\n\nExtract the `code` parameter from the `redirect_uri` in the response.\n\nStep 3 \u2014 Exchange Client A\u0027s code using Client B\u0027s credentials:\n\n```\ncurl -X POST http://localhost:3000/api/oidc/token \\\n -u \"client-b-id:client-b-secret\" \\\n -d \"grant_type=authorization_code\u0026code=\u003cCODE_FROM_STEP_2\u003e\u0026redirect_uri=http://localhost:8080/callback\"\n```\n\nThe server returns a valid `access_token`, `id_token`, and `refresh_token`. Client B has obtained tokens for a user who only authorized Client A.\n\n### Impact\n\nA malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client\u0027s authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.",
"id": "GHSA-xg2q-62g2-cvcm",
"modified": "2026-03-24T21:11:30Z",
"published": "2026-03-12T16:38:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/security/advisories/GHSA-xg2q-62g2-cvcm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32245"
},
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/commit/b2a1bfb1f532e87f205fa3afa3fc9f148c53ab89"
},
{
"type": "PACKAGE",
"url": "https://github.com/steveiliop56/tinyauth"
},
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/releases/tag/v5.0.3"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-4689"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tinyauth\u0027s OIDC authorization codes are not bound to client on token exchange"
}
GHSA-XG36-8C2V-JPXH
Vulnerability from github – Published: 2024-10-10 12:31 – Updated: 2024-10-11 18:24Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Incorrect Authorization vulnerability that could result in a security feature bypass. A low-privileged attacker could exploit this vulnerability to have a low impact on integrity. Exploitation of this issue does not require user interaction.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.7-beta1"
},
{
"fixed": "2.4.7-p3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.6-p1"
},
{
"fixed": "2.4.6-p8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.5-p1"
},
{
"fixed": "2.4.5-p10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4-p11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.7"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.6"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.5"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.4"
]
}
],
"aliases": [
"CVE-2024-45125"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-11T18:24:29Z",
"nvd_published_at": "2024-10-10T10:15:05Z",
"severity": "MODERATE"
},
"details": "Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Incorrect Authorization vulnerability that could result in a security feature bypass. A low-privileged attacker could exploit this vulnerability to have a low impact on integrity. Exploitation of this issue does not require user interaction.",
"id": "GHSA-xg36-8c2v-jpxh",
"modified": "2024-10-11T18:24:30Z",
"published": "2024-10-10T12:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45125"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb24-73.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Magento Open Source Incorrect Authorization vulnerability"
}
GHSA-XG59-F45V-9R9J
Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-04-06 22:45Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-g7cr-9h7q-4qxq. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.3.8 contains a sender allowlist bypass vulnerability in its Microsoft Teams plugin that allows unauthorized senders to bypass intended authorization checks. When a team/channel route allowlist is configured with an empty groupAllowFrom parameter, the message handler synthesizes wildcard sender authorization, permitting any sender in the matched team/channel to trigger replies in allowlisted Teams routes.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-06T22:45:43Z",
"nvd_published_at": "2026-03-31T12:16:30Z",
"severity": "LOW"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-g7cr-9h7q-4qxq. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.8 contains a sender allowlist bypass vulnerability in its Microsoft Teams plugin that allows unauthorized senders to bypass intended authorization checks. When a team/channel route allowlist is configured with an empty groupAllowFrom parameter, the message handler synthesizes wildcard sender authorization, permitting any sender in the matched team/channel to trigger replies in allowlisted Teams routes.",
"id": "GHSA-xg59-f45v-9r9j",
"modified": "2026-04-06T22:45:43Z",
"published": "2026-03-31T12:31:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g7cr-9h7q-4qxq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34506"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/88aee9161e0e6d32e810a25711e32a808a1777b2"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-sender-allowlist-bypass-in-microsoft-teams-plugin-via-route-allowlist-configuration"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/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"
}
],
"summary": "Duplicate Advisory: OpenClaw\u0027s MS Teams sender allowlist bypass when route allowlist is configured and sender allowlist is empty",
"withdrawn": "2026-04-06T22:45:43Z"
}
GHSA-XGC5-8VG7-68X3
Vulnerability from github – Published: 2025-06-11 00:30 – Updated: 2025-06-11 00:30The ws.stash.app.mac.daemon.helper tool contains a vulnerability caused by an incorrect use of macOS’s authorization model. Instead of validating the client's authorization reference, the helper invokes AuthorizationCopyRights() using its own privileged context (root), effectively authorizing itself rather than the client. As a result, it grants the system.preferences.admin right internally, regardless of the requesting client's privileges. This flawed logic allows unprivileged clients to invoke privileged operations via XPC, including unauthorized changes to system-wide network preferences such as SOCKS, HTTP, and HTTPS proxy settings. The absence of proper code-signing checks further enables arbitrary processes to exploit this flaw, leading to man-in-the-middle (MITM) attacks through traffic redirection.
{
"affected": [],
"aliases": [
"CVE-2024-7457"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-11T00:15:23Z",
"severity": "HIGH"
},
"details": "The ws.stash.app.mac.daemon.helper tool contains a vulnerability caused by an incorrect use of macOS\u2019s authorization model. Instead of validating the client\u0027s authorization reference, the helper invokes AuthorizationCopyRights() using its own privileged context (root), effectively authorizing itself rather than the client. As a result, it grants the system.preferences.admin right internally, regardless of the requesting client\u0027s privileges. This flawed logic allows unprivileged clients to invoke privileged operations via XPC, including unauthorized changes to system-wide network preferences such as SOCKS, HTTP, and HTTPS proxy settings. The absence of proper code-signing checks further enables arbitrary processes to exploit this flaw, leading to man-in-the-middle (MITM) attacks through traffic redirection.",
"id": "GHSA-xgc5-8vg7-68x3",
"modified": "2025-06-11T00:30:48Z",
"published": "2025-06-11T00:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7457"
},
{
"type": "WEB",
"url": "https://pentraze.com"
}
],
"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"
}
]
}
GHSA-XGHP-2WJ5-QCMQ
Vulnerability from github – Published: 2022-03-03 00:00 – Updated: 2022-03-17 00:04Improper Authorization in GitHub repository webmin/webmin prior to 1.990.
{
"affected": [],
"aliases": [
"CVE-2022-0829"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-02T12:15:00Z",
"severity": "HIGH"
},
"details": "Improper Authorization in GitHub repository webmin/webmin prior to 1.990.",
"id": "GHSA-xghp-2wj5-qcmq",
"modified": "2022-03-17T00:04:16Z",
"published": "2022-03-03T00:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0829"
},
{
"type": "WEB",
"url": "https://github.com/webmin/webmin/commit/eeeea3c097f5cc473770119f7ac61f1dcfa671b9"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/f2d0389f-d7d1-4f34-9f9d-268b0a0da05e"
},
{
"type": "WEB",
"url": "https://notes.netbytesec.com/2022/03/webmin-broken-access-control-to-post-auth-rce.html"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-XGRF-RHVW-H8MR
Vulnerability from github – Published: 2023-02-09 18:30 – Updated: 2025-03-25 15:31The multi-screen collaboration module has a privilege escalation vulnerability. Successful exploitation of this vulnerability may affect data confidentiality.
{
"affected": [],
"aliases": [
"CVE-2022-48286"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-09T17:15:00Z",
"severity": "HIGH"
},
"details": "The multi-screen collaboration module has a privilege escalation vulnerability. Successful exploitation of this vulnerability may affect data confidentiality.",
"id": "GHSA-xgrf-rhvw-h8mr",
"modified": "2025-03-25T15:31:12Z",
"published": "2023-02-09T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48286"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/2"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202302-0000001454769474"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XGWG-M42C-8Q62
Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-24 19:06Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-v8cg-4474-49v8. This link is maintained to preserve external references.
Original Description
OpenClaw versions prior to 2026.2.26 fail to enforce sender authorization in member and message subtype system event handlers, allowing unauthorized events to be enqueued. Attackers can bypass Slack DM allowlists and per-channel user allowlists by sending system events from non-allowlisted senders through message_changed, message_deleted, and thread_broadcast events.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.2.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T19:06:23Z",
"nvd_published_at": "2026-03-21T01:17:10Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-v8cg-4474-49v8. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw versions prior to 2026.2.26 fail to enforce sender authorization in member and message subtype system event handlers, allowing unauthorized events to be enqueued. Attackers can bypass Slack DM allowlists and per-channel user allowlists by sending system events from non-allowlisted senders through message_changed, message_deleted, and thread_broadcast events.",
"id": "GHSA-xgwg-m42c-8q62",
"modified": "2026-03-24T19:06:23Z",
"published": "2026-03-21T03:31:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-v8cg-4474-49v8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32895"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/3d30ba18a2aba1e1b302e77ff33145c3b06c01c8"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-sender-authorization-bypass-in-slack-system-event-handlers"
}
],
"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"
}
],
"summary": "Duplicate Advisory: OpenClaw: Slack system events bypass sender authorization in member and message subtype handlers",
"withdrawn": "2026-03-24T19:06:23Z"
}
GHSA-XH25-GX5F-4HQG
Vulnerability from github – Published: 2025-12-19 00:31 – Updated: 2025-12-19 00:31Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to change a document's sharing type to "global," even though they do not have permission to do so, making it visible to everyone in the space via a crafted a HTTP request.
{
"affected": [],
"aliases": [
"CVE-2025-68386"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T23:15:49Z",
"severity": "MODERATE"
},
"details": "Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to change a document\u0027s sharing type to \"global,\" even though they do not have permission to do so, making it visible to everyone in the space via a crafted a HTTP request.",
"id": "GHSA-xh25-gx5f-4hqg",
"modified": "2025-12-19T00:31:42Z",
"published": "2025-12-19T00:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68386"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-8-19-8-9-1-8-and-9-2-2-security-update-esa-2025-38/384186"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"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.