CVE-2026-56835: Praisonai PraisonAI Slack App_mention Bypasses Configured Vulnerability

HIGH
Advisory Identifier: GHSA-qvpf-j64c-jmhr
CVSS 8.3
CWE-862 CWE-863
Published
Advisory Summary

CVE-2026-56835 is a HIGH (CVSS 8.3) praisonai slack app_mention bypasses configured vulnerability (CWE-862: Missing Authorization) affecting Praisonai libraries in the PyPI ecosystem. The issue involves praisonai slack app_mention bypasses configured user/channel authorization. Remediation is available by upgrading affected packages to version 4.6.59.

CVE-2026-56835 at a Glance

CVE Identifier CVE-2026-56835
GHSA Identifier GHSA-qvpf-j64c-jmhr
Severity HIGH
CVSS v3.1 Base Score 8.3
CWE Classification CWE-862: Missing Authorization
Affected Product Praisonai
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 8.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability Low (A:L)

How to Fix CVE-2026-56835

To remediate this vulnerability, upgrade all affected Praisonai dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

praisonai fixed: 4.6.59
pip install praisonai>=4.6.59
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show praisonai

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-56835, inspect your installed packages using pip:

pip show praisonai

Analyze the terminal output to locate any version of Praisonai in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.6.59), your application is affected.

Note: The pip show praisonai command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-862: Missing Authorization, where the product does not perform an authorization check when an actor attempts to access a resource or perform an action. In Praisonai, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# PraisonAI Slack `app_mention` bypasses configured user/channel authorization ## Summary PraisonAI'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; and - the 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 product - Repository: `MervinPraison/PraisonAI` - Package: `praisonai` - Component: `src/praisonai/praisonai/bots/slack.py` - Configuration component: `src/praisonai-agents/praisonaiagents/bots/config.py` Confirmed affected: ```text v3.11.0 7f37d754a72511a71f7eeaaa8e9f367a5dc45fd8 v3.11.14 44b800df0eddf32dd5242f47da7513e4a3159d76 v3.12.0 51f95ad904a6616b35caede1cd74026ec8f7152c v4.4.5 9a3363c900fa3be3fce5483be7f6c1f418757ebb v4.4.6 90b00f9a25ee5c7ccf4b6ab3152700e1881f262d v4.4.12 7d0657632fc477673153ad116cecf692b454bfa3 v4.5.2 8ddbb4ee7152d3fa68fbaaf6e6c610ae03d938d3 v4.5.16 02a19776517cc76483fd58dcd6a5fdf8c2c45170 v4.5.28 16f93251766505a79f237a0f07f68a0ecb17e358 v4.5.112 bfe3d94bad6db92fc2927c2e3c081ae8303e209e v4.5.128 b4e3a8a84ade44ac3dd9102b792cdb4311a95937 v4.6.10 4b1b17b963cbd0625e41394a30168c95b26429b2 v4.6.33 dfbb8d78ec7e8dc7118bc722ab1b2524bc98ddab v4.6.34 e5928449f73f66cc8af1de61621aa974ab255133 v4.6.56 d3c4a2afadfbf3a3e172e460e607ba4efad263a6 v4.6.57 e90d92231853161ad931f3498da57651a9f8b528 v4.6.58 1ad58ca02975ff1398efeda694ea2ab78f20cf3e ``` Unaffected boundary control: ```text v3.10.24 de1734c29a50af18cf8c69e1d1d90e0f8e391aae ``` `v3.10.24` does not contain `src/praisonai/praisonai/bots/slack.py`. Suggested affected range: `praisonai >= 3.11.0, <= 4.6.58`. ## Root cause The guarded `message` handler converts the Slack event into a `BotMessage`, then applies channel and sender policy before any agent call: ```python @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()`: ```python @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: ```fish 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: ```python 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: ```json { "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.

CVE-2026-56835 Affected Praisonai Versions

1 component(s)
Fixed Versions:
4.6.59
Product / Package Ecosystem Affected Versions Fixed Version
praisonai
PyPI
≥ 3.11.0
< 4.6.59
4.6.59

References

Frequently Asked Questions

