Summary

Discord component/modal interaction events were always dispatched with CommandAuthorized: true.

For guild interactions this incorrectly bypassed command authorization boundaries tied to allowFrom, channel users/roles, and commands.useAccessGroups, allowing non-authorized users to submit component/modal input that downstream command routing could treat as authorized.

This PR computes CommandAuthorized for component events using the same Discord authorizer model used by native command handling.

Change Type

• Security fix
• Regression test

Scope

• src/discord/monitor/agent-components.ts
  • Replace hardcoded CommandAuthorized: true with computed authorization for guild component events.
  • Reuse owner allowlist + member access restrictions + commands.useAccessGroups command-gating semantics.
• src/discord/monitor/monitor.test.ts
  • Add regression test covering guild modal submission by non-allowlisted user.

Security Impact

• Trust boundary crossed before fix:
  • Untrusted guild users could submit component/modal interactions that were flagged as command-authorized even when not in owner allowlists/access groups.
• Practical impact:
  • Component/modal field text can carry command-like payloads into downstream processing under an authorized command context.
• Worst case:
  • Unauthorized command surfaces (including privileged control/tool directives) execute under forged authorization state where commands.allowFrom is not explicitly set.

Repro + Verification

Deterministic repro (pre-fix)

1. Configure Discord with commands.useAccessGroups: true and allowFrom excluding a guild user.
2. Register an agent modal/component entry.
3. Have the non-allowlisted guild user submit the modal.
4. Observe dispatch context contains CommandAuthorized: true (incorrect).

Deterministic verification (post-fix)

• Added test:
  • src/discord/monitor/monitor.test.ts
  • does not mark guild modal events as command-authorized for non-allowlisted users
• Run:
  • pnpm exec vitest run src/discord/monitor/monitor.test.ts --maxWorkers=1
• Result:
  • All tests pass, including the new regression.

Evidence

Dedupe checks (no overlapping open auth fix found)

• Open PR search (discord component CommandAuthorized):
  • https://github.com/openclaw/openclaw/pulls?q=is%3Apr+is%3Aopen+discord+component+CommandAuthorized
• Open issue search (discord component CommandAuthorized):
  • https://github.com/openclaw/openclaw/issues?q=is%3Aissue+is%3Aopen+discord+component+CommandAuthorized
• Nearby component work reviewed (non-overlapping scope):
  • fix(discord): register select menu handlers (unique customId) #19882
  • [Feature]: Discord Components v2 Interaction Handling #21844
  • [Bug]: Discord Components v2: outbound component messages not mirrored to target session transcript #21649

Local failing->passing signal

• Before fix: new regression assertion fails (expected true to be false).
• After fix: src/discord/monitor/monitor.test.ts passes with 36/36 tests.

Human Verification

1. In a guild channel, create/trigger a modal component as a non-owner user not in allowlists.
2. Confirm interaction still processes as configured, but command-gated operations from this event are rejected.
3. Repeat with an allowlisted owner user and confirm command-gated behavior remains allowed.

Compatibility / Migration

• No config schema changes.
• No migration required.

Failure Recovery

• Safe rollback: revert this PR commit to restore previous behavior.
• Operational fallback: set explicit commands.allowFrom if immediate hard owner gating is required.

Risks and Mitigations

• Risk: tighter CommandAuthorized semantics may block previously (incorrectly) allowed command-like component payloads.
• Mitigation: logic aligns with existing Discord command authorizer semantics and is covered by a focused regression test.

Greptile Summary

This PR fixes a security vulnerability where Discord component/modal interactions were hardcoded with CommandAuthorized: true, bypassing authorization checks for guild interactions.

Key Changes:

• Introduced resolveComponentCommandAuthorized function in src/discord/monitor/agent-components.ts:731-780 that mirrors the authorization logic from native Discord commands
• For DM interactions, authorization remains true (line 740)
• For guild interactions, computes authorization using owner allowlists, member access restrictions, and commands.useAccessGroups settings
• Replaced hardcoded CommandAuthorized: true at line 893 with computed value
• Added regression test in src/discord/monitor/monitor.test.ts:394-424 verifying non-allowlisted users get CommandAuthorized: false

Authorization Logic:
The new function correctly replicates the authorization pattern from src/discord/monitor/native-command.ts:1410-1432, using the same resolveCommandAuthorizedFromAuthorizers utility with identical authorizer configuration.

Security Impact:
Before this fix, untrusted guild users could submit modal/component interactions that would be treated as command-authorized, potentially allowing execution of privileged operations when commands.allowFrom restrictions were configured.

Confidence Score: 5/5

• This PR is safe to merge - it fixes a legitimate security issue with proper testing and no breaking changes.
• The implementation correctly mirrors the authorization logic from native Discord commands, uses the same utility functions and patterns, includes focused regression test coverage, and has no side effects. The security fix is well-scoped and addresses the exact vulnerability described.
• No files require special attention

_{Last reviewed commit: f2cb7b5}