Harmony Cross-Shard ONE Mint + Perdas de Chaves de ~$47M

Durante a semana passada (10/08/2026 - 16/08/2026), os seguintes 5 incidentes de segurança notáveis são destacados, envolvendo aproximadamente $47 milhões em perdas totais.

Data	Incidente	Tipo	Perda Estimada
2026/08/10	Coinsbuy	Comprometimento de Chave Privada	~$7,9M
2026/08/10	Carteira de Whale Desconhecida	Comprometimento de Chave Privada	~$25M
2026/08/12	Harmony	Problema de Validação	Desconhecido*
2026/08/13	Kite	Comprometimento de Chave Privada	~$14M
2026/08/15	Fox	Falha de Lógica de Negócio	~$117K

*A Harmony reportou uma primeira onda confirmada de mint de 4 bilhões de ONE e uma reconstrução mais amplo de aproximadamente 3,01 trilhões de ONE forjados, dos quais aproximadamente 2,385 trilhões de ONE foram transferidos [1]. No preço pré-incidente de ~$0,001183, o montante forjado carrega um valor nominal de ~$3,56 bilhões, mas isso é aproximadamente 200x o fornecimento total do ONE e excede em muito a capitalização de mercado do token, portanto não é uma perda realizável nem confirmada como realizada. A Harmony desde então revertou a chain para um checkpoint pré-ataque, descartando o estado forjado [2]. Por isso, a Harmony está excluída das perdas totais.

Motivos para seleção

Harmony: Selecionado porque uma falha de proteção contra replay na implementação da chain permitiu emissão não autorizada de token nativo em escala massiva em todo o ecossistema Harmony. Uma fraqueza separada na verificação de quórum pré-staking foi identificada durante a investigação, embora seu papel no exploit não esteja confirmado.

Destaque da Semana: Harmony

A Harmony é destaque desta semana porque a falha residia na própria implementação da chain, e não em um contrato de aplicação, um modo de falha de impacto excepcionalmente alto porque pode inflacionar o ativo base de uma Layer-1 inteira.

Em 12 de agosto de 2026, a Harmony, uma blockchain Layer-1 fragmentada (sharded), sofreu mint não autorizado de seu token nativo ONE por meio de uma falha de replay de recibo cross-shard. Os shards de destino identificavam um recibo já consumido usando campos que não estavam cobertos pela assinatura do comitê de origem, então um atacante podia reapresentar um recibo genuíno, previamente creditado, mutando apenas esses campos e tê-lo creditado novamente sem o débito correspondente no shard de origem. A Harmony estava reconciliando uma primeira onda confirmada de mint de 4 bilhões de ONE com uma reconstrução mais amplo de aproximadamente 3,01 trilhões de ONE forjados e aproximadamente 2,385 trilhões de ONE transferidos por uma carteira de mint forjado; nenhum desses valores é perda confirmada como realizada, e o impacto final permanece sujeito a rollback e reconciliação com exchanges [1][2]. Durante a investigação, a Harmony identificou uma falha separada na verificação de quórum pré-staking, embora não tenha confirmado se o exploit dependeu dela.

Contexto

A Harmony é uma blockchain Layer-1 fragmentada (sharded). Cada shard mantém seu próprio estado independente, então um shard de origem não pode modificar diretamente uma conta em um shard de destino. Para mover valor entre shards, a Harmony usa um design assíncrono baseado em recibos: o shard de origem debita o remetente e emite um recibo cross-shard, e o shard de destino posteriormente credita o destinatário.

Um recibo cross-shard registra a própria transferência:

type CXReceipt struct {
    TxHash    common.Hash
    From      common.Address
    To        *common.Address
    ShardID   uint32
    ToShardID uint32
    Amount    *big.Int
}

O shard de destino não confia em um recibo puro. O recibo trafega dentro de um CXReceiptsProof, que carrega uma prova de Merkle, o cabeçalho do bloco de origem e a assinatura de comitê (commit signature) do comitê de origem sobre esse cabeçalho:

type CXMerkleProof struct {
    BlockNum      *big.Int
    BlockHash     common.Hash
    ShardID       uint32
    CXReceiptHash common.Hash
    ShardIDs      []uint32
    CXShardHashes []common.Hash
}

type CXReceiptsProof struct {
    Receipts     CXReceipts
    MerkleProof  *CXMerkleProof
    Header       *block.Header
    CommitSig    []byte
    CommitBitmap []byte
}

O caminho normal de verificação valida a prova em relação ao cabeçalho de origem assinado e à assinatura do seu comitê:

VerifyIncomingReceipts()
  -> IsSpent()
  -> ValidateCXReceiptsProof()
      -> VerifyHeaderSignature()
          -> verifySignature()
              -> DecodeSigBitmap()
              -> IsQuorumAchievedByMask()
              -> aggSig.VerifyHash()

Como o shard de origem realiza o débito exatamente uma vez, o shard de destino deve garantir que cada recibo cross-shard seja consumido apenas uma vez.

Análise da Vulnerabilidade

O caminho de liquidação cross-shard continha dois problemas: uma fraqueza de proteção contra replay em como um recibo consumido era identificado, e uma fraqueza na verificação de quórum pré-staking.

Replay de Recibo Cross-Shard

A proteção contra replay registrava e consultava o marcador "gasto" (spent) de um recibo, mas sua chave vinha de dois campos mutáveis da prova de Merkle:

CXMerkleProof.ShardID
CXMerkleProof.BlockNum

