GHSA-chm2-m3w2-wcxm
OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
openclawnpmDescription
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.13clawdbot(npm):<= 2026.1.24-3
Details
Affected component:
extensions/googlechat/src/monitor.ts
The allowFrom checks accept:
- Immutable sender id (
users/<id>) - Raw email (
[email protected]) 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | openclaw | all versions | 2026.2.14 |
| 📦npm | clawdbot | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openclaw. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openclaw to 2026.2.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-chm2-m3w2-wcxm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-chm2-m3w2-wcxm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-chm2-m3w2-wcxm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-chm2-m3w2-wcxm in your dependencies?
O3 detects GHSA-chm2-m3w2-wcxm across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.