Mar 29, 2026·6 min read·18 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.
A symbolic link directory traversal vulnerability was identified in go-git, a pure Go implementation of the Git specification. This vulnerability allows an attacker to construct a repository that, when checked out or processed, bypasses directory boundaries to write or overwrite arbitrary files on the host filesystem.
CVE-2026-71557 is a path traversal vulnerability in go-git, a pure-Go implementation of Git. In vulnerable versions, the filesystem-backed storage engine fails to validate reference names before mapping them to on-disk paths. An attacker hosting a malicious Git server can advertise references containing directory traversal sequences, such as 'refs/heads/../../config', to write or overwrite files outside the intended reference storage directory.
An information disclosure vulnerability in the Nuxt development server allows adjacent network attackers to retrieve the absolute project root directory and a persistent workspace UUID by querying the unprotected Chrome DevTools workspace endpoint. This occurs when the development server is bound to a network-reachable interface, allowing requests that bypass the header-based security verification checks.
A Regular Expression Denial of Service (ReDoS) vulnerability exists in SvelteKit's content negotiation header parser prior to version 2.70.2. An unauthenticated remote attacker can exploit this vulnerability by sending a crafted Accept header with highly repetitive malformed values. This triggers catastrophic backtracking on the single-threaded Node.js/Bun event loop, leading to CPU exhaustion and full denial of service.
An OS command injection vulnerability exists in the npm package loading component of the jsii-diff CLI tool within the AWS jsii framework. Prior to version 1.131.0, when parsing package specifiers prefixed with `npm:`, the tool concatenated user-controlled inputs directly into a shell execution string via child_process.exec. This allows attackers to execute arbitrary shell commands under the context of the running Node.js process.
CodeIgniter4 versions prior to v4.7.4 contain a protocol-spoofing vulnerability due to improper verification of upstream reverse proxy forwarding headers. Remote, unauthenticated attackers can inject headers like X-Forwarded-Proto to deceive the framework into identifying an insecure HTTP request as a secure HTTPS connection.