Five OpenClaw Flaws Let Attackers Hijack Trusted AI Agent Access Across Chat Platforms

Five newly reported OpenClaw vulnerabilities exposed a serious weakness in how AI agents decide who can issue trusted commands across messaging platforms such as Slack, Discord, Matrix, Zalo, and Microsoft Teams.

The flaws, described in an InfosecWriteups analysis, came from a repeated identity-matching mistake. Several OpenClaw channel integrations relied on mutable human-readable names during allowlist processing instead of requiring stable platform IDs.

This matters because OpenClaw agents can connect chat apps to sensitive workflows, developer tools, files, browser automation, internal systems, and command execution. If an attacker can impersonate a trusted sender, the attacker may be able to drive the agent from a chat channel that operators believed was restricted.

What OpenClaw is and why allowlists matter

OpenClaw is a self-hosted gateway that connects AI agents to messaging apps and channel plugins. The official OpenClaw documentation says the platform supports channels such as Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo, and others.

That design makes messaging apps the control surface for the agent. A user can send a message from a supported platform, and the OpenClaw gateway routes the request to an AI agent that may have access to tools, memory, local files, or system actions.

To keep this safe, many deployments use allowlists. These lists define which people, accounts, groups, or channels can talk to an agent. The problem appears when the allowlist trusts a name that a user can change instead of a stable ID that the platform assigns.

Trust item	Safe use	Risky use
Stable user ID	Matches an immutable platform identity	Lower risk when verified correctly
Display name	Useful for showing a friendly name	Unsafe for authorization because users can change it
Username or handle	Useful for discovery and convenience	Can be renamed, recycled, reassigned, or spoofed on some platforms
Group name	Useful for operator readability	Can collide with another group using the same name

The same bug pattern returned after an earlier Telegram fix

The root issue was not new. OpenClaw previously patched a Telegram allowlist issue under GHSA-mj5r-hh7j-4gxf. That advisory said Telegram allowlist authorization could match mutable or recyclable usernames instead of immutable numeric sender IDs.

The Telegram fix rejected username-based allowlist principals and required numeric Telegram sender IDs. It also added a warning for legacy configurations that still contained non-numeric Telegram allowlist entries.

The newer research shows why patching one adapter did not solve the larger class of bugs. The same identity-binding mistake appeared across five other channel extensions because each integration handled allowlist resolution separately.

How the OpenClaw identity bypass worked

The reported flaws centered on startup or initialization logic. At runtime, a channel integration may check a stable user ID. But during initialization, the system could resolve allowlist entries by looking up display names, usernames, or other mutable fields.

If an attacker changed their display name to match an allowlisted user before the service restarted, the integration could bind the attacker’s stable ID into the trusted allowlist. After that, the attacker could interact with the agent as if they were the approved user.

The issue is especially serious because OpenClaw’s own security guidance warns that high-risk tools such as exec, browser, web_fetch, and web_search should be limited to trusted agents or explicit allowlists. If an allowlist can be bypassed, those downstream tools may become reachable by the wrong sender.

Channel area	Reported weakness	Security impact
Slack	Name-based identity resolution during allowlist setup	An attacker could be treated as a trusted sender if name matching succeeded
Discord	Mutable display identity used in trust decisions	Unauthorized users could reach an agent through a trusted identity collision
Matrix	Allowlist matching could rely on mutable profile fields	A renamed account could receive access intended for another user
Zalo	Mutable group names or normalized names could satisfy allowlist entries	Messages from an unintended group could reach the agent
Microsoft Teams	Allowlist processing could mix readable names with stable identities	Trusted-agent access could shift to an unintended sender or route

Why this is more dangerous in AI agent environments

In a normal chat bot, a spoofed identity might expose messages or trigger limited actions. In an AI agent gateway, the consequences can be wider because the agent may connect to code, files, internal APIs, browser sessions, and automation tools.

OpenClaw’s security documentation tells operators to keep inbound direct messages locked down, use pairing or allowlists, avoid always-on bots in public rooms, treat links and attachments as hostile, and run sensitive tool execution in a sandbox.

Those controls still matter, but the incident shows that the identity layer must be correct first. A sandbox can reduce damage, but it cannot fix a trust decision that lets the wrong user become the agent’s trusted operator.

• An attacker could send commands to an agent from a renamed chat identity.
• The legitimate allowlisted user could lose access or share access unknowingly.
• The attacker could trigger tools that the operator intended only for trusted users.
• The agent could read files, query internal systems, send messages, or run workflows depending on deployment settings.
• The issue could become more severe when combined with prompt injection or permissive tool policies.

Automated analysis helped find the repeated flaw

The five findings came from agentgg, a static analysis workflow that turns earlier advisory patterns into targeted detectors. Instead of searching only for generic coding mistakes, the tool looked for the same OpenClaw-specific anti-pattern that had already caused problems.

