GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

BREW-OPENCLAW-CLI-GHSA-C… (GHSA-CHM2-M3W2-WCXM)

Vulnerability from osv_homebrew – Published: 2026-08-13 17:21 – Updated: 2026-09-17 17:24 – Source website
VLAI
Summary
OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch
Details

Summary

Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (users/<id>). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

Affected Packages / Versions

(As of 2026-02-14; based on latest published npm versions) - openclaw (npm): <= 2026.2.13 - clawdbot (npm): <= 2026.1.24-3

Details

Affected component: - extensions/googlechat/src/monitor.ts

The allowFrom checks accept: - Immutable sender id (users/<id>) - Raw email (alice@example.com) for usability

Historically, users/<email> was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

Security Triage (2026-02-14)

Severity: Low

Rationale: - Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector. - A realistic exploit generally requires Google Workspace / IdP administrative control over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different users/<id>. - With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

Remediation / Behavior Changes

Goal: preserve usability while reducing footguns. - Raw email allowlists remain supported. - users/<email> is deprecated and treated as a user id, not as an email allowlist. - Documentation recommends users/<id> when strict immutable binding is required.

Fix Commit(s)

  • c8424bf29a921e25663b29f308640b3d91a49432 (PR #16243)

Thanks @vincentkoc for reporting.


{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "2026.2.14"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "openclaw-cli",
        "purl": "pkg:brew/openclaw-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.1.29"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "npm",
        "key": "pkg:npm/openclaw@2026.9.4",
        "name": "openclaw",
        "strategy": "registry",
        "subject_version": "2026.9.4"
      }
    ]
  },
  "details": "### Summary\nGoogle Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/\u003cid\u003e`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.\n\n### Affected Packages / Versions\n(As of 2026-02-14; based on latest published npm versions)\n- `openclaw` (npm): `\u003c= 2026.2.13`\n- `clawdbot` (npm): `\u003c= 2026.1.24-3`\n\n### Details\nAffected component:\n- `extensions/googlechat/src/monitor.ts`\n\nThe `allowFrom` checks accept:\n- Immutable sender id (`users/\u003cid\u003e`)\n- Raw email (`alice@example.com`) for usability\n\nHistorically, `users/\u003cemail\u003e` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.\n\n### Security Triage (2026-02-14)\nSeverity: **Low**\n\nRationale:\n- Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector.\n- A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/\u003cid\u003e`.\n- With that level of access, the attacker typically has broader compromise paths.\n\nWe still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.\n\n### Remediation / Behavior Changes\nGoal: preserve usability while reducing footguns.\n- Raw email allowlists remain supported.\n- `users/\u003cemail\u003e` is deprecated and treated as a **user id**, not as an email allowlist.\n- Documentation recommends `users/\u003cid\u003e` when strict immutable binding is required.\n\n### Fix Commit(s)\n- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)\n\nThanks @vincentkoc for reporting.",
  "id": "BREW-openclaw-cli-GHSA-chm2-m3w2-wcxm",
  "modified": "2026-09-17T17:24:13Z",
  "published": "2026-08-13T17:21:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-chm2-m3w2-wcxm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/16243"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c8424bf29a921e25663b29f308640b3d91a49432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch",
  "upstream": [
    "GHSA-chm2-m3w2-wcxm"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

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.


Loading…