CVE-2026-28480: OpenClaw Auth Bypass Vulnerability

CVE-2026-28480 Overview

OpenClaw versions prior to 2026.2.14 contain an authorization bypass vulnerability in the Telegram integration component. The vulnerability stems from the allowlist matching mechanism accepting mutable Telegram usernames instead of immutable numeric sender IDs. This design flaw allows attackers to spoof identities by obtaining recycled usernames, effectively bypassing allowlist restrictions and interacting with bots as unauthorized senders.

Critical Impact

Attackers can bypass Telegram allowlist authorization controls by acquiring recycled usernames previously associated with authorized users, enabling unauthorized access to bot functionality.

Affected Products

• OpenClaw versions prior to 2026.2.14

Discovery Timeline

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

Technical Details for CVE-2026-28480

Vulnerability Analysis

This authorization bypass vulnerability (CWE-290: Authentication Bypass by Spoofing) exploits a fundamental weakness in how OpenClaw validates Telegram senders against its allowlist. The core issue lies in the authentication mechanism relying on Telegram usernames for identity verification rather than immutable numeric user IDs.

Telegram usernames are inherently mutable—users can change or release their usernames at any time, and released usernames become available for registration by other users after a period. When OpenClaw uses these mutable identifiers for allowlist authorization, it creates a window of opportunity for attackers to assume the identity of previously authorized users.

The impact includes unauthorized access to bot commands and functionality, potential data exfiltration through bot interactions, and the ability to perform actions on behalf of legitimate users within the OpenClaw ecosystem.

Root Cause

The root cause is the use of mutable Telegram usernames as authentication identifiers instead of immutable numeric sender IDs. The original implementation stored and compared usernames in both the allowFrom and groupAllowFrom configuration arrays, which could be spoofed through username recycling. The type definitions previously documented these fields as accepting "user ids or usernames" without enforcing the security requirement for numeric IDs only.

Attack Vector

The attack can be executed remotely over the network without any privileges or user interaction required. An attacker would:

1. Identify a target OpenClaw bot that uses Telegram username-based allowlisting
2. Discover or guess usernames that are likely on the allowlist (e.g., common admin usernames)
3. Monitor for when these usernames become available through Telegram's username recycling mechanism
4. Register the recycled username on a new or existing Telegram account
5. Interact with the OpenClaw bot, which validates the spoofed username against its allowlist

// Security patch in src/telegram/bot-access.ts - fix(telegram): require sender ids for allowlist auth
 
export type NormalizedAllowFrom = {
  entries: string[];
-  entriesLower: string[];
  hasWildcard: boolean;
  hasEntries: boolean;
+  invalidEntries: string[];
};

-export type AllowFromMatch = AllowlistMatch<"wildcard" | "id" | "username">;
+export type AllowFromMatch = AllowlistMatch<"wildcard" | "id">;

+const warnedInvalidEntries = new Set<string>();

+function warnInvalidAllowFromEntries(entries: string[]) {
+  if (process.env.VITEST || process.env.NODE_ENV === "test") {
+    return;
+  }
+  for (const entry of entries) {
+    if (warnedInvalidEntries.has(entry)) {
+      continue;
+    }
+    warnedInvalidEntries.add(entry);
+    console.warn(
+      [
+        "[telegram] Invalid allowFrom entry:",
+        JSON.stringify(entry),
+        "- allowFrom/groupAllowFrom authorization requires numeric Telegram sender IDs only.",
+        'If you had "@username" entries, re-run onboarding (it resolves @username to IDs) or replace them manually.',
+      ].join(" "),

Source: GitHub Commit Update

Detection Methods for CVE-2026-28480

Indicators of Compromise

• Unexpected bot interactions from users not previously authorized in your organization
• Configuration files containing @username entries in allowFrom or groupAllowFrom arrays instead of numeric IDs
• Log entries showing allowlist matches for usernames that were recently changed or recycled

Detection Strategies

• Review OpenClaw configuration files for non-numeric entries in allowFrom and groupAllowFrom fields
• Audit bot interaction logs for messages from sender IDs that don't match expected authorized users
• Implement monitoring for new console warnings containing "Invalid allowFrom entry" after upgrading to patched versions

Monitoring Recommendations

• Enable verbose logging for Telegram bot authentication events to track allowlist matching behavior
• Set up alerts for any authorization bypass attempts detected by the patched version's validation warnings
• Periodically review and validate that all allowlist entries contain only numeric Telegram user IDs

How to Mitigate CVE-2026-28480

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.14 or later immediately
• Review and update all allowFrom and groupAllowFrom configuration entries to use numeric Telegram user IDs instead of usernames
• Re-run the OpenClaw onboarding process which now automatically resolves @username entries to immutable numeric IDs

Patch Information

The security patches have been released and are available through the following commits:

• GitHub Commit Change - Updated type definitions to document numeric ID requirement
• GitHub Commit Update - Implemented sender ID validation with warnings for invalid entries

Additional details are available in the GitHub Security Advisory and VulnCheck Advisory on Openclaw.

Workarounds

• Manually convert all username entries to numeric Telegram user IDs in your configuration before patching
• Use Telegram's API or a Telegram client to look up the numeric user ID for each authorized user
• Temporarily disable Telegram integration if immediate patching is not possible

// Configuration example - Updated allowFrom configuration
// Before (vulnerable):
// allowFrom: ["@adminuser", "@trusteduser"]

// After (secure - use numeric Telegram user IDs):
// allowFrom: [123456789, 987654321]

// The onboarding wizard now prompts for proper configuration:
// message: "Telegram allowFrom (numeric sender id; @username resolves to id)"

Source: GitHub Commit Update