Severity: Critical — seeded-node exploit against dual-gated targets

Affected component: Secret3dev/SecretNetwork at commit 2b8e18788e70d79245343ed53bc2cc42a345d2d4 (v1.26.0-community-continuance), contract-engine migration and message/contract validation inside SGX.

Fix: v1.27.2, released 2026-09-23 and activated on secret-4 at height 27,286,266 (2026-09-23 12:29:45 UTC) under governance proposal 377; v1.27.3 later retained the enclave.

Secret Network’s v1.26 contract engine could accept an ordinary signed MsgExecuteContract as authorization for the enclave’s migrate operation. For affected contracts, that operation started attacker-chosen Wasm inside SGX with access to the victim contract’s decrypted state. The attacker’s code could select records and return their plaintext to the untrusted node host.

This was not a uniform break of every Secret contract. The demonstrated path required all of the following:

• a legitimately provisioned, seeded Secret SGX full node;
• a target contract/admin pair accepted by the engine’s compiled hardcoded-admin exception; and
• a historical code hash for that target accepted by the compiled allowlist.

SHD and SILK met both target-specific conditions in the September 2026 live snapshots. A partial read-only sweep found additional matching contracts, but it was not a measurement of network-wide prevalence.

The root cause was a composition of two authorization errors. First, the direct-execute verifier matched sender, contract, and encrypted message without checking that the requested enclave operation was Execute; the same message could therefore satisfy a Migrate request. Second, the historical-hash exception validated the code hash carried in the encrypted message, not the host-supplied Wasm that was about to run. Together, those errors let an untrusted node host run its own code inside the enclave with the victim contract’s state context.

The hardware witness showed attacker-selected code reading encrypted records through the normal db_read path. Decryption occurred inside SGX. The breach was that attacker-chosen enclave code had access to the decrypted values and sent plaintext outputs to the host; the research did not observe a raw victim state key leaving SGX.

The exploit path

1. A signed execute entered the verified block FIFO

The attacker signed a normal zero-fund MsgExecuteContract for the target from an ordinary account. Production block verification checked the signed transaction and appended its exact protobuf message to the enclave’s current-block FIFO.

That transaction was genuine. The exploit did not forge a signature, bypass current-block membership, or mutate the message after signing.

2. The host invoked the public migrate entrypoint

On its own node, the hostile host called the shipped migrate bridge and supplied:

• the signed execute message and its SigInfo;
• the target address and the migrate inputs read from local chain state;
• the target’s public hardcoded admin and a zero admin proof; and
• attacker-chosen Wasm.

ecall_migrate is a public enclave entrypoint exposed through the shipped host library. The normal keeper constructs migration-shaped inputs, but the host is outside the trusted boundary, so the enclave must independently authenticate the requested operation and all security-sensitive operands.

3. An execute matched a migrate request

The migrate implementation asked the shared verifier for VerifyParamsType::Migrate. The verifier then searched the authenticated messages from the current block. Its direct-execute arm accepted a match on sender, contract, and encrypted message:

Verbatim vulnerable source (cosmwasm/enclaves/shared/contract-engine/src/input_validation/msg_validation.rs:45-54, Secret3dev/SecretNetwork@2b8e1878):

DirectSdkMsg::MsgExecuteContract {
    msg,
    sender,
    contract,
    ..
} => {
    sent_sender == sender
        && sent_contract_address == contract
        && &sent_wasm_input.to_vec() == msg
}

The arm did not inspect the requested VerifyParamsType or the supplied current admin. By contrast, the adjacent migrate arm required the signed migrate sender to be the current admin. A genuine execute could therefore authorize control flow that had requested a migration.

Signature, sender, target, funds, height, time, encrypted-message equality, and current-block membership still had to pass. The attacker’s own included execute satisfied those checks.

4. Two compatibility exceptions admitted the target and code

The first target-specific condition was the hardcoded-admin path. For contract/admin pairs compiled into the engine, a 32-byte zero proof bypassed the ordinary proof that the signed sender was the current admin. SHD and SILK used the same public hardcoded admin in the captured live snapshot.

The second condition was the historical-hash compatibility path. After decrypting the signed execute message, the enclave compared the code hash in that message with the hash of the Wasm supplied by the host. If they differed, the vulnerable code checked whether the message’s decoded historical hash was allowlisted:

Verbatim vulnerable source (cosmwasm/enclaves/shared/contract-engine/src/contract_validation.rs:542-550, Secret3dev/SecretNetwork@2b8e1878):

