security: Phase 2 — remediate the 5 govulncheck findings with no published fix

[mateeullahmalik]

Context

PR #212 adds a strict govulncheck gate. PR #214 (Phase 1) removed 17 of the 22 reachable findings by updating Go and the dependencies that had published fixes.

Five reachable findings remain. None of them has a published fixed release for the module version we actually consume, so none could be resolved by a dependency bump. They are deliberately not suppressed or baselined — the gate stays RED until they are individually resolved or explicitly accepted with an expiry.

This issue tracks that Phase 2 work.

The five residual findings

1. GO-2025-3684 — Cosmos EVM partial precompile state writes

• Module: github.com/cosmos/evm@v0.6.0
• Fixed in DB: N/A
• Path: app → github.com/cosmos/evm/ante

Highest priority. This is not phantom reachability. The vulnerability class is a precompile that returns an error after it has already written state, leaving the write un-reverted. Lumera ships its own precompiles:

• precompiles/supernode
• precompiles/action
• precompiles/wasm

Traces confirm our own code on the path, e.g. precompiles/supernode/supernode.go:89 → common.Precompile.RunNativeAction.

Two independent workstreams:

• (a) Lumera-side audit (do this regardless of upstream). Verify every Lumera precompile takes a state snapshot and reverts it on every error return, including panics and partial multi-write paths. This is a state-machine correctness invariant we own; it does not require an upstream release.
• (b) Upstream bump. v0.6.1, v0.6.2, v0.7.0–v0.7.2, and v1.0.0-rc* exist. A cosmos/evm minor bump changes EVM execution semantics and is consensus-affecting — it needs an upgrade handler, determinism validation, and full devnet upgrade rehearsal. It must not ride in a dependency-only PR.

2. GO-2024-2584 — Cosmos SDK slashing evasion

• Module: github.com/cosmos/cosmos-sdk@v0.53.6
• Fixed in DB: N/A
• Advisory ranges: introduced 0, fixed 0.47.10, introduced 0.50.0 (no fix event for the 0.50+ line)
• Alias: GHSA-86h5-xcpx-cfqc
• Only two traces, one of which is app/test_helpers.go

Verify before acting. The advisory records a fix at 0.47.10 and then re-flags the entire 0.50.0+ line with no fix event. That pattern is consistent with a stale advisory range rather than a genuinely unfixed regression. Task: read the actual slashing/staking code in v0.53.6 and determine whether the 0.47.10 fix is present.

• If present → the correct output is an upstream Go vulndb range correction, not a dependency change.
• If absent → this is a real slashing-safety exposure and escalates immediately.

3. GO-2026-4479 — pion/dtls AES-GCM random nonce, auth-key leak risk

• Module: github.com/pion/dtls/v2@v2.2.7
• Fixed in DB for v2: N/A
• Fixed in v3: 3.0.11 and 3.1.1; v3.1.8 is available
• Path: app → cosmos/evm/x/vm/keeper → go-ethereum/p2p/nat → pion/stun/v2 → pion/dtls/v2

Most tractable of the upstream-blocked set. A fixed line genuinely exists — but on v3, and we do not import it directly. The bump has to happen in go-ethereum moving pion/stun/v2 → v3. Task: check whether a newer go-ethereum already does this, and if not, whether it can be pulled forward compatibly with our cosmos/evm pin.

Note the actual exposure is narrow: this reaches us through geth's NAT/STUN discovery path, not through consensus or transaction execution.

4. GO-2026-4740 — shamaton/msgpack denial of service

• Module: github.com/shamaton/msgpack/v2@v2.2.3
• Fixed in DB: N/A for v2, v3, and the original module — every major is flagged with no fix anywhere
• Path: app → github.com/CosmWasm/wasmvm/v3/types

Not resolvable by us: there is no fixed version of this module in any major line. Requires either an upstream shamaton/msgpack fix or wasmvm dropping/replacing the dependency. Task: assess real decode-path exposure (does untrusted input reach this decoder in our configuration?), then file/track upstream.

5. GO-2026-5932 — x/crypto/openpgp unmaintained and unsafe by design

• Module: golang.org/x/crypto (the openpgp subpackage)
• Fixed in DB: N/A — and there will never be a fix; the package is permanently frozen and deprecated
• Reaches us through the Cosmos SDK keyring's armor handling

This one will never go green via a version bump. The only real resolutions are (a) upstream Cosmos SDK dropping openpgp armor from the keyring, or (b) an explicit, documented, time-boxed accepted risk.

Several of the listed traces are govulncheck symbol-matching noise (for example openrpc.init calls io.ReadAll, which calls armor.openpgpReader.Read). The reachability worth reasoning about is the keyring armor path, which is operator-side key import/export, not consensus.

Proposed Phase 2 tiers

Tier	Findings	Nature	Owner
A — act now	GO-2025-3684	Real state-machine correctness class; audit our own precompiles independent of upstream	Lumera
B — verify then classify	GO-2024-2584	Likely stale advisory range; must be read against v0.53.6 source before any conclusion	Lumera
C — upstream-blocked, track	GO-2026-4479, GO-2026-4740, GO-2026-5932	No consumable fixed release; needs geth / wasmvm / SDK movement	Upstream + tracking

Definition of done

• Lumera precompile snapshot/revert discipline audited and, if needed, corrected with tests
• GO-2024-2584 conclusively classified as fixed-upstream-stale-advisory or genuinely exposed
• Each remaining finding either resolved or carrying a written accepted-risk entry with ID, module and version, why no fix exists, reachability judgment, compensating control, and an expiry date
• Any cosmos/evm bump validated as a consensus-affecting upgrade: upgrade handler, determinism canary, devnet upgrade rehearsal, Supernode and Cascade round trip
• The strict gate's residual set documented so a RED scan is never mistaken for an unreviewed one

Explicit non-goals

• No continue-on-error, no blanket suppression, no silent baselining
• No bundling of a consensus-affecting cosmos/evm bump into a dependency-metadata PR
• No claiming a finding is "not exploitable" from advisory text alone without reading the reachable path