Security researchers at Oasis Security have disclosed a critical vulnerability in the fast-growing self-hosted AI assistant OpenClaw. The flaw, dubbed ClawJacked, allowed a malicious website to silently connect to a user’s local OpenClaw instance, brute-force the administrator password, and seize full control. The issue is fixed in version 2026.2.26, released on 26 February, and users are strongly urged to update immediately.
OpenClaw and the security risks of self-hosted AI assistants
OpenClaw is an open-source, self-hosted AI assistant platform that lets autonomous AI agents send messages, execute commands, and orchestrate tasks across multiple services and devices. Since its launch in November 2025, it has rapidly gained popularity in the automation and developer communities, accumulating over 240,000 GitHub stars.
By design, such AI orchestration systems often hold wide-reaching access: credentials and API keys, corporate chat platforms, CI/CD pipelines, servers, and developer workstations. As a result, compromising OpenClaw is effectively equivalent to compromising the environment it automates. This makes the ClawJacked vulnerability particularly impactful for organizations relying on OpenClaw for daily operations.
Technical analysis of the ClawJacked localhost WebSocket exploit
A central component of OpenClaw’s architecture is its gateway service, which listens on localhost (127.0.0.1) and exposes a WebSocket interface. This pattern is common for local agent frameworks: by binding only to the loopback interface, the service appears to be isolated from the external network.
However, modern browser security models have a subtle but important property: the Same-Origin Policy (SOP) does not block WebSocket connections to localhost. While SOP restricts many cross-origin HTTP interactions, JavaScript running in any browser tab can usually attempt to open a ws://127.0.0.1:port connection if it can guess the port and protocol. This behavior has been documented in web security guidance, including materials from OWASP and major browser vendors.
Bypassing brute-force protections via 127.0.0.1
OpenClaw included basic anti–brute-force mechanisms for authentication, such as rate limits. Critically, the loopback address 127.0.0.1 was exempted from these protections in order to avoid hindering local CLI sessions and administrative tools. This design decision became the entry point for the ClawJacked attack.
A user visiting a malicious website could unwittingly trigger JavaScript that attempts to connect via WebSocket to the OpenClaw gateway on localhost. Once connected, the script could perform unrestricted, high-speed password guessing against the admin account, sending hundreds of login attempts per second without throttling, CAPTCHAs, or even meaningful logging.
According to the researchers, this allows an attacker to exhaust lists of the most common passwords in fractions of a second and large dictionary lists in minutes. Under these conditions, a typical “human” password, especially one reused and present in public breach corpora, stands little chance of withstanding the attack.
From password guessing to full environment compromise
Once the correct password is discovered, the attacker can register their own device as a trusted endpoint. By default, the OpenClaw gateway automatically approved pairings from localhost without requiring further user interaction, which simplifies the escalation of privileges for a successful attacker.
With administrative access, an adversary effectively gains complete control over the OpenClaw deployment: stored credentials, connected nodes, application logs, and task/message histories all become accessible. The attacker can then instruct AI agents to:
- search and exfiltrate sensitive information from prior conversations;
- retrieve files from connected machines;
- execute arbitrary shell commands on paired hosts.
In practice, this means ClawJacked can lead to full compromise of the user’s workstation and, in corporate environments, potentially significant portions of internal infrastructure—all triggered from a single malicious browser tab. Oasis Security has released a proof-of-concept (PoC) demonstrating the feasibility of this end-to-end attack chain.
OpenClaw patch 2026.2.26: how the vulnerability was fixed
Following a responsible disclosure process, Oasis Security provided the OpenClaw team with detailed technical findings and PoC code. The developers reacted quickly: a patch was designed, implemented, and shipped in under 24 hours as part of the 2026.2.26 release.
According to the published changelog, the update strengthens security checks around WebSocket connections and introduces new safeguards against abuse of loopback connections for brute-force and session hijacking. Local authentication is now more strictly enforced, and login attempt limits have been reworked to also apply to requests originating from 127.0.0.1, closing the loophole exploited by ClawJacked.
Security best practices for self-hosted AI and localhost services
All OpenClaw users should immediately upgrade to version 2026.2.26 or later, especially in business and enterprise environments where AI agents have access to critical systems.
To further reduce risk, the following measures are recommended:
- Change the administrator password to a long, unique passphrase and avoid passwords known to appear in previous data breaches.
- Restrict access to the OpenClaw gateway where possible—for example, via a host firewall, a dedicated browser profile used only for local tools, or an isolated administrative workstation.
- Monitor authentication logs and unusual connection attempts, including those from
localhost, rather than assuming loopback traffic is always safe. - Apply the principle of least privilege to AI agents: grant only the minimum keys, tokens, and system permissions they need to function.
The ClawJacked incident underscores a broader lesson for modern infrastructure: services bound to localhost are not inherently secure, especially when browsers and WebSockets are involved. As self-hosted AI assistants become more deeply integrated into operational workflows, organizations should regularly revisit their threat models, scrutinize localhost-exposed APIs, and treat AI orchestration platforms as high-value assets that demand continuous hardening and timely patching. Proactively building security into AI agent architectures today is far more effective than responding after the next “localhost-only” vulnerability has already been weaponized.
