CVE-2026-28472 is an authentication flaw in the OpenClaw gateway WebSocket handshake. The device identity check could be skipped when an auth.token was present but not validated. NVD scores it 8.1. Depending on configuration it could give operator access. Upgrade openclaw to 2026.2.2 or later.
What's affected
The GitHub advisory GHSA-rv39-79c4-7459 lists affected versions 2026.2.1 and earlier and patched versions 2026.2.2 and later of the npm package openclaw. NVD says versions prior to 2026.2.2.
The advisory describes the exposure this way: in deployments where the gateway WebSocket is reachable and connections can be authorized through Tailscale without validating the shared secret, a client could connect without presenting device identity or pairing. Depending on version and configuration, this could result in operator access.
The advisory also gives deployment guidance. The gateway should be reachable only from a trusted network and by trusted users, for example with restricted Tailnet users and access lists when using Tailscale Serve. If only trusted users can reach the gateway, there is typically no untrusted party who can exploit the issue.
The advisory rates it High, and NVD scores it 8.1 with high attack complexity. The weakness is CWE-306 (Missing Authentication for Critical Function).
How to check if you're exposed
Check the OpenClaw version in each project and global install.
npm ls openclaw
npm ls -g openclaw
Then work out who can reach the gateway WebSocket. If you use Tailscale Serve, review your Tailnet access lists and the list of users who can reach the gateway. If you expose the gateway elsewhere, review those paths too.
What to do now
- Upgrade openclaw to 2026.2.2 or later.
- Restrict gateway reachability to trusted networks and users, and review Tailnet access lists if you use Tailscale Serve.
- Review paired devices and operator sessions, and revoke any you do not recognise.
- Rotate the gateway shared secret if the gateway was reachable by anyone you do not fully trust.
- Review gateway logs for connections that did not complete device pairing.
Why it matters
The bug is a check that looked at the wrong thing. The handshake decided whether to demand device identity by asking whether an authentication token was present, not whether the token had been validated. A client that supplied any non-empty value could change the outcome.
The fix makes skipping the device identity step conditional on validated shared-secret authentication, with token or password. Connections authenticated by Tailscale without a validated shared secret now need device identity.
This is the general lesson: presence is not proof. Code that branches on whether a credential exists, instead of whether it is valid, is a common source of bypasses.
The advisory's network guidance is the second layer. A gateway that only trusted users can reach has a much smaller attack surface, so network restriction and the fix reinforce each other.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.
Quick check
Is this exploitable from the open internet?
The advisory ties it to deployments where the gateway WebSocket is reachable and authorized through Tailscale without a validated shared secret. Keep the gateway on trusted networks and upgrade.
What does the fix require?
Skipping device identity now requires validated shared-secret authentication. Tailscale authenticated connections without it must present device identity.
Sources
Last reviewed: 19 October 2026.
