Harmony Cross-Shard ONE Mint + ~47 Mio. $ Key-Verluste

In der vergangenen Woche (10.08.2026 - 16.08.2026) werden die folgenden 5 bemerkenswerten Sicherheitsvorfälle vorgestellt, mit Gesamtverlusten von rund 47 Mio. USD.

Datum	Vorfall	Typ	Geschätzter Verlust
10.08.2026	Coinsbuy	Kompromittierung privater Schlüssel	~7,9 Mio. USD
10.08.2026	Unbekannte Whale-Wallet	Kompromittierung privater Schlüssel	~25 Mio. USD
12.08.2026	Harmony	Validierungsproblem	Unbekannt*
13.08.2026	Kite	Kompromittierung privater Schlüssel	~14 Mio. USD
15.08.2026	Fox	Fehler in der Geschäftslogik	~117.000 USD

*Harmony berichtete von einer bestätigten ersten Mint-Welle von 4 Mrd. ONE und einer umfassenderen Rekonstruktion von etwa 3,01 Bio. ONE gefälschten Token, von denen etwa 2,385 Bio. ONE transferiert wurden [1]. Beim Preis vor dem Vorfall von ~0,001183 USD hat die gefälschte Menge einen Nominalwert von ~3,56 Mrd. USD, was jedoch etwa dem 200-fachen der Gesamtversorgung von ONE entspricht und die Marktkapitalisierung des Tokens bei Weitem übersteigt, sodass es sich weder um einen realisierbaren noch um einen bestätigt realisierten Verlust handelt. Harmony hat die Chain seitdem auf einen Checkpoint vor dem Angriff zurückgesetzt und den gefälschten Zustand verworfen [2]. Harmony ist daher von den Gesamtverlusten ausgeschlossen.

Gründe für die Auswahl

Harmony: Ausgewählt, weil eine Schwachstelle im Replay-Schutz der Chain-Implementierung eine unautorisierte Ausgabe des nativen Tokens in massivem Umfang über das gesamte Harmony-Ökosystem hinweg ermöglichte. Während der Untersuchung wurde eine separate Schwachstelle bei der Quorum-Verifizierung aus der Pre-Staking-Ära identifiziert, deren Rolle beim Exploit jedoch nicht bestätigt ist.

Highlight der Woche: Harmony

Harmony wird diese Woche vorgestellt, weil sich die Schwachstelle in der Chain-Implementierung selbst befand und nicht in einem Anwendungsvertrag – ein ungewöhnlich folgenschwerer Fehlermodus, da er das Basis-Asset einer gesamten Layer-1 aufblähen kann.

Am 12. August 2026 erlitt Harmony, eine geshardete Layer-1-Blockchain, eine unautorisierte Prägung ihres nativen ONE-Tokens durch eine Schwachstelle beim Replay von Cross-Shard-Belegen (Receipts). Ziel-Shards identifizierten einen bereits verbrauchten Beleg anhand von Feldern, die nicht von der Signatur des Quell-Komitees abgedeckt waren, sodass ein Angreifer einen echten, bereits gutgeschriebenen Beleg erneut vorlegen konnte, indem er lediglich diese Felder veränderte, und ihn erneut gutgeschrieben bekam, ohne dass eine entsprechende Belastung auf dem Quell-Shard erfolgte. Harmony glich eine bestätigte erste Mint-Welle von 4 Mrd. ONE mit einer umfassenderen Rekonstruktion von etwa 3,01 Bio. gefälschten ONE und etwa 2,385 Bio. transferierten ONE durch eine gefälschte Mint-Wallet ab; keiner dieser Werte stellt einen bestätigt realisierten Verlust dar, und die endgültigen Auswirkungen unterliegen weiterhin dem Rollback und dem Abgleich mit Börsen [1][2]. Während der Untersuchung identifizierte Harmony eine separate Schwachstelle bei der Quorum-Verifizierung aus der Pre-Staking-Ära, hat jedoch nicht bestätigt, ob der Exploit darauf beruhte.

Hintergrund

