CVE-2026-28454: OpenClaw Auth Bypass Vulnerability

CVE-2026-28454 Overview

OpenClaw versions prior to 2026.2.2 contain an authorization bypass vulnerability in the Telegram webhook mode functionality. The application fails to validate webhook secrets when Telegram webhook mode is enabled, allowing unauthenticated HTTP POST requests to the webhook endpoint that trust attacker-controlled JSON payloads. Remote attackers can forge Telegram updates by spoofing message.from.id and chat.id fields to bypass sender allowlists and execute privileged bot commands.

Critical Impact

Attackers can bypass authentication controls and execute privileged bot commands by forging Telegram webhook requests, potentially leading to unauthorized actions and data manipulation within systems utilizing the OpenClaw bot.

Affected Products

• OpenClaw versions prior to 2026.2.2
• Systems with Telegram webhook mode enabled
• Deployments exposing the webhook endpoint to untrusted networks

Discovery Timeline

• 2026-03-05 - CVE-2026-28454 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-28454

Vulnerability Analysis

This vulnerability is classified as Insufficient Verification of Data Authenticity (CWE-345), an authorization bypass flaw that affects OpenClaw's Telegram webhook integration. When Telegram webhook mode is enabled, the application exposes an HTTP endpoint designed to receive update notifications from Telegram's servers.

The core issue lies in the webhook endpoint's failure to validate the authenticity of incoming requests. Telegram provides a mechanism for webhook secret validation, where the bot token can be used to generate a cryptographic signature that Telegram includes in webhook requests. OpenClaw versions prior to 2026.2.2 do not implement this validation, meaning any HTTP POST request to the webhook endpoint is accepted and processed as if it came from Telegram.

This allows attackers to craft malicious JSON payloads that mimic legitimate Telegram update structures. By spoofing the message.from.id field (which identifies the sender) and the chat.id field (which identifies the conversation), attackers can impersonate authorized users who are on the bot's allowlist. Once the forged message passes the allowlist check, the attacker can execute any privileged bot command that the impersonated user would have access to.

Root Cause

The root cause is the absence of webhook secret validation in the Telegram webhook handler. Telegram recommends that bot developers verify incoming webhook requests using a secret token mechanism to ensure requests originate from Telegram's servers. OpenClaw's implementation accepts all incoming requests without cryptographic verification, trusting the content of the JSON payload without authenticating the source.

Attack Vector

The attack requires network access to the webhook endpoint, which must be exposed for Telegram webhook mode to function. An attacker can exploit this vulnerability by:

1. Discovering the webhook endpoint URL (often predictable or discoverable through reconnaissance)
2. Crafting an HTTP POST request with a JSON payload that mimics Telegram's update format
3. Setting the message.from.id field to match an authorized user ID from the allowlist
4. Setting the chat.id field to a valid chat identifier
5. Including a command payload in the message text to trigger privileged bot functionality

The vulnerability is exploited over the network and does not require prior authentication or user interaction. The attacker must know or guess a valid authorized user ID, but this information may be obtainable through other means.

The attack mechanism involves sending forged HTTP POST requests to the unprotected webhook endpoint. Since there is no secret validation, the server processes these requests as legitimate Telegram updates. For technical implementation details, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-28454

Indicators of Compromise

• Unusual HTTP POST requests to the Telegram webhook endpoint from IP addresses outside Telegram's infrastructure ranges
• High volume of webhook requests within short time periods from single sources
• Webhook requests containing message.from.id values that don't correlate with expected user activity patterns
• Bot command executions that don't match authenticated user behavior or timing

Detection Strategies

• Implement network monitoring to detect POST requests to the webhook endpoint originating from non-Telegram IP ranges
• Deploy web application firewall (WAF) rules to flag requests to the webhook path that lack proper Telegram headers
• Enable verbose logging on the OpenClaw application to capture all incoming webhook requests for forensic analysis
• Monitor bot command execution logs for commands executed by allowlisted users during unusual hours or from unexpected patterns

Monitoring Recommendations

• Configure alerting on the webhook endpoint for requests from IP addresses outside Telegram's published IP ranges (149.154.160.0/20 and 91.108.4.0/22)
• Implement rate limiting detection to identify potential brute-force attempts to guess authorized user IDs
• Cross-reference bot command executions with known user activity to detect anomalous privileged command usage

How to Mitigate CVE-2026-28454

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.2 or later immediately
• If immediate upgrade is not possible, disable Telegram webhook mode and switch to polling mode as a temporary measure
• Review bot command logs for suspicious activity that may indicate prior exploitation
• Audit current allowlist configurations and remove unnecessary privileged users

Patch Information

Security patches have been released addressing this vulnerability. Multiple commits have been made to remediate the issue:

• GitHub Commit Fix
• GitHub Commit Update
• GitHub Commit Change
• GitHub Commit Modification

For complete details, see the GitHub Security Advisory (GHSA-fhvm-j76f-qmjv) and VulnCheck Authorization Bypass Advisory.

Workarounds

• Switch from webhook mode to polling mode, which does not expose an HTTP endpoint and pulls updates directly from Telegram's API
• Implement network-level access controls to restrict webhook endpoint access to Telegram's official IP ranges only
• Deploy a reverse proxy in front of the webhook endpoint that validates the source IP against Telegram's infrastructure
• If using a web application firewall, configure rules to block requests to the webhook path from non-Telegram sources

# Configuration example - restrict webhook access to Telegram IP ranges using iptables
# Telegram IP ranges: 149.154.160.0/20 and 91.108.4.0/22
iptables -A INPUT -p tcp --dport 443 -s 149.154.160.0/20 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 91.108.4.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m string --string "/webhook" --algo bm -j DROP