BSidesSF 2026 - From Assistant to Assassin: Weaponizing An OpenClaw Vulnerability to... (Mav Levin)

Our next speaker uh is Mav Leven and he will be talking about weaponizing an open claw vulnerability to achieve one-click rce. Um we'll be doing Q&A at the end of the session. So if you haven't already scanned the QR code uh for Slido, you can do that by going to bsidesf.org/q&a. With that, over to you, Mav. >> Awesome. Thank you. So, we're going to talk about weaponizing a vulnerability in OpenClaw to get one-click remote code execution. A quick overview about our agenda, a highle background, then we're going to talk about the vulnerability. We're going to see how three features, each independently benign and not interesting, together could be chained into a security weakness with real

impact. Then I'll show how I leverage this vulnerability and bypass four defenses to achieve remote code execution on the host. Taking at the time the most secure configuration of OpenClaw and breaking it. Finally, there'll be a proof of concept. So a bit about myself. I was hacking since I was 13 and loved it more than anything. Watched grow grew up watching Bides talk. So, it's pretty exciting to be here. Then I served in unit 8200 and went to Stanford, worked a bit at Enthropic, and now I'm building and hacking. So, here's the most secure computer. Wait, after you unplug it, now it is. So, if we look, 100% of networks attacks prevented. A lot of security companies want to

claim this number, but none come close to just unplugging your server. 100% data privacy. Again, we can strive for there, but this is the most secure way. Just turn off your computer. However, it's 0% productive. So, what we see is that our goal as security people is to secure while being productive. Operating systems of desktops and mobile have enjoyed a very mature and healthy ecosystem of mitigations that enforce security in depth by creating security boundaries and enabling better security posture for the whole system such that one small vulnerability does not lead to catastrophic exploitation. If you look at browsers, they also developed different mitigations and security practices such that a small bug in one place doesn't bring down the

whole system. These are some samples and of course there are many more mitigations that I'm not mentioning for Asians. However, we have our best effort safety training and then the rest is under construction. We're still very early in this new method of using agentic work to perform our goals and security simply hasn't caught up yet. There have been decades of operating systems and browsers that have been able to develop the correct security posture that let us now run our life on it. And since agents are new, we're still figuring that out. I'm going to use Open Claw as a case study and see how lacking these defenses, we can bring down the whole tower. Raise your hand if you've heard about

Open Claw. Some hands weren't up, but I'll believe you've heard about it cuz the rest of this talk is going to be about OpenClaw. So, by the end, you'll all have your hands raised. It's the most popular agentic assistant with 300,000 GitHub stars, worldwide attention, and was recently bought by OpenAI. It can connect to your email, your Slack, your text message and WhatsApp, your browser, and through skills to so many more things including financials, databases and production, and anything else that can be programmatically accessed. So in the age of open claw, this is what a workflow might look like. For example, getting a refund. In ancient times, what we had to do was open the credit card site, go

through all the charges, find the charge that we wanted a refund for, try to figure out which site it belonged to, look if it was suspicious, if it were us, if it were someone else. Go to the store, find their email if they have one published. send an email to the store for a refund and then follow up on this. But now in modern times, we just can ask OpenClaw. We're living in the future. So now we see that OpenClaw is where work happens. And if previously our goal was about securing productivity, now we need to secure these agentic systems that have taken over and abstracted the operating system. So, we finished the background and next

we're going to go into the vulnerability. Buckle up. This is an exciting part. So, let's talk about OpenClaw authentication. I'm going to talk first in general and then we're going to zone in on where the vulnerability is. So, let's say you're an external event. You woke up and you're a Slack message. If you want to be sent to OpenClaw, you need a cryptographic signature. Through this, OpenClaw verifies that you're authentic and therefore trust what you're saying. There's also the websocket API and HTTP API. These are the APIs that most of us have interacted with. If you're using OpenClaw through the web, these use an authentication token. With this authentication token, OpenClaw can then verify your request is authentic and

trusted and can execute on it. We're going to focus on the right because that's where it went wrong. So zooming in on the websocket API, it gets a few different JSON objects and then invokes functions based on them. So here I selected a few example get the recent logs, send a chat and many more options. It uses the authentication token to send it to openclaw which then executes this for the HTTP API. It also has a few different endpoints each with their own API specification like tools invoke and agent and slash and more. And it also uses the authentication token authentication mechanism. Now, this is important for later, but the HTTP API can actually use

