OpenClaw AI Assistant Compromised via WhatsApp: Three Critical Vulnerabilities Allowed Credential Theft, Sandbox Escape, and Arbitrary Code Execution on Host
Security researchers have disclosed three serious vulnerabilities in OpenClaw that could allow attackers to steal credentials, escalate privileges, and execute arbitrary code on systems running the AI assistant. The flaws affected both home users and corporate deployments, highlighting risks associated with insufficient input validation and sandbox isolation in AI tooling.
Command Filtering Failures (CVSS 8.8)
Two of the vulnerabilities received a CVSS score of 8.8. They were caused by incomplete command filtering mechanisms that did not block all malicious inputs. As a result, an attacker could inject system commands into contexts where they should have been prohibited, enabling unauthorized actions ranging from data exfiltration to privilege escalation.
Sandbox Bypass via Directory Mounting (CVSS 8.4)
The third vulnerability, rated 8.4, allowed attackers to circumvent sandbox restrictions by mounting parent directories. Although OpenClaw blocked direct access to sensitive folders such as ~/.ssh, ~/.aws, and ~/.gnupg, it could still permit mounting of the entire /home directory. This effectively placed SSH keys, cloud tokens, and GPG secrets directly accessible to the attacker.
Further escalation was possible through the /var directory, which could grant access to the Docker socket and enable escape from the sandbox directly onto the host system. Researcher Chinmohan Nayak demonstrated that the attack could be initiated remotely via an external message sent through WhatsApp (owned by Meta, designated as extremist and banned in Russia) without requiring any prior foothold on the target machine.
Impact and Recommendations
In the worst-case scenario, an attacker could exfiltrate sensitive data, establish persistence, and execute arbitrary code on the victim’s machine. Developers addressed all three issues in OpenClaw 2026.6.6. Users are strongly advised to:
- Update to the latest version immediately
- Enable sandboxing for all secondary sessions
- Remove exec from the list of allowed tools
- Narrow the list of trusted communication channels to the minimum necessary
These measures significantly reduce the attack surface and help prevent similar exploitation attempts in the future.
Related articles
Rust Researcher Builds AI Pipeline to Test 900 Vulnerability Hypotheses Across Crates and Linux Kernel
Sergey Gordeychik developed the rust-in-peace research harness that combines multiple LLM agents, traditional SAST tools, and dynamic verification to hunt for memory-safety, logic, and API misuse issues in Rust code. The system generates independent hypotheses, attempts to refute them with separate agents, then validates survivors through fuzzing, protocol tests, or container execution. Starting from the Damn Vulnerable Rust Application, the pipeline was expanded to popular crates including x509-parser, h2, and lopdf, ultimately producing a Linux kernel patch. Experiments showed that three parallel analysis passes yielded 20 confirmed findings after triage, with nine appearing in all passes. The work also highlighted how models can produce convincing but false positives when context such as dependency checks or call order is missing. Gordeychik presented the approach at ZeroNights under the title Rust in Peace: How to Raise Your Own Pet Mythos.
Critical Zero-Day Vulnerability in FortiMail Allows Unauthenticated File Writes
Fortinet disclosed a critical zero-day vulnerability in its FortiMail email security product that is already being exploited in attacks. The flaw, tracked as CVE-2026-104286, affects the graphical user interface component and stems from improper sanitization of path traversal and NULL byte sequences. Attackers can craft malicious HTTP requests to write arbitrary files to the system without authentication. The vulnerability received a CVSS v3.1 base score of 9.8, classifying it as Critical. Fortinet discovered the issue internally but has also received reports of active exploitation. Planned patches include FortiMail 8.0.2, 7.6.7, and 7.4.9, while users on the 7.2 branch are advised to migrate to 7.4 or later.
Six Months After tun0 Leak: Which Android VPN Clients Fixed Server Address Exposure and Which Ignored It
A detailed investigation reveals that Android VPN clients suffer from two distinct server address leaks when split tunneling is enabled. The first leak, tied to an unprotected local SOCKS proxy on 127.0.0.1, was quickly mitigated by most Xray and sing-box based clients through random ports and passwords. The second, more persistent leak allows excluded applications to bind sockets directly to the tun0 interface and discover the VPN server IP without root or special permissions. Only TeapodStream and OlConnect implemented owner-UID checks using ConnectivityManager.getConnectionOwnerUid, yet both initially mishandled the INVALID_UID response returned for excluded apps. AmneziaVPN has unmerged pull requests that correctly reject unknown owners, while sing-box offers a manual package_name_regex rule. v2rayNG closed the report as not planned, and major clients including WireGuard for Android, Mullvad, Proton VPN and others have issued no statements.
Part 2: How Third-Party Developers Closed the tun0 Leak in AmneziaVPN on Android
Third-party contributors to AmneziaVPN have detailed their fix for a VPN tunnel bypass affecting excluded applications on Android. The vulnerability allows any app, even those disallowed from the VPN, to bind sockets directly to the tun0 interface using SO_BINDTODEVICE and thereby discover the VPN server address. The team implemented a packet filter inside the client that queries Android via ConnectivityManager.getConnectionOwnerUid to determine packet ownership and drops traffic from unknown UIDs. The solution was integrated into both the Xray and AmneziaWG traffic paths, with the AmneziaWG hook placed inside amneziawg-go after packet parsing. Testing with leak_probe.py showed zero successful bypass attempts out of six methods when the filter was active, compared to six out of six without it. The developers submitted three pull requests and released a side-loaded test build, while noting remaining limitations such as raw sockets and tethering scenarios.