CWE-639
AllowedAuthorization Bypass Through User-Controlled Key
Abstraction: Base · Status: Incomplete
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
3323 vulnerabilities reference this CWE, most recent first.
GHSA-J4HM-CC75-4F7J
Vulnerability from github – Published: 2026-02-11 09:30 – Updated: 2026-06-05 09:33Authorization Bypass Through User-Controlled Key vulnerability in Saastech Cleaning and Internet Services Inc. TemizlikYolda allows Manipulating User-Controlled Variables.This issue affects TemizlikYolda: through 11022026.
NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-10912"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T08:16:06Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Saastech Cleaning and Internet Services Inc. TemizlikYolda allows Manipulating User-Controlled Variables.This issue affects TemizlikYolda: through 11022026.\n\nNOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-j4hm-cc75-4f7j",
"modified": "2026-06-05T09:33:45Z",
"published": "2026-02-11T09:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10912"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0055"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-26-0055"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-J4XF-96QF-RX69
Vulnerability from github – Published: 2026-03-03 21:41 – Updated: 2026-03-30 13:16Summary
Feishu allowlist authorization could be bypassed by display-name collision.
Details
channels.feishu.allowFrom is documented as an ID-based allowlist (open_id list), but Feishu policy matching accepted mutable sender display names in the same namespace. An attacker could set a display name equal to an allowlisted ID string and pass authorization checks.
The fix enforces ID-only matching for Feishu allowlist checks, normalizes Feishu ID prefixes during comparison, and ignores mutable display names for authorization.
Impact
Deployments using Feishu allowlist-based authorization could incorrectly authorize non-allowlisted senders when a colliding display name was used.
Affected Packages / Versions
- Package:
openclaw(npm) - Latest published version at triage time:
2026.2.21-2 - Affected range:
<= 2026.2.21-2 - Planned patched version:
>= 2026.2.22
Fix Commit(s)
4ed87a667263ed2d422b9d5d5a5d326e099f92c7
Release Process Note
patched_versions is pre-set to the planned next release (>= 2026.2.22) so the advisory is ready to publish once that npm release is available.
OpenClaw thanks @jiseoung for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32021"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:41:38Z",
"nvd_published_at": "2026-03-19T22:16:36Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nFeishu allowlist authorization could be bypassed by display-name collision.\n\n### Details\n\n`channels.feishu.allowFrom` is documented as an ID-based allowlist (open_id list), but Feishu policy matching accepted mutable sender display names in the same namespace. An attacker could set a display name equal to an allowlisted ID string and pass authorization checks.\n\nThe fix enforces ID-only matching for Feishu allowlist checks, normalizes Feishu ID prefixes during comparison, and ignores mutable display names for authorization.\n\n### Impact\n\nDeployments using Feishu allowlist-based authorization could incorrectly authorize non-allowlisted senders when a colliding display name was used.\n\n### Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Latest published version at triage time: `2026.2.21-2`\n- Affected range: `\u003c= 2026.2.21-2`\n- Planned patched version: `\u003e= 2026.2.22`\n\n### Fix Commit(s)\n\n- `4ed87a667263ed2d422b9d5d5a5d326e099f92c7`\n\n### Release Process Note\n\n`patched_versions` is pre-set to the planned next release (`\u003e= 2026.2.22`) so the advisory is ready to publish once that npm release is available.\n\nOpenClaw thanks @jiseoung for reporting.",
"id": "GHSA-j4xf-96qf-rx69",
"modified": "2026-03-30T13:16:06Z",
"published": "2026-03-03T21:41:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-j4xf-96qf-rx69"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32021"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/4ed87a667263ed2d422b9d5d5a5d326e099f92c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-display-name-collision-in-feishu-allowfrom"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw has a Feishu allowFrom authorization bypass via display-name collision"
}
GHSA-J5MC-P8QG-39J7
Vulnerability from github – Published: 2026-07-02 20:44 – Updated: 2026-07-02 20:44Summary
Kimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user's timesheet.id can add that record to, or remove it from, the victim's favorite/recent bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.
Details
The issue affects the following routes:
GET /en/favorite/timesheet/add/{id}GET /en/favorite/timesheet/remove/{id}
Both endpoints accept a user-controlled timesheet identifier and only require the caller to hold the generic start_own_timesheet permission. They do not verify that the referenced Timesheet object belongs to the currently authenticated user.
- In
src/Controller/FavoriteController.php, the controller methods accept aTimesheetobject directly and forward it to the favorite service. - The root cause becomes more obvious in
src/Timesheet/FavoriteRecordService.php. The bookmark owner is derived from$timesheet->getUser()instead of the current session user. - Because of this design, any authenticated user who can reference another user's timesheet ID can modify the victim's
favorite/recentbookmark data.
A PoC was provided, but removed for security reasons.
Impact
This vulnerability allows any authenticated low-privileged user to manipulate another user's favorite bookmark state across accounts. An attacker can inject arbitrary victim-owned timesheet entries into the victim's quick-entry workflow, remove existing favorites, and repeatedly disturb the victim's normal timesheet usage without needing administrative privileges.
The issue does not directly disclose sensitive data, but it is a real cross-user business-state tampering vulnerability with clear integrity impact. Because the add and remove endpoints can be combined, an attacker can reliably insert, remove, and reorder entries in another user's favorite/recent list.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.56.0"
},
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.57.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T20:44:05Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nKimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user\u0027s `timesheet.id` can add that record to, or remove it from, the victim\u0027s `favorite/recent` bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.\n\n### Details\n\nThe issue affects the following routes:\n\n- `GET /en/favorite/timesheet/add/{id}`\n- `GET /en/favorite/timesheet/remove/{id}`\n\nBoth endpoints accept a user-controlled timesheet identifier and only require the caller to hold the generic `start_own_timesheet` permission. They do not verify that the referenced `Timesheet` object belongs to the currently authenticated user.\n\n- In `src/Controller/FavoriteController.php`, the controller methods accept a `Timesheet` object directly and forward it to the favorite service. \n- The root cause becomes more obvious in `src/Timesheet/FavoriteRecordService.php`. The bookmark owner is derived from `$timesheet-\u003egetUser()` instead of the current session user.\n- Because of this design, any authenticated user who can reference another user\u0027s timesheet ID can modify the victim\u0027s `favorite/recent` bookmark data.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows any authenticated low-privileged user to manipulate another user\u0027s favorite bookmark state across accounts. An attacker can inject arbitrary victim-owned timesheet entries into the victim\u0027s quick-entry workflow, remove existing favorites, and repeatedly disturb the victim\u0027s normal timesheet usage without needing administrative privileges.\n\nThe issue does not directly disclose sensitive data, but it is a real cross-user business-state tampering vulnerability with clear integrity impact. Because the add and remove endpoints can be combined, an attacker can reliably insert, remove, and reorder entries in another user\u0027s `favorite/recent` list.",
"id": "GHSA-j5mc-p8qg-39j7",
"modified": "2026-07-02T20:44:05Z",
"published": "2026-07-02T20:44:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-j5mc-p8qg-39j7"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
},
{
"type": "WEB",
"url": "https://www.kimai.org/en/security/ghsa-j5mc-p8qg-39j7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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/E:U",
"type": "CVSS_V4"
}
],
"summary": "Kimai Favorite Timesheet Add and Remove Endpoints Allows Cross-User Bookmark Manipulation"
}
GHSA-J5VG-8WFX-78VQ
Vulnerability from github – Published: 2025-09-30 12:30 – Updated: 2025-10-08 18:30Insecure Direct Object Reference (IDOR) vulnerability in BOLD Workplanner in versions prior to 2.5.25 (4935b438f9b), consisting of a lack of adequate validation of user input, allowing an authenticated user to access to functional contract details using unauthorised internal identifiers.
{
"affected": [],
"aliases": [
"CVE-2025-41094"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-30T11:37:40Z",
"severity": "HIGH"
},
"details": "Insecure Direct Object Reference (IDOR) vulnerability in BOLD Workplanner in versions prior to 2.5.25 (4935b438f9b), consisting of a lack of adequate validation of user input, allowing an authenticated user to\u00a0access to functional\u00a0contract details using unauthorised internal identifiers.",
"id": "GHSA-j5vg-8wfx-78vq",
"modified": "2025-10-08T18:30:15Z",
"published": "2025-09-30T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41094"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/insecure-direct-object-reference-gps-bold-workplanner"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-J5XF-GV89-G422
Vulnerability from github – Published: 2023-11-09 21:30 – Updated: 2023-11-15 18:23Wiki comments required additional sanitizing and access restrictions to prevent a stored XSS risk and potential IDOR risk.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.0-rc2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-5544"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-10T00:41:02Z",
"nvd_published_at": "2023-11-09T20:15:09Z",
"severity": "MODERATE"
},
"details": "Wiki comments required additional sanitizing and access restrictions to prevent a stored XSS risk and potential IDOR risk.",
"id": "GHSA-j5xf-gv89-g422",
"modified": "2023-11-15T18:23:21Z",
"published": "2023-11-09T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5544"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/5fec728be9df3c9fc282cd0897c73ca5cfcfea5f"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2243443"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=451585"
},
{
"type": "WEB",
"url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-79509"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle Cross-site Scripting vulnerability"
}
GHSA-J634-Q9PR-JG3J
Vulnerability from github – Published: 2025-02-01 09:30 – Updated: 2025-02-01 09:30The WP Job Portal – A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the 'jobenforcedelete' due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with employer-level access and above, to delete arbitrary
{
"affected": [],
"aliases": [
"CVE-2024-13429"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-01T08:15:10Z",
"severity": "MODERATE"
},
"details": "The WP Job Portal \u2013 A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the \u0027jobenforcedelete\u0027 due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with employer-level access and above, to delete arbitrary",
"id": "GHSA-j634-q9pr-jg3j",
"modified": "2025-02-01T09:30:28Z",
"published": "2025-02-01T09:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13429"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3229608/wp-job-portal/tags/2.2.7/modules/job/controller.php?old=3216415\u0026old_path=wp-job-portal%2Ftags%2F2.2.6%2Fmodules%2Fjob%2Fcontroller.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9cbce69a-53d0-4b83-9b7a-893a6b9c39c4?source=cve"
}
],
"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"
}
]
}
GHSA-J6R6-VG97-R68X
Vulnerability from github – Published: 2022-02-08 00:00 – Updated: 2022-02-11 00:01The IP2Location Country Blocker WordPress plugin before 2.26.5 bans can be bypassed by using a specific parameter in the URL
{
"affected": [],
"aliases": [
"CVE-2021-25096"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-07T16:15:00Z",
"severity": "MODERATE"
},
"details": "The IP2Location Country Blocker WordPress plugin before 2.26.5 bans can be bypassed by using a specific parameter in the URL",
"id": "GHSA-j6r6-vg97-r68x",
"modified": "2022-02-11T00:01:06Z",
"published": "2022-02-08T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25096"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/2652469"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/e6dd140e-0c9d-41dc-821e-4910a13122c1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J6R7-6FHX-77WX
Vulnerability from github – Published: 2026-07-14 19:07 – Updated: 2026-07-14 19:07Impact
In multi-tenant HTTP deployments — where a single n8n-mcp server serves several tenants — the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants' stored backups.
A stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one.
Affected configurations
- HTTP mode with multi-tenancy enabled (
ENABLE_MULTI_TENANT=true), where multiple tenants are served by a single shared instance and database.
Not affected:
- stdio / single-user deployments (e.g. Claude Desktop).
- Single-tenant HTTP deployments (one tenant per instance and database).
Affected versions
<= 2.56.0
Patched version
2.56.1. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups).
Workarounds
If users cannot upgrade immediately:
- Disable the workflow version tool by setting
DISABLED_TOOLS=n8n_workflow_versionsin the server environment (for example, in your Docker.env). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed. - Alternatively, do not run in multi-tenant mode — serve each tenant from a separate instance with its own database, so no local store is shared between tenants.
- Restrict network access to the HTTP endpoint to trusted operators.
stdio and single-tenant HTTP deployments are not affected.
Credit
Reported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.56.0"
},
"package": {
"ecosystem": "npm",
"name": "n8n-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.56.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54052"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T19:07:14Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Impact\n\nIn multi-tenant HTTP deployments \u2014 where a single n8n-mcp server serves several tenants \u2014 the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants\u0027 stored backups.\n\nA stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one.\n\n## Affected configurations\n\n- HTTP mode with multi-tenancy enabled (`ENABLE_MULTI_TENANT=true`), where multiple tenants are served by a single shared instance and database.\n\nNot affected:\n\n- stdio / single-user deployments (e.g. Claude Desktop).\n- Single-tenant HTTP deployments (one tenant per instance and database).\n\n## Affected versions\n\n`\u003c= 2.56.0`\n\n## Patched version\n\n`2.56.1`. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups).\n\n## Workarounds\n\nIf users cannot upgrade immediately:\n\n- Disable the workflow version tool by setting `DISABLED_TOOLS=n8n_workflow_versions` in the server environment (for example, in your Docker `.env`). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed.\n- Alternatively, do not run in multi-tenant mode \u2014 serve each tenant from a separate instance with its own database, so no local store is shared between tenants.\n- Restrict network access to the HTTP endpoint to trusted operators.\n\nstdio and single-tenant HTTP deployments are not affected.\n\n## Credit\n\nReported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.",
"id": "GHSA-j6r7-6fhx-77wx",
"modified": "2026-07-14T19:07:14Z",
"published": "2026-07-14T19:07:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-j6r7-6fhx-77wx"
},
{
"type": "PACKAGE",
"url": "https://github.com/czlonkowski/n8n-mcp"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.56.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "n8n-MCP: Cross-tenant access to workflow version backups in multi-tenant HTTP deployments"
}
GHSA-J6X3-F5CF-2PG4
Vulnerability from github – Published: 2026-07-22 18:32 – Updated: 2026-07-22 18:32Onlook through 0.2.32, fixed in commit 423e2e9, contains a broken object level authorization vulnerability that allows authenticated attackers to access and manipulate other users' resources by supplying arbitrary UUID values to tRPC API procedures including project.get, member.remove, and chat.conversation.delete. Attackers can provide arbitrary projectId or conversationId values without authorization validation to read, modify, and delete other users' project data, members, and conversation history.
{
"affected": [],
"aliases": [
"CVE-2026-65013"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-22T17:16:59Z",
"severity": "HIGH"
},
"details": "Onlook through 0.2.32, fixed in commit 423e2e9, contains a broken object level authorization vulnerability that allows authenticated attackers to access and manipulate other users\u0027 resources by supplying arbitrary UUID values to tRPC API procedures including project.get, member.remove, and chat.conversation.delete. Attackers can provide arbitrary projectId or conversationId values without authorization validation to read, modify, and delete other users\u0027 project data, members, and conversation history.",
"id": "GHSA-j6x3-f5cf-2pg4",
"modified": "2026-07-22T18:32:39Z",
"published": "2026-07-22T18:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65013"
},
{
"type": "WEB",
"url": "https://github.com/onlook-dev/onlook/issues/3122"
},
{
"type": "WEB",
"url": "https://github.com/onlook-dev/onlook/pull/3129"
},
{
"type": "WEB",
"url": "https://github.com/onlook-dev/onlook/commit/423e2e924366419e418ee049093872d535eea41a"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/onlook-trpc-insecure-direct-object-reference-via-multiple-procedures"
}
],
"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-J72X-XFWG-783F
Vulnerability from github – Published: 2026-05-06 23:19 – Updated: 2026-05-14 20:43Summary
GET /api/devices/:uid returns the full device object whenever the caller is authenticated, without verifying that the device belongs to the caller's namespace (tenant). Any authenticated user (JWT or API Key) who knows or can guess a device UID can read device metadata from any other namespace.
Severity
CVSS 3.1: 7.5 (High) CWE-639 — Authorization Bypass Through User-Controlled Key
Affected versions
ShellHub Community v0.24.1 (validated). Likely all prior versions that share this handler.
Root cause
api/services/device.go:97-104 — GetDevice resolves the device by UID without scoping to the caller's tenant:
go
func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {
device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid))
// ⚠️ missing: s.store.Options().InNamespace(tenant)
...
}
Compare with DeleteDevice in the same file (line 137) which correctly applies InNamespace(tenant).
The Authorize middleware (api/routes/middleware/authorize.go:12-27) only checks that a tenant is present in the context — not that the resource belongs to that tenant.
Proof of concept (validated live against v0.24.1)
Pre-requisite: attacker has any valid user account and knows a target tenant_id (UUIDs frequently leak via UI URLs, email invites, support channels, or prior namespace membership).
```bash ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"attacker","password":"..."}' | jq -r .token)
TARGET_TENANT=""
# Plant a device in the victim tenant via the public device-auth endpoint # (this also works when the victim already has devices and the attacker # merely guessed/obtained a real UID via another vector) VICTIM_UID=$(curl -s -X POST http://target/api/devices/auth \ -H 'Content-Type: application/json' \ -d "{ \"info\":{\"id\":\"x\",\"pretty_name\":\"x\",\"version\":\"v0.24.1\",\"arch\":\"amd64\",\"platform\":\"docker\"}, \"hostname\":\"poc\", \"identity\":{\"mac\":\"aa:bb:cc:dd:ee:ff\"}, \"public_key\":\"-----BEGIN RSA PUBLIC KEY-----\nx\n-----END RSA PUBLIC KEY-----\", \"tenant_id\":\"$TARGET_TENANT\" }" | jq -r .uid)
# Read the device from a completely different tenant curl -i "http://target/api/devices/$VICTIM_UID" \ -H "Authorization: Bearer $ATTACKER_TOKEN" # Expected (fixed): HTTP 403/404 # Observed (v0.24.1): HTTP 200 + full device JSON (tenant_id, public_key, MAC, # namespace name, OS info, last_seen, remote_addr, ...) ```
Impact
- Cross-tenant disclosure of device metadata: hostname, MAC, OS fingerprint, public SSH key, namespace name, last-seen timestamp, remote address.
- Enables namespace enumeration, device inventory reconnaissance of other tenants, and targeted follow-up attacks.
Suggested fix
In api/services/device.go GetDevice, extract tenant from context and apply InNamespace:
go
func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {
tenant := gateway.TenantFromContext(ctx)
opts := []store.QueryOption{}
if tenant != nil {
opts = append(opts, s.store.Options().InNamespace(tenant.ID))
}
device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid), opts...)
...
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.24.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/shellhub-io/shellhub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.24.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44424"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T23:19:46Z",
"nvd_published_at": "2026-05-13T22:16:44Z",
"severity": "MODERATE"
},
"details": "## Summary\n`GET /api/devices/:uid` returns the full device object whenever the caller is authenticated, without verifying that the device belongs to the caller\u0027s namespace (tenant). Any authenticated user (JWT or API Key) who knows or can guess a device UID can read device metadata from any other namespace.\n\n## Severity\n**CVSS 3.1: 7.5 (High)** \nCWE-639 \u2014 Authorization Bypass Through User-Controlled Key\n\n## Affected versions\nShellHub Community v0.24.1 (validated). Likely all prior versions that share this handler.\n\n## Root cause\n`api/services/device.go:97-104` \u2014 `GetDevice` resolves the device by UID without scoping to the caller\u0027s tenant:\n\n ```go\n func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {\n device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid))\n // \u26a0\ufe0f missing: s.store.Options().InNamespace(tenant)\n ...\n }\n ```\n\nCompare with `DeleteDevice` in the same file (line 137) which correctly applies `InNamespace(tenant)`.\n\nThe `Authorize` middleware (`api/routes/middleware/authorize.go:12-27`) only checks that a tenant is present in the context \u2014 not that the resource belongs to that tenant.\n\n## Proof of concept (validated live against v0.24.1)\n\nPre-requisite: attacker has any valid user account and knows a target `tenant_id` (UUIDs frequently leak via UI URLs, email invites, support channels, or prior namespace membership).\n\n ```bash\n ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"attacker\",\"password\":\"...\"}\u0027 | jq -r .token)\n\n TARGET_TENANT=\"\u003cvictim-tenant-uuid\u003e\"\n\n # Plant a device in the victim tenant via the public device-auth endpoint\n # (this also works when the victim already has devices and the attacker\n # merely guessed/obtained a real UID via another vector)\n VICTIM_UID=$(curl -s -X POST http://target/api/devices/auth \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \"{\n \\\"info\\\":{\\\"id\\\":\\\"x\\\",\\\"pretty_name\\\":\\\"x\\\",\\\"version\\\":\\\"v0.24.1\\\",\\\"arch\\\":\\\"amd64\\\",\\\"platform\\\":\\\"docker\\\"},\n \\\"hostname\\\":\\\"poc\\\",\n \\\"identity\\\":{\\\"mac\\\":\\\"aa:bb:cc:dd:ee:ff\\\"},\n \\\"public_key\\\":\\\"-----BEGIN RSA PUBLIC KEY-----\\\\nx\\\\n-----END RSA PUBLIC KEY-----\\\",\n \\\"tenant_id\\\":\\\"$TARGET_TENANT\\\"\n }\" | jq -r .uid)\n\n # Read the device from a completely different tenant\n curl -i \"http://target/api/devices/$VICTIM_UID\" \\\n -H \"Authorization: Bearer $ATTACKER_TOKEN\"\n # Expected (fixed): HTTP 403/404\n # Observed (v0.24.1): HTTP 200 + full device JSON (tenant_id, public_key, MAC,\n # namespace name, OS info, last_seen, remote_addr, ...)\n ```\n\n## Impact\n - Cross-tenant disclosure of device metadata: hostname, MAC, OS fingerprint, public SSH key, namespace name, last-seen timestamp, remote address.\n - Enables namespace enumeration, device inventory reconnaissance of other tenants, and targeted follow-up attacks.\n\n## Suggested fix\nIn `api/services/device.go` `GetDevice`, extract tenant from context and apply `InNamespace`:\n\n ```go\n func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {\n tenant := gateway.TenantFromContext(ctx)\n opts := []store.QueryOption{}\n if tenant != nil {\n opts = append(opts, s.store.Options().InNamespace(tenant.ID))\n }\n device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid), opts...)\n ...\n }\n ```",
"id": "GHSA-j72x-xfwg-783f",
"modified": "2026-05-14T20:43:14Z",
"published": "2026-05-06T23:19:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shellhub-io/shellhub/security/advisories/GHSA-j72x-xfwg-783f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44424"
},
{
"type": "PACKAGE",
"url": "https://github.com/shellhub-io/shellhub"
}
],
"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": "ShellHub has cross-tenant IDOR in `GET /api/devices/:uid` that discloses device data of any namespace"
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Mitigation
Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
No CAPEC attack patterns related to this CWE.