CVE-2026-43992: JunoClaw Information Disclosure Flaw

CVE-2026-43992 Overview

CVE-2026-43992 is a sensitive information exposure vulnerability in JunoClaw, an agentic AI platform built on the Juno Network. Prior to release 0.x.y-security-1, every Model Context Protocol (MCP) write tool accepted mnemonic: string as an explicit tool-call parameter. Affected tools include send_tokens, execute_contract, instantiate_contract, upload_wasm, and ibc_transfer. The BIP-39 seed phrase was embedded directly in the LLM tool-call JSON. Any transport, log, or telemetry surface between the LLM provider and the MCP process could capture the seed. The flaw maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact

Attackers with access to LLM transport logs, provider telemetry, or intermediate proxies can recover the BIP-39 mnemonic and gain full custody of the associated Cosmos/Juno wallet.

Affected Products

• JunoClaw agentic AI platform versions prior to 0.x.y-security-1
• JunoClaw MCP server write tools (send_tokens, execute_contract, instantiate_contract, upload_wasm, ibc_transfer)
• JunoClaw deployments integrating LLM providers with MCP signing flows

Discovery Timeline

• 2026-05-12 - CVE-2026-43992 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-43992

Vulnerability Analysis

JunoClaw exposes MCP tools that an LLM agent invokes to perform on-chain operations on the Juno Network. The pre-patch design required each write tool to receive the user's BIP-39 mnemonic as an inline JSON parameter. Because LLM tool-calls traverse provider APIs, observability pipelines, and prompt/response logs, the seed phrase became visible across the entire request path. An attacker with read access to any of these surfaces, including provider-side telemetry, can extract the mnemonic and reconstruct the wallet. Possession of the seed grants permanent, irrevocable control over all funds and contract authority bound to the wallet.

Root Cause

The root cause is an API contract that treats long-lived signing material as a per-call argument. The MCP tool schema declared mnemonic: string as a public parameter, forcing the LLM to serialize the secret into the tool-call JSON. The signing client factory in mcp/src/utils/cosmos-client.ts constructed a DirectSecp256k1HdWallet directly from this parameter, with no in-process key custody layer.

Attack Vector

Exploitation is network-based and requires no authentication or user interaction beyond normal agent use. Any party with visibility into the LLM tool-call channel can harvest the mnemonic. Viable observation points include LLM provider logs, prompt/response caches, OpenTelemetry traces, reverse proxies, and SIEM ingestion pipelines.

// Patch excerpt: mcp/src/utils/cosmos-client.ts
// Pre-patch design accepted a mnemonic argument in getSigningClient.
// Post-patch removes that surface entirely.

/**
 * CosmJS Client Factory
 *
 * Read path: `getQueryClient(chain)` — anyone can use, no wallet.
 * Write path: `WalletStore.signFor(walletId, chain)` — see
 *             `../wallet/store.ts`.
 *
 * Per Ffern C-3 (April 2026), this module no longer exposes a
 * mnemonic-taking `getSigningClient`. All signing flows go through
 * the encrypted wallet registry by `wallet_id`; the mnemonic is
 * decrypted in-process for one signing-client construction and
 * scrubbed from memory immediately afterwards.
 */

import { CosmWasmClient, SigningCosmWasmClient } from "@cosmjs/cosmwasm-stargate";
import { type ChainConfig } from "../resources/chains.js";

Source: GitHub Commit 339701e

Detection Methods for CVE-2026-43992

Indicators of Compromise

• Tool-call JSON payloads containing a mnemonic field with 12 or 24 lowercase BIP-39 words in LLM provider logs or proxy captures.
• Unexpected send_tokens, execute_contract, or ibc_transfer transactions broadcast from wallet addresses tied to JunoClaw deployments.
• Outbound transfers to attacker-controlled Juno or IBC-connected addresses immediately following LLM session activity.

Detection Strategies

• Scan historical LLM provider logs, OpenTelemetry traces, and reverse-proxy archives for JSON keys matching mnemonic or 12/24-word BIP-39 patterns.
• Audit MCP server access logs for invocations of write tools while the vulnerable schema was deployed.
• Cross-reference on-chain transaction history for affected wallets against authorized agent sessions.

Monitoring Recommendations

• Forward MCP server logs and LLM gateway telemetry to a centralized data lake and alert on any mnemonic token in transit.
• Monitor Juno Network addresses controlled by JunoClaw deployments for unauthorized signing activity.
• Track upgrades of the JunoClaw package to confirm all instances reach 0.x.y-security-1 or later.

How to Mitigate CVE-2026-43992

Immediate Actions Required

• Upgrade JunoClaw to 0.x.y-security-1 or later, which removes mnemonic from MCP tool schemas and routes signing through the encrypted wallet registry.
• Treat any mnemonic previously transmitted through tool-call JSON as compromised; rotate to a new BIP-39 seed and migrate funds.
• Purge LLM provider logs, traces, and proxy caches that may retain historical tool-call payloads containing seeds.
• Re-enrol wallets through the new WalletStore flow using the passphrase or OS keychain backend.

Patch Information

The fix ships in the JunoClaw v0.x.y-security-1 release and is documented in GHSA-j75q-8xvm-6c48. The patch in commit 339701e introduces a wallet registry where signing is invoked by wallet_id through WalletStore.signFor(walletId, chain). The mnemonic is decrypted in-process for a single signing-client construction and scrubbed from memory immediately afterwards.

Workarounds

• If patching is not immediately possible, disable all MCP write tools and restrict the deployment to query-only operations.
• Terminate integrations with external LLM providers until the registry-based signing path is enabled.
• Route MCP traffic through a local-only LLM with no external telemetry to limit seed exposure surface.

# Upgrade JunoClaw and configure the wallet registry backend
npm install junoclaw@0.x.y-security-1

# Option A: passphrase-backed registry
export JUNOCLAW_WALLET_PASSPHRASE_FILE=/etc/junoclaw/passphrase

# Option B: OS keychain backend (leave passphrase unset)
npm install @napi-rs/keyring

# Enrol an existing mnemonic into the encrypted registry, then rotate funds
tsx mcp/src/signing-smoke.ts