CVE-2026-26327: OpenClaw Auth Bypass Vulnerability

CVE-2026-26327 Overview

CVE-2026-26327 is a high-severity vulnerability affecting OpenClaw, a personal AI assistant application. The vulnerability exists in the handling of discovery beacons (Bonjour/mDNS and DNS-SD) where TXT records containing sensitive routing information such as lanHost, tailnetDns, gatewayPort, and gatewayTlsSha256 are treated as authoritative inputs despite being unauthenticated. This insufficient verification of data authenticity (CWE-345) allows attackers on shared or untrusted local networks to spoof service discovery records and redirect client connections to malicious endpoints.

Critical Impact
Attackers on shared LANs can advertise rogue _openclaw-gw._tcp services, causing clients to connect to attacker-controlled endpoints, potentially exfiltrating Gateway credentials including auth.token and auth.password during the connection process.

Affected Products

OpenClaw iOS client (alpha builds prior to version 2026.2.14)
OpenClaw Android client (alpha builds prior to version 2026.2.14)
OpenClaw macOS client (prior to version 2026.2.14)

Discovery Timeline

2026-02-19 - CVE CVE-2026-26327 published to NVD
2026-02-19 - Last updated in NVD database

Technical Details for CVE-2026-26327

Vulnerability Analysis

The vulnerability stems from OpenClaw clients improperly trusting unauthenticated TXT records received via mDNS/DNS-SD service discovery. When clients on iOS and macOS received discovery beacons, they used TXT-provided host hints (lanHost/tailnetDns) and port values (gatewayPort) to construct connection URLs without proper validation. More critically, iOS and Android clients allowed discovery-provided TLS fingerprints (gatewayTlsSha256) to override previously stored TLS pins, effectively bypassing certificate pinning protections.

This design flaw enables man-in-the-middle attacks where an adversary on the same network segment can advertise a malicious service instance. The attack requires adjacent network access, making it particularly dangerous in shared network environments such as public WiFi, corporate guest networks, or co-working spaces.

Root Cause

The root cause is insufficient verification of data authenticity (CWE-345) in the service discovery implementation. The application architecture incorrectly assumed that mDNS TXT records were trustworthy sources for security-critical routing and certificate pinning information. This violated the security principle that network-provided data should never be implicitly trusted, especially when it affects connection security decisions.

Additionally, Android builds had hostname verification globally disabled, further weakening the TLS security posture and making certificate spoofing attacks more feasible.

Attack Vector

This vulnerability requires adjacent network access to exploit. An attacker must be positioned on the same local network as the victim to broadcast malicious mDNS/DNS-SD responses.

The attack follows this sequence: First, the attacker establishes presence on a shared network where potential victims use OpenClaw clients. They then advertise a rogue _openclaw-gw._tcp service with TXT records containing the attacker's endpoint information and a malicious TLS certificate fingerprint. When a vulnerable OpenClaw client performs service discovery, it receives the spoofed TXT records and uses them to build its connection URL. The client connects to the attacker-controlled endpoint and, due to the TLS pin override behavior, accepts the attacker's certificate. During the connection handshake, Gateway credentials (auth.token / auth.password) are transmitted to the malicious endpoint.

The practical impact is currently limited primarily to developers and testers running alpha builds, as the iOS and Android apps have not been publicly released on the App Store or Play Store. However, any shipped clients relying on discovery on shared or untrusted LANs remain at risk.

Detection Methods for CVE-2026-26327

Indicators of Compromise

Unexpected mDNS traffic advertising _openclaw-gw._tcp services from unknown or suspicious source IP addresses on the local network
Multiple competing service discovery responses for OpenClaw gateway services with differing TXT record values
Connection attempts from OpenClaw clients to unfamiliar IP addresses or non-standard ports that do not correspond to legitimate gateway infrastructure
TLS certificate warnings or unexpected certificate changes when connecting to OpenClaw services

Detection Strategies

Monitor network traffic for anomalous mDNS (port 5353) broadcasts advertising _openclaw-gw._tcp services, particularly from endpoints not part of your authorized infrastructure
Implement network segmentation and mDNS filtering at the network perimeter to prevent cross-segment service discovery spoofing
Deploy endpoint detection to identify OpenClaw client versions and flag installations running vulnerable alpha builds prior to 2026.2.14
Analyze authentication logs for credential usage patterns that suggest compromise, such as gateway tokens being used from unexpected IP addresses

Monitoring Recommendations

Enable detailed logging for mDNS service discovery events on endpoints running OpenClaw clients to establish baselines and detect anomalies
Implement network intrusion detection rules to alert on mDNS responses containing gatewayTlsSha256 TXT records from unauthorized hosts
Monitor for credential rotation patterns that may indicate compromised auth.token or auth.password values

How to Mitigate CVE-2026-26327

Immediate Actions Required

Upgrade all OpenClaw clients to version 2026.2.14 or later immediately
Rotate any Gateway credentials (auth.token and auth.password) that may have been exposed on untrusted networks
Avoid using OpenClaw on shared or untrusted networks until patching is complete
Review network security policies to restrict mDNS traffic where feasible

Patch Information

Version 2026.2.14 addresses this vulnerability through multiple security improvements. Clients now prefer the resolved service endpoint (SRV + A/AAAA records) over TXT-provided routing hints. Discovery-provided fingerprints no longer override stored TLS pins. In iOS and Android, first-time TLS pins require explicit user confirmation with the fingerprint displayed, eliminating silent Trust-On-First-Use (TOFU) behavior. Discovery-based direct connections are now TLS-only. In Android, hostname verification is no longer globally disabled and is only bypassed when pinning is explicitly configured.

For detailed patch information, see the GitHub Security Advisory GHSA-pv58-549p-qh99, the GitHub Release v2026.2.14, and the GitHub Commit Details.

Workarounds

Disable mDNS/Bonjour service discovery in OpenClaw client configuration and manually configure gateway endpoints where supported
Use VPN connections when operating on untrusted networks to isolate mDNS traffic from potential attackers
Implement network-level mDNS filtering using firewall rules to block unsolicited mDNS responses from unknown hosts on shared network segments
Restrict OpenClaw usage to trusted network environments until the patch can be applied

Network administrators can implement mDNS filtering at the network level to reduce exposure. For environments where automatic service discovery is not required, consider disabling mDNS entirely on client endpoints or restricting it to specific trusted interfaces.