BREW-OPENCLAW-CLI-CVE-20… (GHSA-MQPW-46FH-299H)

Vulnerability from osv_homebrew – Published: 2026-08-13 17:21 – Updated: 2026-09-25 08:57 – Source website
VLAI
Summary
OpenClaw authorization bypass: operator.write can resolve exec approvals via chat.send -> /approve
Details

Summary

What this means (plain language)

If you give a client “chat/write” access to the gateway (operator.write) but you do not intend to let that client approve exec requests (operator.approvals), affected versions could still let that client approve/deny a pending exec approval by sending the /approve chat command.

This is mainly relevant for shared or multi-client setups where different tokens are intentionally scoped differently. Single-operator installs are typically less impacted.

Technical summary

A gateway client authenticated with a device token scoped only to operator.write (without operator.approvals) could approve/deny pending exec approval requests by sending a chat message containing the built-in /approve command.

exec.approval.resolve is correctly scoped to operator.approvals for direct RPC calls, but the /approve command path invoked it via an internal privileged gateway client.

Affected Packages / Versions

  • openclaw (npm): < 2026.2.2

Fix

  • Fixed in openclaw 2026.2.2.
  • Fix commit(s): efe2a464afcff55bb5a95b959e6bd9ec0fef086e.
  • Change: when /approve is invoked from gateway clients (webchat/internal channel), it now requires the requesting client to have operator.approvals (or operator.admin).

Workarounds

  • Upgrade to openclaw >= 2026.2.2.
  • If you cannot upgrade: avoid issuing write-only device tokens to untrusted clients; disable text commands (commands.text=false) or restrict access to the webchat/control UI.

References

  • Fix: src/auto-reply/reply/commands-approve.ts
  • Coverage: src/auto-reply/reply/commands-approve.test.ts

Release Process Note

This advisory is kept in draft; once the fixed npm versions are available, it can be published without further edits.

Thanks @yueyueL for reporting.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
7.2 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "2026.2.2"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "openclaw-cli",
        "purl": "pkg:brew/openclaw-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "npm",
        "key": "pkg:npm/openclaw@2026.9.6",
        "name": "openclaw",
        "strategy": "registry",
        "subject_version": "2026.9.6"
      }
    ]
  },
  "details": "## Summary\n\n### What this means (plain language)\n\nIf you give a client \u201cchat/write\u201d access to the gateway (`operator.write`) but you do not intend to let that client approve exec requests (`operator.approvals`), affected versions could still let that client approve/deny a pending exec approval by sending the `/approve` chat command.\n\nThis is mainly relevant for shared or multi-client setups where different tokens are intentionally scoped differently. Single-operator installs are typically less impacted.\n\n### Technical summary\n\nA gateway client authenticated with a device token scoped only to `operator.write` (without `operator.approvals`) could approve/deny pending exec approval requests by sending a chat message containing the built-in `/approve` command.\n\n`exec.approval.resolve` is correctly scoped to `operator.approvals` for direct RPC calls, but the `/approve` command path invoked it via an internal privileged gateway client.\n\n## Affected Packages / Versions\n\n- `openclaw` (npm): `\u003c 2026.2.2`\n\n## Fix\n\n- Fixed in `openclaw` `2026.2.2`.\n- Fix commit(s): `efe2a464afcff55bb5a95b959e6bd9ec0fef086e`.\n- Change: when `/approve` is invoked from gateway clients (webchat/internal channel), it now requires the requesting client to have `operator.approvals` (or `operator.admin`).\n\n## Workarounds\n\n- Upgrade to `openclaw \u003e= 2026.2.2`.\n- If you cannot upgrade: avoid issuing write-only device tokens to untrusted clients; disable text commands (`commands.text=false`) or restrict access to the webchat/control UI.\n\n## References\n\n- Fix: `src/auto-reply/reply/commands-approve.ts`\n- Coverage: `src/auto-reply/reply/commands-approve.test.ts`\n\n## Release Process Note\n\nThis advisory is kept in draft; once the fixed npm versions are available, it can be published without further edits.\n\nThanks @yueyueL for reporting.",
  "id": "BREW-openclaw-cli-CVE-2026-28473",
  "modified": "2026-09-25T08:57:16Z",
  "published": "2026-08-13T17:21:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mqpw-46fh-299h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28473"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/efe2a464afcff55bb5a95b959e6bd9ec0fef086e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-approve-chat-command"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw authorization bypass: operator.write can resolve exec approvals via chat.send -\u003e /approve",
  "upstream": [
    "GHSA-mqpw-46fh-299h",
    "CVE-2026-28473"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.