Klever-Go: Validator registration accepts an unvalidated BLS public key → consensus liveness DoSGHSA-9wh6-9hq7-9688
Fix: klever-io/klever-go@11606a9GHSA-9wh6-9hq7-9688 is a Improper Input Validation vulnerability in github.com/klever-io/klever-go. A fix is available for github.com/klever-io/klever-go — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-9wh6-9hq7-9688.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/klever-io/klever-goReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Location: core/kapp/validators/validators.go:201 (Register), (genesis/checking/nodesSetupChecker.go:73). core/consensus/slot/bls/subslotStartSlot.go:165 core/consensus/.../headerSignatureVerify.go:123 (Create(...)).
Description
Klever uses a BDN (Boneh-Drijvers-Neven) BLS multi-signature over BLS12-381 to finalize blocks (crypto/signing/mcl/multisig/bls.go, herumi/bls-go-binary). The library is initialized with only bls.Init(bls.BLS12_381) and no order-verification flags, so Deserialize does not enforce prime-order-subgroup membership subgroup safety relies on explicit IsValidOrder() calls in the wrappers.
Runtime validator registration (validators.Register) stores the submitted 96-byte BLSPublicKey via SetBLSPublicKey with no curve check, no subgroup check, and no proof-of-possession (CreateValidatorContract carries the key but no signature proving key ownership; grep confirms no proofOfPossession/VerifyProof/BLSSignature verification anywhere in core/kapp/validators/). CheckPublicKeyValid — which does IsValid && IsValidOrder && !IsZero — runs only at genesis, not on runtime registration/update.
POC
Attack:
(1) stake the minimum to register a validator, submitting a 96-byte BLSPublicKey that is not a valid G2 point (arbitrary bytes). Registration succeeds.
(2) Once the validator is eligible and selected into a consensus group, every in-group node including the honest leader (group[0]) calls MultiSigner().Reset(groupPubKeys, selfIndex) at slot start, which deserializes all group keys via PublicKeyFromByteArray → herumi Deserialize deterministically fails on the malformed key → SetSlotCanceled(true). The verify side (Create(consensusPubKeys)) fails identically. No block is produced for that round.
Impact
Every consensus round whose group contains the malformed-key validator is a missed slot. One eligible bad-key validator poisons roughly a groupSize / eligibleSet fraction of rounds → sustained liveness degradation. Where the consensus group equals the eligible set (small or early-stage networks), this is a full chain halt. Cost is the minimum validator stake, permissionless, and repeatable; no fork flag gates the missing validation.
Rated High (Byzantine liveness; Critical on small validator sets). The severity scales down to a fractional missed-slot / throughput-degradation attack on a large validator set where the bad validator is only occasionally in the active group.
Recommendation
Enforce CheckPublicKeyValid (curve + prime-order subgroup + non-zero) on the submitted BLS key at runtime validator registration and config-update, and ideally require a proof-of-possession (a BLS signature over the validator's own key/identity) at registration to prove key ownership and well-formedness. Gate the stricter validation behind an epoch fork flag for reprocessing consistency.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/klever-io/klever-go | all versions | 1.7.20go get github.com/klever-io/klever-go@v1.7.20 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/klever-io/klever-go, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/klever-io/klever-go to 1.7.20 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9wh6-9hq7-9688 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Frequently Asked Questions
Is GHSA-9wh6-9hq7-9688 in your dependencies?
Find it across Go, including transitive dependencies.