the websocket API and often does. So, a lot of the buttons we're clicking on the HTTP site are performing websocket requests in the back end. We're going to focus on the right because that's where it went wrong. So, on the right is the OpenClaw chat for the very few who haven't used it yet. And let's take a look at some of the endpoints that are exposed. So for tools/invoke it needs an authentication token. This authentication token is something unique to openclaw. That means the browser doesn't send it implicitly. And so it also acts as a CSRF token. If someone tries to load an image from tool/invoke such as a classic CSRF attack, it won't work because it won't have the

authentication token. Let's look at some more endpoints. SL agent also uses the authentication token which is stored in the which is stored in the session storage. Every single request through the HTTP API requires the authentication token except for slash. Slash is a login page and so it makes sense you don't need to log in to the login page to perform the login. However, because there's no authentication token, it also means that you can perform CSRF on it. But so what? Someone can trigger opening the slash page. The slash page in OpenClaw is a fully static site. It only serves static files and then there's JavaScript that runs on the client side. And so very validly, so what? This can't do

anything. We're going to see through a chain of these so whats all together we can actually have a vulnerability with real security impact. So we said no authentication. So what does it matter? Let's take a look at the client side and see what actually happens. There's apply settings from URL. This is invoked the moment the client connects. We can see that there's a gateway URL which is taken from the URL and then used to be the backend server that OpenClaw will eventually connect to. This is a great feature. You can set your OpenClaw to connect to a different OpenClaw instance. This can debug. This allows any client to connect to any server. This doesn't look like a

security vulnerability. So what? So now we have two items each independently benign together might allow more play but still not a vulnerability. So let's keep looking. Here we have a big function handle connected. I cut out some things that weren't relevant. We see the apply settings from URL which we looked at last slide and there there's connect gateway. If we go into it or just even by the title, we can see that it connects to the gateway which was previously set by the URL. Regardless, it connects to the back end. What this means is there's JavaScript enabled auto login again. So what many sites have auto login? That's not a vulnerability. This doesn't allow too

much. But we see a pattern here where we're starting to collect these different primitives and together we're going to have an exciting time with them. Looking at more code, we see the connect. What actually happens? We can see that the authentication token, which we already know is how we authenticate to the service, is sent in the parameters and in the hello. So that means when you connect to a server, you're sending it your authentication token. Independently, this doesn't really matter. When you connect to many sites, you send your password or a hash of your password or other such information since you trust that site. Again, alone, it doesn't matter. But together, let's see how this causes a

vulnerability. So, a user is maliciously tricked to click here right away. They'll get a million dollars. And what we see is this is a specially crafted link that sets a gateway URL to that attacker. So the browser in blue, which is the victim, happy innocent person, is going to access slash from the HTTP API. They're going to load that static file, which runs JavaScript inside the browser. Because there's no authentication, you can define the URL through the get request, which is what we're doing here. We're saying the URL is now connect to attacker. Then the JavaScript performs an auto login and sends the authentication token together. What happens is that the authentication token is sent to the attacker server

because when you log into OpenClaw, you're the admin and now your authentication token is being sent to an attacker. This is an admin authentication token. From here, an attacker can directly interface with OpenClaw and have a party. By chaining three features that independently aren't so bad and also as we'll see later have different defenses and other walls. We see that one click can lead the authentication token. So that was the vulnerability. We talked about the background how we changed a few different primitives to perform a really cool exfiltration leak. And next we're going to talk about the exploit. This is my favorite part. So many of you might have thought well an attacker can't connect to my open

claw it's behind a firewall it's running locally and etc. So let's demonstrate that in blue is a local host the gated community and the gray is a scary scary internet where the hackers live. So we have our Chrome the client innocent trying to get a refund for being overcharged. We have the open claw also running on local host. They make a request and it goes through to their own openclaw server. This is a happy path. However, if we try the same attack, wow, look, click here. You'll get your refund for free ASAP. So, the off token leak exploit sends the authentication token to the attacker. But from here, the attacker can't interface with OpenCloud directly. So,

we might think we've solved the problem. This vulnerability isn't exploitable. However, here is a bypath bypass. We can run the exploit fully locally. The idea is because web pages run already from local host on your local computer, those web pages can actually already interface with the locally running open claw. So, what we're going to do is instead of making the victim click on that crazy URL with a gateway directly inside it, we're going to have them visit evilsite.com. They will suspect nothing. Then we're going to run two background victim windows. One to trigger the authentication exfiltration we've already seen and then the other to interface with the open claw. So, we have evil site. It's going to want two

