Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.20, the default-open GET /subscribe endpoint in network/api/websocket/routes.go accepts unauthenticated WebSocket clients with permissive origin handling, does not call SetReadLimit to bound message size, and has no live-connection cap. SocketHub.HandleClientInsertion also accepts an unbounded address list that grows addressSubscription, and client.loopIn continues reading without a size limit, allowing one client to grow subscription maps or many clients to retain goroutines, buffered channels, and descriptors. The global HTTP request throttler does not count upgraded live WebSocket connections. Because the REST and WebSocket API runs in the node process, memory or scheduler exhaustion can crash the node and interrupt P2P and consensus participation. This issue is fixed in version 1.7.20.

Affected: Go: github.com/klever-io/klever-go

## Summary The unauthenticated WebSocket endpoint `GET /subscribe` is registered `open: true` by default (`config/node/api.yaml`) and lets a remote, unauthenticated client exhaust the node's memory and goroutines. Because the REST API runs IN-PROCESS with the node — `network/api/api.go` `Start(...)` ends with `ws.Run(kleverFacade.RestAPIInterface())` — exhausting/killing the API process takes down the entire node, including its P2P and consensus participation. No API key, account, stake, or funds are required.

Three compounding, independently-exploitable gaps stack on this one endpoint:

1. Permissive origin — `upgrader.CheckOrigin` always returns `true` (`network/api/websocket/routes.go`), so any web origin can complete the handshake. 2. No read-size limit — the connection never calls `conn.SetReadLimit(...)`. gorilla's default is UNLIMITED, so a single `conn.ReadJSON` (`processSubscription`) or `conn.ReadMessage` (`client.loopIn`) can be forced to allocate an arbitrarily large buffer from ONE frame. 3. No connection / fan-out cap — the gin global throttler (`simultaneousRequests: 100`) releases its slot as soon as `handleSubscribe` returns, which it does immediately after `go processSubscription(conn, hub)`. Live WebSocket connections are therefore NOT counted by it. There is no per-IP / per-connection / hub-level cap. Each accepted connection spawns 2 goroutines plus a 500-entry buffered channel, and `req.Addresses` has no length cap, so the hub's…