O hardfork Bloom fortaleceu isso na mainnet na época 2964 (13 de julho de 2026), controlado por IsCXMerkleProofReplayFixEpoch [3]: para uma prova cujo Header.Epoch() assinado seja igual ou posterior a essa época, IsSpent() e WriteCXReceiptsProofSpent() derivam a chave do marcador de gasto a partir do cabeçalho de origem assinado (Header.ShardID e Header.Number) em vez desses dois campos. No entanto, a chaveação mais robusta nunca foi aplicada retroativamente — para uma prova cujo Header.Epoch() é anterior ao fork, ambas as funções mantiveram o fallback legado para MerkleProof.ShardID e MerkleProof.BlockNum, que ValidateCXReceiptsProof() nunca vinculou ao cabeçalho assinado para essas épocas.

Esses dois campos ficam fora da assinatura de commit, que cobre apenas o Header de origem. Alterar o Header falharia em VerifyHeaderSignature(), mas mutar MerkleProof.ShardID ou MerkleProof.BlockNum não rompe nenhuma verificação — nem a assinatura do cabeçalho, nem a validação da prova, que para essas épocas nunca os vinculou de volta ao Header. Como a chave legada do marcador de gasto era derivada desses campos não autenticados, a identidade de proteção contra replay de um recibo estava dissociada da assinatura que autenticava o restante da prova: duas provas com o mesmo cabeçalho assinado e recibos, mas com valores diferentes de MerkleProof.ShardID ou MerkleProof.BlockNum, eram tratadas como distintas para fins de rastreamento de gasto.

Verificação de Quórum Pré-Staking

Uma segunda falha afetava a verificação de quórum pré-staking. A lógica uniformVerifier.IsQuorumAchievedByMask() comparava o limite (threshold) com

len(mask.Publics)

tratando isso como o número de signatários. Mas mask.Publics é a lista completa das chaves públicas do comitê para um shard e época, não o conjunto de validadores que realmente assinaram; esse conjunto é representado pelo bitmap de signatários. Como resultado, um bitmap de signatários vazio ainda podia atingir o limite de quórum, porque a verificação media o tamanho do comitê em vez dos bits ativados no bitmap. Combinado com uma assinatura BLS agregada de identidade (toda zero), isso poderia fazer com que um cabeçalho de origem da era pré-staking aparentasse ter quórum suficiente.

Análise do Ataque

O atacante partiu de um recibo cross-shard genuíno, já processado, de um bloco de shard de origem anterior ao hardfork, e então o repetiu (replay) mutando apenas sua identidade de prova não autenticada. O ONE forjado foi mintado em quatro carteiras exploradoras. A análise a seguir se baseia nas transações 0xf3d4e8b1...8242c7f e 0x9a756ef9...b0a4d678.

Etapa 1: O atacante obteve um CXReceiptsProof histórico válido de um bloco de shard de origem anterior ao hardfork. A prova continha recibos válidos, um cabeçalho de bloco de origem válido e uma assinatura de commit válida do comitê de origem.
Etapa 2: O shard de destino já havia consumido esse recibo uma vez e escrito seu marcador de gasto, chaveado a partir dos campos da prova de Merkle.
Etapa 3: O atacante mutou apenas os campos de identidade da prova não autenticados, deixando o cabeçalho assinado e todos os campos cobertos por assinatura intocados:
```
MerkleProof.ShardID
MerkleProof.BlockNum
```
Etapa 4: A prova mutada foi submetida como um recibo entrante em um bloco posterior do shard de destino. IsSpent() derivou a chave do marcador de gasto a partir dos campos mutados e falhou em encontrar o marcador anterior, de modo que o recibo apareceu como não gasto.
Etapa 5: ValidateCXReceiptsProof() ainda aceitou a prova, porque os campos de identidade mutados não eram cobertos por assinatura, enquanto todos os campos autenticados permaneceram inalterados: o hash do cabeçalho e o hash de recibos saintes, o hash do bloco e o hash de recibo da prova de Merkle, o hash dos recibos, e a assinatura e o bitmap de commit.
Etapa 6: ApplyIncomingReceipt() foi executado no shard de destino e creditou o destinatário novamente via db.AddBalance(*cx.To, cx.Amount). Nenhum débito correspondente ocorreu no shard de origem, porque a transação cross-shard original já havia sido executada exatamente uma vez, produzindo inflação nativa do ONE no shard de destino.

Conclusão

A causa raiz confirmada pelo projeto foi uma falha de proteção contra replay no nível do protocolo: a identidade de estado consumido de um recibo cross-shard era derivada de campos de prova não autenticados, em vez do cabeçalho de origem assinado, de modo que um recibo já processado podia ser creditado uma segunda vez. A Harmony também confirmou uma falha separada na verificação de quórum pré-staking, embora as divulgações públicas não estabeleçam se o atacante a utilizou neste caso.

Os patches fecham ambas as lacunas [4][5][6]. De forma mais ampla, uma implementação de chain deve autenticar todos os campos que utiliza para identificar estado já consumido, e deve julgar o quórum pelos validadores que realmente assinaram, e não pelo comitê completo.

Referências

Sobre a BlockSec

A BlockSec é uma provedora full-stack de segurança blockchain e conformidade cripto. Construímos produtos e serviços que ajudam clientes a realizar auditoria de código (incluindo smart contracts, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou diversos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares, e protegeu bilhões em criptomoedas.