https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:41:02 +0000 https://db.gcve.eu/vuln/brew-openclaw-cli-ghsa-chm2-m3w2-wcxm <p><strong>Affected:</strong> Homebrew: openclaw-cli</p> <p>### Summary Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/&lt;id&gt;`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.</p> <p>### Affected Packages / Versions (As of 2026-02-14; based on latest published npm versions) - `openclaw` (npm): `&lt;= 2026.2.13` - `clawdbot` (npm): `&lt;= 2026.1.24-3`</p> <p>### Details Affected component: - `extensions/googlechat/src/monitor.ts`</p> <p>The `allowFrom` checks accept: - Immutable sender id (`users/&lt;id&gt;`) - Raw email (`alice@example.com`) for usability</p> <p>Historically, `users/&lt;email&gt;` 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.</p> <p>### Security Triage (2026-02-14) Severity: **Low**</p> <p>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/&lt;id&gt;`. - With that level of access, the attacker typically has broader compromise paths.</p> <p>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.</p> <p>### Remediation / Behavior Changes G…</p> <p><strong>Affected:</strong> Homebrew: openclaw-cli</p> <p>### Summary Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/&lt;id&gt;`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.</p> <p>### Affected Packages / Versions (As of 2026-02-14; based on latest published npm versions) - `openclaw` (npm): `&lt;= 2026.2.13` - `clawdbot` (npm): `&lt;= 2026.1.24-3`</p> <p>### Details Affected component: - `extensions/googlechat/src/monitor.ts`</p> <p>The `allowFrom` checks accept: - Immutable sender id (`users/&lt;id&gt;`) - Raw email (`alice@example.com`) for usability</p> <p>Historically, `users/&lt;email&gt;` 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.</p> <p>### Security Triage (2026-02-14) Severity: **Low**</p> <p>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/&lt;id&gt;`. - With that level of access, the attacker typically has broader compromise paths.</p> <p>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.</p> <p>### Remediation / Behavior Changes G…</p> https://db.gcve.eu/vuln/brew-openclaw-cli-ghsa-chm2-m3w2-wcxm