Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenClaw privilege escalation vulnerability

nvd.nist.gov

Post reply on HN
Print view View original

261–270 of 306 posts

Re: OpenClaw privilege escalation vulnerability

#261

Post by nightpool »

steipete wrote: post #253
nightpool wrote: post #70

Earlier quoted context omitted.

Can you speak a little bit more to the stats in the OP? * 135k+ OpenClaw instances are publicly exposed * 63% of those run zero authentication. Meaning the "low privilege required" in the CVE = literally anyone on the internet can request pairing access and start the exploit chain Is this accurate? This is definitely a very different picture then the one you paint

Honestly that seems like total guesswork. There's a lot of FUD going around, or people running portscans and assuming just because they detect a gateway on a port, that they can connect to it. That’s not the case.

Definitely agree—that's why I hoped the openclaw maintainer would have been able to speak to those numbers and whether or not they were accurate.

Re: OpenClaw privilege escalation vulnerability

#263

Post by BoiledCabbage »

vasco wrote: post #210

> We're working hard to harden the codebase with folks from Nvidia, ByteDance, Tencent and OpenAI. But coding is solved? Why do you need those guys if all they do is use claude code? Just have it solve it overnight. You forgot to prompt "make it secure pls"?

> But coding is solved?

My belief, is the people who post this quote thinking it's some big win are the same people who are upset they can't post "stochastic parrot" anymore.

And we all saw how that went.

Re: OpenClaw privilege escalation vulnerability

#264

Post by turadg »

steipete wrote: post #55

OpenClaw creator here. This was a privilege-escalation bug, but not "any random Telegram/Discord message can instantly own every OpenClaw instance." The root issue was an incomplete fix. The earlier advisory hardened the gateway RPC path for device approvals by passing the caller's scopes into the core approval check. But the `/pair approve` plugin command path still called the same approval function without `callerS…

[dead]

Re: OpenClaw privilege escalation vulnerability

#266

Post by lnenad »

throwatdem12311 wrote: post #240

Steinberger has a vested interest in protecting his, and OpenAIs reputation from the ramifications of serious in-the-wild exploits like this. Or inviting any legal or regulatory scrutiny. They don’t even read the code in any serious capacity so excuse me for not taking any assessment of the situation from him too seriously. Might as well just ask Claude Code to assess it yourself. Welcome to the world vibe coding cre…

> Welcome to the world vibe coding created.

Hard disagree. Vibe coding isn't responsible for people not doing the slightest due diligence when running this (pardon my French) shit. You can vibe code stuff and keep it at a much higher quality. And you can check who did the vibecoding and how they approached it, so the burden also falls on the person running the stuff to understand what they're running. This isn't an enterprise level application that has a full team behind it that had an issue. This is a pandora's box vibecoded overnight for fun, full of stuff we don't even know about, that was opened the moment you touched it with a stick.

Re: OpenClaw privilege escalation vulnerability

#267

Post by DrewADesign »

lnenad wrote: post #266
throwatdem12311 wrote: post #240

Steinberger has a vested interest in protecting his, and OpenAIs reputation from the ramifications of serious in-the-wild exploits like this. Or inviting any legal or regulatory scrutiny. They don’t even read the code in any serious capacity so excuse me for not taking any assessment of the situation from him too seriously. Might as well just ask Claude Code to assess it yourself. Welcome to the world vibe coding cre…

> Welcome to the world vibe coding created. Hard disagree. Vibe coding isn't responsible for people not doing the slightest due diligence when running this (pardon my French) shit. You can vibe code stuff and keep it at a much higher quality. And you can check who did the vibecoding and how they approached it, so the burden also falls on the person running the stuff to understand what they're running. This isn't an e…

In my experience, most garden variety security problems stem from a) the developer not understanding the implications of something (maybe because they’re new, or operating outside of their usual domain,) or b) the developer not paying close enough attention to realize they did something they know is stupid. We’re only human.

Vibe coding obviously doesn’t make something insecure, per se, but saying it doesn’t reduce the attention paid to any given line of code, or encourage less knowledgeable people to write code, seems pretty dubious to me.

The Claude Code team is clearly competent and professional, yet they accidentally published the proprietary source code for one of the world’s hottest products. That’s like a Bank manager walking away with the keys in the door and alarm disarmed. When’s the last time you heard of a human team of developers doing that?

Again, I’m not saying that vibe coding necessarily creates unsafe code, but I don’t see how anyone could say vibe coding was devoid of security implications. I think this is an organizational/logistical problem that we’ll figure out at some point, but in think it’s going to be more of a C buffer overflow ‘figured out’ that never really goes away.

Re: OpenClaw privilege escalation vulnerability

#268

Post by steipete »

tdeck wrote: post #236
vasco wrote: post #210

> We're working hard to harden the codebase with folks from Nvidia, ByteDance, Tencent and OpenAI. But coding is solved? Why do you need those guys if all they do is use claude code? Just have it solve it overnight. You forgot to prompt "make it secure pls"?

They didn't say the "folks" from those companies were engineers! Maybe it's a group of PMs from Nvidia, ByteDance, Tencent and OpenAI that are working to harden the codebase.

ofc it's software engineers.

Re: OpenClaw privilege escalation vulnerability

#269

Post by [deleted] »

nightpool wrote: post #260
stingraycharles wrote: post #202

Earlier quoted context omitted.

That’s surprising, as the OpenClaw installation makes it pretty difficult to run without auth and explicit device pairing (I don’t even know if that’s possible).

I agree—it looks like the OP didn't provide any sources for these numbers either. That's why I would have hoped that the original maintainer had a better set of metrics to dispute them. It doesn't seem like he does though :(

[deleted]

Re: OpenClaw privilege escalation vulnerability

#270

Post by ctoth »

nightpool wrote: post #260
stingraycharles wrote: post #202

Earlier quoted context omitted.

That’s surprising, as the OpenClaw installation makes it pretty difficult to run without auth and explicit device pairing (I don’t even know if that’s possible).

I agree—it looks like the OP didn't provide any sources for these numbers either. That's why I would have hoped that the original maintainer had a better set of metrics to dispute them. It doesn't seem like he does though :(

Those numbers aren't in the CVE. You introduced them, attributed them to a source that doesn't contain them, and now you're disclaiming them. Where did they come from, and what was the goal of sharing them?
Post reply on HN