Web3 Sicherheitsbericht August: 29 Hauptsicherheitsvorfälle mit einem Verlust von über 68,29 Millionen USD

Im August 2026 waren die Hauptursachen für schwerwiegende Sicherheitsvorfälle Vertragsanfälligkeiten, darunter 18 Vorfälle aufgrund von Vertrags-/Netzwerkschwächen und 2 Vorfälle aufgrund von Schlüsselverlusten. Die Sicherheit von Smart Contracts und das Management privater Schlüssel bleiben nach wie vor Schwachstellen in der Web3-Sicherheit.

Verfasser: Beosin

Laut den Überwachungsdaten der Beosin Alert-Plattform belief sich der Gesamtverlust durch verschiedene Sicherheitsvorfälle im August 2026 auf etwa 76,15 Millionen USD, wobei insgesamt 29 schwerwiegende Sicherheitsvorfälle auftraten, hauptsächlich aufgrund von Vertragsanfälligkeiten. Davon gab es 18 Vorfälle aufgrund von Vertrags-/Netzwerkschwächen und 2 Vorfälle aufgrund von Schlüsselverlusten. Die Sicherheit von Smart Contracts und das Management privater Schlüssel bleiben nach wie vor Schwachstellen in der Web3-Sicherheit.

Top 10 Verluste im August

Am 13. August wurde die persönliche Benutzeradresse 0x13e3....179e aufgrund eines Schlüsselverlusts um WBTC, cbBTC, LDO, USDS, CRV und andere Krypto-Assets betrogen, mit einem Gesamtverlust von etwa 25,6 Millionen USD, was den höchsten tatsächlichen Verlust unter den Sicherheitsvorfällen darstellt. Am 30. August wurde das Kreditprotokoll Tectonic im Cronos-Netzwerk aufgrund von Vertragsanfälligkeiten von Hackern angegriffen, mit einem geschätzten Verlust von etwa 74 Millionen USD. Dieser Angriff führte dazu, dass das Cronos-Netzwerk Notmaßnahmen ergriff, das Netzwerk pausierte und Transaktionen zurückrollte. Die Hacker konnten schließlich durch Cross-Chain-Transaktionen etwa 6 Millionen USD ins Ethereum-Netzwerk transferieren.

Darüber hinaus wurden aufgrund einer Schwachstelle im Harmony Public Chain etwa 4 Milliarden ONE-Token zusätzlich geprägt, was nominalen Verlusten von über 4 Millionen USD entspricht, aber letztendlich durch das Zurückrollen von Transaktionen der Status der gefälschten Token bereinigt wurde, sodass dies nicht als Verlust gezählt wird.

Angreifertypen und Verlustsituation nach Ketten

In diesem Monat umfassten die angegriffenen Objekte verschiedene Typen wie öffentliche Ketten, Kreditprotokolle, Wallet-Anwendungen, Token-Verträge, Cross-Chain-Brücken und normale Benutzer. Dabei verzeichneten DeFi-Projekte die höchsten Verluste mit insgesamt 33,09 Millionen USD; während persönliche Adressen aufgrund von Schlüsselverlusten oder Phishing etwa 28,4 Millionen USD verloren. Die Anzahl der Angriffe auf Token-Verträge war am höchsten, mit insgesamt 10 Vorfällen; DeFi-Verträge wurden insgesamt 9 Mal angegriffen.

Die Kette mit den höchsten Verlusten im Mai war Ethereum, mit Verlusten von über 48,58 Millionen USD und insgesamt 15 Sicherheitsvorfällen. Die meisten DeFi-Protokolle und Phishing-Angriffe auf Wale konzentrieren sich weiterhin auf Ethereum. Die Kette mit den zweithäufigsten Sicherheitsvorfällen war die BNB Chain, wobei die Angriffsziele hauptsächlich Token-Verträge waren, was zu geringeren Verlusten führte. Darüber hinaus gab es auch Sicherheitsvorfälle auf anderen öffentlichen Ketten wie Cronos, Base, Harmony, Bitcoin und Solana, was auf eine Multi-Chain-Angriffsituation hinweist.

Analyse der Hauptsicherheitsvorfälle

1. Tectonic und Moonwell: Preismanipulation

Tectonic und Moonwell sind On-Chain-Kreditprotokolle, die aufgrund der Manipulation von Preisen von illiquiden Token als Sicherheiten angegriffen wurden, wodurch überbewertete Vermögenswerte ausgeliehen wurden, um Gewinne zu erzielen. Bei dem Angriff auf Tectonic erhöhte der Angreifer den Preis des Governance-Tokens $TONIC um das 100-fache und erhielt ein Darlehen von etwa 74 Millionen USD, das er anschließend in USDT und andere Vermögenswerte auslieh. Nach dem Vorfall pausierte das Cronos-Netzwerk die gesamte Kette, und der Angreifer transferierte vor der Pausierung etwa 6 Millionen USD nach Ethereum. Anschließend rollte das Cronos-Netzwerk zurück, um die Verluste zu minimieren.

