CVE-2026-52880: klever-go REST API Slow-header Connection Exhaustion Vulnerability

HIGH
Advisory Identifier: GHSA-w4c6-7r69-w7j9
CVSS 7.5
CWE-400 CWE-770
Published
Advisory Summary

CVE-2026-52880 is a HIGH (CVSS 7.5) rest api slow-header connection exhaustion vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting klever-go libraries in the Go ecosystem. The issue involves rest api slow-header connection exhaustion via gin engine.run. Remediation is available by upgrading affected packages to version 1.7.18.

CVE-2026-52880 at a Glance

CVE Identifier CVE-2026-52880
GHSA Identifier GHSA-w4c6-7r69-w7j9
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product klever-go
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix CVE-2026-52880

To remediate this vulnerability, upgrade all affected klever-go dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/klever-io/klever-go fixed: 1.7.18
Upgrade github.com/klever-io/klever-go to 1.7.18
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/klever-io/klever-go

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-52880, inspect your project dependencies for klever-go:

inspect dependencies for github.com/klever-io/klever-go

Analyze the terminal output to locate any version of klever-go in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.7.18), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In klever-go, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary The Klever seednode REST API starts a Gin engine with `Engine.Run(restAPIInterface)`. In Gin v1.9.1, `Engine.Run` calls Go's default `http.ListenAndServe`, which constructs an HTTP server without application-level `ReadHeaderTimeout`, `ReadTimeout`, or `MaxHeaderBytes` limits. An unauthenticated client that can reach a REST listener bound with Klever's documented `--rest-api-interface :8080` all-interface option can hold incomplete HTTP headers open indefinitely. In a local proof against the real `cmd/seednode/api.Start` path on `v1.7.17`, 120 slow-header connections caused 20/20 legitimate `/log` probes to fail with `accept: too many open files`. A fixed control using the same Gin router behind an explicit `http.Server` with `ReadHeaderTimeout`, `ReadTimeout`, and `MaxHeaderBytes` retained 0 slow connections and served 20/20 probes. This report is distinct from the P2P advisories and from my direct-message goroutine report. This finding concerns Klever-owned HTTP REST startup code (`cmd/seednode/api` and `network/api`) using Gin `Engine.Run` without server-level header deadlines. It does not depend on `MultiDataInterceptor`, `Batch.Decompress`, libp2p, malformed P2P messages, or direct-message goroutine spawning. ### Details Seednode REST API, latest release `v1.7.17`: - `cmd/seednode/api/api.go:17` defines `Start(restAPIInterface, marshalizer)`. - `cmd/seednode/api/api.go:18` creates `ws := gin.Default()`. - `cmd/seednode/api/api.go:23` returns `ws.Run(restAPIInterface)`. - `cmd/seednode/CLI.md:23` documents `--rest-api-interface`; it says `:8080` binds all interfaces and `off` disables the API. Node REST API, latest release `v1.7.17`: - `network/api/api.go:79` creates `ws = gin.Default()`. - `network/api/api.go:98` returns `ws.Run(kleverFacade.RestAPIInterface())`. - `cmd/node/main.go:147-150` documents the same `--rest-api-interface` flag and says `:8080` binds all interfaces. - `docker/README.md:56-61` and `docker/README.md:67-70` publish host port `8080` for full-node and validator Docker examples. - `README.md:264-268` documents that the node exposes a REST API for blockchain queries and operations. The seednode REST API source is byte-identical across `v1.7.14` through `v1.7.17`; the captured runtime PoC was executed on `v1.7.17`. Current `develop` commit `10bcfd50` remains affected: - `network/api/api.go:98` still returns `ws.Run(kleverFacade.RestAPIInterface())`. - `cmd/seednode/api/api.go:59` still returns `ws.Run(restAPIInterface)`. Gin v1.9.1 implements `Engine.Run` as: ```go func (engine *Engine) Run(addr ...string) (err error) { address := resolveAddress(addr) err = http.ListenAndServe(address, engine.Handler()) return } ``` In my source sweep, I did not find a production `http.Server{ReadHeaderTimeout: ...}` wrapper for either REST start path. The only `ReadHeaderTimeout` hit I found in the repository was a test helper under `network/api/websocket/routes_test.go`. ### PoC GitHub Private Vulnerability Reporting does not appear to allow file attachments in this form, so I am including the reproduction command and captured output inline. I can paste the full 254-line Go test patch in a reply immediately if useful. The test starts two local child servers: 1. Vulnerable: the real `cmd/seednode/api.Start` path. 2. Fixed control: the same Gin router served through `http.Server{ReadHeaderTimeout: 250ms, ReadTimeout: 250ms, MaxHeaderBytes: 4096}`. Reproduction from a clean checkout: ```bash git clone https://github.com/klever-io/klever-go cd klever-go git checkout v1.7.17 # Apply the PoC patch to cmd/seednode/api. # I can provide the full patch in this advisory thread. go test ./cmd/seednode/api -run TestPoC_SeednodeAPISlowlorisDifferential -count=1 -v -timeout 60s ``` Captured output on `v1.7.17`: ```text POC_RESULT mode=vulnerable slow_connections_opened=120 slow_connections_still_open=111 legitimate_probe_ok=0 legitimate_probe_fail=20 POC_RESULT mode=fixed slow_connections_opened=120 slow_connections_still_open=0 legitimate_probe_ok=20 legitimate_probe_fail=0 ``` The vulnerable server also logs repeated accept failures: ```text http: Accept error: accept tcp 127.0.0.1:56415: accept: too many open files; retrying in 1s ``` ### Impact For an externally reachable Klever REST listener, a single unauthenticated client can retain many server-side connections by never completing HTTP headers. Because the Go server has no read-header deadline, those connections persist until the client closes them or an external proxy/firewall intervenes. The direct result is REST API unavailability for legitimate clients. The local proof demonstrates this as 0/20 legitimate `/log` probes succeeding while the vulnerable server is saturated, versus 20/20 succeeding with the fixed server wrapper. I am not claiming default public internet exposure. The default bind is `localhost:8080`. The affected condition is a REST API listener exposed through Klever's documented all-interface bind or Docker port-publish deployment shape. This maps to the `SECURITY.md` High category: "Denial of Service affecting network availability." If Klever treats externally reachable REST API unavailability as non-critical because the default bind is localhost, the conservative classification is Medium under "Performance degradation attacks" / "Non-critical DoS vectors." All testing was local loopback only. I did not contact Klever mainnet, public testnet, hosted RPCs, explorers, or third-party production infrastructure. Suggested fix: Start both REST APIs through explicit `http.Server` values instead of `Engine.Run`, for example: ```go srv := &http.Server{ Addr: restAPIInterface, Handler: ws.Handler(), ReadHeaderTimeout: 5 * time.Second, ReadTimeout: 10 * time.Second, WriteTimeout: 30 * time.Second, IdleTimeout: 120 * time.Second, MaxHeaderBytes: 32 << 10, } return srv.ListenAndServe() ``` Apply the same pattern to: - `cmd/seednode/api.Start` - `network/api.Start` If Klever expects deployments to expose the REST API through a reverse proxy, I still recommend setting server-level limits in the application. That keeps the binary safe when operators use the documented direct bind or Docker port-publish path.

