Root cause

The guarded message handler converts the Slack event into a BotMessage, then applies channel and sender policy before any agent call:

@self._app.event("message")
async def handle_message(event, say):
    if event.get("bot_id"):
        return

    bot_message = self._convert_event_to_message(event)
    bot_message._channel_type = "slack"
    self.fire_message_received(bot_message)

    if not self.config.is_channel_allowed(
        bot_message.channel.channel_id if bot_message.channel else ""
    ):
        return

    user_id = bot_message.sender.user_id if bot_message.sender else ""
    is_explicitly_allowed = (
        bool(self.config.allowed_users) and self.config.is_user_allowed(user_id)
    )
    if not is_explicitly_allowed:
        user_allowed = await UnknownUserHandler.handle(bot_message, self._bot_context)
        if not user_allowed:
            return

Only after these checks does handle_message call the session manager and agent.

The adjacent app_mention handler strips the bot mention and directly invokes the agent session. It never calls is_channel_allowed(), is_user_allowed(), or UnknownUserHandler.handle():

@self._app.event("app_mention")
async def handle_mention(event, say):
    if event.get("bot_id"):
        return

    text = event.get("text", "")
    if self._bot_user:
        text = text.replace(f"<@{self._bot_user.user_id}>", "").strip()

    if self._agent:
        user_id = event.get("user", "unknown")
        response = await self._session.chat(
            self._agent, user_id, text,
            chat_id=str(event.get("channel", "")),
            thread_id=event.get("thread_ts", "") or "",
            message_id=event.get("ts", ""),
            account=self._config.get("account", "default"),
        )

Older affected releases use self._agent.chat(text) instead of self._session.chat(...), but have the same policy gap: message checks allowed_users and allowed_channels; app_mention does not.

Local-only PoV

Run from the harness checkout:

env PYTHONPATH="artifacts/repos/praisonai-v4.6.58/src/praisonai:artifacts/repos/praisonai-v4.6.58/src/praisonai-agents" \
  python3 submission-bundle/praisonai-prai-cand-017-slack-app-mention-authz-bypass/poc/pov_prai_cand_017_slack_app_mention_authz_bypass.py \
    --repo artifacts/repos/praisonai-v4.6.58 \
    --label v4.6.58

The PoV mocks Slack Bolt and Slack SDK in-process. It does not connect to Slack, bind a network port, or require real tokens.

The PoV configures:

BotConfig(
    allowed_users=["U_ALLOWED"],
    allowed_channels=["C_ALLOWED"],
    unknown_user_policy="deny",
    mention_required=True,
)

It then invokes the real registered SlackBot handlers with the same event payloads.

Observed v4.6.58 result:

{
  "affected": true,
  "scenarios": [
    {
      "name": "blocked_user_blocked_channel",
      "message_delta": 0,
      "app_mention_delta": 1
    },
    {
      "name": "blocked_user_allowed_channel",
      "message_delta": 0,
      "app_mention_delta": 1
    },
    {
      "name": "allowed_user_blocked_channel",
      "message_delta": 0,
      "app_mention_delta": 1
    },
    {
      "name": "allowed_user_allowed_channel_control",
      "message_delta": 1,
      "app_mention_delta": 1
    }
  ]
}

The first three scenarios are authorization bypasses. The fourth is the positive control showing that an allowed user in an allowed channel can invoke the agent through both paths.

Stored evidence:

• evidence/pov-v4.6.58.json
• evidence/version-sweep.tsv

Why this is not intended behavior

PraisonAI's bot security documentation describes Slack user/channel allowlists and built-in DM filtering as Slack security features. It also describes unknown_user_policy="deny" and pairing flows as production controls for unknown users.

The code itself confirms the intended boundary: the normal message handler performs channel and sender authorization before any agent call. The vulnerable app_mention path is adjacent to that handler and routes the same sender, channel, text, timestamp, and thread metadata to the agent without those checks.

Slack's own documentation states that app_mention is a separate event type, not a message.* event. A PraisonAI deployment that subscribes to app_mention therefore cannot rely on the normal message handler to apply the same sender/channel policy.

The PoV includes a direct control: the same unauthorized payloads are dropped by the guarded message handler and accepted by app_mention.

Impact

An attacker needs the ability to cause Slack to deliver an app_mention event to the PraisonAI Slack app, such as by mentioning the bot in a channel where the app is present or by using Slack's invite-by-mention flow where applicable.

When exploited, the attacker can submit arbitrary prompt text to the configured PraisonAI agent despite Slack bot allowlists or pairing policy. The downstream impact depends on the deployed agent and tools. PraisonAI's default bot config auto-approves safe tools and includes web, memory, scheduling, file, planning, and skill tools, so unauthorized invocation can affect confidentiality and integrity in real deployments.

This report does not claim compromise of Slack itself, bypass of Slack request signature verification, or arbitrary code execution by default.

Suggested fix

Use one shared authorization preflight for every Slack ingress path before firing message hooks or invoking agents.

Concrete patch direction:

1. Convert app_mention events through _convert_event_to_message() or a dedicated equivalent that preserves sender, channel, text, timestamp, and thread metadata.
2. Set bot_message._channel_type = "slack" for app_mention.
3. Run the same channel check, user allowlist check, and UnknownUserHandler.handle(...) policy used by handle_message.
4. Only then strip the bot mention and invoke _session.chat(...).
5. Add regression tests for:
   • blocked user plus blocked channel: message and app_mention both drop;
   • blocked user in allowed channel: both drop;
   • allowed user in blocked channel: both drop;
   • allowed user in allowed channel: both invoke;
   • unknown_user_policy="pair": app_mention starts the same pairing flow instead of invoking the agent.