Die Adresse des Hackers, die Gewinne in Ethereum erzielt hat: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD und der Fluss der gestohlenen Gelder:

Derzeit sind etwa 2659 ETH noch auf 0xc4041 gespeichert, 140,1 ETH wurden an 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c transferiert und dann weiter auf mehrere neu erstellte Adressen verteilt.

Moonwell hingegen verlor etwa 8,7 Millionen USD, weil der Angreifer den Preis des illiquiden MAMO-Tokens manipulierte, um cbBTC auszuleihen:

Diese beiden Angriffe basierten nicht auf Schwachstellen in Smart Contracts, sondern darauf, dass das Protokoll die Sicherheiten aus schwacher Spotliquidität bewertete und den Wert der Sicherheiten falsch berechnete. Um solche Angriffe zu vermeiden, könnte das Protokoll Daten aus mehreren Orakeln beziehen und zusätzliche Überprüfungen bei starken Preisbewegungen durchführen.

2. Harmony: Replay-Angriff

Harmony ist eine Layer-1-Blockchain, die Sharding unterstützt und vier Shards betreibt, wobei sie ein asynchrones Cross-Shard-Mechanismus auf Basis von Belegen zur Übertragung von Vermögenswerten zwischen ihnen verwendet. Der Quell-Shard generiert kryptografische Belege für ausgehende Transaktionen, während der Ziel-Shard dafür verantwortlich ist, vor der Buchung der Transaktion zu überprüfen, ob der Beleg und sein Merkle-Beweis mit dem signierten Quellblockkopf übereinstimmen, wobei jeder Beleg nur einmal verwendet werden kann.

Die Schwachstelle in diesem Angriff lag im veralteten Teil des Harmony-Sharding-Systems. Zuvor überprüfte Harmony, ob die Shard-Belege bereits verwendet wurden, indem es zwei Felder, CXMerkleProof.ShardID und BlockNum, betrachtete,

Da sich diese beiden Felder außerhalb des signierten Blockkopfes befinden, konnte der Angreifer sie ändern, ohne bestehende Funktionen zu beeinträchtigen. Bei diesem Angriff erlangte der Angreifer einen Cross-Shard-Beleg und änderte die ShardID und BlockNum, sodass der Verifier ihn als neuen Beleg erkannte. Der Ziel-Shard akzeptierte den geänderten Beleg und buchte ihn erneut, während der ursprüngliche Shard die entsprechenden Vermögenswerte nicht abgezogen hatte.

Dies ist ein sehr typischer Replay-Angriff. Für alle Felder, die als „einmalig verwendbare Markierungen“ dienen, müssen sie Teil des signierten Kopfes sein. Bei der Überprüfung von Belegen sollten die Shard-ID und die Blocknummer direkt aus dem signierten Blockkopf gelesen werden, anstatt den nicht zertifizierten Feldern der Beweisstruktur zu vertrauen.

3. Term Finance: Governance-Angriff

Term Finance ist ein DeFi-Protokoll für Kredite mit festem Zinssatz, dessen jede Vault auf dem ERC-4626 Vault basierenden Yearn V3-Code basiert. Die Governance der Term Finance Vaults erfolgt nicht durch Genehmigungsabstimmungen, sondern durch Ablehnungsabstimmungen. Wenn Kuratoren einen Vorschlag zur Änderung von Parametern einreichen, öffnet der Governance-Prozess ein Fenster, in dem LP-Token-Inhaber Einwände erheben können. Die Schwelle für die Governance-Abstimmung weist jedoch schwerwiegende Schwächen auf:

● Fehlende absolute Stimmen- oder Kapitaluntergrenze: Die Bedingungen für die Genehmigung eines Vorschlags, isSupportThresholdReached() und isMinParticipationReached(), überprüfen nur relative Anteile und nicht absolute Stimmen. Das bedeutet, dass ein Vorschlag genehmigt werden kann, solange er die relative Mehrheit erreicht, unabhängig von der Gesamtzahl der Stimmen oder des Kapitals.

● Extrem niedrige Beteiligung: Fast keine Einleger haben Vault-Anteile (tmvETH) in Governance-Token (gtmvETH) umgewandelt, um an Abstimmungen teilzunehmen. Dies führte zu einer extrem niedrigen Gesamtversorgung der Governance-Token der betreffenden Vaults.