if decoded_hash != contract_hash {
    debug!("Message contains mismatched contract hash, checking hardcoded contract hash...");
    if is_code_hash_allowed(contract_address, &hex::encode(&decoded_hash)) {
        debug!("Message contains mismatched contract hash, but it's allowed");
    } else {
        warn!("Message contains mismatched contract hash, and it's not allowed");
        return Err(EnclaveError::ValidationFailure);
    }
}

decoded_hash came from the authentic encrypted message. contract_hash represented the host-selected Wasm, but the exception did not require that hash itself to be allowlisted. For the demonstrated targets, the signed execute carried an accepted historical hash while unrelated attacker Wasm was selected to run.

Neither condition alone exposed every contract. The exploit depended on their intersection: the target needed both a recognized hardcoded admin and an accepted historical hash.

5. Attacker code read state and emitted plaintext

After those checks, migrate instantiated the host-supplied Wasm in the victim contract’s state context:

Upstream excerpt (cosmwasm/enclaves/shared/contract-engine/src/contract_operations.rs:388-398, Secret3dev/SecretNetwork@2b8e1878); ... replaces the remaining upstream call arguments, and the block contains no Bluethroat commentary:

let mut engine = start_engine(
    context,
    gas_limit,
    &contract_code,
    &og_contract_key,
    ContractOperation::Migrate,
    ...
)?;

Inside that engine, the attacker Wasm selected a database key and called db_read. The enclave derived the storage key, requested ciphertext through the host callback, and decrypted the record internally. The attacker code then disclosed the plaintext through two independent output paths: response data encrypted for the attacker’s own request key, and a plaintext BankQuery crossing the query OCALL.

The accepted migration also returned an enclave-authenticated query credential, represented by a current-key/proof tuple, for the attacker Wasm and target state context. The host reused that credential in unsigned local queries, selecting another record without a new transaction or SigInfo. A fresh process reopened the same sealed keychain and repeated the query disclosures.

Why this crossed the confidentiality boundary

Secret Network treats the node process as untrusted. Contract data is meant to become plaintext only inside SGX while authorized contract code is running. Users can inspect the public contract code intended to process their private state.

Here, the enclave authenticated a real transaction but not the operation being requested of it. It then authenticated a historical hash from that transaction without binding the check to the code actually instantiated. The resulting security failure was not key exfiltration: it was unauthorized code execution inside the enclave with access to a victim contract’s decrypted state, followed by plaintext outputs to the untrusted host.

The violated property can be stated narrowly:

A signed contract message must authorize only its encoded operation, and only code authenticated for that operation may execute with access to the target contract’s decrypted state.

Reproduction and evidence boundary

The primary witness ran on an Azure Standard_DC4s_v3 SGX machine with the shipped v1.26 libgo_cosmwasm.so and a source-built production-feature enclave compiled from the exact v1.26 release-tag source. It retained the production block verifier, transaction parser, FIFO, current-block predicate, input verifier, migration operation, storage crypto, Wasm engine, response encryption, and query path. A two-hunk lab patch (identified by hash in the appendix; not published with this article) replaced five baked validator addresses with five deterministic lab signers so a researcher-generated signed block could pass SubmitBlockSignatures.

That witness was not an execution of the unmodified production-signed enclave. The official production-signed enclave artifact was hash-pinned for provenance, but the exploit witness used the source-built enclave described above. A separate matrix harness used a three-byte current-block predicate adapter; it supplied rejection controls and the restart test, while the primary witness exercised the unmodified production FIFO and membership predicate.

The evidence boundary is therefore:

• the primary SGX witness demonstrated the signed-block-to-confused-migrate path, attacker-code access to decrypted synthetic state, two host plaintext outputs, an enclave-authenticated reusable query credential, and unsigned reuse queries;
• a matched execute absent from the verified block failed with 0x3255 and produced no output call, and matched controls rejected a tampered signature, wrong signer, wrong funds, nonzero admin proof, wrong hardcoded admin, mutated ciphertext under unchanged SigInfo, non-hardcoded target, non-allowlisted historical hash, wrong original or current key/proof, wrong response-decryption key, and wrong ciphertext;
• source and artifact provenance connected the exercised v1.26 paths to the affected release and the September 2026 1.26.0 endpoint snapshot;
• September read-only live snapshots captured target addresses, admins, code IDs, code hashes, downloaded public Wasm, and contract metadata/state needed to assess reachability;
• no private live contract plaintext was accessed, although read-only live metadata and state queries were performed; no exploit transaction was broadcast to secret-4; and node admission was a precondition rather than part of the exploit witness.

