GHSA-WPPH-CJGR-7C39: Identity Collision in OpenClaw Group Policy Resolver

OpenClaw is an AI assistant framework that integrates with various chat platforms (Slack, Telegram, Discord) to execute tools and manage workflows. A core security feature of OpenClaw is the Group Policy Resolver, specifically the toolsBySender configuration, which allows administrators to define tool execution permissions on a per-user basis. This system is designed to restrict dangerous capabilities—such as shell execution or file system access—to trusted administrators only.

However, a severe design flaw in the identity resolution logic created a "polymorphic" matching behavior. When resolving permissions, the system did not enforce strict typing on the identity keys provided in the configuration. This meant that a policy intended for a specific User ID (immutable) could inadvertently match a User Display Name (mutable). This ambiguity effectively collapsed the security boundary between trusted system identifiers and untrusted, user-controlled inputs.

The vulnerability is classified as an Identity Collision or Type Confusion issue. It allows a standard user with no special privileges to masquerade as an administrator simply by manipulating their profile attributes within the chat platform. Once the resolver matches the spoofed attribute to a privileged policy key, the attacker is granted the full scope of permissions associated with that key.

The vulnerability stems from the implementation of resolveToolsBySender in src/config/group-policy.ts. The resolver was designed to be flexible, allowing administrators to define policies using various identifiers (ID, username, phone number) without explicitly specifying the type of identifier being used. The matching logic iterated through available sender attributes and checked if any of them matched a key in the configuration map.

Technically, this was achieved via a "first-match" or "any-match" strategy. If the configuration contained a rule for the key "1001" (intended as a User ID), the resolver would check:

1. Does sender.id equal "1001"?
2. Does sender.username equal "1001"?
3. Does sender.displayName equal "1001"?

The critical failure was including sender.displayName in this unprivileged lookup pool. Unlike sender.id (which is assigned by the platform and immutable) or sender.e164 (which requires phone verification), the displayName is often arbitrarily mutable by the user in real-time. This created a direct path for privilege escalation: if an attacker knows the ID of an admin (often visible in API responses or logs), they can adopt that ID as their display name, satisfying the policy condition.

The remediation strategy involved deprecating untyped keys and enforcing strict namespaces for identity attributes. The fix was applied in src/config/group-policy.ts, introducing a parsing step that categorizes keys before matching.

Vulnerable Logic (Conceptual): The original code effectively flattened the identity check:

// Pseudo-code of the vulnerable logic
function isAuthorized(sender, configKey) {
  return sender.id === configKey ||
         sender.username === configKey ||
         sender.displayName === configKey; // <--- VULNERABLE
}

Patched Logic: The fix introduces typed buckets. Keys must now be prefixed (e.g., id:123, username:alice). Crucially, legacy untyped keys are now strictly bound to the id field only, removing the ambiguity.

// Updated logic in src/config/group-policy.ts
function parseSenderPolicyKey(rawKey: string): ParsedSenderPolicyKey | undefined {
  const typed = parseTypedSenderKey(trimmed);
  
  // Case 1: Explicitly typed key (e.g., "username:alice")
  if (typed) {
    return { kind: "typed", type: typed.type, key: normalizeTypedSenderKey(typed.value, typed.type) };
  }
  
  // Case 2: Legacy untyped key -> Force 'id' type
  // This prevents the key from matching 'name' or 'username'
  return { kind: "typed", type: "id", key: normalizeLegacySenderKey(trimmed) };
}

This change ensures that if an admin has a legacy config like "1001": { ... }, the system will only compare it against sender.id. A user changing their display name to "1001" will no longer trigger a match because displayName is never checked against keys resolved as type: "id".

To exploit this vulnerability, an attacker requires two pieces of information: the internal ID of a privileged user (the target) and the ability to change their own display name in the chat platform connected to OpenClaw.

Step-by-Step Attack Vector:

1. Reconnaissance: The attacker interacts with the bot or inspects message metadata to discover the internal ID of an administrator. In many platforms (like Telegram or Discord), User IDs are numeric and publicly retrievable.
2. Configuration: The attacker changes their display name (profile name) to match the target's ID exactly. For example, if the admin ID is 123456789, the attacker sets their name to 123456789.
3. Execution: The attacker issues a command to the OpenClaw bot that requires elevated privileges, such as /exec whoami or a file system read command.
4. Bypass: The vulnerable resolver iterates the attacker's attributes. It compares the attacker's new display name ("123456789") against the policy configuration. Finding a match for the key "123456789", the system incorrectly applies the admin's policy to the attacker's session.

> [!WARNING] > If the OpenClaw instance has the exec tool enabled for admins, this vulnerability results in immediate Remote Code Execution (RCE) on the host machine running the bot.

The impact of this vulnerability is critical due to the nature of AI assistants as operational bridges. OpenClaw is often deployed with access to internal APIs, databases, or the local shell to perform automation tasks.

Severity Metrics:

• CVSS v3.1: 9.9 (Critical) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
• Scope: Changed (S:C). The vulnerability allows a chat user to affect the confidentiality and integrity of the underlying host system, escaping the sandbox of the chat application.
• Privileges Required: Low. Any user who can send messages to the bot can attempt this attack.

Consequences: Successful exploitation allows unauthorized users to execute any tool enabled for the victim. In default configurations where admins have shell access, this leads to full system compromise. Even in restricted configurations, attackers could access sensitive data, manipulate workflows, or disrupt services by impersonating decision-makers.