Harmony ist eine geshardete Layer-1-Blockchain. Jeder Shard verwaltet seinen eigenen unabhängigen Zustand, sodass ein Quell-Shard ein Konto auf einem Ziel-Shard nicht direkt verändern kann. Um Werte zwischen Shards zu übertragen, verwendet Harmony ein asynchrones, beleg-basiertes Design: Der Quell-Shard belastet den Absender und erzeugt einen Cross-Shard-Beleg, und der Ziel-Shard schreibt den Betrag später dem Empfänger gut.

Ein Cross-Shard-Beleg erfasst den Transfer selbst:

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

Der Ziel-Shard vertraut keinem nackten Beleg. Der Beleg reist innerhalb eines CXReceiptsProof, der einen Merkle-Beweis, den Quell-Block-Header und die Commit-Signatur des Quell-Komitees über diesen Header enthält:

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
}

Der normale Verifizierungspfad validiert den Beweis anhand des signierten Quell-Headers und dessen Komitee-Signatur:

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

Da der Quell-Shard die Belastung genau einmal durchführt, muss der Ziel-Shard sicherstellen, dass jeder Cross-Shard-Beleg nur einmal verbraucht wird.

Schwachstellenanalyse

Der Cross-Shard-Abwicklungspfad enthielt zwei Probleme: eine Schwäche im Replay-Schutz bei der Identifizierung eines bereits verbrauchten Belegs sowie eine Schwäche bei der Quorum-Verifizierung aus der Pre-Staking-Ära.

Cross-Shard-Beleg-Replay

Der Replay-Schutz zeichnete den „Verbraucht"-Marker eines Belegs auf und suchte danach, doch sein Schlüssel stammte aus zwei veränderlichen Feldern des Merkle-Beweises:

CXMerkleProof.ShardID
CXMerkleProof.BlockNum

Der Bloom-Hardfork verstärkte dies im Mainnet bei Epoch 2964 (13. Juli 2026), gesteuert durch IsCXMerkleProofReplayFixEpoch [3]: Für einen Beweis, dessen signierte Header.Epoch() bei oder nach dieser Epoche liegt, leiten IsSpent() und WriteCXReceiptsProofSpent() den Schlüssel des „Verbraucht"-Markers aus dem signierten Quell-Header ab (Header.ShardID und Header.Number) statt aus jenen beiden Feldern. Die stärkere Schlüsselbildung wurde jedoch nie rückwirkend angewendet – für einen Beweis, dessen Header.Epoch() vor dem Fork liegt, behielten beide Funktionen den veralteten Fallback auf MerkleProof.ShardID und MerkleProof.BlockNum bei, welche ValidateCXReceiptsProof() für diese Epochen nie an den signierten Header gebunden hatte.

Diese beiden Felder liegen außerhalb der Commit-Signatur, die nur den Quell-Header abdeckt. Eine Veränderung des Header würde bei VerifyHeaderSignature() scheitern, aber das Verändern von MerkleProof.ShardID oder MerkleProof.BlockNum bricht überhaupt keine Prüfung – weder die Header-Signatur, noch die Beweisvalidierung, die diese für diese Epochen nie mit dem Header verknüpft hatte. Da der veraltete Schlüssel des „Verbraucht"-Markers aus diesen nicht authentifizierten Feldern abgeleitet wurde, war die Replay-Schutz-Identität eines Belegs von der Signatur entkoppelt, welche den Rest des Beweises authentifizierte: Zwei Beweise mit demselben signierten Header und denselben Belegen, aber unterschiedlichen Werten für MerkleProof.ShardID oder MerkleProof.BlockNum, wurden für Zwecke der Verbrauchsverfolgung als verschieden behandelt.

Pre-Staking-Quorum-Prüfung

Ein zweiter Fehler betraf die Quorum-Verifizierung aus der Pre-Staking-Ära. Die Logik von uniformVerifier.IsQuorumAchievedByMask() verglich den Schwellenwert mit

len(mask.Publics)

