Summary

Security fix: DISCORD_ALLOWED_ROLES is not guild-scoped, causing a cross-guild DM bypass.

The role allowlist implementation merged in #11608 (from #9873, authored by @0xyg3n) iterates every mutual guild the bot is in when resolving a user's roles. If a user holds a configured role in any server the bot is also in, they are authorized — including in DMs, where there is no guild context to anchor the check.

This violates the principle of least privilege expressed by the original feature request (#7871), where moderators wanted role-scoped authorization for their specific server, not cross-guild access to every Hermes-backed bot deployment they happen to share a guild with.

Severity

CVSS:3.1 / AV:N / AC:L / PR:L / UI:N / S:C / C:H / I:H / A:N — Base score 8.1 (High)

• Network (N): exploitable over Discord
• Low attack complexity (L): just hold the role in any shared guild
• Privileges required: Low (L): attacker needs basic Discord access to the public guild
• User interaction: None (N)
• Scope changed (C): privilege obtained in one guild applies to a different guild/DM
• Confidentiality/Integrity: High: full bot access (chat, memory, tools, delegations)

Exploit scenario:

1. Operator runs Hermes with DISCORD_ALLOWED_ROLES=111222333 to authorize moderators of a private trusted server B.
2. The bot is also a member of a large public server A (e.g. a community / support server).
3. An attacker in server A obtains role ID 111222333 (easily done if the role is anything non-trivially gated, or through a role ID collision they discover).
4. The attacker DMs the bot. The allowlist iterates self._client.guilds, finds the role in server A, and authorizes the DM.
5. The attacker now has authorized access to the bot and can exercise any capability it exposes (tool calls, memory, file access, LLM calls billed to the operator, cross-plugin side effects).

The same cross-guild leakage applies to guild messages: a user with the allowed role in one mutual guild can speak authorized in a channel of a different mutual guild if that second guild has no allowlist of its own beyond DISCORD_ALLOWED_ROLES.

Root cause

gateway/platforms/discord.py :: _is_allowed_user (as merged in #11608):

# Fallback: scan mutual guilds for member's roles
if self._client is not None:
    ...
    for guild in self._client.guilds:   # <-- cross-guild scan
        m = guild.get_member(uid_int)
        if m is None:
            continue
        m_roles = getattr(m, "roles", None) or []
        if any(getattr(r, "id", None) in allowed_roles for r in m_roles):
            return True

Two design flaws:

1. No origin-guild argument. _is_allowed_user(user_id, author=None) has no way to know where the message came from, so it cannot scope role checks to that guild.
2. DM path silently reuses the mutual-guild scan. DMs have message.guild is None, but the fallback iterates all of self._client.guilds, which is exactly the cross-guild leak.

Fix

1. Extend the signature to _is_allowed_user(user_id, author=None, *, guild=None, is_dm=False).
2. Guild messages: role check is restricted to guild only. Author-object .roles are only trusted if author.guild.id == guild.id. Fallback resolves the Member in guild.get_member(...) — never in other mutual guilds.
3. DMs: role-based auth is disabled by default. Operators who deliberately want role-based DM access can opt in via DISCORD_DM_ROLE_AUTH_GUILD=<guild_id>, which restricts the role lookup to a single explicitly-trusted guild.
4. Call sites (on_message, voice listen loop) updated to pass guild + is_dm.

Backwards compatibility

• DISCORD_ALLOWED_USERS unchanged — still authorizes in both DMs and guild channels.
• Empty allowlists still allow everyone (unchanged).
• Role-based auth on guild messages where the operator has the role in that same guild continues to work (the intended use case in Support DISCORD_ALLOWED_ROLES for role-based access control #7871).
• Role-based auth on DMs now requires the new DISCORD_DM_ROLE_AUTH_GUILD opt-in. This is a behavior change but a security-positive one: deployments that relied on the cross-guild path were exposed to the bypass.

Tests

9 new regression guards in tests/gateway/test_discord_roles_dm_scope.py:

• test_dm_rejects_role_held_in_other_guild — exploit path MUST reject
• test_dm_role_auth_requires_explicit_guild_optin — opt-in works
• test_dm_role_auth_optin_rejects_when_not_member — opt-in scope is correct
• test_guild_message_role_check_scoped_to_originating_guild — cross-guild guild-message bypass rejected
• test_guild_message_role_check_allows_when_role_in_same_guild — positive path
• test_guild_message_rejects_author_roles_from_different_guild — cached Member from wrong guild not trusted
• test_user_id_allowlist_works_in_dm — backwards compat
• test_user_id_allowlist_works_in_guild — backwards compat
• test_empty_allowlists_allow_everyone — backwards compat

All 47 Discord-auth tests pass (new + existing test_discord_bot_auth_bypass.py, test_unauthorized_dm_behavior.py, test_discord_allowed_mentions.py). Zero regressions.

References

• Original feature request: Support DISCORD_ALLOWED_ROLES for role-based access control #7871
• Initial implementation: feat(discord): DISCORD_ALLOWED_ROLES for role-based access control #11608 (merged from feat(discord): add DISCORD_ALLOWED_ROLES env var for role-based access control #9873, authored by @0xyg3n)
• Related prior auth-bypass fix pattern: test_discord_bot_auth_bypass.py (DISCORD_ALLOW_BOTS has no effect without also adding the bot to DISCORD_ALLOWED_USERS #4466)

Deployment guidance

Operators currently using DISCORD_ALLOWED_ROLES:

• If you only grant access in guild channels → no config change needed. The fix tightens semantics but preserves your use case.
• If you rely on role-based auth for DMs → add DISCORD_DM_ROLE_AUTH_GUILD=<your_trusted_guild_id> to restore DM authorization against that one guild.
• If you want the old cross-guild behavior (not recommended) → revert to DISCORD_ALLOWED_USERS with explicit user IDs.

cc @teknium1 — this fixes a security issue in the implementation you merged.