CVE-2026-53857: 
OpenClaw (formerly Moltbot or Clawdbot) vulnerability analysis and mitigation

CVE-2026-53857 is a policy enforcement vulnerability in OpenClaw (npm package) where the Zalo allowFrom feature incorrectly binds to mutable display names rather than stable Zalo identifiers, enabling authentication bypass by spoofing. It affects all OpenClaw versions prior to 2026.5.3 (i.e., <= 2026.5.2). The vulnerability was first published on May 28, 2026, and disclosed publicly via GitHub Advisory GHSA-8c59-hr4w-qg69 on June 18, 2026. It carries a CVSS v4.0 base score of 8.6 (High) and a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Github Advisory).

The root cause is classified as CWE-290 (Authentication Bypass by Spoofing): OpenClaw's Zalo integration evaluates allowFrom policy entries by matching against mutable display metadata (i.e., a contact's changeable display name) rather than a stable, immutable Zalo identity identifier (Github Advisory). An authenticated attacker who is a Zalo friend or contact of the target Gateway can change their display name to match a value present in the operator's allowFrom policy, causing the system to incorrectly treat them as an authorized identity. Exploitation requires low privileges (an existing Zalo contact relationship), no user interaction, and that the affected Zalo feature is enabled and reachable in the deployment (Github Advisory). No public proof-of-concept code has been identified.

Successful exploitation allows an authenticated attacker to receive agent responses intended for a different Zalo identity, resulting in high confidentiality and integrity impact within the vulnerable system. An attacker can intercept communications and information not intended for them, and may be able to inject or manipulate responses directed at other identities. Availability is not impacted, and there is no known lateral movement to subsequent systems. Practical impact is configuration-dependent — deployments where lower-trust Zalo contacts can reach the affected policy path are most at risk (Github Advisory, Github Advisory).

1. Identify target deployment: Confirm the target OpenClaw instance is running a version <= 2026.5.2 with the Zalo integration enabled and an allowFrom policy configured.
2. Establish Zalo contact relationship: Ensure the attacker's Zalo account is already a friend or contact of the target Gateway's Zalo account (a prerequisite for the feature to be reachable).
3. Enumerate allowFrom policy values: Determine the display name(s) or patterns used in the operator's allowFrom policy entries — this may be inferred from social engineering, prior access, or observable behavior of the system.
4. Change display name: Modify the attacker's Zalo display name to exactly match a value present in the target's allowFrom policy.
5. Trigger agent interaction: Send a message or request through the Zalo channel to the OpenClaw Gateway, causing the policy engine to evaluate the allowFrom check against the spoofed display name.
6. Receive unauthorized responses: The Gateway incorrectly matches the attacker's identity to the policy entry and routes agent responses intended for the legitimate Zalo identity to the attacker, exposing confidential communications (Github Advisory).

• Logs: OpenClaw Gateway logs showing allowFrom policy matches for a Zalo contact whose display name recently changed; unexpected agent responses routed to a contact not previously seen in that policy path.
• Application Behavior: Agent responses delivered to a Zalo identity that does not correspond to the expected stable Zalo user ID; policy evaluation logs referencing display name fields rather than stable identifiers.
• Zalo Contact Activity: A Zalo contact with a recently modified display name that now matches a value in the allowFrom policy configuration; unusual message patterns from contacts whose display names changed shortly before the anomalous activity.

The primary remediation is to upgrade OpenClaw to version 2026.5.3 or later, which is the first stable patched release (Github Advisory). If immediate patching is not possible, operators should disable the Zalo contact feature with mutable display metadata, restrict friend/contact access to the Gateway, and configure allowFrom policies using stable Zalo identifiers rather than display names. As general hardening, keep channel and tool allowlists narrow, avoid sharing a single Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

The advisory was originally published by maintainer steipete on May 28, 2026, and credited reporter PhilipPhil for discovery (Github Advisory). A duplicate advisory (GHSA-w7m7-3xcf-mp48) was published and subsequently withdrawn on June 18, 2026, as it was identified as a duplicate of the canonical GHSA-8c59-hr4w-qg69 (Github Advisory). No significant broader media coverage or notable community commentary beyond the GitHub advisory ecosystem has been identified.