CVE-2026-26327 in OpenClaw
Summary
by MITRE • 02/20/2026
OpenClaw is a personal AI assistant. Discovery beacons (Bonjour/mDNS and DNS-SD) include TXT records such as `lanHost`, `tailnetDns`, `gatewayPort`, and `gatewayTlsSha256`. TXT records are unauthenticated. Prior to version 2026.2.14, some clients treated TXT values as authoritative routing/pinning inputs. iOS and macOS used TXT-provided host hints (`lanHost`/`tailnetDns`) and ports (`gatewayPort`) to build the connection URL. iOS and Android allowed the discovery-provided TLS fingerprint (`gatewayTlsSha256`) to override a previously stored TLS pin. On a shared/untrusted LAN, an attacker could advertise a rogue `_openclaw-gw._tcp` service. This could cause a client to connect to an attacker-controlled endpoint and/or accept an attacker certificate, potentially exfiltrating Gateway credentials (`auth.token` / `auth.password`) during connection. As of time of publication, the iOS and Android apps are alpha/not broadly shipped (no public App Store / Play Store release). Practical impact is primarily limited to developers/testers running those builds, plus any other shipped clients relying on discovery on a shared/untrusted LAN. Version 2026.2.14 fixes the issue. Clients now prefer the resolved service endpoint (SRV + A/AAAA) over TXT-provided routing hints. Discovery-provided fingerprints no longer override stored TLS pins. In iOS/Android, first-time TLS pins require explicit user confirmation (fingerprint shown; no silent TOFU) and discovery-based direct connects are TLS-only. In Android, hostname verification is no longer globally disabled (only bypassed when pinning).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/23/2026
The vulnerability described in CVE-2026-26327 affects OpenClaw, a personal AI assistant application that utilizes service discovery mechanisms to establish connections with gateway services. The issue stems from the improper handling of TXT records within Bonjour/mDNS and DNS-SD discovery protocols, which are inherently unauthenticated. These TXT records contain critical routing information including `lanHost`, `tailnetDns`, `gatewayPort`, and `gatewayTlsSha256` parameters that are meant to guide client applications in establishing secure connections to gateway endpoints. This vulnerability falls under CWE-295 which addresses improper certificate validation and CWE-347 which covers improper certificate validation in the context of secure communication protocols.
The technical flaw manifests in how client applications process discovery information from the network. Prior to version 2026.2.14, both iOS and Android clients would blindly trust TXT record values and use them as authoritative routing hints for establishing connections. This behavior creates a significant attack surface where malicious actors on a shared or untrusted local area network can advertise rogue `_openclaw-gw._tcp` services. The attackers can manipulate the `lanHost` and `tailnetDns` values to redirect clients to attacker-controlled endpoints while simultaneously providing malicious `gatewayPort` values that could route traffic through compromised infrastructure. Additionally, the `gatewayTlsSha256` value could override previously stored TLS certificates, effectively bypassing established security measures that were designed to prevent man-in-the-middle attacks.
The operational impact of this vulnerability extends beyond simple network redirection to potentially enable credential exfiltration and complete compromise of the gateway authentication system. When clients connect to attacker-controlled endpoints, they may unknowingly transmit sensitive information including `auth.token` and `auth.password` credentials during the connection process. This represents a critical security failure that could allow attackers to gain unauthorized access to user accounts and potentially escalate privileges within the OpenClaw ecosystem. The vulnerability is particularly concerning because it operates at the network discovery layer, meaning that any device on the same LAN could exploit this weakness without requiring any special privileges or user interaction beyond the initial network discovery process.
The mitigation strategy implemented in version 2026.2.14 addresses the core issues by changing the priority order of discovery information processing. Clients now prefer resolved service endpoint information obtained through SRV and A/AAAA record resolution over TXT-provided routing hints, effectively breaking the attack vector that relied on TXT record manipulation. The fix also ensures that discovery-provided TLS fingerprints no longer override stored TLS pins, maintaining the security posture established through certificate pinning. In iOS and Android implementations, the security model was significantly strengthened by requiring explicit user confirmation for first-time TLS pins, displaying fingerprint information for verification, and eliminating silent trust-on-first-use (TOFU) behavior. Additionally, Android's security model was enhanced by removing global hostname verification bypasses, limiting such exceptions only to specific pinning scenarios rather than disabling verification entirely.
The vulnerability demonstrates how seemingly minor implementation details in service discovery protocols can create significant security risks when combined with improper trust models in client applications. It highlights the importance of following established security best practices such as those outlined in the OWASP Mobile Top 10 and NIST guidelines for secure mobile application development. The issue also aligns with ATT&CK technique T1566 which covers Phishing via Service Discovery, where attackers exploit legitimate discovery mechanisms to gain unauthorized access. The fix implemented represents a proper security hardening approach that emphasizes defense in depth, ensuring that multiple layers of security controls work together to prevent compromise even when individual components might be bypassed. This vulnerability serves as a reminder that network-level protocols must be treated with appropriate security considerations, particularly when they are used to make critical routing and authentication decisions in client applications.