According to this[1] your statement that practical risk was low is not accurate.

  > 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...

OpenClaw privilege-escalation bug