The Name Game: Hijacking OpenClaw Bots via Telegram Username Recycling

In the world of identity and access management (IAM), there is one golden rule: never trust a label that can be peeled off. Yet, developers consistently fall into the trap of using human-readable identifiers because, well, they are readable. It is much easier to write allowFrom: ['@TheBoss'] in a config file than it is to look up 182736459.

OpenClaw, a popular automation tool for Telegram, fell squarely into this trap. It is designed to be the glue between your chat ops and your infrastructure—running scripts, managing groups, and handling alerts. To do this, it needs to know who is boss.

Unfortunately, until version 2026.2.14, OpenClaw treated Telegram usernames as immutable truths. It assumed that if a message came from @sysadmin, it must be the system administrator. It failed to account for the chaotic marketplace that is the Telegram namespace, where identities are rented, sold, and discarded like fast fashion.

The vulnerability here is a classic case of Identity Rebinding. In Telegram, a @username is a pointer, not a principal. It is a public alias that points to an underlying, immutable numeric ID (e.g., 123456789).

The critical misunderstanding in the OpenClaw logic was equating the pointer with the principal. Usernames in Telegram are volatile properties. If I change my handle from @hacker to @retired_hacker, the handle @hacker is immediately released back into the public pool (or the Fragment auction block).

This created a race condition of sorts, but one measured in days or weeks rather than milliseconds. If an authorized user changed their handle—perhaps for privacy, or rebranding—and did not immediately update the bot's configuration, their old 'identity' became a master key lying on the sidewalk, waiting for anyone to pick it up. The code performed a string comparison on msg.from.username against the allowlist, completely ignoring the msg.from.id which creates the actual cryptographic binding to the account.

The fix required a shift from string-based auth to ID-based auth. The maintainers implemented a check to ensure that the configuration only contains numeric values. Let's look at the validation logic introduced in commit e3b432e481a96b8fd41b91273818e514074e05c3.

The Validator:

function isNumericTelegramUserId(raw: string): boolean {
  return /^\d+$/.test(raw);
}

This simple regex enforces that any entry in the allowFrom array must consist solely of digits. If you try to put @admin in your config after this patch, the system will yell at you (specifically, the openclaw doctor utility will flag it).

However, there is a subtle irony in this fix. While it solves the username spoofing, the regex /^\d+$/ strictly matches positive integers. In the Telegram API, Group IDs and Channel IDs are often negative integers (e.g., -100123456789). If a user attempts to allow a specific group to interact with the bot using this same logic path, this regex might inadvertently block valid group IDs depending on where exactly this helper is applied in the wider stack. It is a classic example of a security patch that might need a patch.

Exploiting this does not require buffer overflows or heap spraying. It requires patience and a bit of social engineering (or just luck). Here is how an attacker creates a verified session from thin air:

1. Reconnaissance: The attacker identifies an OpenClaw bot. Maybe they see it in a public group, or find a config.json committed to a public GitHub repo (a surprisingly common sin). They note the allowed username: @ProjectLead.

2. Surveillance: The attacker monitors @ProjectLead. They wait. Humans are fickle. Eventually, @ProjectLead might decide they want a cooler name, or they leave the company, or they simply delete their Telegram account in a rage-quit moment.

3. The Snatch: The moment @ProjectLead is free, the attacker registers it. Telegram allows this instantly for standard usernames.

4. Execution: The attacker opens a chat with the bot and types /restart_production. The bot checks msg.from.username, sees @ProjectLead, and happily executes the command. The attacker now controls the ops pipeline.

The remediation is twofold: code enforcement and configuration migration.

First, you must update the package. But updating the code isn't enough—you have to update your config file, or you will be locked out of your own bot. The maintainers provided a migration tool in commit 9e147f00b48e63e7be6964e0e2a97f2980854128.

Running openclaw doctor --fix triggers a script that takes your existing string-based usernames, queries the Telegram API (using getChat), and resolves them to their current numeric IDs. It then rewrites your config file.

> [!WARNING] > You must perform this migration while you still own the usernames! If you lose the username before running the migration, the tool will resolve the username to the new owner (the attacker), permanently hardcoding the attacker's ID into your safe-list.

For manual remediation, use a tool like @userinfobot to find your ID (e.g., 123456789) and replace all instances of @yourname in openclaw.json with that string of digits.