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.
4522 vulnerabilities reference this CWE, most recent first.
GHSA-6462-H5CX-J55P
Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30OpenClaw (npm package 'openclaw') before 2026.7.1 incorrectly trusts requester provenance in message.action. In identity-bearing Gateway deployments (authentication modes that honor caller identity and narrower operator scopes), a write-scoped caller can supply another sender's identifier to the channel authorization checks and invoke a channel action under that spoofed requester identity, reaching operations the channel adapter would have denied to the real caller. Practical impact depends on the enabled channel, the action, and the target account's permissions. Shared-secret token and password callers are full trusted operators under OpenClaw's security model and are out of scope. The issue is fixed in 2026.7.1; as a workaround, restrict message.action to administrators and disable sensitive channel actions that rely on requester identity.
{
"affected": [],
"aliases": [
"CVE-2026-100579"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-26T03:17:05Z",
"severity": "HIGH"
},
"details": "OpenClaw (npm package \u0027openclaw\u0027) before 2026.7.1 incorrectly trusts requester provenance in message.action. In identity-bearing Gateway deployments (authentication modes that honor caller identity and narrower operator scopes), a write-scoped caller can supply another sender\u0027s identifier to the channel authorization checks and invoke a channel action under that spoofed requester identity, reaching operations the channel adapter would have denied to the real caller. Practical impact depends on the enabled channel, the action, and the target account\u0027s permissions. Shared-secret token and password callers are full trusted operators under OpenClaw\u0027s security model and are out of scope. The issue is fixed in 2026.7.1; as a workaround, restrict message.action to administrators and disable sensitive channel actions that rely on requester identity.",
"id": "GHSA-6462-h5cx-j55p",
"modified": "2026-09-26T03:30:27Z",
"published": "2026-09-26T03:30:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4wvr-f35r-f8w4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100579"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-before-2026.7.1-authentication-bypass-via-spoofed-requester"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/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-64GV-6CQ2-45JR
Vulnerability from github – Published: 2026-07-06 09:30 – Updated: 2026-08-28 19:33Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel JIRA component.
The camel-jira producers read their operation parameters - the issue key, project key, transition id, summary, type, assignee, components, watchers, link type, work-log minutes and others - from Exchange message headers. The header constants defined in JiraConstants (for example ISSUE_KEY = IssueKey, ISSUE_PROJECT_KEY = ProjectKey, ISSUE_TRANSITION_ID = IssueTransitionId, LINK_TYPE = linkType) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a jira: producer, any HTTP client could therefore supply these headers and override the values the route intended, driving JIRA operations against the configured JIRA instance with the endpoint's configured service-account credentials - for example deleting or transitioning an arbitrary issue (via IssueKey / IssueTransitionId), creating an issue in a different project (via ProjectKey), modifying issue fields, adding or removing watchers, or logging work. The operations are bounded by what the configured service account is permitted to do. No credentials are required from the attacker when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that drive JIRA operations via the raw header names must use the CamelJira* names (for example CamelJiraIssueKey) instead of the old values. For deployments that cannot upgrade immediately, strip the camel-jira control headers from any untrusted ingress before the jira: producer (for example removing the IssueKey, ProjectKey, IssueTransitionId and related headers at the start of the route), and set the required JIRA operation parameters from a trusted source.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jira"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.14.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jira"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jira"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48206"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T19:33:21Z",
"nvd_published_at": "2026-07-06T09:16:38Z",
"severity": "MODERATE"
},
"details": "Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel JIRA component.\n\nThe camel-jira producers read their operation parameters - the issue key, project key, transition id, summary, type, assignee, components, watchers, link type, work-log minutes and others - from Exchange message headers. The header constants defined in JiraConstants (for example ISSUE_KEY = IssueKey, ISSUE_PROJECT_KEY = ProjectKey, ISSUE_TRANSITION_ID = IssueTransitionId, LINK_TYPE = linkType) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a jira: producer, any HTTP client could therefore supply these headers and override the values the route intended, driving JIRA operations against the configured JIRA instance with the endpoint\u0027s configured service-account credentials - for example deleting or transitioning an arbitrary issue (via IssueKey / IssueTransitionId), creating an issue in a different project (via ProjectKey), modifying issue fields, adding or removing watchers, or logging work. The operations are bounded by what the configured service account is permitted to do. No credentials are required from the attacker when the bridging consumer is unauthenticated.\nThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that drive JIRA operations via the raw header names must use the CamelJira* names (for example CamelJiraIssueKey) instead of the old values. For deployments that cannot upgrade immediately, strip the camel-jira control headers from any untrusted ingress before the jira: producer (for example removing the IssueKey, ProjectKey, IssueTransitionId and related headers at the start of the route), and set the required JIRA operation parameters from a trusted source.",
"id": "GHSA-64gv-6cq2-45jr",
"modified": "2026-08-28T19:33:21Z",
"published": "2026-07-06T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48206"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23417"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23460"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23472"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/024704f95f16d1260304054088fa0b34acb57ebf"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/3240a174a3707ba2b1d893c4ac0880829e0c9233"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/6863ea624605ab3fa8827c43a4c5df333f767dc4"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-48206.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.14.8"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.18.3"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.21.0"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-23576"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/05/20"
}
],
"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"
}
],
"summary": "Apache Camel-JIRA: A set of non-Camel-prefixed Exchange header constants bypass the HTTP header filter"
}
GHSA-64Q9-48CG-F6VV
Vulnerability from github – Published: 2026-05-27 21:31 – Updated: 2026-05-27 21:31GitLab has remediated an issue in GitLab EE affecting all versions from 18.8 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that, under certain conditions, could have allowed an authenticated user to cause specific Duo AI workflows to run under another user's identity due to improper user identity resolution when triggering Duo AI workflow runners.
{
"affected": [],
"aliases": [
"CVE-2026-4868"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T19:16:24Z",
"severity": "HIGH"
},
"details": "GitLab has remediated an issue in GitLab EE affecting all versions from 18.8 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that, under certain conditions, could have allowed an authenticated user to cause specific Duo AI workflows to run under another user\u0027s identity due to improper user identity resolution when triggering Duo AI workflow runners.",
"id": "GHSA-64q9-48cg-f6vv",
"modified": "2026-05-27T21:31:25Z",
"published": "2026-05-27T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4868"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3619872"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/05/27/patch-release-gitlab-19-0-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/594809"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-64VW-M4RV-F6RJ
Vulnerability from github – Published: 2026-05-27 12:31 – Updated: 2026-05-27 12:31Authorization Bypass Through User-Controlled Key vulnerability in wordplus BP Better Messages bp-better-messages allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects BP Better Messages: from n/a through <= 2.14.16.
{
"affected": [],
"aliases": [
"CVE-2026-42736"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T11:16:20Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in wordplus BP Better Messages bp-better-messages allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects BP Better Messages: from n/a through \u003c= 2.14.16.",
"id": "GHSA-64vw-m4rv-f6rj",
"modified": "2026-05-27T12:31:22Z",
"published": "2026-05-27T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42736"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/bp-better-messages/vulnerability/wordpress-bp-better-messages-plugin-2-14-16-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-64WC-QRFG-GH7M
Vulnerability from github – Published: 2024-03-18 03:30 – Updated: 2024-03-18 03:30A vulnerability, which was classified as critical, has been found in SourceCodester Employee Task Management System 1.0. Affected by this issue is some unknown functionality of the file /task-details.php. The manipulation of the argument task_id leads to authorization bypass. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-257078 is the identifier assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2024-2575"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-18T02:15:06Z",
"severity": "HIGH"
},
"details": "A vulnerability, which was classified as critical, has been found in SourceCodester Employee Task Management System 1.0. Affected by this issue is some unknown functionality of the file /task-details.php. The manipulation of the argument task_id leads to authorization bypass. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-257078 is the identifier assigned to this vulnerability.",
"id": "GHSA-64wc-qrfg-gh7m",
"modified": "2024-03-18T03:30:32Z",
"published": "2024-03-18T03:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2575"
},
{
"type": "WEB",
"url": "https://github.com/skid-nochizplz/skid-nochizplz/blob/main/TrashBin/CVE/SOURCECODESTER%20Employee%20Task%20Management%20System/IDOR%20-%20task-details.php.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.257078"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.257078"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-6547-8HRG-C55M
Vulnerability from github – Published: 2026-03-19 17:25 – Updated: 2026-03-25 18:48Summary
The setPassword.json.php endpoint in the CustomizeUser plugin allows administrators to set a channel password for any user. Due to a logic error in how the submitted password value is processed, any password containing non-numeric characters is silently coerced to the integer zero before being stored. This means that regardless of the intended password, the stored channel password becomes 0, which any visitor can trivially guess to bypass channel-level access control.
Details
The endpoint correctly restricts access to administrators only, but the password value submitted via the ProfilePassword request parameter is processed with intval() before being passed to User::setProfilePassword(). The relevant code is:
$obj->ProfilePassword = intval(@$_REQUEST['ProfilePassword']);
$obj->users_id = $users_id;
$obj->response = User::setProfilePassword($users_id, $obj->ProfilePassword);
The call to intval() on an alphanumeric string such as secretabc123 returns 0. This silently discards the intended password value and stores 0 as the channel password instead. Because the coercion is silent, the administrator receives no error or warning and has no indication that the password they set was not stored correctly. Any visitor to the channel who enters 0 as the password will be granted access, completely defeating the channel password protection feature.
This is not a case where a malicious admin deliberately sets a weak password. The vulnerability causes well-intentioned admins to unknowingly install a trivially guessable password on any channel for which they attempt to configure a non-numeric password.
PoC
curl -s -X POST "https://target.example.com/plugin/CustomizeUser/setPassword.json.php" \
-b "PHPSESSID=<admin_session_cookie>" \
-d "users_id=42&ProfilePassword=secretPassword123"
curl -s -X POST "https://target.example.com/channel_password_check_endpoint" \
-d "users_id=42&password=0"
import requests
base_url = "https://target.example.com"
session = requests.Session()
session.post(f"{base_url}/login", data={"user": "admin", "pass": "adminpass"})
session.post(
f"{base_url}/plugin/CustomizeUser/setPassword.json.php",
data={"users_id": "42", "ProfilePassword": "mySuperSecretPassword"}
)
resp = session.post(
f"{base_url}/plugin/CustomizeUser/setPassword.json.php",
data={"users_id": "42", "ProfilePassword": "0"}
)
print(resp.text)
Impact
Any administrator who sets a channel password using a non-numeric string unknowingly reduces that password to 0. Any unauthenticated or unprivileged user who simply enters 0 as the channel password can access the content that was intended to be protected. This breaks the confidentiality guarantees of the channel password protection feature across all channels managed by administrators who use alphanumeric passwords. The impact is scoped to channel-level access control and does not enable account takeover or privilege escalation, but it renders the password protection feature entirely ineffective for the common case of non-numeric passwords.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33297"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T17:25:34Z",
"nvd_published_at": "2026-03-23T14:16:33Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `setPassword.json.php` endpoint in the CustomizeUser plugin allows administrators to set a channel password for any user. Due to a logic error in how the submitted password value is processed, any password containing non-numeric characters is silently coerced to the integer zero before being stored. This means that regardless of the intended password, the stored channel password becomes 0, which any visitor can trivially guess to bypass channel-level access control.\n\n### Details\n\nThe endpoint correctly restricts access to administrators only, but the password value submitted via the ProfilePassword request parameter is processed with `intval()` before being passed to `User::setProfilePassword()`. The relevant code is:\n\n```php\n$obj-\u003eProfilePassword = intval(@$_REQUEST[\u0027ProfilePassword\u0027]);\n$obj-\u003eusers_id = $users_id;\n$obj-\u003eresponse = User::setProfilePassword($users_id, $obj-\u003eProfilePassword);\n```\n\nThe call to `intval()` on an alphanumeric string such as secretabc123 returns 0. This silently discards the intended password value and stores 0 as the channel password instead. Because the coercion is silent, the administrator receives no error or warning and has no indication that the password they set was not stored correctly. Any visitor to the channel who enters 0 as the password will be granted access, completely defeating the channel password protection feature.\n\nThis is not a case where a malicious admin deliberately sets a weak password. The vulnerability causes well-intentioned admins to unknowingly install a trivially guessable password on any channel for which they attempt to configure a non-numeric password.\n\n### PoC\n\n```bash\ncurl -s -X POST \"https://target.example.com/plugin/CustomizeUser/setPassword.json.php\" \\\n -b \"PHPSESSID=\u003cadmin_session_cookie\u003e\" \\\n -d \"users_id=42\u0026ProfilePassword=secretPassword123\"\n```\n\n```bash\ncurl -s -X POST \"https://target.example.com/channel_password_check_endpoint\" \\\n -d \"users_id=42\u0026password=0\"\n```\n\n```python\nimport requests\n\nbase_url = \"https://target.example.com\"\nsession = requests.Session()\n\nsession.post(f\"{base_url}/login\", data={\"user\": \"admin\", \"pass\": \"adminpass\"})\n\nsession.post(\n f\"{base_url}/plugin/CustomizeUser/setPassword.json.php\",\n data={\"users_id\": \"42\", \"ProfilePassword\": \"mySuperSecretPassword\"}\n)\n\nresp = session.post(\n f\"{base_url}/plugin/CustomizeUser/setPassword.json.php\",\n data={\"users_id\": \"42\", \"ProfilePassword\": \"0\"}\n)\n\nprint(resp.text)\n```\n\n### Impact\n\nAny administrator who sets a channel password using a non-numeric string unknowingly reduces that password to 0. Any unauthenticated or unprivileged user who simply enters 0 as the channel password can access the content that was intended to be protected. This breaks the confidentiality guarantees of the channel password protection feature across all channels managed by administrators who use alphanumeric passwords. The impact is scoped to channel-level access control and does not enable account takeover or privilege escalation, but it renders the password protection feature entirely ineffective for the common case of non-numeric passwords.",
"id": "GHSA-6547-8hrg-c55m",
"modified": "2026-03-25T18:48:44Z",
"published": "2026-03-19T17:25:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-6547-8hrg-c55m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33297"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/7a6a94631a0a18c313894395e6eb6703cca4abd0"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AVideo: IDOR - Any Admin Can Set Another User\u0027s Channel Password via setPassword.json.php"
}
GHSA-655W-H872-387J
Vulnerability from github – Published: 2026-08-07 00:31 – Updated: 2026-08-07 00:31The Events Made Easy WordPress plugin before 3.1.2 does not bind the payment authorization token to the payment record being charged, allowing unauthenticated attackers to pay a low amount for a cheap booking and have a separate, higher-priced booking marked as fully paid.
{
"affected": [],
"aliases": [
"CVE-2026-14842"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T22:16:47Z",
"severity": "MODERATE"
},
"details": "The Events Made Easy WordPress plugin before 3.1.2 does not bind the payment authorization token to the payment record being charged, allowing unauthenticated attackers to pay a low amount for a cheap booking and have a separate, higher-priced booking marked as fully paid.",
"id": "GHSA-655w-h872-387j",
"modified": "2026-08-07T00:31:14Z",
"published": "2026-08-07T00:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14842"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/76856b3d-8f87-4d66-a22a-d65afa98c4ad"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-656W-6F6C-M9R6
Vulnerability from github – Published: 2026-03-09 17:29 – Updated: 2026-03-10 18:44Summary
OneUptime's GitHub App callback trusts attacker-controlled state and installation_id values and updates Project.gitHubAppInstallationId with isRoot: true without validating that the caller is authorized for the target project. This allows an attacker to overwrite another project's GitHub App installation binding.
Related GitHub endpoints also lack effective authorization, so a valid installation ID can be used to enumerate repositories and create CodeRepository records in an arbitrary project.
Details
The callback decodes unsigned base64 JSON from state and uses the embedded projectId directly:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112
It then writes the supplied installation_id into the target project with root privileges:
await ProjectService.updateOneById({
id: new ObjectID(projectId),
data: { gitHubAppInstallationId: installationId },
props: { isRoot: true },
});
The userId in state is only checked for presence, not authenticity:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79
The install flow also generates state as plain base64 JSON, not a signed or session-bound token:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165
The follow-on endpoints are also vulnerable:
- Repository listing: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258
- Repository connect: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356
- Middleware allows requests with no token to continue as
Public: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211 - Installation tokens are minted from any valid installation ID: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425
PoC
Minimal proof of unauthorized project tampering:
STATE=$(printf '%s' '{"projectId":"<victim-project-uuid>","userId":"x"}' | base64 | tr -d '\n')
curl -isk "https://<host>/api/github/auth/callback?installation_id=999999999&state=${STATE}"
Expected result:
- Server returns a
302redirect to/dashboard/<victim-project-uuid>/code-repository?installation_id=999999999 - The target project's
gitHubAppInstallationIdis overwritten
Impact
- Unauthorized modification of
Project.gitHubAppInstallationId - Temporary GitHub integration breakage if a bogus installation ID is set
- Cross-project binding of attacker-controlled GitHub App installations
- Repository metadata disclosure for a supplied valid installation ID
- Unauthorized creation of
CodeRepositoryrecords in arbitrary projects
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.19"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30920"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T17:29:47Z",
"nvd_published_at": "2026-03-10T17:40:16Z",
"severity": "HIGH"
},
"details": "### Summary\n\nOneUptime\u0027s GitHub App callback trusts attacker-controlled `state` and `installation_id` values and updates `Project.gitHubAppInstallationId` with `isRoot: true` without validating that the caller is authorized for the target project. This allows an attacker to overwrite another project\u0027s GitHub App installation binding.\n\nRelated GitHub endpoints also lack effective authorization, so a valid installation ID can be used to enumerate repositories and create `CodeRepository` records in an arbitrary project.\n\n### Details\n\nThe callback decodes unsigned base64 JSON from `state` and uses the embedded `projectId` directly:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112\n\nIt then writes the supplied `installation_id` into the target project with root privileges:\n\n```ts\nawait ProjectService.updateOneById({\n id: new ObjectID(projectId),\n data: { gitHubAppInstallationId: installationId },\n props: { isRoot: true },\n});\n```\n\nThe `userId` in `state` is only checked for presence, not authenticity:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79\n\nThe install flow also generates `state` as plain base64 JSON, not a signed or session-bound token:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165\n\nThe follow-on endpoints are also vulnerable:\n\n- Repository listing: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258\n- Repository connect: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356\n- Middleware allows requests with no token to continue as `Public`: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211\n- Installation tokens are minted from any valid installation ID: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425\n\n### PoC\n\nMinimal proof of unauthorized project tampering:\n\n```bash\nSTATE=$(printf \u0027%s\u0027 \u0027{\"projectId\":\"\u003cvictim-project-uuid\u003e\",\"userId\":\"x\"}\u0027 | base64 | tr -d \u0027\\n\u0027)\ncurl -isk \"https://\u003chost\u003e/api/github/auth/callback?installation_id=999999999\u0026state=${STATE}\"\n```\n\nExpected result:\n\n- Server returns a `302` redirect to `/dashboard/\u003cvictim-project-uuid\u003e/code-repository?installation_id=999999999`\n- The target project\u0027s `gitHubAppInstallationId` is overwritten\n\n### Impact\n\n- Unauthorized modification of `Project.gitHubAppInstallationId`\n- Temporary GitHub integration breakage if a bogus installation ID is set\n- Cross-project binding of attacker-controlled GitHub App installations\n- Repository metadata disclosure for a supplied valid installation ID\n- Unauthorized creation of `CodeRepository` records in arbitrary projects",
"id": "GHSA-656w-6f6c-m9r6",
"modified": "2026-03-10T18:44:14Z",
"published": "2026-03-09T17:29:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-656w-6f6c-m9r6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30920"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "OneUptime has broken access control in GitHub App installation flow that allows unauthorized project binding"
}
GHSA-6593-25JW-QMHP
Vulnerability from github – Published: 2023-04-16 09:30 – Updated: 2024-04-04 03:30The Bluetooth module has a vulnerability of bypassing the user confirmation in the pairing process. Successful exploitation of this vulnerability may affect confidentiality.
{
"affected": [],
"aliases": [
"CVE-2022-48313"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-16T08:15:00Z",
"severity": "MODERATE"
},
"details": "The Bluetooth module has a vulnerability of bypassing the user confirmation in the pairing process. Successful exploitation of this vulnerability may affect confidentiality.",
"id": "GHSA-6593-25jw-qmhp",
"modified": "2024-04-04T03:30:09Z",
"published": "2023-04-16T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48313"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/4"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202304-0000001506528486"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-65XF-8W4C-54H2
Vulnerability from github – Published: 2026-08-31 09:30 – Updated: 2026-08-31 09:30ToolJet before v3.16.208 fails to validate that the path organizationId matches the authenticated user's workspace before performing ToolJet DB table operations. A workspace admin can create, view, and delete database tables in another workspace by replacing the organizationId parameter in table-management API requests.
{
"affected": [],
"aliases": [
"CVE-2026-82872"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-31T09:17:08Z",
"severity": "HIGH"
},
"details": "ToolJet before v3.16.208 fails to validate that the path organizationId matches the authenticated user\u0027s workspace before performing ToolJet DB table operations. A workspace admin can create, view, and delete database tables in another workspace by replacing the organizationId parameter in table-management API requests.",
"id": "GHSA-65xf-8w4c-54h2",
"modified": "2026-08-31T09:30:33Z",
"published": "2026-08-31T09:30:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ToolJet/ToolJet/security/advisories/GHSA-2jhv-482p-4php"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82872"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/tooljet-before-3.16.208-cross-workspace-authorization-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/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"
}
]
}
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.