Severity Assessment

CVSS Assessment

Threat Model Alignment

Classification: security-specific

This crosses the gateway authentication boundary because resolveConnectAuthDecision() upgrades a connection to authMethod = "bootstrap-token" whenever verifyDeviceBootstrapToken() accepts the setup code (src/gateway/server/ws-connection/auth-context.ts:159-176). openclaw/SECURITY.md and docs/gateway/security/index.md both define gateway auth and paired-node onboarding as in-scope operator trust boundaries. This finding is not covered by the out-of-scope shared-gateway, prompt-injection-only, or trusted-local-state exclusions because the replay comes from a race in OpenClaw's own bootstrap-token store.

Impact

A consumed setup code can be written back into devices/bootstrap.json by a concurrent issuer process, making the old code valid again for bootstrap authentication. Anyone holding that stale code can silently pair a fresh node device and inherit the bootstrap handoff roles and scopes, while the same race can also delete a newly issued replacement code.

Affected Component

File: src/infra/device-bootstrap.ts:209-225,343-405

export async function issueDeviceBootstrapToken(...) {
  return await withLock(async () => {
    const state = await loadState(params.baseDir);
    state[token] = { token, ts: issuedAtMs, profile, redeemedProfile, issuedAtMs };
    await persistState(state, params.baseDir);
    return { token, expiresAtMs: issuedAtMs + DEVICE_BOOTSTRAP_TOKEN_TTL_MS };
  });
}

export async function verifyDeviceBootstrapToken(...) {
  return await withLock(async () => {
    const state = await loadState(params.baseDir);
    state[tokenKey] = { ...record, profile: allowedProfile, deviceId, publicKey, lastUsedAtMs };
    await persistState(state, params.baseDir);
    return { ok: true };
  });
}

src/infra/json-files.ts:84-161 provides only process-local createAsyncLock() serialization plus atomic whole-file replacement, while src/gateway/server/ws-connection/auth-context.ts:159-176 and src/gateway/server/ws-connection/message-handler.ts:986-1041,1478-1505 turn a verified bootstrap token into silent node pairing and post-hello-ok revocation.

Technical Reproduction

1. Generate setup code A with openclaw qr --setup-code-only; the CLI goes through resolvePairingSetupFromConfig() and issueDeviceBootstrapToken() and writes A into devices/bootstrap.json (src/cli/qr-cli.ts:197-214, src/pairing/setup-code.ts:334-385, src/infra/device-bootstrap.ts:201-225).
2. Start a node handshake that presents A. resolveConnectAuthDecision() calls verifyDeviceBootstrapToken(), which loads the JSON map, binds the token to the connecting device identity, and persists the whole file (src/gateway/server/ws-connection/auth-context.ts:159-176, src/infra/device-bootstrap.ts:335-405). Pause the Gateway after loadState() and before persistState().
3. From a second process pointed at the same state directory, run openclaw qr --setup-code-only again. Its own issueDeviceBootstrapToken() instance reads the stale pre-bind snapshot and prepares a whole-file write containing unbound A plus new token B.
4. Resume the first handshake and let it reach hello-ok. The gateway silently approves bootstrap pairing for an unpaired node and only then redeems and revokes the bootstrap token (src/gateway/server/ws-connection/message-handler.ts:986-1041,1478-1505). Let the stale issuer write land last.
5. devices/bootstrap.json now contains A again as an unbound live record. Reconnect from a different device identity with A; verifyDeviceBootstrapToken() accepts it, resolveConnectAuthDecision() sets authMethod = "bootstrap-token", and the bootstrap-only silent approval path pairs the new node.

Demonstrated Impact

This is a cross-process lost-update bug on an authentication artifact. createAsyncLock() in src/infra/json-files.ts:146-160 serializes only callers inside one process, and writeJsonAtomic() in src/infra/json-files.ts:84-144 replaces the full JSON snapshot without merging concurrent changes. OpenClaw already uses a .lock sidecar file for cross-process pairing-store writes through withFileLock() (src/plugin-sdk/file-lock.ts:166-229, src/pairing/pairing-store.ts:36-45,107-115), but src/infra/device-bootstrap.ts does not.

The revived token is immediately security-relevant in the handshake sink. After verifyDeviceBootstrapToken() succeeds, resolveConnectAuthDecision() authenticates the connection as bootstrap-token, and requirePairing("not-paired") auto-approves an unpaired node when the bound bootstrap profile is present (src/gateway/server/ws-connection/message-handler.ts:949-1041). The same path then provisions device tokens for every role in the bootstrap profile, including operator scopes from PAIRING_SETUP_BOOTSTRAP_PROFILE (src/shared/device-bootstrap-profile.ts:22-25, src/gateway/server/ws-connection/message-handler.ts:1242-1267).

The race also has a second observable effect: whichever writer lands last can delete the other writer's update, so a freshly issued replacement code can disappear before the operator uses it. That contradicts the user-facing guarantee that the setup code is a single-use bootstrap token (extensions/device-pair/index.ts:387-391).

Environment

Re-verified against latest stable release v2026.5.4 (325df3efefe9c0887d9357732e68fc8556e78d79, published 2026-05-05T08:24:01Z) and current main (8a68ea092d0a79e7d95f41f5fe59167a7f37dd92, commit date 2026-05-06T04:50:33Z). In both trees, src/infra/device-bootstrap.ts still protects bootstrap state with only process-local createAsyncLock() around load/persist of devices/bootstrap.json; there is no cross-process withFileLock() or equivalent around these whole-file writes. Reproduction requires a running Gateway process plus a second process issuing openclaw qr --setup-code-only against the same pairing state directory. The mutable state directory defaults to ~/.openclaw and can be overridden with OPENCLAW_STATE_DIR (src/config/paths.ts:55-69).

Remediation Advice

Protect devices/bootstrap.json with the same kind of cross-process lock already used for pairing-store state, or move bootstrap issuance, verification, redemption, and revocation behind one Gateway-owned transactional API. The write path also needs reload-before-commit or compare-and-merge semantics so stale snapshots cannot resurrect revoked tokens, roll back device binding, or erase freshly issued setup codes.