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.
6551 vulnerabilities reference this CWE, most recent first.
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-WVM9-9G5J-623F
Vulnerability from github – Published: 2026-09-10 23:04 – Updated: 2026-09-10 23:04Summary
Open WebUI's OAuth token exchange endpoint issues a session for a provider access token without running the OAuth role management that the normal OAuth login callback runs. A user whose provider roles the login callback would refuse, or would demote, could still obtain a working session at their existing role through this endpoint.
Preconditions
ENABLE_OAUTH_TOKEN_EXCHANGE=True. It is disabled by default, so a default deployment is not affected.ENABLE_OAUTH_ROLE_MANAGEMENT=Truetogether withOAUTH_ALLOWED_ROLESorOAUTH_ADMIN_ROLES. Role management is off by default, and deployments not using it are not affected.- A valid, unexpired access token on the configured provider.
- An Open WebUI account already linked to that provider subject, or an account with a matching email when
OAUTH_MERGE_ACCOUNTS_BY_EMAILis enabled. This endpoint never creates accounts, so a token for a subject with no existing account is rejected.
Impact
An admin who relies on OAuth role management expects a user to lose access, or lose admin, as soon as the identity provider stops reporting the required role. The login callback does enforce this on the next sign-in. Token exchange kept issuing sessions and never re-evaluated the role, so the user retained working access as their existing account at its existing role, including an admin role the provider had already revoked. The endpoint cannot create an account and cannot raise anyone's role, so this grants continued access rather than new or elevated access.
Fix
d799e81ed, released in 0.11.1, runs the same role evaluation on the provider's response that the login callback runs. The exchange is denied with 403 when the reported roles match no allowed or admin role, and the account's role is updated to match the provider otherwise. Upgrading restores the check with no further action.
Root cause
The affected component is the OAuth token exchange endpoint in backend/open_webui/routers/auths.py, present in builds from 0.8.0 onward.
The endpoint was added as a second entry point into the same session-issuing path the OAuth login callback uses, but it re-implemented only the identity lookup and not the policy checks surrounding it. Role evaluation lived inside the callback's own body rather than in shared code, so the second caller inherited none of it.
Credits
@Classic298
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88006"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T23:04:57Z",
"nvd_published_at": "2026-09-10T15:17:55Z",
"severity": "MODERATE"
},
"details": "## Summary\nOpen WebUI\u0027s OAuth token exchange endpoint issues a session for a provider access token without running the OAuth role management that the normal OAuth login callback runs. A user whose provider roles the login callback would refuse, or would demote, could still obtain a working session at their existing role through this endpoint.\n\n## Preconditions\n- `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. It is disabled by default, so a default deployment is not affected.\n- `ENABLE_OAUTH_ROLE_MANAGEMENT=True` together with `OAUTH_ALLOWED_ROLES` or `OAUTH_ADMIN_ROLES`. Role management is off by default, and deployments not using it are not affected.\n- A valid, unexpired access token on the configured provider.\n- An Open WebUI account already linked to that provider subject, or an account with a matching email when `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled. This endpoint never creates accounts, so a token for a subject with no existing account is rejected.\n\n## Impact\nAn admin who relies on OAuth role management expects a user to lose access, or lose admin, as soon as the identity provider stops reporting the required role. The login callback does enforce this on the next sign-in. Token exchange kept issuing sessions and never re-evaluated the role, so the user retained working access as their existing account at its existing role, including an admin role the provider had already revoked. The endpoint cannot create an account and cannot raise anyone\u0027s role, so this grants continued access rather than new or elevated access.\n\n## Fix\nd799e81ed, released in 0.11.1, runs the same role evaluation on the provider\u0027s response that the login callback runs. The exchange is denied with 403 when the reported roles match no allowed or admin role, and the account\u0027s role is updated to match the provider otherwise. Upgrading restores the check with no further action.\n\n## Root cause\nThe affected component is the OAuth token exchange endpoint in `backend/open_webui/routers/auths.py`, present in builds from 0.8.0 onward.\n\nThe endpoint was added as a second entry point into the same session-issuing path the OAuth login callback uses, but it re-implemented only the identity lookup and not the policy checks surrounding it. Role evaluation lived inside the callback\u0027s own body rather than in shared code, so the second caller inherited none of it.\n\n## Credits\n@Classic298",
"id": "GHSA-wvm9-9g5j-623f",
"modified": "2026-09-10T23:04:57Z",
"published": "2026-09-10T23:04:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-wvm9-9g5j-623f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88006"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/d799e81edbdc971c6deb096b6474cd95b93504bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Users denied by the OAuth role policy can still sign in via token exchange"
}
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": []
}
GHSA-WVXG-VJ6J-J677
Vulnerability from github – Published: 2023-07-03 15:30 – Updated: 2024-04-04 05:20Arcserve UDP through 9.0.6034 allows authentication bypass. The method getVersionInfo at WebServiceImpl/services/FlashServiceImpl leaks the AuthUUID token. This token can be used at /WebServiceImpl/services/VirtualStandbyServiceImpl to obtain a valid session. This session can be used to execute any task as administrator.
{
"affected": [],
"aliases": [
"CVE-2023-26258"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-03T15:15:10Z",
"severity": "CRITICAL"
},
"details": "Arcserve UDP through 9.0.6034 allows authentication bypass. The method getVersionInfo at WebServiceImpl/services/FlashServiceImpl leaks the AuthUUID token. This token can be used at /WebServiceImpl/services/VirtualStandbyServiceImpl to obtain a valid session. This session can be used to execute any task as administrator.",
"id": "GHSA-wvxg-vj6j-j677",
"modified": "2024-04-04T05:20:34Z",
"published": "2023-07-03T15:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26258"
},
{
"type": "WEB",
"url": "https://support.arcserve.com/s/article/KB000015720?language=en_US"
},
{
"type": "WEB",
"url": "https://www.arcserve.com/products/arcserve-udp"
},
{
"type": "WEB",
"url": "https://www.mdsec.co.uk/2023/06/cve-2023-26258-remote-code-execution-in-arcserve-udp-backup"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WW3G-F2HV-R6P3
Vulnerability from github – Published: 2026-08-20 00:35 – Updated: 2026-08-20 00:35In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
{
"affected": [],
"aliases": [
"CVE-2026-76342"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T22:17:18Z",
"severity": "MODERATE"
},
"details": "In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the \"power\" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the \"admin\" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the \"power\" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.",
"id": "GHSA-ww3g-f2hv-r6p3",
"modified": "2026-08-20T00:35:00Z",
"published": "2026-08-20T00:35:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76342"
},
{
"type": "WEB",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0801"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WW5J-8G6W-H99H
Vulnerability from github – Published: 2026-01-26 18:31 – Updated: 2026-01-29 15:30Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) contain an authorization flaw in the user management API that allows a low-privileged authenticated user to change the administrator account password. By sending a crafted request directly to the backend endpoint, an attacker can bypass role-based restrictions enforced by the web interface and obtain full administrative privileges.
{
"affected": [],
"aliases": [
"CVE-2026-24428"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-26T18:16:40Z",
"severity": "HIGH"
},
"details": "Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) contain an authorization flaw in the user management API that allows a low-privileged authenticated user to change the administrator account password. By sending a crafted request directly to the backend endpoint, an attacker can bypass role-based restrictions enforced by the web interface and obtain full administrative privileges.",
"id": "GHSA-ww5j-8g6w-h99h",
"modified": "2026-01-29T15:30:26Z",
"published": "2026-01-26T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24428"
},
{
"type": "WEB",
"url": "https://www.tendacn.com/product/W30E"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/tenda-w30e-v2-incorrect-authorization-allows-administrator-password-change"
}
],
"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"
},
{
"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/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-WW63-9P7H-RC9V
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19In WordPress before 4.9.9 and 5.x before 5.0.1, authors could modify metadata to bypass intended restrictions on deleting files.
{
"affected": [],
"aliases": [
"CVE-2018-20147"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-14T20:29:00Z",
"severity": "MODERATE"
},
"details": "In WordPress before 4.9.9 and 5.x before 5.0.1, authors could modify metadata to bypass intended restrictions on deleting files.",
"id": "GHSA-ww63-9p7h-rc9v",
"modified": "2022-05-13T01:19:52Z",
"published": "2022-05-13T01:19:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20147"
},
{
"type": "WEB",
"url": "https://codex.wordpress.org/Version_4.9.9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/02/msg00019.html"
},
{
"type": "WEB",
"url": "https://wordpress.org/news/2018/12/wordpress-5-0-1-security-release"
},
{
"type": "WEB",
"url": "https://wordpress.org/support/wordpress-version/version-5-0-1"
},
{
"type": "WEB",
"url": "https://wpvulndb.com/vulnerabilities/9169"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4401"
},
{
"type": "WEB",
"url": "https://www.zdnet.com/article/wordpress-plugs-bug-that-led-to-google-indexing-some-user-passwords"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106220"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WW63-PV5X-VFC8
Vulnerability from github – Published: 2026-06-16 21:05 – Updated: 2026-07-20 21:14Summary
Sandbox previews that were switched from public to private could remain reachable without authentication for a short period after the change, due to a cached visibility state that was not invalidated when the sandbox's visibility changed.
Impact
When a sandbox owner changed a preview from public to private, the preview proxy could continue serving unauthenticated requests to that sandbox's ordinary preview ports for a bounded period before the change took effect. Only sandboxes that had been made public and were later set back to private were affected, and only until the proxy's cached visibility state was refreshed. Terminal, toolbox, and recording-dashboard ports were never affected, as those always require authentication. The issue did not involve cross-tenant access, privilege escalation, or remote code execution.
Patches
Fixed in v0.184.0. Sandbox visibility changes now invalidate the proxy's cached preview state immediately, so revoking a public preview takes effect on the next request.
Workarounds
Upgrade to v0.184.0 or later. There is no configuration workaround for earlier versions.
Credit
Reported through Daytona's Vulnerability Disclosure Program by mrknightnidu(nidalkhan). Linkedin: https://www.linkedin.com/in/mrknight-nidu-031340328/
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.183.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/daytonaio/daytona"
},
"ranges": [
{
"events": [
{
"introduced": "0.101.0"
},
{
"fixed": "0.184.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54321"
],
"database_specific": {
"cwe_ids": [
"CWE-613",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T21:05:13Z",
"nvd_published_at": "2026-06-23T19:17:08Z",
"severity": "HIGH"
},
"details": "### Summary\nSandbox previews that were switched from public to private could remain reachable without authentication for a short period after the change, due to a cached visibility state that was not invalidated when the sandbox\u0027s visibility changed.\n\n### Impact\nWhen a sandbox owner changed a preview from public to private, the preview proxy could continue serving unauthenticated requests to that sandbox\u0027s ordinary preview ports for a bounded period before the change took effect. Only sandboxes that had been made public and were later set back to private were affected, and only until the proxy\u0027s cached visibility state was refreshed. Terminal, toolbox, and recording-dashboard ports were never affected, as those always require authentication. The issue did not involve cross-tenant access, privilege escalation, or remote code execution.\n\n### Patches\nFixed in v0.184.0. Sandbox visibility changes now invalidate the proxy\u0027s cached preview state immediately, so revoking a public preview takes effect on the next request.\n\n### Workarounds\nUpgrade to v0.184.0 or later. There is no configuration workaround for earlier versions.\n\n### Credit\nReported through Daytona\u0027s Vulnerability Disclosure Program by **mrknightnidu(nidalkhan)**.\n**Linkedin**: https://www.linkedin.com/in/mrknight-nidu-031340328/",
"id": "GHSA-ww63-pv5x-vfc8",
"modified": "2026-07-20T21:14:49Z",
"published": "2026-06-16T21:05:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/daytonaio/daytona/security/advisories/GHSA-ww63-pv5x-vfc8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54321"
},
{
"type": "PACKAGE",
"url": "https://github.com/daytonaio/daytona"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Daytona: Public sandbox previews remain accessible for up to one hour after being made private"
}
GHSA-WW6F-VP8M-358F
Vulnerability from github – Published: 2021-12-01 00:00 – Updated: 2022-07-13 00:01Trend Micro Antivirus for Mac 2021 v11 (Consumer) is vulnerable to an improper access control privilege escalation vulnerability that could allow an attacker to establish a connection that could lead to full local privilege escalation within the application. Please note that an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-43771"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-30T12:15:00Z",
"severity": "HIGH"
},
"details": "Trend Micro Antivirus for Mac 2021 v11 (Consumer) is vulnerable to an improper access control privilege escalation vulnerability that could allow an attacker to establish a connection that could lead to full local privilege escalation within the application. Please note that an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.",
"id": "GHSA-ww6f-vp8m-358f",
"modified": "2022-07-13T00:01:48Z",
"published": "2021-12-01T00:00:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43771"
},
{
"type": "WEB",
"url": "https://helpcenter.trendmicro.com/en-us/article/TMKA-10832"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1320"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.