openclaw - 💡(How to fix) Fix Security: allowBots=true in group channels allows bot-to-bot relay without owner present — add requireOwnerPresent guard [1 participants]

Summary

When allowBots: true is set on a Slack channel config, the inbound message handler allows other bots to route messages to the agent — even if the authorized owner user is not a member of that channel. No human oversight is present to catch the relay.

Root Cause

In extensions/slack/src/monitor/message-handler/prepare.ts, the authorizeSlackInboundMessage function drops bot messages only when allowBots=false. When allowBots=true, bot messages proceed through authorization with the same path as human messages.

The ownerAuthorized check resolved at line ~431 is only used for control command gating (resolveControlCommandGate) — it does not gate general message routing. A bot whose sender ID is not in allowFrom can still successfully route a message as long as it clears channelUserAuthorized (channel-level users allowlist, if configured, or open by default).

This means: a rogue bot (or another agent) in a Slack channel with allowBots: true can relay messages to the OpenClaw agent indefinitely, with no human present to oversee it.

Reproduction

1. Configure a Slack channel with allowBots: true:

{
  "channels": {
    "slack": {
      "channels": {
        "C0XXXXXXX": {
          "allowBots": true
        }
      }
    }
  }
}

1. Ensure the authorized owner (from allowFrom) is not a member of that channel.
2. Have another bot post a message in that channel.
3. Observe: OpenClaw routes the message and responds, with no authorized human present.

Proposed Fix

Add a requireOwnerPresent config option (per-channel and/or global under channels.slack) that, when enabled, checks whether the authorized owner is a member of the channel before routing any message (bot or human).

Config surface (proposed):

{
  "channels": {
    "slack": {
      "channels": {
        "C0XXXXXXX": {
          "allowBots": true,
          "requireOwnerPresent": true
        }
      }
    }
  }
}

Implementation sketch:

• In resolveSlackConversationContext (or authorizeSlackInboundMessage), after resolving channelConfig, check if requireOwnerPresent is set.
• If set, call conversations.members to check whether any user from allowFrom is a member of the channel.
• Cache the result per channel (TTL ~60s) to avoid per-message API calls.
• If no authorized owner is present → drop with logVerbose('slack: drop message (owner not present in channel)') and return null.

Alternatively, consider making requireOwnerPresent: true the default when allowBots: true is set on a channel, to fail-safe rather than fail-open.

Related Types

Relevant field to add to SlackChannelConfigEntry in channel-config.ts:

requireOwnerPresent?: boolean;

And in SlackChannelConfigResolved:

requireOwnerPresent?: boolean;

Severity

Medium–High. An attacker controlling another bot in a shared Slack workspace could relay arbitrary prompts to an OpenClaw agent running with tool access (exec, file writes, etc.), with no authorized human in the loop to notice.

Notes

• The allowBots feature is legitimate and necessary (e.g. receiving notifications from CI bots, webhook bots). The fix should not disable it — only add the owner-presence guard as an opt-in (or opt-out-of-default) control.
• Member caching is important: conversations.members is rate-limited. A per-channel in-memory cache with a short TTL (30–60s) is sufficient.
• This was surfaced during a live deployment where the OpenClaw agent was in a Slack MPDM with another agent (Hermes). The owner was present in the group, but the vulnerability was visible: if the owner left, the bot relay would continue unguarded.