Full hashes, receipts, controls, and dated September snapshots are in the technical appendix.

Target reachability

For code ID 877, the public reference implementation derives address-indexed balance keys as:

balances || u16_be(len(human_address)) || human_address

The Wasm downloaded in that September snapshot exposed db_read and included address-indexed namespaces such as balances, allowances, transfers, transactions, and viewing_keys, along with fixed-key namespaces including config, total_supply, contract_status, and minters. Those observations established that a hostile node could construct meaningful keys for contracts meeting both compatibility conditions.

A partial September snapshot queried 320 addresses from the source allowlist before the courtesy endpoint rate-limited most requests. Of 29 successful current-hash responses, 28 still used an allowed historical hash and 27 also had a compiled hardcoded admin. Those figures establish breadth beyond SHD and SILK among the responses received; they do not estimate the affected share of all Secret contracts.

Remediation

Secret's shipped fix

Maintainers state that the shipped v1.27 line binds the authenticated Cosmos message type to the enclave operation, preventing an execute from authorizing a migrate. The fix was packaged in v1.27.2, released on 2026-09-23 and activated on secret-4 at height 27,286,266 under governance proposal 377 (v1.27.3 followed later and retained the enclave).

The public changelog's 1.27.0 entry, which the v1.27.2 tag carries forward, records the change as “Authenticated wasm message type is bound to the enclave op; execute cannot authorize migrate.” The public v1.27.2 source tag shows the matching change in the verifier's two arms.

Verbatim upstream source (cosmwasm/enclaves/shared/contract-engine/src/input_validation/msg_validation.rs:48-73, Secret3dev/SecretNetwork@v1.27.2; the block contains no Bluethroat commentary):

DirectSdkMsg::MsgExecuteContract {
    msg,
    sender,
    contract,
    ..
} => {
    matches!(
        verify_params_types,
        VerifyParamsType::HandleType(HandleType::HANDLE_TYPE_EXECUTE)
    ) && sent_sender == sender
        && sent_contract_address == contract
        && &sent_wasm_input.to_vec() == msg
}
DirectSdkMsg::MsgMigrateContract {
    msg,
    sender,
    contract,
    ..
} => {
    matches!(verify_params_types, VerifyParamsType::Migrate)
        && sent_sender == sender
        && sent_current_admin.is_some()
        && sent_current_admin.unwrap() == sender
        && sent_contract_address == contract
        && &sent_wasm_input.to_vec() == msg
}

A signed execute no longer satisfies a Migrate request. This describes the public tag source; Bluethroat did not rebuild the signed enclave running on secret-4, did not receive the maintainers' regression tests, and does not assess any other part of the v1.27 line here.

Bluethroat's recommended controls

These are Bluethroat's design recommendations, not a description of what Secret shipped beyond the message-type binding above.

A complete control enforces an exact mapping between requested operations and signed message variants. Execute accepts only MsgExecuteContract; Migrate requires a signed MsgMigrateContract whose signer is authenticated as the current admin. The code instantiated with access to contract state should also be bound to that authenticated migration decision, and a historical hash taken from an authentic message should never authorize different host-supplied code.

Regression coverage should exercise every cross-entrypoint pairing, especially execute → migrate, and assert rejection before untrusted code is instantiated.

Timeline

• 2026-09-06 to 2026-09-07 — Azure SGX witness, controls, source parity checks, and read-only September snapshots captured.
• September 2026 — Finding and supporting evidence reported to Secret Network maintainers under coordinated disclosure.
• 2026-09-21 — Governance proposal 377 submitted to upgrade secret-4 to v1.27.2 at height 27,286,266; it passed on 2026-09-22.
• 2026-09-22 — Maintainers confirmed remediation that binds the authenticated message type to the enclave operation.
• 2026-09-23 — v1.27.2 released; secret-4 upgraded at height 27,286,266, block time 12:29:45 UTC (v1.27.3 followed later and retained the enclave).
• 2026-10-15 — Maintainers cleared the finding for publication.

References

• Secret Network v1.26 release and package hashes
• contract_operations.rs — migrate requests VerifyParamsType::Migrate
• msg_validation.rs — direct-execute and migrate match arms
• contract_validation.rs — historical-hash exception
• db.rs — storage-key derivation and decryption
• Enclave.edl — public ecall_migrate
• Code-877 public reference implementation
• Historical-hash compatibility change, PR #1702
• Secret Network private computation and consensus flow
• Secret Network Azure node registration
• msg_validation.rs at v1.27.2 — operation-bound match arms

