GHSA-qvpf-j64c-jmhr: PraisonAI Slack app_mention bypasses configured user/channel authorization
PraisonAI Slack `app_mention` bypasses configured user/channel authorizationSummaryPraisonAI's Slack bot applies its configured `allowed_users`,
`allowed_channels`, and unknown-user pairing policy in the normal Slack
`message` event handler, but not in the adjacent Slack `app_mention` event
handler.A Slack workspace user who can mention the bot in a channel where the Slack app
is present can trigger the configured PraisonAI agent even when:the sender is not in `BotConfig.allowed_users`;the channel is not in `BotConfig.allowed_channels`;`unknown_user_policy="deny"` is configured; andthe same event content is correctly dropped by the normal `message` handler.This is a sibling-handler guard-coverage issue. Slack documents
`app_mention` as a distinct event type rather than a `message.*` event, so
deployments subscribed to app mentions can route unauthorized sender input
around the guarded message path.Affected productRepository: `MervinPraison/PraisonAI`Package: `praisonai`Component: `src/praisonai/praisonai/bots/slack.py`Configuration component: `src/praisonai-agents/praisonaiagents/bots/config.py`Confirmed affected:Unaffected boundary control:`v3.10.24` does not contain `src/praisonai/praisonai/bots/slack.py`.Suggested affected range: `praisonai >= 3.11.0, <= 4.6.58`.Root causeThe guarded `message` handler converts the Slack event into a `BotMessage`,
then applies channel and sender policy before any agent call: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()`: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 PoVRun from the harness checkout: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:It then invokes the real registered SlackBot handlers with the same event
payloads.Observed `v4.6.58` result: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 behaviorPraisonAI'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`.ImpactAn 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 fixUse one shared authorization preflight for every Slack ingress path before
firing message hooks or invoking agents.Concrete patch direction:Convert `app_mention` events through `_convert_event_to_message()` or a
dedicated equivalent that preserves sender, channel, text, timestamp, and
thread metadata.Set `bot_message._channel_type = "slack"` for `app_mention`.Run the same channel check, user allowlist check, and
`UnknownUserHandler.handle(...)` policy used by `handle_message`.Only then strip the bot mention and invoke `_session.chat(...)`.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.
CVSS v3.1: 8.3