und behandelte diesen Wert als Anzahl der Unterzeichner. Doch mask.Publics ist die vollständige Liste der öffentlichen Schlüssel des Komitees für einen Shard und eine Epoche, nicht die Menge der Validatoren, die tatsächlich unterschrieben haben; diese Menge wird durch die Signer-Bitmap repräsentiert. Infolgedessen konnte eine leere Signer-Bitmap den Quorum-Schwellenwert dennoch erreichen, da die Prüfung die Komiteegröße statt der aktivierten Bitmap-Bits maß. In Kombination mit einer identitätsähnlichen (vollständig aus Nullen bestehenden) aggregierten BLS-Signatur konnte dies dazu führen, dass ein Quell-Header aus der Pre-Staking-Ära ein ausreichendes Quorum aufzuweisen schien.

Angriffsanalyse

Der Angreifer ging von einem echten, bereits verarbeiteten Cross-Shard-Beleg aus einem Quell-Shard-Block vor dem Hardfork aus und replayte ihn dann, indem er nur dessen nicht authentifizierte Beweisidentität veränderte. Das gefälschte ONE wurde in vier Exploiter-Wallets geprägt. Die folgende Analyse basiert auf den Transaktionen 0xf3d4e8b1...8242c7f und 0x9a756ef9...b0a4d678.

Schritt 1: Der Angreifer beschaffte sich einen gültigen historischen CXReceiptsProof aus einem Quell-Shard-Block vor dem Hardfork. Der Beweis enthielt gültige Belege, einen gültigen Quell-Block-Header und eine gültige Commit-Signatur des Quell-Komitees.
Schritt 2: Der Ziel-Shard hatte diesen Beleg bereits einmal verbraucht und dessen „Verbraucht"-Marker geschrieben, der aus den Merkle-Beweis-Feldern abgeleitet war.
Schritt 3: Der Angreifer veränderte nur die nicht authentifizierten Beweisidentitätsfelder, ließ jedoch den signierten Header und alle signaturgeschützten Felder unverändert:
```
MerkleProof.ShardID
MerkleProof.BlockNum
```
Schritt 4: Der veränderte Beweis wurde als eingehender Beleg in einem späteren Ziel-Shard-Block eingereicht. IsSpent() leitete den Schlüssel des „Verbraucht"-Markers aus den veränderten Feldern ab und fand den früheren Marker nicht, sodass der Beleg als unverbraucht erschien.
Schritt 5: ValidateCXReceiptsProof() akzeptierte den Beweis dennoch, weil die veränderten Identitätsfelder nicht signaturgeschützt waren, während alle authentifizierten Felder unverändert blieben: der Header-Hash und der ausgehende-Beleg-Hash, der Merkle-Beweis-Block-Hash und der Beleg-Hash, der Belege-Hash sowie die Commit-Signatur und -Bitmap.
Schritt 6: ApplyIncomingReceipt() wurde auf dem Ziel-Shard ausgeführt und schrieb dem Empfänger den Betrag über db.AddBalance(*cx.To, cx.Amount) erneut gut. Auf dem Quell-Shard erfolgte keine entsprechende Belastung, da die ursprüngliche Cross-Shard-Transaktion bereits genau einmal ausgeführt worden war, was zu einer nativen ONE-Inflation auf dem Ziel-Shard führte.

Fazit

Die vom Projekt bestätigte Grundursache war ein Ausfall des Replay-Schutzes auf Protokollebene: Die Identität des verbrauchten Zustands eines Cross-Shard-Belegs wurde aus nicht authentifizierten Beweisfeldern abgeleitet statt aus dem signierten Quell-Header, sodass ein bereits verarbeiteter Beleg ein zweites Mal gutgeschrieben werden konnte. Harmony bestätigte zudem eine separate Schwachstelle bei der Quorum-Verifizierung aus der Pre-Staking-Ära, jedoch geht aus den öffentlichen Offenlegungen nicht hervor, ob der Angreifer diese hier ausnutzte.

Die Patches schließen beide Lücken [4][5][6]. Allgemeiner betrachtet muss eine Chain-Implementierung jedes Feld authentifizieren, das sie zur Identifizierung bereits verbrauchten Zustands verwendet, und das Quorum anhand der tatsächlich unterschreibenden Validatoren beurteilen, nicht anhand des gesamten Komitees.

Referenzen

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei unterstützen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um über 20 Millionen US-Dollar zu retten, und Kryptowährungen im Milliardenwert abgesichert.