CKFORGE-001 Technical Appendix

This appendix preserves the receipts and provenance behind CKFORGE-001. Live-network observations are dated September 2026 snapshots, not statements about current network state.

The lab patch, hardware harness, and attacker and victim Wasm sources are not published with this article. Their hashes and the verbatim harness output below are retained as provenance for the reported runs; a reader cannot rerun them from this appendix alone. The public-source anchors (file paths, commits, and byte-identical file hashes) can be checked independently.

Pinned revisions

The following load-bearing enclave files were byte-identical across the September live-build commit 4aebd17…, the v1.26 release tag 2b8e187…, and the v1.27 checkout 91145f355…:

Release-package provenance

These downloadable artifacts were checked against the public v1.26 release:

Build tags on the live binary were netgo ledger hw sgx production; Cosmos SDK v0.50.14-secret.12; CometBFT v0.38.23-secret.1; built with go1.24.0.

The official production-signed enclave above was provenance checked. It was not the enclave used to execute the exploit witness.

Hardware platform and witness build

Captured at 2026-09-07T06:21:28Z on a researcher-controlled ephemeral VM:

The primary witness used a source-built production-feature enclave compiled from the exact v1.26 release-tag source. It was not the unmodified production-signed enclave. A two-hunk lab-state patch substituted five baked validator addresses with five deterministic lab signers so the researcher-generated block could pass SubmitBlockSignatures. The block verifier, transaction parser, FIFO, current-block predicate, input verifier, migrate operation, contract-key logic, encrypted database, Wasm engine, response encryption, and query path remained source-identical.

Primary stock-FIFO SGX receipt

A five-validator signed block passed stock SubmitBlockSignatures. A genuine signed instantiate created the victim state context and two encrypted records. The confused migrate ran attacker Wasm, which read and disclosed both records; two unsigned queries then reused the returned current-key/proof credential.

Verbatim harness output:

STOCK_SUBMIT_BLOCK_SIGNATURES=PASS height=1 txs=2 validators=5
STOCK_FIFO_VICTIM_SETUP=ACCEPT gas=533846 og_key_len=64 og_key_sha256=5da16f81887fbd843ca0f98926ec940ff64e612abe1101b50da22c9014fcd5d9
VICTIM_CIPHERTEXT_RECORD index=1 key_len=66 value_len=83
VICTIM_CIPHERTEXT_RECORD index=2 key_len=99 value_len=90
VICTIM_CIPHERTEXT_RECORDS=2 PLAINTEXT_AT_HOST=false
STOCK_FIFO_MIGRATE=ACCEPT gas=388112 response_decrypt=PASS bank_ocall=PASS new_key_len=64 proof_len=32
QUERY_ONE_REUSE=ACCEPT gas=545738 response_decrypt=PASS bank_ocall=PASS
QUERY_TWO_REUSE=ACCEPT gas=743070 response_decrypt=PASS bank_ocall=PASS
RESULT=STOCK_SUBMIT_BLOCK_TO_MIGRATE_REUSABLE_QUERY_DUAL_SINK_PASS total_ocalls=3

The attacker code serialized a plaintext canary into the query OCALL on each disclosure. One captured line was:

Verbatim harness output:

OCALL_QUERY_CHAIN_PLAINTEXT depth=1 request={"bank":{"all_balances":{"address":"CKFORGE_STATE|...|QkxVRV9QUklWQVRFX1NUT1JBR0VfQ0FOQVJZ"}}}

The second query selected a balances-prefixed key constructed for the SHD address captured in the September live snapshot, demonstrating chosen-key selection against the same address-indexed namespace.

A fresh-shell run from an empty environment reproduced the markers. A separate fresh-process run reopened the sealed data and repeated both disclosures without SigInfo:

Verbatim harness output:

PROCESS_RESTART_STATE records=2 plaintext_at_host=false
Sealed data opened
RESTART_QUERY ... response_decrypt=PASS bank_ocall=PASS
RESTART_QUERY ... response_decrypt=PASS bank_ocall=PASS
RESULT=PROCESS_RESTART_REUSABLE_QUERY_PASS
HARNESS_EXIT=0

Matched block-membership negative

With the same block and victim setup, a different signed execute absent from the verified block was rejected before an output call.