Angreifer nutzten die oben genannten Designfehler, um mit sehr geringen Kosten einen Governance-Angriff auf die Vaults durchzuführen:

(1) Erwerb von Stimmrechten: Der Angreifer tauschte etwa 0,5 ETH gegen etwa 0,485 tmvETH Vault-Anteile und verpackte diese 1:1 in 0,485 gtmvETH Governance-Token, um Stimmrechte zu erlangen.

(2) Einreichung eines böswilligen Vorschlags: Bei der Erstellung des Vorschlags wurde die Gesamtversorgung der Governance-Token zu diesem Zeitpunkt mit nur 0,535 gtmvETH aufgezeichnet. Das bedeutet, dass die 0,485 gtmvETH, die der Angreifer hielt, 90,66 % der Gesamtmenge ausmachten.

(3) Abstimmung und Ausführung: Der Angreifer gab als einziger Wähler eine Zustimmung ab. Da es keine Gegenstimmen gab, überstieg seine Zustimmungsrate weit den Schwellenwert von 50 %; gleichzeitig überstieg seine persönliche Stimmkraft auch die Mindestbeteiligungsschwelle (minVotingPower), die auf der extrem niedrigen Gesamtversorgung basierte.

(4) Abhebung von Vermögenswerten: Nach Genehmigung des Vorschlags wurde eine böswillige Operation ausgeführt, um die Vermögenswerte (WETH) aus der Vault abzuziehen.

Der Angreifer wandte dieselbe Methode an und griff 6 Vaults von Term Finance an, was zu einem Verlust von etwa 8,5 Millionen USD führte.

Dieser Angriff ist ebenfalls ein sehr typischer Governance-Angriff auf On-Chain-Protokolle. Um On-Chain-Governance zu schützen, sollten Projekte die folgenden Kontrollpunkte einrichten:

● Festlegung einer absoluten Stimmen- oder Kapitaluntergrenze: Governance-Vorschläge sollten nicht nur auf relativen Anteilen basieren. Es muss eine harte Schwelle auf Basis absoluter Zahlen festgelegt werden, z. B. dass die Zustimmung eine bestimmte Summe (z. B. 1 Million USD) oder eine bestimmte Anzahl unabhängiger Adressen erreichen muss.

● Ausrüstung von Zeitverzögerungen mit Aufsichtspersonen oder Stornierungswegen: Obwohl die Durchführung der Governance normalerweise verzögert wird, bietet dies nur eine gewisse Reaktionszeit. Projekte müssen effektive Überwachungsmechanismen (Guardian) oder Stornierungswege für die Verzögerungszeit einrichten. Wenn während der Verzögerungszeit ein böswilliger Vorschlag entdeckt wird, kann der Guardian sofort eingreifen und stornieren.

● Überwachung der Governance-Beteiligung: Protokolle sollten eine Echtzeitüberwachung der Governance-Beteiligung für jede Vault einrichten. Wenn festgestellt wird, dass die Gesamtversorgung der Governance-Token oder die Abstimmungsteilnahme einer Vault ungewöhnlich niedrig ist, sollten sofort Warnungen ausgegeben und sogar Schutzmaßnahmen automatisch ausgelöst werden.

Trends bei Web3-Sicherheitsbedrohungen

Die tiefste Tendenz der Web3-Sicherheit im Jahr 2026 ist die systematische Erweiterung der Angriffsfläche. Schwachstellen treten sowohl auf Code-Ebene als auch im täglichen Betrieb und in Interaktionen auf, sodass mehrere Sicherheitsprüfungen oder Tools nicht ausreichen, um die Betriebssicherheit, On-Chain-Governance und geschäftliche Logikfehler abzudecken. Dies stellt neue Herausforderungen für Web3-Projekte bei der Schaffung von Sicherheitsabwehrsystemen dar.

Darüber hinaus nehmen Angriffe auf DeFi-Verträge und persönliche Benutzer zu. Vertragsanfälligkeiten oder Autorisierungen sind leicht von Angreifern auszunutzen. Vertragsentwickler oder Betreiber sollten die Sicherheit der Verträge überprüfen, und für Verträge, die das Kerngeschäft abwickeln, sollten mehrere, umfassende Sicherheitsprüfungen durchgeführt werden. Für persönliche Benutzer ist es ratsam, regelmäßig Blockchain-Explorer oder Widerrufs-Tools zu verwenden, um nicht mehr verwendete Vertragsautorisierungen zu überprüfen und zu widerrufen und sich über gängige und neue Phishing-Methoden zu informieren, um das Sicherheitsbewusstsein zu erhöhen.