What is CVE-2026-56835?
CVE-2026-56835 is a security vulnerability in Praisonai involving PraisonAI Slack app_mention bypasses configured user/channel authorization under CWE-862: Missing Authorization.
Which Praisonai versions are affected?
Affected versions include releases prior to 4.6.59 across affected packages: praisonai.
What version fixes CVE-2026-56835?
Upgrading to 4.6.59 (or the latest patched release for your respective branch) resolves the vulnerability.
Is praisonai affected?
Yes, praisonai is affected in releases prior to 4.6.59. Upgrade your dependency to 4.6.59 or later.
What is the CVSS score of CVE-2026-56835?
CVE-2026-56835 has a CVSS v3.1 base score of 8.3 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L.
What CWE is associated with CVE-2026-56835?
CVE-2026-56835 is classified under CWE-862: Missing Authorization (The product does not perform an authorization check when an actor attempts to access a resource or perform an action.).
How can I check PyPI dependencies for CVE-2026-56835?
Run the dependency tree command: 'pip show praisonai'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-qvpf-j64c-jmhr",
  "modified" : "2026-07-20T21:23:29Z",
  "published" : "2026-06-18T13:52:47Z",
  "aliases" : [ "CVE-2026-56835" ],
  "summary" : "PraisonAI Slack app_mention bypasses configured user/channel authorization",
  "details" : "# PraisonAI Slack `app_mention` bypasses configured user/channel authorization\n\n## Summary\n\nPraisonAI's Slack bot applies its configured `allowed_users`,\n`allowed_channels`, and unknown-user pairing policy in the normal Slack\n`message` event handler, but not in the adjacent Slack `app_mention` event\nhandler.\n\nA Slack workspace user who can mention the bot in a channel where the Slack app\nis present can trigger the configured PraisonAI agent even when:\n\n- the sender is not in `BotConfig.allowed_users`;\n- the channel is not in `BotConfig.allowed_channels`;\n- `unknown_user_policy=\"deny\"` is configured; and\n- the same event content is correctly dropped by the normal `message` handler.\n\nThis is a sibling-handler guard-coverage issue. Slack documents\n`app_mention` as a distinct event type rather than a `message.*` event, so\ndeployments subscribed to app mentions can route unauthorized sender input\naround the guarded message path.\n\n## Affected product\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Component: `src/praisonai/praisonai/bots/slack.py`\n- Configuration component: `src/praisonai-agents/praisonaiagents/bots/config.py`\n\nConfirmed affected:\n\n```text\nv3.11.0  7f37d754a72511a71f7eeaaa8e9f367a5dc45fd8\nv3.11.14 44b800df0eddf32dd5242f47da7513e4a3159d76\nv3.12.0  51f95ad904a6616b35caede1cd74026ec8f7152c\nv4.4.5   9a3363c900fa3be3fce5483be7f6c1f418757ebb\nv4.4.6   90b00f9a25ee5c7ccf4b6ab3152700e1881f262d\nv4.4.12  7d0657632fc477673153ad116cecf692b454bfa3\nv4.5.2   8ddbb4ee7152d3fa68fbaaf6e6c610ae03d938d3\nv4.5.16  02a19776517cc76483fd58dcd6a5fdf8c2c45170\nv4.5.28  16f93251766505a79f237a0f07f68a0ecb17e358\nv4.5.112 bfe3d94bad6db92fc2927c2e3c081ae8303e209e\nv4.5.128 b4e3a8a84ade44ac3dd9102b792cdb4311a95937\nv4.6.10  4b1b17b963cbd0625e41394a30168c95b26429b2\nv4.6.33  dfbb8d78ec7e8dc7118bc722ab1b2524bc98ddab\nv4.6.34  e5928449f73f66cc8af1de61621aa974ab255133\nv4.6.56  d3c4a2afadfbf3a3e172e460e607ba4efad263a6\nv4.6.57  e90d92231853161ad931f3498da57651a9f8b528\nv4.6.58  1ad58ca02975ff1398efeda694ea2ab78f20cf3e\n```\n\nUnaffected boundary control:\n\n```text\nv3.10.24 de1734c29a50af18cf8c69e1d1d90e0f8e391aae\n```\n\n`v3.10.24` does not contain `src/praisonai/praisonai/bots/slack.py`.\n\nSuggested affected range: `praisonai >= 3.11.0, <= 4.6.58`.\n\n## Root cause\n\nThe guarded `message` handler converts the Slack event into a `BotMessage`,\nthen applies channel and sender policy before any agent call:\n\n```python\n@self._app.event(\"message\")\nasync def handle_message(event, say):\n    if event.get(\"bot_id\"):\n        return\n\n    bot_message = self._convert_event_to_message(event)\n    bot_message._channel_type = \"slack\"\n    self.fire_message_received(bot_message)\n\n    if not self.config.is_channel_allowed(\n        bot_message.channel.channel_id if bot_message.channel else \"\"\n    ):\n        return\n\n    user_id = bot_message.sender.user_id if bot_message.sender else \"\"\n    is_explicitly_allowed = (\n        bool(self.config.allowed_users) and self.config.is_user_allowed(user_id)\n    )\n    if not is_explicitly_allowed:\n        user_allowed = await UnknownUserHandler.handle(bot_message, self._bot_context)\n        if not user_allowed:\n            return\n```\n\nOnly after these checks does `handle_message` call the session manager and\nagent.\n\nThe adjacent `app_mention` handler strips the bot mention and directly invokes\nthe agent session. It never calls `is_channel_allowed()`,\n`is_user_allowed()`, or `UnknownUserHandler.handle()`:\n\n```python\n@self._app.event(\"app_mention\")\nasync def handle_mention(event, say):\n    if event.get(\"bot_id\"):\n        return\n\n    text = event.get(\"text\", \"\")\n    if self._bot_user:\n        text = text.replace(f\"<@{self._bot_user.user_id}>\", \"\").strip()\n\n    if self._agent:\n        user_id = event.get(\"user\", \"unknown\")\n        response = await self._session.chat(\n            self._agent, user_id, text,\n            chat_id=str(event.get(\"channel\", \"\")),\n            thread_id=event.get(\"thread_ts\", \"\") or \"\",\n            message_id=event.get(\"ts\", \"\"),\n            account=self._config.get(\"account\", \"default\"),\n        )\n```\n\nOlder affected releases use `self._agent.chat(text)` instead of\n`self._session.chat(...)`, but have the same policy gap: `message` checks\n`allowed_users` and `allowed_channels`; `app_mention` does not.\n\n## Local-only PoV\n\nRun from the harness checkout:\n\n```fish\nenv PYTHONPATH=\"artifacts/repos/praisonai-v4.6.58/src/praisonai:artifacts/repos/praisonai-v4.6.58/src/praisonai-agents\" \\\n  python3 submission-bundle/praisonai-prai-cand-017-slack-app-mention-authz-bypass/poc/pov_prai_cand_017_slack_app_mention_authz_bypass.py \\\n    --repo artifacts/repos/praisonai-v4.6.58 \\\n    --label v4.6.58\n```\n\nThe PoV mocks Slack Bolt and Slack SDK in-process. It does not connect to\nSlack, bind a network port, or require real tokens.\n\nThe PoV configures:\n\n```python\nBotConfig(\n    allowed_users=[\"U_ALLOWED\"],\n    allowed_channels=[\"C_ALLOWED\"],\n    unknown_user_policy=\"deny\",\n    mention_required=True,\n)\n```\n\nIt then invokes the real registered SlackBot handlers with the same event\npayloads.\n\nObserved `v4.6.58` result:\n\n```json\n{\n  \"affected\": true,\n  \"scenarios\": [\n    {\n      \"name\": \"blocked_user_blocked_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"blocked_user_allowed_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"allowed_user_blocked_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"allowed_user_allowed_channel_control\",\n      \"message_delta\": 1,\n      \"app_mention_delta\": 1\n    }\n  ]\n}\n```\n\nThe first three scenarios are authorization bypasses. The fourth is the\npositive control showing that an allowed user in an allowed channel can invoke\nthe agent through both paths.\n\nStored evidence:\n\n- `evidence/pov-v4.6.58.json`\n- `evidence/version-sweep.tsv`\n\n## Why this is not intended behavior\n\nPraisonAI's bot security documentation describes Slack user/channel allowlists\nand built-in DM filtering as Slack security features. It also describes\n`unknown_user_policy=\"deny\"` and pairing flows as production controls for\nunknown users.\n\nThe code itself confirms the intended boundary: the normal `message` handler\nperforms channel and sender authorization before any agent call. The vulnerable\n`app_mention` path is adjacent to that handler and routes the same sender,\nchannel, text, timestamp, and thread metadata to the agent without those checks.\n\nSlack's own documentation states that `app_mention` is a separate event type,\nnot a `message.*` event. A PraisonAI deployment that subscribes to\n`app_mention` therefore cannot rely on the normal `message` handler to apply\nthe same sender/channel policy.\n\nThe PoV includes a direct control: the same unauthorized payloads are dropped\nby the guarded `message` handler and accepted by `app_mention`.\n\n## Impact\n\nAn attacker needs the ability to cause Slack to deliver an `app_mention` event\nto the PraisonAI Slack app, such as by mentioning the bot in a channel where the\napp is present or by using Slack's invite-by-mention flow where applicable.\n\nWhen exploited, the attacker can submit arbitrary prompt text to the configured\nPraisonAI agent despite Slack bot allowlists or pairing policy. The downstream\nimpact depends on the deployed agent and tools. PraisonAI's default bot config\nauto-approves safe tools and includes web, memory, scheduling, file, planning,\nand skill tools, so unauthorized invocation can affect confidentiality and\nintegrity in real deployments.\n\nThis report does not claim compromise of Slack itself, bypass of Slack request\nsignature verification, or arbitrary code execution by default.\n\n## Suggested fix\n\nUse one shared authorization preflight for every Slack ingress path before\nfiring message hooks or invoking agents.\n\nConcrete patch direction:\n\n1. Convert `app_mention` events through `_convert_event_to_message()` or a\n   dedicated equivalent that preserves sender, channel, text, timestamp, and\n   thread metadata.\n2. Set `bot_message._channel_type = \"slack\"` for `app_mention`.\n3. Run the same channel check, user allowlist check, and\n   `UnknownUserHandler.handle(...)` policy used by `handle_message`.\n4. Only then strip the bot mention and invoke `_session.chat(...)`.\n5. Add regression tests for:\n   - blocked user plus blocked channel: `message` and `app_mention` both drop;\n   - blocked user in allowed channel: both drop;\n   - allowed user in blocked channel: both drop;\n   - allowed user in allowed channel: both invoke;\n   - `unknown_user_policy=\"pair\"`: `app_mention` starts the same pairing flow\n     instead of invoking the agent.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "praisonai"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.11.0"
      }, {
        "fixed" : "4.6.59"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.6.58"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qvpf-j64c-jmhr"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/MervinPraison/PraisonAI"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-862", "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-18T13:52:47Z",
    "nvd_published_at" : null
  }
}