+ "details": "### Summary\nGoogle 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.\n\n### Affected Packages / Versions\n(As of 2026-02-14; based on latest published npm versions)\n- `openclaw` (npm): `<= 2026.2.13`\n- `clawdbot` (npm): `<= 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/<id>`)\n- Raw email (`alice@example.com`) for usability\n\nHistorically, `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.\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/<id>`.\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/<email>` is deprecated and treated as a **user id**, not as an email allowlist.\n- Documentation recommends `users/<id>` when strict immutable binding is required.\n\n### Fix Commit(s)\n- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)\n\nThanks @vincentkoc for reporting.",
0 commit comments