OpenClaw Open Door: Bypassing Slack Authorization via Direct Messages

AI agents are the new sysadmins. We give them keys to our AWS environments, access to our production databases, and the ability to deploy code. OpenClaw is one such autonomous agent, designed to live inside your chat apps like Slack and do your bidding. Naturally, you'd expect a digital entity with that much power to be picky about who it takes orders from.

OpenClaw implements an allowFrom list—a VIP club of users allowed to invoke slash commands. But it also has a configuration setting called channels.slack.dm.policy. If you set this to open, the intention is innocent enough: allow random users to chat with the bot, ask it questions, or get help.

However, in versions prior to 2026.2.14, the developers made a classic security blunder. They assumed that if a door is unlocked for visitors, it should also lead directly to the bank vault. This vulnerability is a story about how a single boolean flag turned a chatty bot into a confused deputy, willing to execute administrative commands for anyone who bothered to slide into its DMs.

The vulnerability lies in src/slack/monitor/slash.ts, specifically within the logic that handles incoming slash commands from Slack. Access control in chat bots usually follows a two-step verification: Authentication (who are you?) and Authorization (are you on the list?).

OpenClaw's logic for Direct Messages (DMs) short-circuited this process. When the bot received a command, it checked the context. If the message came from a public channel, it correctly checked the user against the allowFrom list. But if the message came from a DM, and the policy was set to open, the code explicitly set the authorization flag to true.

Here is the logic flaw in plain English: "If the user is allowed to DM me, they are allowed to control me." This ignores the reality that slash commands (like /openclaw-config or /restart) are fundamentally different from conversational inputs. The code failed to differentiate between permission to speak and permission to execute.

Let's look at the "smoking gun" in the codebase. This snippet is from src/slack/monitor/slash.ts before the patch. Notice how commandAuthorized is handled inside the DM check.

// src/slack/monitor/slash.ts (Vulnerable)
 
// 1. Default to true (already a bad smell, secure by default!)
let commandAuthorized = true;
 
if (isDirectMessage) {
  // ... code to check policies ...
  if (ctx.dmPolicy === "open") {
    // 2. The Fatal Flaw
    // If DMs are open, we blindly authorize the COMMAND.
    commandAuthorized = true;
  }
}

Because of this block, the subsequent checks (which would normally filter out users not in the allowFrom group) were rendered moot. The variable commandAuthorized was hard-set to true based solely on the transport medium (Direct Message) rather than the user's identity.

The fix in version 2026.2.14 (Commit f19eabee54c49e9a2e264b4965edf28a2f92e657) inverts the default and forces a lookup:

// src/slack/monitor/slash.ts (Patched)
 
// 1. Default to false
let commandAuthorized = false;
 
// ... inside the DM check ...
// 2. Even if DM policy is open, we specificially check the authorizers
commandAuthorized = resolveCommandAuthorizedFromAuthorizers({
  useAccessGroups: ctx.useAccessGroups,
  authorizers: [{ configured: effectiveAllowFromLower.length > 0, allowed: ownerAllowed }],
  modeWhenAccessGroupsOff: "configured",
});

By forcing the code to call resolveCommandAuthorizedFromAuthorizers, the patch ensures that the allowFrom list is respected regardless of whether the command comes from a public channel or a private DM.

Exploiting this vulnerability does not require complex memory corruption or packet manipulation. It requires a Slack account in the target workspace and the audacity to talk to the bot privately.

The Attack Scenario:

1. Reconnaissance: The attacker (perhaps a contractor or an intern with low-level Slack access) notices the OpenClaw bot in the workspace.
2. Testing the Waters: The attacker attempts to run a privileged command like /openclaw-config dump in a public channel (#general). The bot correctly responds: "You are not authorized to perform this action."
3. The Bypass: The attacker opens a Direct Message with the OpenClaw bot.
4. Execution: The attacker sends the same slash command /openclaw-config dump in the DM.
5. Success: Because channels.slack.dm.policy is set to open (a common config for friendly bots), the vulnerable code sees the DM context, skips the ACL check, and dumps the configuration—potentially revealing API keys, environment variables, or other sensitive data.

> [!NOTE] > This attack vector is particularly dangerous because slash commands are often used for administrative tasks: restarting services, changing configurations, or triggering deployments.

The CVSS score of 4.4 (Moderate) is deceptively low here. It relies on the metric Attack Complexity: High because the victim must explicitly configure dmPolicy: open. However, enabling DMs is a standard feature for conversational agents. If an administrator turns that feature on, they inadvertently dismantle their entire authorization model.

If OpenClaw is connected to critical infrastructure (e.g., it can trigger CI/CD pipelines or access cloud provider APIs), this vulnerability is effectively a Privilege Escalation exploit. An unprivileged user in the Slack workspace can perform actions as the bot. If the bot has 'God Mode' permissions, now the intern does too.

Furthermore, because the attack happens in a Direct Message, it is quieter than a public channel exploit. There are no witnesses in #general to see the intern executing admin commands, making detection harder without rigorous audit logs.

Remediation is straightforward: update the openclaw package immediately.

Remediation Steps:

1. Upgrade: Update your deployment to openclaw version 2026.2.14 or later.
2. Audit: Check your config.yaml or environment variables. If you use channels.slack.dm.policy: "open", assume that prior to the patch, any user could have executed commands.
3. Review Logs: If you have audit logs for command execution, look for privileged slash commands originating from users who should not have access, specifically within DMs.

If you cannot patch immediately, the workaround is to change the configuration:

channels:
  slack:
    dm:
      policy: "restricted" # or "disabled"

This will prevent the vulnerable code path from being triggered, though it also disables the ability for general users to chat with the bot in DMs.