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.
5528 vulnerabilities reference this CWE, most recent first.
GHSA-WRX7-QM3P-QW79
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:33An issue was discovered in network-manager-applet (aka network-manager-gnome) in Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS, and 16.10. A local attacker could use this issue at the default Ubuntu login screen to access local files and execute arbitrary commands as the lightdm user. The exploitation requires physical access to the locked computer and the Wi-Fi must be turned on. An access point that lets you use a certificate to login is required as well, but it's easy to create one. Then, it's possible to open a nautilus window and browse directories. One also can open some applications such as Firefox, which is useful for downloading malicious binaries.
{
"affected": [],
"aliases": [
"CVE-2017-6590"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-09T19:59:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in network-manager-applet (aka network-manager-gnome) in Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS, and 16.10. A local attacker could use this issue at the default Ubuntu login screen to access local files and execute arbitrary commands as the lightdm user. The exploitation requires physical access to the locked computer and the Wi-Fi must be turned on. An access point that lets you use a certificate to login is required as well, but it\u0027s easy to create one. Then, it\u0027s possible to open a nautilus window and browse directories. One also can open some applications such as Firefox, which is useful for downloading malicious binaries.",
"id": "GHSA-wrx7-qm3p-qw79",
"modified": "2025-04-20T03:33:56Z",
"published": "2022-05-13T01:46:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6590"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1668321"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201707-09"
},
{
"type": "WEB",
"url": "https://www.ubuntu.com/usn/usn-3217-1"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=Fp2lwRVg0l0"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037977"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WV26-J37Q-2G7P
Vulnerability from github – Published: 2026-07-02 16:18 – Updated: 2026-07-02 16:18Summary
Slack plugin approvals used the exec approver gate for plugin actions. In affected versions, a Slack user authorized only for exec approvals could resolve a plugin approval through the exec approver gate.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
Impact
When the affected feature is enabled and reachable, this could approve a plugin action outside the operator's intended approval split. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
Patched Versions
The first stable patched version is 2026.5.12.
Mitigations
keep approval allowlists aligned and review Slack approval actions manually until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T16:18:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nSlack plugin approvals used the exec approver gate for plugin actions. In affected versions, a Slack user authorized only for exec approvals could resolve a plugin approval through the exec approver gate.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could approve a plugin action outside the operator\u0027s intended approval split. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.12`.\n\n### Mitigations\n\nkeep approval allowlists aligned and review Slack approval actions manually until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
"id": "GHSA-wv26-j37q-2g7p",
"modified": "2026-07-02T16:18:24Z",
"published": "2026-07-02T16:18:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-wv26-j37q-2g7p"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "OpenClaw\u0027s Slack plugin approvals used the exec approver gate for plugin actions"
}
GHSA-WV3H-X6C4-R867
Vulnerability from github – Published: 2026-01-21 09:31 – Updated: 2026-02-13 20:24A flaw was found in the keycloak-services component of Keycloak. This vulnerability allows the issuance of access and refresh tokens for disabled users, leading to unauthorized use of previously revoked privileges, via a business logic vulnerability in the Token Exchange implementation when a privileged client invokes the token exchange flow.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.5.0"
},
{
"fixed": "26.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-14559"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-21T22:30:24Z",
"nvd_published_at": "2026-01-21T07:16:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the keycloak-services component of Keycloak. This vulnerability allows the issuance of access and refresh tokens for disabled users, leading to unauthorized use of previously revoked privileges, via a business logic vulnerability in the Token Exchange implementation when a privileged client invokes the token exchange flow.",
"id": "GHSA-wv3h-x6c4-r867",
"modified": "2026-02-13T20:24:37Z",
"published": "2026-01-21T09:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14559"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/issues/45651"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/2d0aa31c4830ebaad094c3762e78b884c141e659"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/d67349f3aa9fed5c61750619d0f9de6356aeaeff"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2365"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2366"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-14559"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2421711"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/releases/tag/26.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak services allows the issuance of access and refresh tokens for disabled users"
}
GHSA-WV3V-P4HP-955F
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-10-21 19:01An Improper Access Control vulnerability in the logging component of Bitdefender Endpoint Security Tools for Windows versions prior to 6.6.23.320 allows a regular user to learn the scanning exclusion paths. This issue was discovered during external security research.
{
"affected": [],
"aliases": [
"CVE-2020-15279"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-18T11:15:00Z",
"severity": "LOW"
},
"details": "An Improper Access Control vulnerability in the logging component of Bitdefender Endpoint Security Tools for Windows versions prior to 6.6.23.320 allows a regular user to learn the scanning exclusion paths. This issue was discovered during external security research.",
"id": "GHSA-wv3v-p4hp-955f",
"modified": "2022-10-21T19:01:12Z",
"published": "2022-05-24T19:02:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15279"
},
{
"type": "WEB",
"url": "https://www.bitdefender.com/support/security-advisories/scanning-exclusion-paths-disclosure-in-best-for-windows-va-9380"
}
],
"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-WV76-CP7M-4V99
Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2022-09-29 00:00Smart eVision has insufficient authorization for task acquisition function. An unauthorized remote attacker can exploit this vulnerability to acquire the Session IDs of other general users only.
{
"affected": [],
"aliases": [
"CVE-2022-39031"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-28T04:15:00Z",
"severity": "MODERATE"
},
"details": "Smart eVision has insufficient authorization for task acquisition function. An unauthorized remote attacker can exploit this vulnerability to acquire the Session IDs of other general users only.",
"id": "GHSA-wv76-cp7m-4v99",
"modified": "2022-09-29T00:00:17Z",
"published": "2022-09-29T00:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39031"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-6568-331c1-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WV7F-C794-82V6
Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-18 14:34Incorrect Authorization vulnerability allows users to access workflow instance information belonging to projects they do not have permission to access.
This issue affects Apache DolphinScheduler versions prior to 3.4.2.
Users are recommended to upgrade to version 3.4.2, which fixes this issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.dolphinscheduler:dolphinscheduler-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42357"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:34:32Z",
"nvd_published_at": "2026-06-17T13:20:39Z",
"severity": "MODERATE"
},
"details": "Incorrect Authorization vulnerability allows users to access workflow instance information belonging to projects they do not have permission to access.\n\nThis issue affects Apache DolphinScheduler versions prior to 3.4.2.\n\n\nUsers are recommended to upgrade to version 3.4.2, which fixes this issue.",
"id": "GHSA-wv7f-c794-82v6",
"modified": "2026-06-18T14:34:32Z",
"published": "2026-06-17T18:35:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42357"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/dolphinscheduler"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/74l2rrz32w2chn7vz64313gk7ox5wjtr"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/17/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache DolphinScheduler: Incorrect Authorization vulnerability allows users to access workflow instance information belonging to projects they do not have permission to access. "
}
GHSA-WVCV-9XPM-7MQC
Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-06-01 15:13Mattermost versions 11.5.x <= 11.5.1, 10.11.x <= 10.11.13, 11.4.x <= 11.4.3 Fail to enforce slash command trigger-word uniqueness during command updates which allows an authenticated team member with Manage Own Slash Commands permission to hijack and impersonate existing system or custom slash commands via editing their own slash command trigger to an already-registered trigger through the command update API. Mattermost Advisory ID: MMSA-2026-00597
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.5.0"
},
{
"fixed": "11.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.4.0"
},
{
"fixed": "11.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20260306123948-f5fe8ded6b63"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20260306123948-f5fe8ded6b63"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28732"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-01T15:13:28Z",
"nvd_published_at": "2026-05-18T09:16:22Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.5.x \u003c= 11.5.1, 10.11.x \u003c= 10.11.13, 11.4.x \u003c= 11.4.3 Fail to enforce slash command trigger-word uniqueness during command updates which allows an authenticated team member with Manage Own Slash Commands permission to hijack and impersonate existing system or custom slash commands via editing their own slash command trigger to an already-registered trigger through the command update API. Mattermost Advisory ID: MMSA-2026-00597",
"id": "GHSA-wvcv-9xpm-7mqc",
"modified": "2026-06-01T15:13:28Z",
"published": "2026-05-18T09:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28732"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/f5fe8ded6b633db7804ae25b42ea12ce635d6ea6"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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"
}
],
"summary": "Mattermost doesn\u0027t enforce slash command trigger-word uniqueness during command updates"
}
GHSA-WVHQ-WP8G-C7VQ
Vulnerability from github – Published: 2026-03-06 18:48 – Updated: 2026-03-09 13:15Summary
Flowise trusts any HTTP client that sets the header x-request-from: internal, allowing an authenticated tenant session to bypass all /api/v1/** authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.
Details
The global middleware that guards /api/v1 routes lives in external/Flowise/packages/server/src/index.ts:214. After filtering out the whitelist, the logic short-circuits on the spoofable header:
if (isWhitelisted) {
next();
} else if (req.headers['x-request-from'] === 'internal') {
verifyToken(req, res, next);
} else {
const { isValid } = await validateAPIKey(req);
if (!isValid) return res.status(401).json({ error: 'Unauthorized Access' });
… // owner context stitched from API key
}
Because the middle branch blindly calls verifyToken, any tenant that already has a UI session cookie is treated as an internal client simply by adding that header. No additional permission checks are performed before next() executes, so every downstream router under /api/v1 becomes reachable.
PoC
- Log into Flowise 3.0.8 and capture cookies (e.g.,
curl -c /tmp/flowise_cookies.txt … /api/v1/auth/login). - Invoke an internal-only endpoint with the spoofed header:
curl -sS -b /tmp/flowise_cookies.txt \
-H 'Content-Type: application/json' \
-H 'x-request-from: internal' \
-X POST http://127.0.0.1:3100/api/v1/apikey \
-d '{"keyName":"Bypass Demo"}'
The server returns HTTP 200 and the newly created key object.
- Remove the header and retry:
curl -sS -b /tmp/flowise_cookies.txt \
-H 'Content-Type: application/json' \
-X POST http://127.0.0.1:3100/api/v1/apikey \
-d '{"keyName":"Bypass Demo"}'
This yields {"error":"Unauthorized Access"}, confirming the header alone controls access.
The same spoof grants access to other privileged routes like /api/v1/credentials, /api/v1/tools, /api/v1/node-custom-function, etc.
Impact
This is an authorization bypass / privilege escalation. Any authenticated tenant (even without API keys or elevated roles) can execute internal administration APIs solely from the browser, enabling actions such as minting new API keys, harvesting stored secrets, and, when combined with other flaws (e.g., Custom Function RCE), full system compromise. All self-hosted Flowise 3.0.8 deployments that rely on the default middleware are affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30820"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-06T18:48:22Z",
"nvd_published_at": "2026-03-07T05:16:26Z",
"severity": "HIGH"
},
"details": "### Summary\n\nFlowise trusts any HTTP client that sets the header `x-request-from: internal`, allowing an authenticated tenant session to bypass all `/api/v1/**` authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.\n\n### Details\n\nThe global middleware that guards `/api/v1` routes lives in `external/Flowise/packages/server/src/index.ts:214`. After filtering out the whitelist, the logic short-circuits on the spoofable header:\n\n```javascript\nif (isWhitelisted) {\n next();\n} else if (req.headers[\u0027x-request-from\u0027] === \u0027internal\u0027) {\n verifyToken(req, res, next);\n} else {\n const { isValid } = await validateAPIKey(req);\n if (!isValid) return res.status(401).json({ error: \u0027Unauthorized Access\u0027 });\n \u2026 // owner context stitched from API key\n}\n```\n\nBecause the middle branch blindly calls verifyToken, any tenant that already has a UI session cookie is treated as an internal client simply by adding that header. No additional permission checks are performed before `next()` executes, so every downstream router under `/api/v1` becomes reachable.\n\n### PoC\n\n1. Log into Flowise 3.0.8 and capture cookies (e.g., `curl -c /tmp/flowise_cookies.txt \u2026 /api/v1/auth/login`).\n2. Invoke an internal-only endpoint with the spoofed header:\n\n```bash\n curl -sS -b /tmp/flowise_cookies.txt \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027x-request-from: internal\u0027 \\\n -X POST http://127.0.0.1:3100/api/v1/apikey \\\n -d \u0027{\"keyName\":\"Bypass Demo\"}\u0027\n```\n The server returns HTTP 200 and the newly created key object.\n3. Remove the header and retry:\n\n```bash\n curl -sS -b /tmp/flowise_cookies.txt \\\n -H \u0027Content-Type: application/json\u0027 \\\n -X POST http://127.0.0.1:3100/api/v1/apikey \\\n -d \u0027{\"keyName\":\"Bypass Demo\"}\u0027\n```\n This yields {\"error\":\"Unauthorized Access\"}, confirming the header alone controls access.\n\nThe same spoof grants access to other privileged routes like `/api/v1/credentials`, `/api/v1/tools`, `/api/v1/node-custom-function`, etc.\n\n### Impact\n\nThis is an authorization bypass / privilege escalation. Any authenticated tenant (even without API keys or elevated roles) can execute internal administration APIs solely from the browser, enabling actions such as minting new API keys, harvesting stored secrets, and, when combined with other flaws (e.g., Custom Function RCE), full system compromise. All self-hosted Flowise 3.0.8 deployments that rely on the default middleware are affected.",
"id": "GHSA-wvhq-wp8g-c7vq",
"modified": "2026-03-09T13:15:20Z",
"published": "2026-03-06T18:48:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-wvhq-wp8g-c7vq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30820"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.0.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise has Authorization Bypass via Spoofed x-request-from Header"
}
GHSA-WVP2-9PPW-337J
Vulnerability from github – Published: 2023-07-25 18:24 – Updated: 2023-07-25 18:24Impact
Spring supports Matrix variables.
When Spring integration is used, Armeria calls Spring controllers via TomcatService or JettyService with the path
that may contain matrix variables.
In this situation, the Armeria decorators might not invoked because of the matrix variables.
Let's see the following example:
// Spring controller
@GetMapping("/important/resources")
public String important() {...}
// Armeria decorator
ServerBuilder sb = ...
sb.decoratorUnder("/important/", authService);
If an attacker sends a request with /important;a=b/resources, the request would bypass the authrorizer
Patches
- https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c
Workarounds
Users can add decorators using regex. e.g. "regex:^/important.*"
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.24.2"
},
"package": {
"ecosystem": "Maven",
"name": "com.linecorp.armeria:armeria"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.24.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-38493"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-25T18:24:39Z",
"nvd_published_at": "2023-07-25T21:15:10Z",
"severity": "HIGH"
},
"details": "### Impact\nSpring supports [Matrix variables](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller/ann-methods/matrix-variables.html).\nWhen Spring integration is used, Armeria calls Spring controllers via `TomcatService` or `JettyService` with the path\nthat may contain matrix variables.\nIn this situation, the Armeria decorators might not invoked because of the matrix variables.\nLet\u0027s see the following example:\n```\n// Spring controller\n@GetMapping(\"/important/resources\")\npublic String important() {...}\n\n// Armeria decorator\nServerBuilder sb = ...\nsb.decoratorUnder(\"/important/\", authService);\n```\nIf an attacker sends a request with `/important;a=b/resources`, the request would bypass the authrorizer\n\n### Patches\n- https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c\n\n### Workarounds\nUsers can add decorators using regex. `e.g. \"regex:^/important.*\"`\n",
"id": "GHSA-wvp2-9ppw-337j",
"modified": "2023-07-25T18:24:39Z",
"published": "2023-07-25T18:24:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/line/armeria/security/advisories/GHSA-wvp2-9ppw-337j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38493"
},
{
"type": "WEB",
"url": "https://github.com/line/armeria/commit/039db50bbfc88014ea8737fd1e1ddd6fd3fc4f07"
},
{
"type": "WEB",
"url": "https://github.com/line/armeria/commit/49e04ef231ad65750739529c7fa4ce946ff7588b"
},
{
"type": "WEB",
"url": "https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller/ann-methods/matrix-variables.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/line/armeria"
}
],
"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"
}
],
"summary": "Paths contain matrix variables bypass decorators"
}
GHSA-WVV5-79H5-39G9
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-05-24 19:01An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.8. GitLab was not properly validating authorisation tokens which resulted in GraphQL mutation being executed.
{
"affected": [],
"aliases": [
"CVE-2021-22209"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-06T14:15:00Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.8. GitLab was not properly validating authorisation tokens which resulted in GraphQL mutation being executed.",
"id": "GHSA-wvv5-79h5-39g9",
"modified": "2022-05-24T19:01:30Z",
"published": "2022-05-24T19:01:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22209"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22209.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/327155"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.