CVE-2026-52880 Affected klever-go Versions

1 component(s)
Fixed Versions:
1.7.18
Product / Package Ecosystem Affected Versions Fixed Version
github.com/klever-io/klever-go
Go
≥ 1.7.14
< 1.7.18
1.7.18

References

Frequently Asked Questions

What is CVE-2026-52880?
CVE-2026-52880 is a security vulnerability in klever-go involving REST API slow-header connection exhaustion via Gin Engine.Run under CWE-400: Uncontrolled Resource Consumption.
Which klever-go versions are affected?
Affected versions include releases prior to 1.7.18 across affected packages: github.com/klever-io/klever-go.
What version fixes CVE-2026-52880?
Upgrading to 1.7.18 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/klever-io/klever-go affected?
Yes, github.com/klever-io/klever-go is affected in releases prior to 1.7.18. Upgrade your dependency to 1.7.18 or later.
What is the CVSS score of CVE-2026-52880?
CVE-2026-52880 has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2026-52880?
CVE-2026-52880 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check Go dependencies for CVE-2026-52880?
Run the dependency tree command: 'inspect dependencies for github.com/klever-io/klever-go'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-w4c6-7r69-w7j9",
  "modified" : "2026-06-09T18:40:44Z",
  "published" : "2026-06-05T16:41:58Z",
  "aliases" : [ "CVE-2026-52880" ],
  "summary" : "klever-go: REST API slow-header connection exhaustion via Gin Engine.Run",
  "details" : "### Summary\n\nThe Klever seednode REST API starts a Gin engine with `Engine.Run(restAPIInterface)`. In Gin v1.9.1, `Engine.Run` calls Go's default `http.ListenAndServe`, which constructs an HTTP server without application-level `ReadHeaderTimeout`, `ReadTimeout`, or `MaxHeaderBytes` limits.\n\nAn unauthenticated client that can reach a REST listener bound with Klever's documented `--rest-api-interface :8080` all-interface option can hold incomplete HTTP headers open indefinitely. In a local proof against the real `cmd/seednode/api.Start` path on `v1.7.17`, 120 slow-header connections caused 20/20 legitimate `/log` probes to fail with `accept: too many open files`. A fixed control using the same Gin router behind an explicit `http.Server` with `ReadHeaderTimeout`, `ReadTimeout`, and `MaxHeaderBytes` retained 0 slow connections and served 20/20 probes.\n\nThis report is distinct from the P2P advisories and from my direct-message goroutine report. This finding concerns Klever-owned HTTP REST startup code (`cmd/seednode/api` and `network/api`) using Gin `Engine.Run` without server-level header deadlines. It does not depend on `MultiDataInterceptor`, `Batch.Decompress`, libp2p, malformed P2P messages, or direct-message goroutine spawning.\n\n### Details\n\nSeednode REST API, latest release `v1.7.17`:\n\n- `cmd/seednode/api/api.go:17` defines `Start(restAPIInterface, marshalizer)`.\n- `cmd/seednode/api/api.go:18` creates `ws := gin.Default()`.\n- `cmd/seednode/api/api.go:23` returns `ws.Run(restAPIInterface)`.\n- `cmd/seednode/CLI.md:23` documents `--rest-api-interface`; it says `:8080` binds all interfaces and `off` disables the API.\n\nNode REST API, latest release `v1.7.17`:\n\n- `network/api/api.go:79` creates `ws = gin.Default()`.\n- `network/api/api.go:98` returns `ws.Run(kleverFacade.RestAPIInterface())`.\n- `cmd/node/main.go:147-150` documents the same `--rest-api-interface` flag and says `:8080` binds all interfaces.\n- `docker/README.md:56-61` and `docker/README.md:67-70` publish host port `8080` for full-node and validator Docker examples.\n- `README.md:264-268` documents that the node exposes a REST API for blockchain queries and operations.\n\nThe seednode REST API source is byte-identical across `v1.7.14` through `v1.7.17`; the captured runtime PoC was executed on `v1.7.17`.\n\nCurrent `develop` commit `10bcfd50` remains affected:\n\n- `network/api/api.go:98` still returns `ws.Run(kleverFacade.RestAPIInterface())`.\n- `cmd/seednode/api/api.go:59` still returns `ws.Run(restAPIInterface)`.\n\nGin v1.9.1 implements `Engine.Run` as:\n\n```go\nfunc (engine *Engine) Run(addr ...string) (err error) {\n    address := resolveAddress(addr)\n    err = http.ListenAndServe(address, engine.Handler())\n    return\n}\n```\n\nIn my source sweep, I did not find a production `http.Server{ReadHeaderTimeout: ...}` wrapper for either REST start path. The only `ReadHeaderTimeout` hit I found in the repository was a test helper under `network/api/websocket/routes_test.go`.\n\n### PoC\n\nGitHub Private Vulnerability Reporting does not appear to allow file attachments in this form, so I am including the reproduction command and captured output inline. I can paste the full 254-line Go test patch in a reply immediately if useful.\n\nThe test starts two local child servers:\n\n1. Vulnerable: the real `cmd/seednode/api.Start` path.\n2. Fixed control: the same Gin router served through `http.Server{ReadHeaderTimeout: 250ms, ReadTimeout: 250ms, MaxHeaderBytes: 4096}`.\n\nReproduction from a clean checkout:\n\n```bash\ngit clone https://github.com/klever-io/klever-go\ncd klever-go\ngit checkout v1.7.17\n\n# Apply the PoC patch to cmd/seednode/api.\n# I can provide the full patch in this advisory thread.\n\ngo test ./cmd/seednode/api -run TestPoC_SeednodeAPISlowlorisDifferential -count=1 -v -timeout 60s\n```\n\nCaptured output on `v1.7.17`:\n\n```text\nPOC_RESULT mode=vulnerable slow_connections_opened=120 slow_connections_still_open=111 legitimate_probe_ok=0 legitimate_probe_fail=20\nPOC_RESULT mode=fixed slow_connections_opened=120 slow_connections_still_open=0 legitimate_probe_ok=20 legitimate_probe_fail=0\n```\n\nThe vulnerable server also logs repeated accept failures:\n\n```text\nhttp: Accept error: accept tcp 127.0.0.1:56415: accept: too many open files; retrying in 1s\n```\n\n### Impact\n\nFor an externally reachable Klever REST listener, a single unauthenticated client can retain many server-side connections by never completing HTTP headers. Because the Go server has no read-header deadline, those connections persist until the client closes them or an external proxy/firewall intervenes.\n\nThe direct result is REST API unavailability for legitimate clients. The local proof demonstrates this as 0/20 legitimate `/log` probes succeeding while the vulnerable server is saturated, versus 20/20 succeeding with the fixed server wrapper.\n\nI am not claiming default public internet exposure. The default bind is `localhost:8080`. The affected condition is a REST API listener exposed through Klever's documented all-interface bind or Docker port-publish deployment shape.\n\nThis maps to the `SECURITY.md` High category: \"Denial of Service affecting network availability.\" If Klever treats externally reachable REST API unavailability as non-critical because the default bind is localhost, the conservative classification is Medium under \"Performance degradation attacks\" / \"Non-critical DoS vectors.\"\n\nAll testing was local loopback only. I did not contact Klever mainnet, public testnet, hosted RPCs, explorers, or third-party production infrastructure.\n\nSuggested fix:\n\nStart both REST APIs through explicit `http.Server` values instead of `Engine.Run`, for example:\n\n```go\nsrv := &http.Server{\n    Addr:              restAPIInterface,\n    Handler:           ws.Handler(),\n    ReadHeaderTimeout: 5 * time.Second,\n    ReadTimeout:       10 * time.Second,\n    WriteTimeout:      30 * time.Second,\n    IdleTimeout:       120 * time.Second,\n    MaxHeaderBytes:    32 << 10,\n}\nreturn srv.ListenAndServe()\n```\n\nApply the same pattern to:\n\n- `cmd/seednode/api.Start`\n- `network/api.Start`\n\nIf Klever expects deployments to expose the REST API through a reverse proxy, I still recommend setting server-level limits in the application. That keeps the binary safe when operators use the documented direct bind or Docker port-publish path.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/klever-io/klever-go"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.7.14"
      }, {
        "fixed" : "1.7.18"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.7.17"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/klever-io/klever-go/security/advisories/GHSA-w4c6-7r69-w7j9"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/klever-io/klever-go"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/klever-io/klever-go/releases/tag/v1.7.18"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-400", "CWE-770" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-05T16:41:58Z",
    "nvd_published_at" : null
  }
}