openclaw - ✅(Solved) Fix Bug: gateway connect-frame auth.* fields are not bounded at the protocol schema [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#77977Fetched 2026-05-06 06:18:27
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Timeline (top)
commented ×1cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #77538: fix(gateway): bound connect frame auth.* fields at the protocol schema

Description (problem / solution / changelog)

Closes #77977

Summary

The connect-frame schema at src/gateway/protocol/schema/frames.ts:61-71 accepted auth.token, auth.bootstrapToken, auth.deviceToken, and auth.password as unbounded Type.String(). The only effective cap was the 64KB pre-auth frame limit (MAX_PREAUTH_PAYLOAD_BYTES).

safeEqualSecret (src/security/secret-equal.ts) pads both operands to Math.max(provided, expected) before timingSafeEqual and only post-checks lengths. So a remote client could submit a ~60KB auth.bootstrapToken and force every stored-pairing/bootstrap comparison on the pre-auth path to allocate and constant-time-scan the inflated payload. Combined with the mutex-serialized pairing-state walk in device-bootstrap.ts, oversized tokens amplify per-comparison work for legitimate node onboarding.

This PR rejects oversized values at schema validation, before any handshake or secret-compare work runs:

  • Add HandshakeAuthTokenString (256 chars) and HandshakeAuthPasswordString (1024 chars) primitives. Real shared-secret/bootstrap/device tokens are 32-byte base64url (43 chars) or hex (64 chars), so 256 is well above any legitimate value while bounding the work an attacker can force on pre-auth code paths.
  • Apply the bounded primitives to the four auth.* fields in ConnectParamsSchema.

Test plan

  • New src/gateway/protocol/connect-auth-bounds.test.ts (6 tests):
    • Accepts token/bootstrapToken/deviceToken/password exactly at the documented caps.
    • Rejects each one byte over the cap.
    • Rejects a 60KB bootstrapToken (representative attacker payload).
  • Regression suite: pnpm test src/gateway/protocol/connect-auth-bounds.test.ts src/gateway/server/ws-connection/handshake-auth-helpers.test.ts src/gateway/server.auth.modes.test.ts src/gateway/server.auth.browser-hardening.test.ts → 54/54 pass.
  • pnpm exec oxfmt --check and oxlint pass on touched files.

Notes

  • Caps are well above the legitimate values (32-byte base64url = 43 chars, 64-byte hex signature = 86 chars), so no realistic client should hit them. Operators using auth.password for the legacy shared-secret path get 1024 chars of headroom.
  • This is additive at the schema layer — no behavior change for any in-spec request.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/protocol/connect-auth-bounds.test.ts (added, +82/-0)
  • src/gateway/protocol/schema/frames.ts (modified, +11/-5)
  • src/gateway/protocol/schema/primitives.ts (modified, +21/-0)
RAW_BUFFERClick to expand / collapse

Problem

The gateway connect-frame protocol accepts auth.* fields without size or shape bounds at the schema layer. A malformed or oversized auth object can land deep in the auth pipeline before being rejected, increasing surface area and exposing inner code paths to attacker-controlled payloads of arbitrary size.

Defense-in-depth: bound every auth.* field at the protocol schema so payloads are rejected at the boundary instead of inside auth-handling logic.

Tracking PR

Fix in #77538.

extent analysis

TL;DR

Bound every auth.* field at the protocol schema layer to prevent oversized or malformed payloads from reaching inner auth-handling logic.

Guidance

  • Review the schema definition for the gateway connect-frame protocol to identify areas where auth.* fields are accepted without bounds.
  • Update the schema to include size and shape bounds for all auth.* fields, ensuring that malformed or oversized payloads are rejected at the boundary.
  • Verify that the updated schema correctly rejects payloads that exceed the defined bounds, using test cases with varying payload sizes and shapes.
  • Consider implementing additional validation or sanitization steps for auth.* fields to further reduce the attack surface.

Example

No code snippet is provided as the issue does not include specific code details.

Notes

The effectiveness of this fix relies on the accuracy and completeness of the schema updates, as well as the robustness of the validation and sanitization mechanisms in place.

Recommendation

Apply workaround: bound every auth.* field at the protocol schema layer, as this directly addresses the identified vulnerability and reduces the attack surface.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING