CWE-285
DiscouragedImproper Authorization
Abstraction: Class · Status: Draft
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
2321 vulnerabilities reference this CWE, most recent first.
GHSA-37P9-RR5Q-Q9RR
Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2024-04-04 01:19An issue was discovered in PrinterOn Central Print Services (CPS) through 4.1.4. The core components that create and launch a print job do not perform complete verification of the session cookie that is supplied to them. As a result, an attacker with guest/pseudo-guest level permissions can bypass the session checks (that would otherwise logout a low-privileged user) by calling the core print job components directly via crafted HTTP GET and POST requests.
{
"affected": [],
"aliases": [
"CVE-2018-17210"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-20T00:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in PrinterOn Central Print Services (CPS) through 4.1.4. The core components that create and launch a print job do not perform complete verification of the session cookie that is supplied to them. As a result, an attacker with guest/pseudo-guest level permissions can bypass the session checks (that would otherwise logout a low-privileged user) by calling the core print job components directly via crafted HTTP GET and POST requests.",
"id": "GHSA-37p9-rr5q-q9rr",
"modified": "2024-04-04T01:19:28Z",
"published": "2022-05-24T16:50:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17210"
},
{
"type": "WEB",
"url": "https://github.com/DrunkenShells/Disclosures/tree/master/CVE-2018-17210-Authorization_Bypass-PrinterOn"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-37PW-QW47-4JXM
Vulnerability from github – Published: 2019-05-31 16:09 – Updated: 2021-05-11 16:17In Apache Hadoop versions 3.0.0-alpha1 to 3.1.0, 2.9.0 to 2.9.1, and 2.2.0 to 2.8.4, a user who can escalate to yarn user can possibly run arbitrary commands as root user.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.hadoop:hadoop-main"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.hadoop:hadoop-main"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.hadoop:hadoop-main"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-8029"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2019-05-31T16:08:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "In Apache Hadoop versions 3.0.0-alpha1 to 3.1.0, 2.9.0 to 2.9.1, and 2.2.0 to 2.8.4, a user who can escalate to yarn user can possibly run arbitrary commands as root user.",
"id": "GHSA-37pw-qw47-4jxm",
"modified": "2021-05-11T16:17:59Z",
"published": "2019-05-31T16:09:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8029"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/0b8d58e02dbd0fb8bf7320c514fe58da1d6728bdc150f1ba04e0d9fc@%3Cissues.hbase.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/17084c09e6dedf60efe08028b429c92ffd28aacc28454e4fa924578a@%3Cgeneral.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/a0164b87660223a2d491f83c88f905fe1a9fa8dc795148d9b0d968c8@%3Cdev.hbase.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/a97c53a81e639ca2fc7b8f61a4fcd1842c2a78544041244a7c624727@%3Cissues.hbase.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4dddf1705dbedfa94392913b2dad1cd2d1d89040facd389eea0b3510@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb21df54a4e39732ce653d2aa5672e36a792b59eb6717f2a06bb8d02a@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190617-0001"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108518"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Privilege escalation vulnerability in Apache Hadoop"
}
GHSA-386G-PGM8-CFCR
Vulnerability from github – Published: 2022-05-12 00:01 – Updated: 2022-05-21 00:01An improper authorization vulnerability in Palo Alto Network Cortex XSOAR software enables authenticated users in non-Read-Only groups to generate an email report that contains summary information about all incidents in the Cortex XSOAR instance, including incidents to which the user does not have access. This issue impacts: All versions of Cortex XSOAR 6.1; All versions of Cortex XSOAR 6.2; All versions of Cortex XSOAR 6.5; Cortex XSOAR 6.6 versions earlier than Cortex XSOAR 6.6.0 build 6.6.0.2585049.
{
"affected": [],
"aliases": [
"CVE-2022-0027"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-11T17:15:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization vulnerability in Palo Alto Network Cortex XSOAR software enables authenticated users in non-Read-Only groups to generate an email report that contains summary information about all incidents in the Cortex XSOAR instance, including incidents to which the user does not have access. This issue impacts: All versions of Cortex XSOAR 6.1; All versions of Cortex XSOAR 6.2; All versions of Cortex XSOAR 6.5; Cortex XSOAR 6.6 versions earlier than Cortex XSOAR 6.6.0 build 6.6.0.2585049.",
"id": "GHSA-386g-pgm8-cfcr",
"modified": "2022-05-21T00:01:06Z",
"published": "2022-05-12T00:01:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0027"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2022-0027"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-38F9-JC9V-RGW6
Vulnerability from github – Published: 2024-05-02 18:30 – Updated: 2024-07-03 18:38An RBAC authorization risk in Carina v0.13.0 and earlier allows local attackers to execute arbitrary code through designed commands to obtain the secrets of the entire cluster and further take over the cluster.
{
"affected": [],
"aliases": [
"CVE-2024-32359"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-02T16:15:08Z",
"severity": "MODERATE"
},
"details": "An RBAC authorization risk in Carina v0.13.0 and earlier allows local attackers to execute arbitrary code through designed commands to obtain the secrets of the entire cluster and further take over the cluster.",
"id": "GHSA-38f9-jc9v-rgw6",
"modified": "2024-07-03T18:38:44Z",
"published": "2024-05-02T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32359"
},
{
"type": "WEB",
"url": "https://gist.github.com/HouqiyuA/568d9857dab4ddba6b8b6a791e90f906"
},
{
"type": "WEB",
"url": "https://github.com/HouqiyuA/k8s-rbac-poc"
},
{
"type": "WEB",
"url": "https://github.com/carina-io/carina"
},
{
"type": "WEB",
"url": "http://carina.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-39MP-545Q-W789
Vulnerability from github – Published: 2026-03-30 19:06 – Updated: 2026-04-10 19:45Fixed in OpenClaw 2026.3.24, the current shipping release.
Title
Non-owner command-authorized sender can change the owner-only /send session delivery policy
CWE
CWE-285 Improper Authorization
CVSS v3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Base score: 5.4 (Medium)
Severity Assessment
Medium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session’s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.
Impact
A non-owner sender who is allowed to run commands can invoke /send on|off|inherit and persistently change the current session’s sendPolicy, even though OpenClaw documents /send as owner-only.
That lets a lower-trust participant:
- disable reply delivery for the current session (/send off), suppressing future replies in that chat;
- re-enable reply delivery (/send on) after the owner intentionally disabled it;
- remove the session override (/send inherit).
Affected Component
Verified against the latest published GitHub release tag v2026.3.23 (ccfeecb6887cd97937e33a71877ad512741e82b2), published 2026-03-23T23:15:50Z.
Exact vulnerable path on the shipped tag:
- src/auto-reply/reply/commands-session.ts:212-239
- handleSendPolicyCommand(...) checks only params.command.isAuthorizedSender.
- when true, it mutates params.sessionEntry.sendPolicy and persists the session entry.
Authorization behavior that makes this reachable:
- src/auto-reply/command-auth.ts:401-407
- senderIsOwner is computed separately from general command authorization.
- src/auto-reply/command-auth.ts:420-429
- command authorization can succeed even when senderIsOwner === false.
- src/auto-reply/command-auth.owner-default.test.ts:10-47
- existing coverage confirms a sender can be command-authorized while not treated as owner.
Documented owner-only contract:
- docs/tools/slash-commands.md:112
- /send on|off|inherit is documented as owner-only.
- docs/concepts/session-tool.md:156
- sendPolicy is documented as settable via sessions.patch or owner-only /send on|off|inherit.
Related privilege model:
- src/gateway/method-scopes.ts:131-133
- sessions.patch is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.
Version history:
- The vulnerable handler exists in release history going back at least to commit ea018a68ccb92dbc735bc1df9880d5c95c63ca35 (refactor(auto-reply): split reply pipeline).
- Earliest released affected tag found: v2026.1.14-1
- Latest released affected tag verified: v2026.3.23
Technical Reproduction
1. Check out the shipped release tag v2026.3.23.
2. Configure a channel where:
- a non-owner sender is allowed to run commands, for example through commands.allowFrom;
- the owner identity is distinct, for example via commands.ownerAllowFrom.
3. Start or reuse a session with a live sessionEntry and sessionStore.
4. Send /send off as the non-owner but command-authorized sender.
5. Confirm the resolved command context has:
- isAuthorizedSender === true
- senderIsOwner === false
6. Observe that the handler still accepts the command, mutates sessionEntry.sendPolicy, and persists the session entry.
Demonstrated Impact
The vulnerable handler performs a real persistent session-state change:
- src/auto-reply/reply/commands-session.ts:232-238
- /send inherit deletes sessionEntry.sendPolicy
- other modes assign sessionEntry.sendPolicy = sendPolicyCommand.mode
- the handler then calls persistSessionEntry(params)
The mutation is not gated by owner status, only by general command authorization.
That changes subsequent delivery behavior for the current session, which matches the documented meaning of sendPolicy.
Environment
- Product: OpenClaw
- Verified shipped tag: v2026.3.23
- Shipped tag commit: ccfeecb6887cd97937e33a71877ad512741e82b2
- Published GitHub release time: 2026-03-23T23:15:50Z
- Verification date: 2026-03-24
Duplicate Check
Upon inspection there is no preexisting GHSA for /send.
This is distinct from:
- GHSA-r7vr-gr74-94p8
- that advisory covered owner-only authorization bypasses for /config and /debug, not /send.
This is the same authorization class, but a different privileged command surface that still lacks the owner check.
In Scope Check
This report is in scope under SECURITY.md because:
- it does not rely on adversarial operators sharing one gateway host or config;
- it does not rely on trusted local state tampering;
- SECURITY.md:151-152 explicitly says non-owner sender status matters for owner-only tools and commands;
- /send is explicitly documented as owner-only, so this is a direct owner-only authorization bypass, not a complaint about normal shared-agent steering.
This is therefore a concrete authorization flaw against a documented product boundary.
Remediation Advice
1. Change /send to require owner status, not just command authorization.
2. Reuse the same owner-only rejection pattern already used by privileged command surfaces such as /config, /debug, and owner-only /plugins writes.
3. Add regression coverage for the exact case where:
- a non-owner sender is command-authorized;
- /send must still be rejected unless senderIsOwner === true.
4. Verify that the owner can still use /send on|off|inherit normally.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35620"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T19:06:22Z",
"nvd_published_at": "2026-04-10T17:17:04Z",
"severity": "MODERATE"
},
"details": "\u003e Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n**Title** \nNon-owner command-authorized sender can change the owner-only `/send` session delivery policy\n\n**CWE** \nCWE-285 Improper Authorization\n\n**CVSS v3.1** \nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L \nBase score: **5.4 (Medium)**\n\n**Severity Assessment** \nMedium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session\u2019s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.\n\n**Impact** \nA non-owner sender who is allowed to run commands can invoke `/send on|off|inherit` and persistently change the current session\u2019s `sendPolicy`, even though OpenClaw documents `/send` as owner-only.\n\nThat lets a lower-trust participant:\n- disable reply delivery for the current session (`/send off`), suppressing future replies in that chat;\n- re-enable reply delivery (`/send on`) after the owner intentionally disabled it;\n- remove the session override (`/send inherit`).\n\n**Affected Component** \nVerified against the latest published GitHub release tag `v2026.3.23` (`ccfeecb6887cd97937e33a71877ad512741e82b2`), published `2026-03-23T23:15:50Z`.\n\nExact vulnerable path on the shipped tag:\n- `src/auto-reply/reply/commands-session.ts:212-239`\n - `handleSendPolicyCommand(...)` checks only `params.command.isAuthorizedSender`.\n - when true, it mutates `params.sessionEntry.sendPolicy` and persists the session entry.\n\nAuthorization behavior that makes this reachable:\n- `src/auto-reply/command-auth.ts:401-407`\n - `senderIsOwner` is computed separately from general command authorization.\n- `src/auto-reply/command-auth.ts:420-429`\n - command authorization can succeed even when `senderIsOwner === false`.\n- `src/auto-reply/command-auth.owner-default.test.ts:10-47`\n - existing coverage confirms a sender can be command-authorized while not treated as owner.\n\nDocumented owner-only contract:\n- `docs/tools/slash-commands.md:112`\n - `/send on|off|inherit` is documented as owner-only.\n- `docs/concepts/session-tool.md:156`\n - `sendPolicy` is documented as settable via `sessions.patch` or owner-only `/send on|off|inherit`.\n\nRelated privilege model:\n- `src/gateway/method-scopes.ts:131-133`\n - `sessions.patch` is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.\n\nVersion history:\n- The vulnerable handler exists in release history going back at least to commit `ea018a68ccb92dbc735bc1df9880d5c95c63ca35` (`refactor(auto-reply): split reply pipeline`).\n- Earliest released affected tag found: `v2026.1.14-1`\n- Latest released affected tag verified: `v2026.3.23`\n\n**Technical Reproduction** \n1. Check out the shipped release tag `v2026.3.23`.\n2. Configure a channel where:\n - a non-owner sender is allowed to run commands, for example through `commands.allowFrom`;\n - the owner identity is distinct, for example via `commands.ownerAllowFrom`.\n3. Start or reuse a session with a live `sessionEntry` and `sessionStore`.\n4. Send `/send off` as the non-owner but command-authorized sender.\n5. Confirm the resolved command context has:\n - `isAuthorizedSender === true`\n - `senderIsOwner === false`\n6. Observe that the handler still accepts the command, mutates `sessionEntry.sendPolicy`, and persists the session entry.\n\n**Demonstrated Impact** \nThe vulnerable handler performs a real persistent session-state change:\n- `src/auto-reply/reply/commands-session.ts:232-238`\n - `/send inherit` deletes `sessionEntry.sendPolicy`\n - other modes assign `sessionEntry.sendPolicy = sendPolicyCommand.mode`\n - the handler then calls `persistSessionEntry(params)`\n\nThe mutation is not gated by owner status, only by general command authorization.\n\nThat changes subsequent delivery behavior for the current session, which matches the documented meaning of `sendPolicy`.\n\n**Environment** \n- Product: OpenClaw\n- Verified shipped tag: `v2026.3.23`\n- Shipped tag commit: `ccfeecb6887cd97937e33a71877ad512741e82b2`\n- Published GitHub release time: `2026-03-23T23:15:50Z`\n- Verification date: `2026-03-24`\n\n**Duplicate Check** \nUpon inspection there is no preexisting GHSA for `/send`.\n\nThis is distinct from:\n- `GHSA-r7vr-gr74-94p8`\n - that advisory covered owner-only authorization bypasses for `/config` and `/debug`, not `/send`.\n\nThis is the same authorization class, but a different privileged command surface that still lacks the owner check.\n\n**In Scope Check** \nThis report is in scope under `SECURITY.md` because:\n- it does **not** rely on adversarial operators sharing one gateway host or config;\n- it does **not** rely on trusted local state tampering;\n- `SECURITY.md:151-152` explicitly says non-owner sender status matters for owner-only tools and commands;\n- `/send` is explicitly documented as owner-only, so this is a direct owner-only authorization bypass, not a complaint about normal shared-agent steering.\n\nThis is therefore a concrete authorization flaw against a documented product boundary.\n\n**Remediation Advice** \n1. Change `/send` to require owner status, not just command authorization.\n2. Reuse the same owner-only rejection pattern already used by privileged command surfaces such as `/config`, `/debug`, and owner-only `/plugins` writes.\n3. Add regression coverage for the exact case where:\n - a non-owner sender is command-authorized;\n - `/send` must still be rejected unless `senderIsOwner === true`.\n4. Verify that the owner can still use `/send on|off|inherit` normally.",
"id": "GHSA-39mp-545q-w789",
"modified": "2026-04-10T19:45:32Z",
"published": "2026-03-30T19:06:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-39mp-545q-w789"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vqvg-86cc-cg83"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35620"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/555b2578a8cc6e1b93f717496935ead97bfbed8b"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/ccfeecb6887cd97937e33a71877ad512741e82b2"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/ea018a68ccb92dbc735bc1df9880d5c95c63ca35"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-missing-authorization-in-send-and-allowlist-chat-commands"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Non-owner command-authorized sender can change the owner-only `/send` session delivery policy"
}
GHSA-39P2-8HQ9-FWJ6
Vulnerability from github – Published: 2025-07-30 16:40 – Updated: 2025-07-31 11:18Summary
An attacker can exploit the way GitProxy handles new branch creation to bypass the approval of prior commits on the parent branch.
Because it can greatly affect system integrity, we classify this as a High impact vulnerability.
Details
GitProxy checks for the 0000000000000000000000000000000000000000 hash to detect new branches. This is used to process the commit accordingly in both getDiff.ts and parsePush.ts. However, the logic can be exploited as follows:
- Make a commit in branch
a(could bemain) - Make a new branch
bfrom that commit - Make a new commit in
b, then approve it/get it approved - Go back to
a, and attempt to push this commit to the proxy
The unapproved commit from a will be pushed to the remote.
PoC
To reproduce this vulnerability:
- Clone the target repository and make an unapproved commit on a mainline branch (e.g. main):
git checkout -b a origin/main
echo "DEBUG=true" > config.env
git add config.env
git commit -m "Sensitive debug config"
git push proxy a
- Without approving/getting the commit approved on branch
a, create a new branchbbased on it:
git checkout -b b
echo "feature x implemented" > feature.txt
git add feature.txt
git commit -m "Feature implementation"
git push proxy b
-
Approve/get approval for the push to branch
b. -
Now attempt to push the original unapproved commit from branch
a:
git checkout a
git push proxy a
Prior to 1.19.2, this results in unapproved commits from a getting pushed without any policy checks or explicit approval.
From 1.19.2 onwards, this flow will allow pushing all commits to branch b (and explicit approval will be asked for the changes on b only). However, commits on branch a now require approval on push. If merging branch b into a, this also requires explicit approval of the (previously unapproved) commits originating from a to prevent loopholes.
Impact
The vulnerability impacts all users or organizations relying on GitProxy to enforce policy and prevent unapproved changes. It requires no elevated privileges beyond regular push access, and no extra user interaction. It does however, require a GitProxy administrator or designated user (canUserApproveRejectPush) to approve pushes to the child branch.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.19.1"
},
"package": {
"ecosystem": "npm",
"name": "@finos/git-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-54585"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-30T16:40:35Z",
"nvd_published_at": "2025-07-30T21:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can exploit the way GitProxy handles new branch creation to bypass the approval of prior commits on the parent branch.\n\nBecause it can greatly affect system integrity, we classify this as a High impact vulnerability.\n\n### Details\nGitProxy checks for the `0000000000000000000000000000000000000000` hash to detect new branches. This is used to process the commit accordingly in both `getDiff.ts` and `parsePush.ts`. However, the logic can be exploited as follows:\n\n1. Make a commit in branch `a` (could be `main`)\n2. Make a new branch `b` from that commit\n3. Make a new commit in `b`, then approve it/get it approved\n4. Go back to `a`, and attempt to push this commit to the proxy\n\nThe unapproved commit from `a` will be pushed to the remote.\n\n### PoC\nTo reproduce this vulnerability:\n\n1. Clone the target repository and make an unapproved commit on a mainline branch (e.g. main):\n\n```bash\ngit checkout -b a origin/main\necho \"DEBUG=true\" \u003e config.env\ngit add config.env\ngit commit -m \"Sensitive debug config\"\ngit push proxy a\n```\n\n2. Without approving/getting the commit approved on branch `a`, create a new branch `b` based on it:\n\n```bash\ngit checkout -b b\necho \"feature x implemented\" \u003e feature.txt\ngit add feature.txt\ngit commit -m \"Feature implementation\"\ngit push proxy b\n```\n\n3. Approve/get approval for the push to branch `b`.\n\n4. Now attempt to push the original unapproved commit from branch `a`:\n\n```bash\ngit checkout a\ngit push proxy a\n```\n\nPrior to `1.19.2`, this results in unapproved commits from `a` getting pushed without any policy checks or explicit approval.\n\nFrom `1.19.2` onwards, this flow will allow pushing all commits to branch `b` (and explicit approval will be asked for the changes on `b` only). However, commits on branch `a` now require approval on push. If merging branch `b` into `a`, this also requires explicit approval of the (previously unapproved) commits originating from `a` to prevent loopholes.\n\n### Impact\nThe vulnerability impacts all users or organizations relying on GitProxy to enforce policy and prevent unapproved changes. It requires no elevated privileges beyond regular push access, and no extra user interaction. It does however, require a GitProxy administrator or designated user (`canUserApproveRejectPush`) to approve pushes to the child branch.",
"id": "GHSA-39p2-8hq9-fwj6",
"modified": "2025-07-31T11:18:46Z",
"published": "2025-07-30T16:40:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/finos/git-proxy/security/advisories/GHSA-39p2-8hq9-fwj6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54585"
},
{
"type": "WEB",
"url": "https://github.com/finos/git-proxy/commit/a620a2f33c39c78e01783a274580bf822af3cc3a"
},
{
"type": "WEB",
"url": "https://github.com/finos/git-proxy/commit/f99fe42082eab0970e4cd0acdc3421a527a7e531"
},
{
"type": "PACKAGE",
"url": "https://github.com/finos/git-proxy"
},
{
"type": "WEB",
"url": "https://github.com/finos/git-proxy/releases/tag/v1.19.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "GitProxy New Branch Approval Exploit"
}
GHSA-39RW-4M66-82GF
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2025-02-10 20:37Magento version 2.4.0 and 2.3.5p1 (and earlier) are affected by an incorrect user permissions vulnerability within the Inventory component. This vulnerability could be abused by authenticated users with Inventory and Source permissions to make unauthorized changes to inventory source data via the REST API.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.4.0"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/project-community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-24403"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-11T17:41:25Z",
"nvd_published_at": "2020-11-09T01:15:00Z",
"severity": "LOW"
},
"details": "Magento version 2.4.0 and 2.3.5p1 (and earlier) are affected by an incorrect user permissions vulnerability within the Inventory component. This vulnerability could be abused by authenticated users with Inventory and Source permissions to make unauthorized changes to inventory source data via the REST API.",
"id": "GHSA-39rw-4m66-82gf",
"modified": "2025-02-10T20:37:53Z",
"published": "2022-05-24T17:33:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24403"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb20-59.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Magento incorrect user permissions vulnerability within the Inventory component"
}
GHSA-3C67-5HWX-F6WX
Vulnerability from github – Published: 2024-10-10 21:20 – Updated: 2025-01-21 17:57Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability is related to CORS origin validation, where the Gradio server fails to validate the request origin when a cookie is present. This allows an attacker’s website to make unauthorized requests to a local Gradio server. Potentially, attackers can upload files, steal authentication tokens, and access user data if the victim visits a malicious website while logged into Gradio. This impacts users who have deployed Gradio locally and use basic authentication.
Patches
Yes, please upgrade to gradio>=4.44 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually enforce stricter CORS origin validation by modifying the CustomCORSMiddleware class in their local Gradio server code. Specifically, they can bypass the condition that skips CORS validation for requests containing cookies to prevent potential exploitation.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.44.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47084"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-10T21:20:06Z",
"nvd_published_at": "2024-10-10T22:15:10Z",
"severity": "HIGH"
},
"details": "### Impact\n**What kind of vulnerability is it? Who is impacted?**\n\nThis vulnerability is related to **CORS origin validation**, where the Gradio server fails to validate the request origin when a cookie is present. This allows an attacker\u2019s website to make unauthorized requests to a local Gradio server. Potentially, attackers can upload files, steal authentication tokens, and access user data if the victim visits a malicious website while logged into Gradio. This impacts users who have deployed Gradio locally and use basic authentication.\n\n### Patches\nYes, please upgrade to `gradio\u003e=4.44` to address this issue.\n\n### Workarounds\n**Is there a way for users to fix or remediate the vulnerability without upgrading?**\n\nAs a workaround, users can manually enforce stricter CORS origin validation by modifying the `CustomCORSMiddleware` class in their local Gradio server code. Specifically, they can bypass the condition that skips CORS validation for requests containing cookies to prevent potential exploitation.\n\n",
"id": "GHSA-3c67-5hwx-f6wx",
"modified": "2025-01-21T17:57:09Z",
"published": "2024-10-10T21:20:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/security/advisories/GHSA-3c67-5hwx-f6wx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47084"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/gradio/PYSEC-2024-196.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gradios\u0027s CORS origin validation is not performed when the request has a cookie"
}
GHSA-3CVX-236H-M9FJ
Vulnerability from github – Published: 2026-03-03 21:49 – Updated: 2026-03-25 18:45Description
In affected releases, when an operator explicitly enabled gateway.controlUi.allowInsecureAuth: true and exposed the gateway over plaintext HTTP, Control UI authentication could permit privileged operator access without the intended device identity + pairing guarantees.
This required an insecure deployment choice and credential exposure risk (for example, plaintext transit or prior token leak). It was fixed on main in commit 40a292619e1f2be3a3b1db663d7494c9c2dc0abf (PR #20684).
Affected Packages / Versions
- Package:
openclaw(npm) - Affected published versions:
<= 2026.2.19-2 - Planned patched version:
2026.2.21
Impact
In these explicitly insecure deployments, an attacker with leaked/intercepted credentials could obtain high-privilege Control UI access.
Fix Commit(s)
40a292619e1f2be3a3b1db663d7494c9c2dc0abf(merged 2026-02-20)
OpenClaw thanks @Vasco0x4 for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.2.19-2"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32034"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-319",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:49:18Z",
"nvd_published_at": "2026-03-19T22:16:39Z",
"severity": "MODERATE"
},
"details": "## Description\n\nIn affected releases, when an operator explicitly enabled `gateway.controlUi.allowInsecureAuth: true` and exposed the gateway over plaintext HTTP, Control UI authentication could permit privileged operator access without the intended device identity + pairing guarantees.\n\nThis required an insecure deployment choice and credential exposure risk (for example, plaintext transit or prior token leak). It was fixed on `main` in commit `40a292619e1f2be3a3b1db663d7494c9c2dc0abf` ([PR #20684](https://github.com/openclaw/openclaw/pull/20684)).\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected published versions: `\u003c= 2026.2.19-2`\n- Planned patched version: `2026.2.21`\n\n## Impact\n\nIn these explicitly insecure deployments, an attacker with leaked/intercepted credentials could obtain high-privilege Control UI access.\n\n## Fix Commit(s)\n\n- `40a292619e1f2be3a3b1db663d7494c9c2dc0abf` (merged 2026-02-20)\n\nOpenClaw thanks @Vasco0x4 for reporting.",
"id": "GHSA-3cvx-236h-m9fj",
"modified": "2026-03-25T18:45:34Z",
"published": "2026-03-03T21:49:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3cvx-236h-m9fj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32034"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/pull/20684"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/40a292619e1f2be3a3b1db663d7494c9c2dc0abf"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-insecure-control-ui-authentication-over-plaintext-http"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw has an opt-in insecure Control UI auth over plaintext HTTP could allow privileged access"
}
GHSA-3F5X-PCJQ-3PWW
Vulnerability from github – Published: 2026-03-23 00:31 – Updated: 2026-03-23 00:31A weakness has been identified in MacCMS up to 2025.1000.4052. This vulnerability affects the function order_info of the file application/index/controller/User.php of the component Member Order Detail Interface. This manipulation of the argument order_id causes authorization bypass. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks.
{
"affected": [],
"aliases": [
"CVE-2026-4563"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-23T00:16:51Z",
"severity": "MODERATE"
},
"details": "A weakness has been identified in MacCMS up to 2025.1000.4052. This vulnerability affects the function order_info of the file application/index/controller/User.php of the component Member Order Detail Interface. This manipulation of the argument order_id causes authorization bypass. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks.",
"id": "GHSA-3f5x-pcjq-3pww",
"modified": "2026-03-23T00:31:08Z",
"published": "2026-03-23T00:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4563"
},
{
"type": "WEB",
"url": "https://github.com/HuajiHD/CVE/issues/10"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.352400"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.352400"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.775050"
}
],
"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:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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
- 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) 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 you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply 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.
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.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-402: Bypassing ATA Password Security
An adversary exploits a weakness in ATA security on a drive to gain access to the information the drive contains without supplying the proper credentials. ATA Security is often employed to protect hard disk information from unauthorized access. The mechanism requires the user to type in a password before the BIOS is allowed access to drive contents. Some implementations of ATA security will accept the ATA command to update the password without the user having authenticated with the BIOS. This occurs because the security mechanism assumes the user has first authenticated via the BIOS prior to sending commands to the drive. Various methods exist for exploiting this flaw, the most common being installing the ATA protected drive into a system lacking ATA security features (a.k.a. hot swapping). Once the drive is installed into the new system the BIOS can be used to reset the drive password.
CAPEC-45: Buffer Overflow via Symbolic Links
This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-5: Blue Boxing
This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
{'xhtml:b': 'This attack pattern is included in CAPEC for historical purposes.'}
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-647: Collect Data from Registries
An adversary exploits a weakness in authorization to gather system-specific data and sensitive information within a registry (e.g., Windows Registry, Mac plist). These contain information about the system configuration, software, operating system, and security. The adversary can leverage information gathered in order to carry out further attacks.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.