CVE-2026-34503: You Removed the Device — It's Still Connected
Removing a device from OpenClaw did not kill its active session. Affected versions kept the revoked device connected until the WebSocket dropped.
Everyone assumes that revoking a device means cutting it off. That is how it should work. But for affected OpenClaw versions, removing a device did not actually terminate the live session.
TL;DR: CVE-2026-34503 means that removing a device from your OpenClaw instance does not immediately kill its active WebSocket session. The device can stay connected and functional until the connection drops on its own. Update to v2026.3.28 or later, then restart the instance so every session has to reconnect under the new rules.
What Happened
A vulnerability published on April 1, 2026 and rated HIGH severity showed that OpenClaw versions before v2026.3.28 did not terminate active WebSocket connections when a device or its token was revoked.
The credential state updated correctly in storage. The problem was the live session already in memory.
If a device was connected at the moment you revoked it, the revocation did not force that session closed. The device could keep sending commands, triggering automations, and interacting with the system as if nothing had changed.
The easiest way to think about it is cancelling a keycard in the access system while the person is already inside the building. The badge is revoked for future entry, but nobody escorts them out.
That session stayed alive until something else interrupted it:
- a server restart
- a network drop
- an application reconnect
- or the session timing out on its own
Until then, the removed device still had access.
Multiple trackers indexed the issue quickly, including Tenable, RedPacket Security, GitLab Advisory Database, and vulert. No exploitation had been publicly reported at publication time, but this is exactly the kind of bug that matters most during an actual revocation event.
Why This Matters
Revocation is supposed to be the emergency brake.
When an operator removes an old phone, a lost laptop, or a device they no longer trust, the expectation is immediate cutoff. If the session stays alive, the operator gets a false sense of safety during the exact moment they are trying to reduce risk.
That is what makes this more than a cosmetic flaw.
The gap is not between "secure" and "insecure" in theory. The gap is between what the interface says happened and what the system actually enforced on the live connection.
What To Do Right Now
1. Check your exact version
If you are running anything before v2026.3.28, assume you are affected.
2. Update immediately
Patch to v2026.3.28 or later.
3. Restart after updating
Do not stop at the package upgrade. Restart the OpenClaw instance so all active WebSocket sessions are forced to reconnect. Reconnection is what makes the updated credential checks actually take effect for live clients.
4. Review revoked and connected devices
If you revoked any devices recently while running an older version, confirm they are no longer connected after the restart. Review your current device list and remove anything you do not actively recognize or need.
Key Takeaways
- CVE-2026-34503 affects OpenClaw versions before v2026.3.28 and is rated HIGH severity.
- Revoking a device did not terminate its active WebSocket session on affected versions.
- A removed device could remain connected until a reconnect event occurred.
- The correct fix is update plus restart. Updating alone does not retroactively kill already-live sessions.
- No public exploitation was reported at disclosure time, but this is exactly the kind of issue operators should patch immediately.
OpenClaw is powerful because it keeps agents and devices persistently connected. That same design means session invalidation has to be real, not assumed. If revocation only applies to the next connection attempt, it is not full revocation when it matters most.