CVE-2026-40045: OpenClaw Information Disclosure Flaw

CVE-2026-40045 Overview

CVE-2026-40045 is a cleartext transmission vulnerability in OpenClaw versions prior to 2026.4.2. The application accepts non-loopback cleartext ws:// gateway endpoints and transmits stored gateway credentials over unencrypted connections. This flaw enables attackers on the adjacent network to forge discovery results or craft malicious setup codes that redirect clients to attacker-controlled endpoints, resulting in the disclosure of plaintext gateway credentials.

Critical Impact

Attackers can intercept gateway credentials transmitted in cleartext over unencrypted WebSocket connections, potentially gaining unauthorized access to OpenClaw gateway infrastructure.

Affected Products

• OpenClaw versions before 2026.4.2
• OpenClaw Android application with remote gateway endpoint functionality

Discovery Timeline

• 2026-04-21 - CVE-2026-40045 published to NVD
• 2026-04-21 - Last updated in NVD database

Technical Details for CVE-2026-40045

Vulnerability Analysis

This vulnerability falls under CWE-319 (Cleartext Transmission of Sensitive Information). The root issue lies in OpenClaw's failure to enforce TLS encryption for remote gateway endpoints. When users configure or discover gateway endpoints, the application accepts ws:// (unencrypted WebSocket) connections for non-loopback addresses. This means that gateway credentials stored in the application's secure preferences are transmitted over the network without encryption, exposing them to any attacker with adjacent network access.

The attack requires physical proximity or network access (adjacent network attack vector) and some user interaction, as the victim must be redirected to a malicious endpoint. However, once these conditions are met, the attacker gains access to highly confidential gateway credentials without requiring any authentication.

Root Cause

The vulnerability stems from insufficient validation of gateway endpoint protocols. Prior to the patch, the OpenClaw Android application did not enforce TLS requirements for remote (non-loopback) gateway connections. The NodeRuntime class lacked TLS fingerprint probing capabilities, and there was no security check to distinguish between local loopback addresses (which may legitimately use unencrypted connections for development) and remote addresses that require encryption.

Attack Vector

An attacker positioned on the same network segment can exploit this vulnerability through several methods:

1. Discovery Result Forgery: Intercept and modify gateway discovery responses to redirect victims to attacker-controlled endpoints
2. Malicious Setup Codes: Craft setup codes containing ws:// endpoints pointing to malicious servers
3. Man-in-the-Middle: Passively intercept credentials transmitted over unencrypted WebSocket connections

The security patch introduces a new GatewayHostSecurity.kt module that validates whether gateway hosts are loopback addresses:

+package ai.openclaw.app.gateway
+
+import android.os.Build
+import java.net.InetAddress
+import java.util.Locale
+
+internal fun isLoopbackGatewayHost(
+  rawHost: String?,
+  allowEmulatorBridgeAlias: Boolean = isAndroidEmulatorRuntime(),
+): Boolean {
+  var host =
+    rawHost
+      ?.trim()
+      ?.lowercase(Locale.US)
+      ?.trim('[', ']')
+      .orEmpty()
+  if (host.endsWith(".")) {
+    host = host.dropLast(1)
+  }
+  val zoneIndex = host.indexOf('%')
+  if (zoneIndex >= 0) {
+    host = host.substring(0, zoneIndex)
+  }
+  if (host.isEmpty()) return false
+  if (host == "localhost") return true
+  if (allowEmulatorBridgeAlias && host == "10.0.2.2") return true
+
+  parseIpv4Address(host)?.let { ipv4 ->
+    return ipv4.first() == 127.toByte()
+  }

Source: GitHub Commit Update

The NodeRuntime class was also updated to include TLS fingerprint probing:

 class NodeRuntime(
   context: Context,
   val prefs: SecurePrefs = SecurePrefs(context.applicationContext),
+  private val tlsFingerprintProbe: suspend (String, Int) -> String? = ::probeGatewayTlsFingerprint,
 ) {
   data class GatewayConnectAuth(
     val token: String?,

Source: GitHub Commit Update

Detection Methods for CVE-2026-40045

Indicators of Compromise

• Outbound WebSocket connections using ws:// protocol to non-loopback remote addresses from OpenClaw applications
• Unexpected gateway discovery responses from unknown network sources
• Gateway credential usage from unauthorized IP addresses or locations
• Network traffic containing plaintext credential data on WebSocket ports

Detection Strategies

• Monitor network traffic for unencrypted WebSocket (ws://) connections originating from OpenClaw application instances
• Implement network-level detection rules to alert on cleartext credential patterns in WebSocket traffic
• Audit gateway access logs for connections from unexpected sources following potential credential exposure
• Deploy intrusion detection signatures to identify forged gateway discovery packets

Monitoring Recommendations

• Enable logging of all gateway endpoint configuration changes in OpenClaw deployments
• Monitor for unusual patterns in gateway credential usage that may indicate credential theft
• Implement network segmentation to limit adjacent network attack exposure
• Use SentinelOne Singularity™ Platform to monitor for suspicious application network behavior and potential credential exfiltration

How to Mitigate CVE-2026-40045

Immediate Actions Required

• Upgrade OpenClaw to version 2026.4.2 or later immediately
• Audit all configured gateway endpoints and ensure they use wss:// (encrypted WebSocket) protocol
• Rotate any gateway credentials that may have been transmitted over unencrypted connections
• Review network logs for evidence of credential interception or malicious endpoint redirection

Patch Information

The vulnerability has been addressed in OpenClaw version 2026.4.2. The fix introduces mandatory TLS validation for all remote (non-loopback) gateway endpoints. The security patch is documented in GitHub Security Advisory GHSA-83f3-hh45-vfw9 and the specific code changes can be reviewed in commit a941a4f.

Workarounds

• If immediate upgrade is not possible, configure firewall rules to block outbound ws:// connections from OpenClaw applications to non-loopback addresses
• Use network segmentation to isolate OpenClaw clients from potentially hostile adjacent networks
• Manually verify all gateway endpoints use wss:// protocol before configuring them in the application
• Consider VPN or other encrypted tunnel solutions for environments where OpenClaw must operate on untrusted networks

# Network firewall rule to block unencrypted WebSocket traffic (example using iptables)
# Block outbound ws:// connections on common WebSocket ports
iptables -A OUTPUT -p tcp --dport 80 -m string --string "Upgrade: websocket" --algo bm -j DROP
iptables -A OUTPUT -p tcp --dport 8080 -m string --string "Upgrade: websocket" --algo bm -j DROP