pages. One of them sends the malicious link we've already gone over and then the other will interface with openclaw. Now why this works? So as we said, evil site is already inside the gated community because when you access a site, it's now running on your computer that JavaScript and the other the second browser can access a local open claw which we might think breaks. However, websockets don't comply with SOP as of the most recent Chrome which fixed this. But that basically meant if you're operating over websockets, any site could talk with any site however much it wanted. And it was a site's responsibility to check the origin header and block it explicitly rather than let the browser do it.

So buckle up. This is now going to be the flow of how we bypass firewalls or locally running instances and still exploit them. So we have evilsite.com. We trick them into clicking it. This spawns two background browser pages. The first one sends a malicious link and it exfiltrates the authentication token. The second one sleeps a little bit and then talk talks with our attacker server. Now it has the authentication token because it's inside the safe walled garden of localhost. It can already talk with openclaw and win. So now let's look at a few mitigations and how to bypass them. So here's the first most simple one that takes up the most real estate on the

site. There's user approvals. The goal here is to have a human in the loop. If a malicious agent goes rogue and wants to run this curl command piped into bash, obviously from attacker.com, then a human could prevent it. However, this was designed to prevent attacks from inside. It was meant to limit the LLM from inside the from inside Open Claw. But our vulnerability is from outside. And so what we can do is since we're admin, we can just disable all these execution approval requests and bypasses defense completely. Now we're at defense 2 that has been knocked down. Let's look at defense 3. There's a sandboxing policy you can employ on Open Claw. In this PC and in

this screenshot, I said block everything. You can't execute anything. trying to be very safe. However, again, there's a bypass. Again, this pattern repeats where this was designed to protect from malicious LLMs or malicious binaries that were trying to escape from OpenClaw rather than a vulnerability in the agentic system itself from the outside. So, what we can do is we can disable it through this websocket API. We can patch the configuration and just say, you know what, no more sandbox. Live your life. Be happy. So now we're going into my favorite defense and also favorite offense of bypassing the pairing mode. I have a friend Ryan Leau who told me about this pairing mode and told me to

look into it because this is really often claimed to be a very secure feature for OpenClaw and it is but it has a fatal flaw. The goal here, what it's trying to do is give cryptographically secure pairing keys to each client. And then the server enforces that only allowed keys can connect through a challenge response protocol. So our allowed client has a key, then it has a challenge response with the server. However, here's a flaw. The key is per client. So that means it's not per client to the specific server. It's not per client to gateway, but rather all clients share the same key for or one client share the same key for all gateways.

That means when OpenClaw connects to a malicious gateway, it's going to use that same key. So we can maninthe middle this. we can just be another server and when we get connected to we can pass on that key or more specifically that challenge response handshake. So here's the attacker from outside the walled garden. here's a malicious website and then instead of having it pass directly to the open claw we can pipe it through us see that traffic and then have a fully authenticated session through to open claw I broke four defenses and we see that agency securing what we trust so awesomely because it's so great to be able to just prompt for whatever we need

we see that comes with some needed security work. Now, we're going to go into the proof of concept.

So, this is set up. Oh, >> is it showing everything? Okay, I think so. All right, so we're going to run the demo. This is going to create a local vulnerable OpenClaw instance on the host with all the defenses enabled that we talked about. So sandboxing and the other ones that I forgot, but especially the user key one. And I used LMS to help make this exploit look nice. So, it's going to start it and open up a site that is better designed than I could ever. And what we should pay attention to are these messages here. So, I'm now showing that there's no calculator running. And after this exploit runs, if it works, a

calculator should pop up. If it doesn't work, I have a video. Here are the messages. Once I click the trigger, then these will all fill up and it's going to be very fast. And then hopefully the calculator pops up. Tada.

Okay. So, thank you Sarah and the rest of the Bites team, Ryan Leau for reviewing this, all of you for being here. You can follow me for more on X on Twitter and LinkedIn. And I'm now opening it up for questions.

Thanks. The questions from my understanding are through the site. >> Thank you. Thank you so much, Ma, for that very interesting talk and demo. For questions, we're using Slido. So, if you don't have the QR code to slide already, you can go to bsidesf.org/q&a and post your questions there and then I'll walk through them.

Okay. So, the first question is, what do you think we could do to patch those three lame vulnerabilities? So, I don't know if to interpret this as the three features that are benign and otherwise not together would not be a vulnerability or those defenses that I bypassed. So, I'll answer both. Those features in themselves aren't bad. And as I said earlier, they are legitimate. The problem is when they're chained together and what I would recommend is having the authentication layer be very, very strong. So being able for example to like for example the pairing mode could have completely ruined this whole exploit and pairing mode is now default in openclaw had every client to gateway

