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 `callerScopes`, and the core logic failed open when that parameter was missing.
So the strongest confirmed exploit path was: a client that ALREADY HAD GATEWAY ACCESS and enough permission to send commands could use `chat.send` with `/pair approve latest` to approve a pending device request asking for broader scopes, including `operator.admin`. In other words: a scope-ceiling bypass from pairing/write-level access to admin.
This was not primarily a Telegram-specific or message-provider-specific bug. The bug lived in the shared plugin command handler, so any already-authorized command sender that could reach `/pair approve` could hit it. For Telegram specifically, the default DM policy blocks unknown outsiders before command execution, so this was not "message the bot once and get admin." But an already-authorized Telegram sender could still reach the vulnerable path.
The practical risk for this was very low, especially if OpenClaw is used as single-user personal assistant. We're working hard to harden the codebase with folks from Nvidia, ByteDance, Tencent and OpenAI.
* 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
LLMs are patient, tireless, capable of rigorous opsec, and effectively infinite in number.
> The attacker acquires an account or session with operator.pairing scope. On the 63% of exposed OpenClaw instances running without authentication, this step requires no credentials at all — the attacker connects and is assigned base pairing rights.
If that's accurate, then this statement: > This was a privilege-escalation bug, but not "any random Telegram/Discord message can instantly own every OpenClaw instance."
...is only true for the 37% of authenticated OpenClaw instances.I'm sure it's extremely stressful and embarrassing to face the prospect that your work created a widespread, significant vulnerability. As another software engineer and a human I empathize with the discomfort of that position. But respectfully, you should put your energy into addressing this and communicating honestly about what happened and the severity, not in attempting to save face and PR damage control. You will be remembered much better for the former.
EDIT: more from the source[2]
> The problem: 63% of the 135,000+ publicly exposed OpenClaw instances run without any authentication layer, according to a 2026 security researcher scan. On these deployments, any network visitor can request pairing access and obtain operator.pairing scope without providing a username or password. The authentication gate that is supposed to slow down CVE-2026-33579 does not exist.
> This is the intersection that makes this vulnerability particularly dangerous in practice. The CVSS vector already rates it PR:L (Privileges Required: Low) rather than PR:N — but on 63% of deployed instances, "low privilege" is functionally equivalent to "no privilege."
[1]: https://blink.new/blog/cve-2026-33579-openclaw-privilege-esc...
[2]: https://blink.new/blog/cve-2026-33579-openclaw-privilege-esc...Did OpenClaw write this for you?
Shipping at the speed of inference for real.
It's a good compromise between running as me and full sandbox-exec. Multi-user Unix-y systems were designed for this kind of stuff since decades ago.
Not too much harder is using a VM:
With Apple's open-source container tool, you can spin up a linux container vm in ~100ms. (No docker root)
With Apple virtualization framework, you can run macOS in a VM (with a separate apple id).
Right, these are system accounts. They don't have access to anything except their own home folder and whatever I put in their .bashrc. `sudo` is a pretty easy sandbox by itself and lets me manage their home folders, shell, and environment easily just with the typical Unix-isms. No need for mounting VM disks, persisting disk images, etc.
I don't need virtualization to let Claude Code run. I just let it run as a "claude" user.
My interpretation is that 135k instances are vulnerable, but of those there's more conditions that need to be met, specifically:
These need to be multi-user systems where there are users with 'basic pairing' privileges. Which I don't think is very common, most instances are single-user.
So way less than the 135k number. I think a more accurate title would have been "If you're running OpenClaw, you are probably vulnerable" but not "you probably got hacked", that's just outright false and there's no evidence that the exposed users were ALL hacked.
Do you so stringently examine most CVEs? I’ll bet you don’t. Are you a big fan of this project? I’ll bet you are. Do you have any actual data to counter what they said or do you just sort of generally not vibe with it? If so, now would be a great time to break it out while this is still fresh. If not…
Otherwise I would say “you may have been hacked” not “you probably have been hacked”.
If you're running OpenClaw, you probably didn't get hacked in the last week.
That doesn’t mean this isn’t a critical vulnerability, and I think it’s insane to run OpenClaw in its current state. But the current headline will burn your credibility, because 80% of users will be fine with no action, and they’ll take future security issues less seriously as a result.
[0] https://itmeetsot.eu/posts/2026-03-27-openclaw_webfetch/
I say to it: check my pending tasks on Todoist and see if you can tackle on of those by yourself.
It then finds some bugs in a webapp that I took note. I tell it to go for it, but use a new branch and deploy it on a new url. So it clones the repo, fix it, commit, push, deploy, and test. It just messages me afterwards.
This is possible because it has access to my todoist and github and several other services.
It also have mine automatically grabs a spot at my gym when spots are released because I always forget.
I'm just playing with it, it's been fun! It's all on a VM in the cloud and I assume it could get pwned at any time but the blast radius would be small.
seems far more efficient/reliable to get codex/claude code to write and set up a bot that does this.
But he already did this. With a bonus of it will continue to work in the future if something breaks or changes. Human time is more precious than computing resources nowadays.
>I use it to give me a weekly digest of what happened in my neighborhood and if there are any public hearings or trash pickups I might want to attend.
Anything not relying on an LLM likely means having to write bespoke scripts. That's not really worth the time, especially when you want summaries and not having to skim things yourself.
Going from doing it manually on a regular basis to an autonomous agent turns a frequent 5-15 minute task into a 30 second one.
The very first line in your readme is "CivicClaw is a set of scripts and prompts" though? And almost the entire repo is a bunch of python scripts under a /scripts folder.
I looked at one randomly chosen script (scripts/sf_rec_park.py) and it's 549 lines of Python to fetch and summarise data that is available on an RSS feed ( https://sanfrancisco.granicus.com/ViewPublisher.php?view_id=... )
The thing where you give it access to all your personal data and whatever I haven't done and wouldn't do.
...and to laugh a little every time it calls me "commander" or asks "What's the next mission?" or (and this is the best one) it uses the catchphrase I gave it which is "it's probably fine" (and it uses it entirely appropriately...I think there must have been a lot of sarcasm in qwen 3.5's training data)
and I've treated it like it's already been compromised the whole time.
The way I'm seeing folks responsibly use OpenClaw is to install it as a well-regulated governor driving other agents and other tools. It is effectively the big brain orchestrating a larger system.
So for instance, you could have an OpenClaw jail where you-the-human talk to OpenClaw via some channel, and then that directs OpenClaw to put lower-level agents to work.
In some sense it's a bit like Dwarf Fortress or the old Dungeon Keeper game. You declare what you want to have happen and then the imps run off and do it.
[EDIT: I truly down understand sometimes why people downvote things. If you don't like what I'm saying, at least reply with some kind of argument.]
Your best way of finding if it's useful for you is to install it and explore, just like you would with any other software tool.
Nina Hagen - Smack Jack
https://www.youtube.com/watch?v=nIDnN34ZZaE
>Smack Ist Dreck, Stop It Oder Verreck!
This is exactly why I have zero interest in engaging with people over this topic.
https://x.com/steipete/status/2005451576971043097
> Confession: I ship code I never read. Here's my 2025 workflow.
Might want to start reading it I'd say.
- "You're absolutely right. One should read and understand their own code. I did, and it looks great"
OpenClaw is probably entering a phase of it's life where prototype-grade YOLO processes (like what the tweet describes) aren't going to cut it anymore. That's not really a criticism, the product's success has over vaulted it's maturity, which is a fortunate problem to have.
Why on earth would you install something like that has access to your entire machine, even if it is a separate one which has the potential to scan local networks?
Who is even making money out of OpenClaw other than the people attempting to host it? I see little use out of it other than a way to get yourself hacked by anyone.
If you think you need to give it the keys to your kingdoom to be useful, you are not actually experimenting with this stack but regurgitating the words of others. I really don't understand the mindset of comments like this.
/s
Edit: Default binding was to 0.0.0.0, and if you were not aware of this and assumed your router was keeping you safe, you probably should not be using OpenClaw. In fact some services may still default to 0.0.0.0: https://github.com/openclaw/openclaw/issues/5263
https://github.com/openclaw/openclaw/commit/5643a934799dc523...
This is bad.
Too much focus on shipping features, not enough attention to stability and security.
As the code base grows exponentially, so does the security vulnerability surface.
Intelligence asset.
Useful idiot.
Plenty of reasons.
We detached this comment from https://news.ycombinator.com/item?id=47629849 and marked it off topic.