Mar 29, 2026·6 min read·4 visits
A logic flaw in OpenClaw's Telegram event handling allows unauthorized actors to bypass DM pairing and alter bot session state by sending crafted callback queries directly to the bot.
OpenClaw versions up to 2026.3.24 suffer from an authorization bypass in the Telegram integration. The vulnerability allows unauthorized users to send inline button callbacks that mutate session state, circumventing the direct message pairing restrictions.
OpenClaw provides a Telegram integration that allows users to interact with AI agents. A core security feature of this integration is "DM Pairing", which restricts direct message interactions strictly to the authorized owner. The system processes incoming Telegram events, including text messages and inline button callbacks (callback_query events).
These callbacks trigger specific internal actions, such as changing the active language model or modifying agent configurations. An authorization bypass exists in versions up to 2026.3.24, tracked as GHSA-j4c9-w69r-cw33. The application fails to strictly enforce DM pairing restrictions for callback_query events when specific configuration flags are present.
This flaw allows an unauthorized user interacting with the bot to trigger state-mutating callbacks. The vulnerability is classified under CWE-285 (Improper Authorization) and CWE-863 (Incorrect Authorization). It carries a CVSS 4.0 score of 8.7 due to the high impact on system integrity and availability without requiring user interaction or elevated privileges.
The vulnerability resides in the Telegram event handling logic within extensions/telegram/src/bot-handlers.runtime.ts. When processing a callback_query event, the system determines the appropriate authorization gate by assigning an authorizationMode. This mode dictates whether the event sender must be strictly verified against an allowlist or if the event falls under a broader scope.
The logic evaluating the authorizationMode relied solely on the execApprovalButtonsEnabled and inlineButtonsScope configuration flags. It omitted contextual information regarding the chat type, specifically whether the interaction occurred in a group chat or a private direct message. In scenarios where execApprovalButtonsEnabled was true or inlineButtonsScope was set to a value other than allowlist, the system defaulted to the callback-scope authorization mode.
The callback-scope mode assumes the event originates from a shared context where any participant can interact with the buttons. In a private DM context, this default behavior bypassed the strict ownership checks required by the DM pairing policy. An attacker sending a callback query directly to the bot's DM interface would have their request processed under this permissive scope.
The pre-patch logic in bot-handlers.runtime.ts evaluated the authorization mode using a flawed ternary operator. The code failed to differentiate between group contexts and direct messages. The configuration flags heavily influenced the outcome, regardless of the chat's privacy context.
const authorizationMode: TelegramEventAuthorizationMode =
!execApprovalButtonsEnabled && inlineButtonsScope === "allowlist"
? "callback-allowlist"
: "callback-scope";This implementation routed DM callbacks to callback-scope unless explicit configuration prerequisites were met. The fix, introduced in commit 269282ac69ab6030d5f30d04822668f607f13065, corrects this by evaluating the isGroup boolean directly within the ternary condition. The patch ensures the chat context is the primary determinant for the authorization mode.
const authorizationMode: TelegramEventAuthorizationMode =
!isGroup || (!execApprovalButtonsEnabled && inlineButtonsScope === "allowlist")
? "callback-allowlist"
: "callback-scope";By prepending !isGroup || to the condition, the logic forces all private direct message callbacks into the callback-allowlist mode. This mode successfully invokes the authorizeTelegramEventSender function, ensuring the sender matches the paired bot owner before processing the callback payload.
The attack requires the adversary to send a direct message to the targeted OpenClaw Telegram bot. The attacker does not need to be the paired owner of the bot instance. The attacker must simulate or trigger a callback_query event containing a valid command payload.
Telegram clients normally send these events when a user clicks an inline keyboard button. An attacker can construct a custom client or use the Telegram API to directly dispatch a callback_query to the bot with a predicted data payload. The application uses structured strings for callback data, making the payloads highly predictable.
For example, the attacker sends a callback with the data string mdl_sel_openai/gpt-5.4. The OpenClaw backend receives the event, evaluates the flawed authorization logic, and routes the event to the callback-scope handler. The handler processes the command without validating the sender ID against the DM pairing allowlist.
This process updates the bot's internal session state to use the specified model for subsequent interactions. The attacker can repeatedly dispatch different payloads to map out available callback endpoints and alter various configuration settings exposed through the inline button interface.
The vulnerability results in a complete compromise of the bot's session state integrity and configuration confidentiality. An unauthorized actor can force the bot to switch underlying language models, alter agent instructions, or modify operational parameters exposed via inline buttons. This state mutation occurs silently at the backend level.
This unauthorized state mutation affects the legitimate owner's interactions with the bot. Depending on the available callback actions, attackers can disrupt availability by selecting non-functional or rate-limited language models. They can also degrade confidentiality by enabling debug modes or logging features via callback toggles.
The attack vector requires network access to the Telegram API to send messages to the bot, but does not require authentication to the OpenClaw service itself. The CVSS vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L reflects the low complexity and high integrity impact of this vulnerability.
The primary remediation is upgrading the OpenClaw deployment to version 2026.3.26. This release contains the corrected authorization logic in the Telegram extension. Administrators must restart the OpenClaw service after applying the update to ensure the new runtime handlers are active.
Administrators unable to immediately patch can mitigate the issue by strictly configuring the inlineButtonsScope setting. Setting inlineButtonsScope to allowlist and disabling execApprovalButtonsEnabled in the openclaw.json configuration file forces the pre-patch logic into the secure callback-allowlist mode.
Security teams should review Telegram bot logs for anomalous callback_query events. Events originating from a senderId that does not match the paired owner's Telegram ID indicate attempted or successful exploitation. A baseline of known authorized IDs should be established to facilitate anomaly detection.
Ensure that the dmPolicy parameter is explicitly set to pairing across all active bot configurations. Regular audits of the openclaw.json configuration file will prevent accidental regression of the secure settings required for the temporary mitigation.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L| Product | Affected Versions | Fixed Version |
|---|---|---|
openclaw OpenClaw | <= 2026.3.24 | 2026.3.26 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-285, CWE-863 |
| CVSS Score | 8.7 |
| Attack Vector | Network (via Telegram API) |
| Impact | High Integrity and Availability Compromise |
| Exploit Status | Proof of Concept Available |
| Vulnerability Class | Authorization Bypass |
The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.