The agentgg write-up says one detector flagged the allowlist identity issue across Slack, Discord, Matrix, Zalo, and Microsoft Teams, while other detectors returned no findings. That result helped focus the review on one recurring class of trust-boundary bugs.

This approach matters for fast-moving AI agent projects. Once maintainers fix a vulnerability in one adapter, they also need to search for the same bug shape in sibling modules, plugins, and channel implementations.

Public advisories show the broader pattern

OpenClaw has published a large number of security advisories in 2026. The project’s GitHub security advisories page lists issues across gateway handling, channel authorization, tool execution, webhook processing, sandboxing, and related surfaces.

Some advisories focus directly on the same kind of mistake. The Zalo advisory, for example, said allowlist authorization matched mutable group names by default rather than stable group identifiers.

A separate academic analysis of the OpenClaw framework also identified channel input as a major attack surface. The OpenClaw security analysis said the channel input interface includes allowlist evaluation and webhook verification across many supported messaging platforms, and it described mutable sender identity fields as a recurring root cause.

Weakness categories behind the flaws

The vulnerability class fits several common security weakness patterns. At a high level, the problem comes from using user-controlled or mutable values in an authorization decision.

The Zalo advisory maps the issue to CWE-807, which covers reliance on untrusted inputs in a security decision. It also maps to incorrect authorization because the product checks access but checks the wrong type of identity.

The Telegram advisory maps its issue to authentication bypass by spoofing and improper access control. These categories all point to the same operational lesson: display names, handles, and group names should help humans read logs, not decide who gets trusted access.

Weakness	What it means here	Safer design choice
Mutable identity	A display name or username can change after allowlist setup	Authorize by stable platform user ID
Identity rebinding	A trusted-looking name can become attached to a different account	Store and verify immutable identifiers
Inconsistent adapter logic	Each messaging plugin repeats its own identity handling	Use one central authorization library across channels
Unsafe startup resolution	The system resolves names into IDs during initialization	Require explicit ID-based configuration or fail closed

What OpenClaw operators should do

OpenClaw users should update to patched versions and review every channel configuration that relies on usernames, display names, email aliases, group names, or other readable identifiers.

Operators should prefer numeric or platform-native stable IDs wherever the channel supports them. They should also rerun configuration checks after updates because older allowlist entries may still exist in config files.

The official Telegram advisory gives a useful model: reject mutable allowlist principals, warn on legacy entries, and attempt best-effort conversion to stable IDs where possible.

• Update OpenClaw and all bundled channel plugins to the latest patched version.
• Audit Slack, Discord, Matrix, Zalo, Microsoft Teams, Telegram, and other channel allowlists.
• Replace display names, handles, aliases, and group names with stable platform IDs.
• Disable or tightly restrict high-risk tools for chat-driven agents.
• Require human confirmation for sensitive actions, especially shell execution and internal API access.
• Use sandboxing for agents that can read files, run commands, or browse internal resources.
• Review logs for unexpected sender IDs bound to previously trusted names.

Why this class of bug keeps returning

The repeated flaws show a common engineering problem in multi-channel products. Each platform has its own identity model, naming rules, group metadata, and API behavior. If each adapter implements authorization differently, the same mistake can return many times.

The OpenClaw security analysis describes this as a decentralized trust-boundary problem. The more places a project repeats security logic, the more chances it creates for one implementation to drift from the intended policy.

The practical fix is not only patching each bug. Projects need shared authorization primitives, strict ID-only matching, regression tests, configuration linting, and code scanning rules based on previous incidents.

AI agent trust boundaries need stronger defaults

AI agents change the impact of ordinary authorization bugs. A chat identity mismatch no longer means only that a bot received a message from the wrong user. It can mean that an attacker reached an automation layer connected to files, browsers, APIs, terminals, or internal workflows.

The official OpenClaw overview describes the gateway as the single source of truth for sessions, routing, and channel connections. That makes channel authentication and allowlist enforcement a central security boundary, not a convenience feature.

Security teams should treat agent access like privileged access. Readable names can appear in dashboards and audit reports, but they should not determine who gets to command an agent.

The safest pattern is strict identity binding from the first message onward. Stable IDs should enter the allowlist, startup logic should fail closed when it cannot resolve an identity safely, and name-based shortcuts should require explicit opt-in with clear warnings.

The OpenClaw advisory history shows why this matters. AI agent frameworks move quickly, but security decisions need consistent enforcement across every channel, plugin, and tool path.

In this case, the main lesson is straightforward. If a trusted AI agent can act on behalf of a user, the platform must prove the sender’s identity with stable IDs, not names that anyone can change.

That conclusion also matches CWE-807: security mechanisms should not rely on values that an untrusted actor can modify. In agent systems, that rule now applies directly to messaging names, group names, handles, aliases, and any field used to decide who can command the agent.

FAQ