had a unique key that would have prevented just take connecting to a malicious gateway and then piping that key. So, it only takes one of them to be very secure and I'd recommend that be the authentication. For the features, I think auto login and being able to set a remote feature through the URL are helpful. Regarding the defenses that I knocked down, it was more to show that these defenses for this vulnerability are misplaced where someone might see a sandbox or user prompting and saying that therefore their agentic system is safe. But these defenses protect against specific vulnerabilities that get a lot of attention from an agent acting rogue or trying to do some other action, but

they don't protect against a gentic system itself. >> Uh I know you touched upon authentication. There's a follow-up to that. Would two factor on every user o prevent this? >> So it depends where and how it's implemented. Oftent times two-factor authentication is used as a login mechanism and then there's a shared secret that is then exchanged and used in subsequent login. And so if that subsequent login if that subsequent secret is exfiltrated so the two-factor authentication didn't protect it. >> Awesome. Could you share a behind thescenes description of your troubleshooting and slash or notetaking approach? Maybe you leaned on past experience or intuition. >> Yeah, absolutely. Great question. I think the real secret is just going

deep. And so if we go all the way back to the vulnerability where I said so what. So a lot of people might stop here. They might say, "Okay, so what? This has no vulnerability. Let me look for a very easily exploitable XSS." However, if you keep on going deeper, then these primitives are found and then they can be combined. So again, independently a URL defined parameter doesn't really help, but going down the line finds more that you can collect and group together. Regarding the defenses, to be honest, after I found after seeing the vulnerability, I first tried no defenses and then I slowly added them and I thought, okay, well, local host, how could I bypass

that? What are some other tricks to get local host? Maybe I can do some DNS rebinding attack or something like that and just trying all these different options. Right now, it's very fun to show the success of what worked, but there were many, many different iterations of things that didn't worked. and one if condition here or there that stopped a whole different vector from an exploit. So my advice would be to go deeper and as suggested in the question collect that knowledge that you gain about the codebase for finding vulnerabilities in that codebase but also later ones to see what common insecure patterns or ways of doing things exist. >> Thanks Mav. We still have a few more

minutes so if you have questions please pose them to Slido. Meanwhile, uh thank you again for attending this session. Uh I'll share a fewformational announcements. Um if you want to take a break from the day's events, uh you can take a stop at the bar and chill out space which is sponsored by RunZero. You have two complimentary drink tickets that were provided to you at registration. We've already paid for them, so make sure you use them. You can use them for both alcoholic and non-alcoholic drinks. We also have head shot all day today sponsored by Nebulock right outside of the talk tracks by concessions. So if you haven't already, go get your head shot. Uh they're open till 5:00

p.m. Um we have another question, Mav. Um, OpenClaw is often derided for being insecure, but is the reality that any agentic system with broad access is inherently insecure no matter the architecture. >> I would say generally right now it seems so. I think OpenCloud does a great job of addressing vulnerabilities and being proactive about security. No one can solve all vulnerabilities, not even the biggest tech companies, with many available resources. I also think OpenClaw does a good job of showing the risk where they show multiple times the threat of hey this is very insecure are you sure you want to download this and use this and the excitement gets us it got me it's only human I think as we

mature and see more agentic systems then more defenses will surface and we'll have a more secure environment I also think that in general openclaw does so much and So there's so much complexity and so many different layers and so many moving parts. So inherently it's harder to secure that rather than a simple app that maybe only does one thing with one API call. And so when you have all these different functions, all these different features, all these different interactions, it's hard to secure them all. >> Okay. when developing open claw or any agent tech uh system when new features come out do you think we should vulnerability chain test in the CI without slowing down the AI progress

>> I'm not sure I understood that question but my interpretation of it is should we test for vulnerabilities new code that is being added to systems and I'd say so there's always a debate of security versus productivity or as I said at the beginning the most secure computer is one that is off and so we could add no new code and guarantee ourselves no new vulnerabilities wouldn't it wouldn't allow us to have more features so it's it's always a trade-off and depends on what features and what security risks are involved >> awesome we'll do one last question what role did the gateway URL play here if the attacker can become the admin in would this vulnerability

sorry one second would this vulnerability apply to most sites that have auto JWT login enabled I'm not sure I follow the question but what the gateway URL does here is it says what backend to connect to the slash in openclaw this endpoint only returns a static JavaScript site and then that JavaScript site with HTML of course and CSS is what we see here and so this is a client and the client can connect to any server in that sense. Yes, what JWT has signing for which users can connect to with which scope to which access points and so JWT has that built-in feature of access and permissioning which if implemented correctly would prevent such a

vulnerability. Thank you so much ma'am. With that we are on time. So thank you again for attending this session.