Verbatim harness output:

STOCK_FIFO_ABSENT_TXRAW=REJECT error="Execution error: Enclave: failed to validate transaction" new_ocalls=0
RESULT=STOCK_CURRENT_BLOCK_ABSENT_MESSAGE_NEGATIVE_PASS
Failed to validate message, error 0x3255

An exact-source unmodified enclave reopened the sealed data and rejected a standalone empty-FIFO call at 0x3555, confirming the current-block gate remained active without a producer. An offline parser confirmed that the signed TxRaw carried /secret.compute.v1beta1.MsgExecuteContract; its Any.value was an exact subslice of the signed bytes; and its encrypted execute msg was byte-identical to the message supplied to ecall_migrate, with empty funds.

Negative-control matrix

Across the stock-FIFO witness and the complementary SGX matrix, every matched near miss rejected before disclosure or produced no canary. Rejection cases recorded new_ocalls=0.

Complementary predicate adapter

The matrix harness omitted the block producer, leaving the enclave-global current-block FIFO empty. It applied this three-byte adapter to the normalized v1.26 enclave at offset 0xd2640:

Verbatim patch bytes with Bluethroat disassembly annotations after ;:

original: 55 41 57    ; start of check_tx_in_current_block
patched:  b0 01 c3    ; mov al, 1; ret

The adapter supplied only the current-block membership result. It did not modify operation/message matching, signature verification, sender, funds, target, admin, code-hash validation, contract-key handling, state crypto, the Wasm engine, output encryption, the query OCALL, the returned proof, or restart behavior. The primary stock-FIFO witness exercised the real producer, FIFO, and membership predicate; the adapter existed only to run the wider control and restart matrix without a block producer.

September 2026 live observations snapshot

The observations in this section are historical snapshots, not claims about current deployment state.

Target snapshot

Read-only observations at height 27,035,699, captured 2026-09-06T22:33:51Z:

The live code-877 Wasm was downloaded read-only: 585,133 bytes, SHA-256 638a3e1d…b561e. It imported env.db_read and env.query_chain. Address-indexed namespaces included balances, allowances, transfers, transactions, and viewing_keys; fixed-key namespaces included config, total_supply, contract_status, minters, and tx-count.

The reference balance-key derivation was pinned to branch f84189ddfd7fbe38bf7c503bb5b817cf1d4c3c18, which declares original mainnet code ID 877:

Verbatim derivation expression from the research receipt:

balances || u16_be(len(human_address)) || human_address

Partial allowlist-breadth snapshot

Captured 2026-09-07T05:34:30Z against a courtesy endpoint. The source allowed-hash table contained 320 entries and the hardcoded-admin table 577. The sweep attempted 320 current-hash queries; 291 failed after endpoint rate limiting.

Verbatim receipt:

successful_live_hash_queries=29
successful_current_hash_matches=28
matches_with_both_source_gates=27
verdict=PARTIAL_LIVE_SWEEP_BREADTH_POSITIVE

This snapshot does not estimate all-chain prevalence. Among the 29 addresses that answered, 28 still used an allowed historical hash and 27 also had a compiled hardcoded admin.

Node-admission snapshot

Secret’s public documentation described Azure-node acceptance without machine whitelisting and a path from attestation registration to encrypted-seed retrieval, with validator creation as an optional later step. A read-only September check of two secret-4 accounts that used this documented registration path recorded both as ordinary BaseAccount values with delegation_count=0, no staking-validator object (HTTP 404), and registration signer sequence 0.

These observations support seeded non-validator node operation as an exploit precondition. They do not represent an admission-to-exploit end-to-end witness. The retained summaries contain public transaction, account, and staking results plus a redacted certificate-structure summary; no attestation token or raw certificate is reproduced here.

Safety and custody

The two disclosed records were synthetic canaries created by a genuine signed instantiate inside the contract engine. Their ciphertexts were recorded with PLAINTEXT_AT_HOST=false before the exploit. Receipts preserve lengths and SHA-256 digests rather than raw private values.

No private live contract plaintext, sealed key-manager file, SSH key, Azure credential, or cloud control-plane datum is included. Read-only live metadata and state queries were made for the dated snapshots above, but no exploit transaction was broadcast to secret-4.

The VM, storage paths, keys, and enclave signing certificate were researcher-controlled and ephemeral and were destroyed after capture. The ephemeral hardware Machine ID is omitted because it is not needed to establish the result.