CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
6890 vulnerabilities reference this CWE, most recent first.
GHSA-978Q-37G3-WQ8G
Vulnerability from github – Published: 2026-08-04 15:32 – Updated: 2026-08-05 21:31In Eclipse Milo versions 1.0.0 through 1.1.4, the Call service dispatches the original mixed batch to address-space handlers after calculating authorization, allowing an anonymous or otherwise low-privileged client to execute a denied method by batching it with an allowed method.
{
"affected": [],
"aliases": [
"CVE-2026-62927"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-04T13:18:55Z",
"severity": "HIGH"
},
"details": "In Eclipse Milo versions 1.0.0 through 1.1.4, the Call service dispatches the original mixed batch to address-space handlers after calculating authorization, allowing an anonymous or otherwise low-privileged client to execute a denied method by batching it with an allowed method.",
"id": "GHSA-978q-37g3-wq8g",
"modified": "2026-08-05T21:31:34Z",
"published": "2026-08-04T15:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62927"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-milo/milo/commit/59b50bed094de0d18a130a48f3527254dc76105d"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/178"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/598"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/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-979G-PGGF-HWP2
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09Huawei mobile phones Ever-L29B versions earlier than 10.0.0.180(C185E6R3P3), earlier than 10.0.0.180(C432E6R1P7), earlier than 10.0.0.180(C636E5R2P3); HUAWEI Mate 20 RS versions earlier than 10.0.0.175(C786E70R3P8); HUAWEI Mate 20 X versions earlier than 10.0.0.176(C00E70R2P8); and Honor Magic2 versions earlier than 10.0.0.175(C00E59R2P11) have an improper authorization vulnerability. Due to improper authorization of some function, attackers can bypass the authorization to perform some operations.
{
"affected": [],
"aliases": [
"CVE-2020-1882"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-18T00:15:00Z",
"severity": "LOW"
},
"details": "Huawei mobile phones Ever-L29B versions earlier than 10.0.0.180(C185E6R3P3), earlier than 10.0.0.180(C432E6R1P7), earlier than 10.0.0.180(C636E5R2P3); HUAWEI Mate 20 RS versions earlier than 10.0.0.175(C786E70R3P8); HUAWEI Mate 20 X versions earlier than 10.0.0.176(C00E70R2P8); and Honor Magic2 versions earlier than 10.0.0.175(C00E59R2P11) have an improper authorization vulnerability. Due to improper authorization of some function, attackers can bypass the authorization to perform some operations.",
"id": "GHSA-979g-pggf-hwp2",
"modified": "2022-05-24T17:09:16Z",
"published": "2022-05-24T17:09:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1882"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200122-01-phone-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-97CV-X867-6XHM
Vulnerability from github – Published: 2026-09-23 19:27 – Updated: 2026-09-23 19:27Description
The VM built-in function KleverUpdateAccountPermission (registered always-active, creator.go:381-390 / core/vmconstants.go:234) rewrites an account's entire permission set. Its authorization check uses vmInput.RecipientAddr attacker-controlled instead of the authenticated vmInput.CallerAddr. The sibling handler kleverChangeOwnerAddress.go:86 uses vmInput.CallerAddr correctly, so the safe pattern exists in-repo; this handler deviates. The native transaction path (txProcess.go:833) is safe it uses tx.GetSender().
Mechanism:
1. Wrong variable: CallerAddr is never referenced in the handler; auth is contractHasValidPermission(target.GetPermissions(), RecipientAddr), which returns true if RecipientAddr is a signer with Weight >= Threshold in the target account's permissions and the permission grants UpdateAccountPermissionContractType.
2. RecipientAddr is attacker-controlled: when a contract calls a built-in via ExecuteOnDestContextWithTypedArgs (baseOps.go:1967), prepareIndirectContractCallInput (baseOps.go:2485) sets RecipientAddr = destination (contract-chosen) and CallerAddr = the calling contract. The blockchain hook (blockChainHook.go:454/467) dispatches on input.Function and passes the input through unchanged; no guard forces RecipientAddr == CallerAddr and there is no SC-destination validation on this path.
3. Self-signer default satisfies the check: createDefaultOwnerPermission (accounts.go:1848) makes an account its own signer (weight 1, threshold 1, Owner type), and CheckPermissionGrantedForContracts returns true for Owner, so contractHasValidPermission(V.perms, V) == true. (More generally, RecipientAddr can be set to any of V's signer addresses meeting threshold all public on-chain.) Accounts with no stored permissions have empty GetPermissions() and are immune.
4. Overwrite is unrestricted: UpdatePermission(V, attackerContract) (accounts.go:1863) replaces V's permission set with attacker-supplied signers; if the attacker supplies an Owner-type permission, no default is appended and V's prior control is fully evicted.
Code walkthrough
(a) The vulnerable handler — core/kapp/builtInFunctions/kleverUpdateAccountPermission.go:
func (e *kleverUpdateAccountPermission) ProcessBuiltinFunction(vmInput *vmcommon.ContractCallInput) (*vmcommon.VMOutput, error) {
...
address := vmInput.NextArg() // Arguments[0] — attacker-chosen target account V
contract, err := e.getUpdateAccountPermissionContract(vmInput) // Arguments[1] — attacker-chosen new permissions
...
acc, err := e.accountsCacher.LoadUser(address) // loads V
...
// BUG: authorizes against vmInput.RecipientAddr (attacker-controlled), NOT vmInput.CallerAddr
if !e.contractHasValidPermission(acc.GetPermissions(), vmInput.RecipientAddr) { // L91
return nil, errors.New("invalid permission operation")
}
// overwrites V's entire permission set with attacker-supplied signers
resultCode, err := e.kappController.GetAccountsKApp().UpdatePermission(address, contract)
...
}
(b) The check just name-matches recipientAddr against V's own signers — same file:
func (e *kleverUpdateAccountPermission) contractHasValidPermission(permissions []*state.Permission, recipientAddr []byte) bool {
for _, permission := range permissions {
for _, signer := range permission.Signers {
if !bytes.Equal(signer.Address, recipientAddr) { // recipientAddr, not the authenticated caller
continue
}
if signer.Weight >= permission.Threshold &&
permission.CheckPermissionGrantedForContracts(transaction.TXContract_UpdateAccountPermissionContractType) {
return true
}
}
}
return false
}
(c) The dispatch makes RecipientAddr attacker-controlled — kvm/vmhost/vmhooks/baseOps.go:2464 prepareIndirectContractCallInput (invoked when a contract calls the built-in via ExecuteOnDestContext):
contractCallInput := &vmcommon.ContractCallInput{
VMInput: vmcommon.VMInput{
CallerAddr: sender, // the calling contract (authenticated) — NOT used by the handler
Arguments: data, // attacker-chosen: [V, attackerPermissions]
...
},
RecipientAddr: destination, // the contract's chosen `dest` argument — attacker sets this to V
Function: string(function),
}
(d) Every account with configured permissions is its own signer — core/kapp/accounts/accounts.go:1848 createDefaultOwnerPermission (appended by UpdatePermission when no Owner permission is supplied):
return &state.Permission{
Type: state.Permission_Owner, // Owner grants ALL contract types incl. type 22
Threshold: 1,
Signers: []*state.Key{
{ Address: ownerAcc.AddressBytes(), Weight: 1 }, // the account signs for itself
},
}
So contractHasValidPermission(V.perms, RecipientAddr=V) finds V's own address as a Weight 1 >= Threshold 1 Owner signer → returns true.
(e) Contrast — the sibling handler does it correctly — core/kapp/builtInFunctions/kleverChangeOwnerAddress.go:86:
callerAddress := vmInput.CallerAddr // authenticated caller
...
if !bytes.Equal(callerAddress, acc.GetOwnerAddress()) { // checks the CALLER, not RecipientAddr
return nil, ErrOperationNotPermitted
}
Putting it together — the attacker's contract call:
ExecuteOnDestContext(
gas, dest = V, // → RecipientAddr = V
value = 0,
function = "KleverUpdateAccountPermission",
args = [ V, attackerOwnerPermsWithOnlyAttackerKey ], // Arguments[0]=V, Arguments[1]=new perms
)
→ CallerAddr = attackerContract (ignored), RecipientAddr = V, contractHasValidPermission(V.perms, V) == true → V's permissions overwritten with the attacker's key as sole Owner signer. The attacker never held a key of V and provided no signature from V.
POC
put the following poc testcase under /core/kapp/builtInFunctions/
POC Code: https://gist.github.com/mabdullah22/a41f90aa5ba86bbebf121f739bd5f5e9
Run:
cd klever-go
GOTOOLCHAIN=auto go test ./core/kapp/builtInFunctions/ -run TestPoC_PermTakeover -v
Output:
TAKEOVER CONFIRMED: caller="attacker-contract" (attacker SC) rewrote account V="victim-account-V"; new sole owner signer="attacker-key-EVIL"
--- PASS: TestPoC_PermTakeover
--- PASS: TestPoC_PermTakeover_NoStoredPermsIsSafe
The harm asserted is the takeover itself: after the call, V's permission set is a single Owner permission whose sole signer is the attacker's key; V's original owner signer is gone.
Impact
Full takeover of any account that has configured permissions i.e. every multisig / advanced-permission account , by an attacker who deploys a cheap smart contract and supplies only public on-chain addresses (no keys, no signatures from the victim). After takeover the attacker controls all of the victim's operations → theft or permanent lock of all the account's assets. Reachable via a permissionlessly-deployed contract (the plain-tx path is safe, so it is Critical-via-contract, not fully no-contract). No fork flag gates it.
Severity Critical: Impact High (full account/asset compromise)
Recommendation
Authorize against the authenticated caller, mirroring kleverChangeOwnerAddress:
if !e.contractHasValidPermission(acc.GetPermissions(), vmInput.CallerAddr) { ... }
Reconcile the SC-call authority model: on the built-in path CallerAddr is the calling contract, so a contract should only be able to update permissions of accounts that legitimately list it as an authorized signer — never an arbitrary victim. Consider also requiring the target account (Arguments[0]) to equal the authorized caller's account, matching the native tx.GetSender() model.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.19"
},
"package": {
"ecosystem": "Go",
"name": "github.com/klever-io/klever-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-82405"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-23T19:27:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\n\nThe VM built-in function `KleverUpdateAccountPermission` (registered always-active, `creator.go:381-390` / `core/vmconstants.go:234`) rewrites an account\u0027s entire permission set. Its authorization check uses `vmInput.RecipientAddr` **attacker-controlled** instead of the authenticated `vmInput.CallerAddr`. The sibling handler `kleverChangeOwnerAddress.go:86` uses `vmInput.CallerAddr` correctly, so the safe pattern exists in-repo; this handler deviates. The native transaction path (`txProcess.go:833`) is safe it uses `tx.GetSender()`.\n\nMechanism:\n1. **Wrong variable:** `CallerAddr` is never referenced in the handler; auth is `contractHasValidPermission(target.GetPermissions(), RecipientAddr)`, which returns true if `RecipientAddr` is a signer with `Weight \u003e= Threshold` in the *target* account\u0027s permissions and the permission grants `UpdateAccountPermissionContractType`.\n2. **RecipientAddr is attacker-controlled:** when a contract calls a built-in via `ExecuteOnDestContextWithTypedArgs` (`baseOps.go:1967`), `prepareIndirectContractCallInput` (`baseOps.go:2485`) sets `RecipientAddr = destination` (contract-chosen) and `CallerAddr = the calling contract`. The blockchain hook (`blockChainHook.go:454/467`) dispatches on `input.Function` and passes the input through unchanged; no guard forces `RecipientAddr == CallerAddr` and there is no SC-destination validation on this path.\n3. **Self-signer default satisfies the check:** `createDefaultOwnerPermission` (`accounts.go:1848`) makes an account its own signer (weight 1, threshold 1, Owner type), and `CheckPermissionGrantedForContracts` returns true for Owner, so `contractHasValidPermission(V.perms, V) == true`. (More generally, `RecipientAddr` can be set to *any* of V\u0027s signer addresses meeting threshold all public on-chain.) Accounts with no stored permissions have empty `GetPermissions()` and are immune.\n4. **Overwrite is unrestricted:** `UpdatePermission(V, attackerContract)` (`accounts.go:1863`) replaces V\u0027s permission set with attacker-supplied signers; if the attacker supplies an Owner-type permission, no default is appended and V\u0027s prior control is fully evicted.\n\n### Code walkthrough\n\n**(a) The vulnerable handler** \u2014 `core/kapp/builtInFunctions/kleverUpdateAccountPermission.go`:\n```go\nfunc (e *kleverUpdateAccountPermission) ProcessBuiltinFunction(vmInput *vmcommon.ContractCallInput) (*vmcommon.VMOutput, error) {\n ...\n address := vmInput.NextArg() // Arguments[0] \u2014 attacker-chosen target account V\n contract, err := e.getUpdateAccountPermissionContract(vmInput) // Arguments[1] \u2014 attacker-chosen new permissions\n ...\n acc, err := e.accountsCacher.LoadUser(address) // loads V\n ...\n // BUG: authorizes against vmInput.RecipientAddr (attacker-controlled), NOT vmInput.CallerAddr\n if !e.contractHasValidPermission(acc.GetPermissions(), vmInput.RecipientAddr) { // L91\n return nil, errors.New(\"invalid permission operation\")\n }\n // overwrites V\u0027s entire permission set with attacker-supplied signers\n resultCode, err := e.kappController.GetAccountsKApp().UpdatePermission(address, contract)\n ...\n}\n```\n\n**(b) The check just name-matches `recipientAddr` against V\u0027s own signers** \u2014 same file:\n```go\nfunc (e *kleverUpdateAccountPermission) contractHasValidPermission(permissions []*state.Permission, recipientAddr []byte) bool {\n for _, permission := range permissions {\n for _, signer := range permission.Signers {\n if !bytes.Equal(signer.Address, recipientAddr) { // recipientAddr, not the authenticated caller\n continue\n }\n if signer.Weight \u003e= permission.Threshold \u0026\u0026\n permission.CheckPermissionGrantedForContracts(transaction.TXContract_UpdateAccountPermissionContractType) {\n return true\n }\n }\n }\n return false\n}\n```\n\n**(c) The dispatch makes `RecipientAddr` attacker-controlled** \u2014 `kvm/vmhost/vmhooks/baseOps.go:2464` `prepareIndirectContractCallInput` (invoked when a contract calls the built-in via `ExecuteOnDestContext`):\n```go\ncontractCallInput := \u0026vmcommon.ContractCallInput{\n VMInput: vmcommon.VMInput{\n CallerAddr: sender, // the calling contract (authenticated) \u2014 NOT used by the handler\n Arguments: data, // attacker-chosen: [V, attackerPermissions]\n ...\n },\n RecipientAddr: destination, // the contract\u0027s chosen `dest` argument \u2014 attacker sets this to V\n Function: string(function),\n}\n```\n\n**(d) Every account with configured permissions is its own signer** \u2014 `core/kapp/accounts/accounts.go:1848` `createDefaultOwnerPermission` (appended by `UpdatePermission` when no Owner permission is supplied):\n```go\nreturn \u0026state.Permission{\n Type: state.Permission_Owner, // Owner grants ALL contract types incl. type 22\n Threshold: 1,\n Signers: []*state.Key{\n { Address: ownerAcc.AddressBytes(), Weight: 1 }, // the account signs for itself\n },\n}\n```\nSo `contractHasValidPermission(V.perms, RecipientAddr=V)` finds V\u0027s own address as a `Weight 1 \u003e= Threshold 1` Owner signer \u2192 returns `true`.\n\n**(e) Contrast \u2014 the sibling handler does it correctly** \u2014 `core/kapp/builtInFunctions/kleverChangeOwnerAddress.go:86`:\n```go\ncallerAddress := vmInput.CallerAddr // authenticated caller\n...\nif !bytes.Equal(callerAddress, acc.GetOwnerAddress()) { // checks the CALLER, not RecipientAddr\n return nil, ErrOperationNotPermitted\n}\n```\n\n**Putting it together \u2014 the attacker\u0027s contract call:**\n```\nExecuteOnDestContext(\n gas, dest = V, // \u2192 RecipientAddr = V\n value = 0,\n function = \"KleverUpdateAccountPermission\",\n args = [ V, attackerOwnerPermsWithOnlyAttackerKey ], // Arguments[0]=V, Arguments[1]=new perms\n)\n```\n\u2192 `CallerAddr = attackerContract` (ignored), `RecipientAddr = V`, `contractHasValidPermission(V.perms, V) == true` \u2192 V\u0027s permissions overwritten with the attacker\u0027s key as sole Owner signer. The attacker never held a key of V and provided no signature from V.\n\n### POC\n\nput the following poc testcase under /core/kapp/builtInFunctions/ \n\nPOC Code: https://gist.github.com/mabdullah22/a41f90aa5ba86bbebf121f739bd5f5e9\n\nRun:\n```\ncd klever-go\nGOTOOLCHAIN=auto go test ./core/kapp/builtInFunctions/ -run TestPoC_PermTakeover -v\n```\nOutput:\n```\nTAKEOVER CONFIRMED: caller=\"attacker-contract\" (attacker SC) rewrote account V=\"victim-account-V\"; new sole owner signer=\"attacker-key-EVIL\"\n--- PASS: TestPoC_PermTakeover\n--- PASS: TestPoC_PermTakeover_NoStoredPermsIsSafe\n```\nThe harm asserted is the takeover itself: after the call, V\u0027s permission set is a single Owner permission whose sole signer is the attacker\u0027s key; V\u0027s original owner signer is gone.\n\n### Impact\n\nFull takeover of **any account that has configured permissions** i.e. every multisig / advanced-permission account , by an attacker who deploys a cheap smart contract and supplies only public on-chain addresses (no keys, no signatures from the victim). After takeover the attacker controls all of the victim\u0027s operations \u2192 theft or permanent lock of all the account\u0027s assets. Reachable via a permissionlessly-deployed contract (the plain-tx path is safe, so it is Critical-via-contract, not fully no-contract). No fork flag gates it.\n\nSeverity **Critical**: Impact High (full account/asset compromise)\n\n### Recommendation\n\nAuthorize against the authenticated caller, mirroring `kleverChangeOwnerAddress`:\n```go\nif !e.contractHasValidPermission(acc.GetPermissions(), vmInput.CallerAddr) { ... }\n```\nReconcile the SC-call authority model: on the built-in path `CallerAddr` is the calling contract, so a contract should only be able to update permissions of accounts that legitimately list *it* as an authorized signer \u2014 never an arbitrary victim. Consider also requiring the target account (`Arguments[0]`) to equal the authorized caller\u0027s account, matching the native `tx.GetSender()` model.",
"id": "GHSA-97cv-x867-6xhm",
"modified": "2026-09-23T19:27:08Z",
"published": "2026-09-23T19:27:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-97cv-x867-6xhm"
},
{
"type": "WEB",
"url": "https://github.com/klever-io/klever-go/commit/c58740eb74d7ee8f07db1e18a7d6214b5559ba32"
},
{
"type": "WEB",
"url": "https://gist.github.com/mabdullah22/a41f90aa5ba86bbebf121f739bd5f5e9"
},
{
"type": "PACKAGE",
"url": "https://github.com/klever-io/klever-go"
},
{
"type": "WEB",
"url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Klever-Go Account takeover: `kleverUpdateAccountPermission` authorizes on attacker-controlled `RecipientAddr` instead of the authenticated caller"
}
GHSA-97GQ-4JQF-CVGM
Vulnerability from github – Published: 2023-08-08 03:30 – Updated: 2024-09-29 00:30The ACL (Access Control List) of SAP Message Server - versions KERNEL 7.22, KERNEL 7.53, KERNEL 7.54, KERNEL 7.77, RNL64UC 7.22, RNL64UC 7.22EXT, RNL64UC 7.53, KRNL64NUC 7.22, KRNL64NUC 7.22EXT, can be bypassed in certain conditions, which may enable an authenticated malicious user to enter the network of the SAP systems served by the attacked SAP Message server. This may lead to unauthorized read and write of data as well as rendering the system unavailable.
{
"affected": [],
"aliases": [
"CVE-2023-37491"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-08T01:15:18Z",
"severity": "HIGH"
},
"details": "The ACL (Access\u00a0Control\u00a0List) of SAP Message Server - versions KERNEL 7.22, KERNEL 7.53, KERNEL 7.54, KERNEL 7.77, RNL64UC 7.22, RNL64UC 7.22EXT, RNL64UC 7.53, KRNL64NUC 7.22, KRNL64NUC 7.22EXT, can be bypassed in certain conditions, which may enable an authenticated malicious user to enter the network of the SAP systems served by the attacked SAP Message server. This may lead to unauthorized read and write of data as well as rendering the system unavailable.\n\n",
"id": "GHSA-97gq-4jqf-cvgm",
"modified": "2024-09-29T00:30:57Z",
"published": "2023-08-08T03:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37491"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3344295"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"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"
}
]
}
GHSA-97QC-PWC2-QCFQ
Vulnerability from github – Published: 2026-09-02 15:34 – Updated: 2026-09-02 15:34The HIPAA FORMS WordPress plugin before 3.2.0 contains a hardcoded authentication bypass via a hardcoded parameter alongside all AJAX requests. The server explicitly checks for this value to skip nonce validation entirely. This allows unauthenticated attackers to access protected AJAX endpoints.
{
"affected": [],
"aliases": [
"CVE-2026-2688"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-02T15:17:38Z",
"severity": "MODERATE"
},
"details": "The HIPAA FORMS WordPress plugin before 3.2.0 contains a hardcoded authentication bypass via a hardcoded parameter alongside all AJAX requests. The server explicitly checks for this value to skip nonce validation entirely. This allows unauthenticated attackers to access protected AJAX endpoints.",
"id": "GHSA-97qc-pwc2-qcfq",
"modified": "2026-09-02T15:34:49Z",
"published": "2026-09-02T15:34:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2688"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/779304f2-7dc2-4f12-b134-dede9a0c5eb6"
}
],
"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"
}
]
}
GHSA-9832-MGG4-3GR6
Vulnerability from github – Published: 2023-09-06 15:30 – Updated: 2023-09-07 13:59An improper default REST API permission for Gamma users in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma user to test database connections.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "apache-superset"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-36387"
],
"database_specific": {
"cwe_ids": [
"CWE-281",
"CWE-863",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-07T13:59:27Z",
"nvd_published_at": "2023-09-06T13:15:08Z",
"severity": "MODERATE"
},
"details": "An improper default REST API permission for Gamma users in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma user to test database connections.\n",
"id": "GHSA-9832-mgg4-3gr6",
"modified": "2023-09-07T13:59:27Z",
"published": "2023-09-06T15:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36387"
},
{
"type": "WEB",
"url": "https://github.com/apache/superset/pull/24185"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/superset"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/tt6s6hm8nv6s11z8bfsk3r3d9ov0ogw3"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Apache Superset has improper default REST API permission for Gamma users"
}
GHSA-9868-VXMX-W862
Vulnerability from github – Published: 2026-03-03 19:53 – Updated: 2026-03-19 21:21Summary
In OpenClaw system.run allowlist mode, shell-wrapper analysis could be bypassed by splitting command substitution as $\\ + newline + ( inside double quotes. Analysis treated the payload as allowlisted (for example /bin/echo), while shell runtime folded the line continuation into $(...) and executed non-allowlisted subcommands.
Affected Packages / Versions
- Package: npm
openclaw - Latest published affected version:
2026.2.21-2 - Affected range:
<=2026.2.21-2 - Patched version (planned next release):
2026.2.22
Impact
In deployments that opt into tools.exec.security=allowlist (with ask=on-miss or off), this can bypass approval boundaries and lead to unintended command execution.
Fix Commit(s)
3f0b9dbb36c86e308267924c0d3d4a4e1fc4d1e9
Remediation
- Upgrade to
2026.2.22(or newer) when published. - Temporary mitigation: set
tools.exec.ask=alwaysortools.exec.security=deny.
Release Process Note
patched_versions is pre-set to planned next release 2026.2.22. After npm release is out, this advisory should be ready for direct publish without additional metadata edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28460"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T19:53:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nIn OpenClaw `system.run` allowlist mode, shell-wrapper analysis could be bypassed by splitting command substitution as `$\\\\` + newline + `(` inside double quotes. Analysis treated the payload as allowlisted (for example `/bin/echo`), while shell runtime folded the line continuation into `$(...)` and executed non-allowlisted subcommands.\n\n### Affected Packages / Versions\n- Package: npm `openclaw`\n- Latest published affected version: `2026.2.21-2`\n- Affected range: `\u003c=2026.2.21-2`\n- Patched version (planned next release): `2026.2.22`\n\n### Impact\nIn deployments that opt into `tools.exec.security=allowlist` (with `ask=on-miss` or `off`), this can bypass approval boundaries and lead to unintended command execution.\n\n### Fix Commit(s)\n- `3f0b9dbb36c86e308267924c0d3d4a4e1fc4d1e9`\n\n### Remediation\n- Upgrade to `2026.2.22` (or newer) when published.\n- Temporary mitigation: set `tools.exec.ask=always` or `tools.exec.security=deny`.\n\n### Release Process Note\n`patched_versions` is pre-set to planned next release `2026.2.22`. After npm release is out, this advisory should be ready for direct publish without additional metadata edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-9868-vxmx-w862",
"modified": "2026-03-19T21:21:47Z",
"published": "2026-03-03T19:53:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9868-vxmx-w862"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28460"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/3f0b9dbb36c86e308267924c0d3d4a4e1fc4d1e9"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-shell-line-continuation-command-substitution-in-system-run"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "OpenClaw\u0027s system.run allowlist bypass via shell line-continuation command substitution"
}
GHSA-987J-G759-4RQ3
Vulnerability from github – Published: 2024-04-24 18:30 – Updated: 2025-03-12 21:31Improper Authentication vulnerability in Repute Infosystems BookingPress allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects BookingPress: from n/a through 1.0.74.
{
"affected": [],
"aliases": [
"CVE-2023-51405"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-24T16:15:08Z",
"severity": "MODERATE"
},
"details": "Improper Authentication vulnerability in Repute Infosystems BookingPress allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects BookingPress: from n/a through 1.0.74.",
"id": "GHSA-987j-g759-4rq3",
"modified": "2025-03-12T21:31:28Z",
"published": "2024-04-24T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51405"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/bookingpress-appointment-booking/wordpress-bookingpress-plugin-1-0-74-booking-price-manipulation-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-987P-R3JC-8C8V
Vulnerability from github – Published: 2025-04-29 13:59 – Updated: 2025-04-30 17:29Impact
The Solr script service that is accessible in XWiki's scripting API normally requires programming right to be called. Due to using the wrong API for checking rights, it doesn't take the fact into account that programming rights might have been dropped by calling $xcontext.dropPermissions(). If some code relies on this for the safety of executing Velocity code with the wrong author context, this could allow a user with script right to either cause a high load by indexing documents or to temporarily remove documents from the search index. We're not aware that this is exploitable in XWiki itself.
To reproduce, a user with programming right can add the following XWiki syntax to a page:
{{velocity}}
$xcontext.dropPermissions()
$services.solr.index('document:xwiki:Main.WebHome')
{{/velocity}}
This should trigger an error in XWiki's log, otherwise the installation is vulnerable.
Patches
This has been patched in XWiki 15.10.13, 16.8.0RC1, and 16.4.4.
Workarounds
We're not aware of any workarounds apart from being careful whom you grant script right.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-search-solr-api"
},
"ranges": [
{
"events": [
{
"introduced": "4.5.1"
},
{
"fixed": "15.10.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-search-solr-api"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-rc-1"
},
{
"fixed": "16.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-search-solr-api"
},
"ranges": [
{
"events": [
{
"introduced": "16.5.0-rc-1"
},
{
"fixed": "16.8.0-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-32971"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-29T13:59:45Z",
"nvd_published_at": "2025-04-30T15:16:01Z",
"severity": "LOW"
},
"details": "### Impact\nThe Solr script service that is accessible in XWiki\u0027s scripting API normally requires programming right to be called. Due to using the wrong API for checking rights, it doesn\u0027t take the fact into account that programming rights might have been dropped by calling `$xcontext.dropPermissions()`. If some code relies on this for the safety of executing Velocity code with the wrong author context, this could allow a user with script right to either cause a high load by indexing documents or to temporarily remove documents from the search index. We\u0027re not aware that this is exploitable in XWiki itself.\n\nTo reproduce, a user with programming right can add the following XWiki syntax to a page:\n```\n{{velocity}}\n$xcontext.dropPermissions()\n$services.solr.index(\u0027document:xwiki:Main.WebHome\u0027)\n{{/velocity}} \n```\n\nThis should trigger an error in XWiki\u0027s log, otherwise the installation is vulnerable.\n\n### Patches\nThis has been patched in XWiki 15.10.13, 16.8.0RC1, and 16.4.4.\n\n### Workarounds\nWe\u0027re not aware of any workarounds apart from being careful whom you grant script right.",
"id": "GHSA-987p-r3jc-8c8v",
"modified": "2025-04-30T17:29:21Z",
"published": "2025-04-29T13:59:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-987p-r3jc-8c8v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32971"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/6570f40f976aec82baf388b5239d1412cab238c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-22474"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Solr script service doesn\u0027t take dropped programming right into account"
}
GHSA-988C-QPG2-7HPV
Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-03-29 15:30OpenClaw before 2026.3.12 contains an authorization bypass vulnerability where Feishu reaction events with omitted chat_type are misclassified as p2p conversations instead of group chats. Attackers can exploit this misclassification to bypass groupAllowFrom and requireMention protections in group chat reaction-derived events.
{
"affected": [],
"aliases": [
"CVE-2026-32924"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-29T13:17:00Z",
"severity": "MODERATE"
},
"details": "OpenClaw before 2026.3.12 contains an authorization bypass vulnerability where Feishu reaction events with omitted chat_type are misclassified as p2p conversations instead of group chats. Attackers can exploit this misclassification to bypass groupAllowFrom and requireMention protections in group chat reaction-derived events.",
"id": "GHSA-988c-qpg2-7hpv",
"modified": "2026-03-29T15:30:19Z",
"published": "2026-03-29T15:30:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-m69h-jm2f-2pv8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32924"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-misclassified-reaction-events-in-feishu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/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"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.