~23 Mio. $ verloren: Exploits bei Cosmos EVM und Moonwell | BlockSec Weekly

Während des Berichtszeitraums (22.08.2026 - 30.08.2026) haben wir 5 Sicherheitsvorfälle mit einem geschätzten Gesamtschaden von etwa 22,7 Mio. USD beobachtet.

*Die Cosmos-EVM-Serie begann am 20.08. (MANTRA), noch vor dem Berichtszeitraum dieser Woche, und wurde im letzten Wochenbericht nicht behandelt; sie wird hier der Vollständigkeit halber aufgeführt. Die ~5,7 Mio. USD sind der Betrag, den die Angreifer über die sechs betroffenen Chains realisiert haben (~2,87 Mio. USD über DEXes und ~2,85 Mio. USD über zentralisierte Börsen, seither eingefroren), zu Preisen vom 19. August, laut der offiziellen Cosmos-Post-Mortem-Analyse. Die nominalen Abflüsse waren größer, sofern eine Token-Menge bekannt ist (TAC ~3 Mrd. TAC, ~7,5 Mio. USD; MANTRA 720,9 Mio. Token, ~3,6 Mio. USD; KiiChain 148,3 Mio. KII), aber die meisten Token blieben unverkauft, eingefroren oder waren on-chain wiederherstellbar.

†Die ~1,1 Mio. USD sind der geschätzte Gesamtbetrag über die Rain-unterstützten Programme, die durch den gemeinsamen Contract offengelegt wurden; Avici und Tria sind die beiden größten, mit gemeldeten ~500.859 USD (1.685 Nutzer) bzw. ~431.945 USD (636 Nutzer).

‡Die ~6 Mio. USD sind der realisierte Schaden, der vor dem Rollback zu Ethereum gebrückt wurde. Schätzungen des gesamten Abflusses reichen von ~74 Mio. USD (nachverfolgt in den Wallets des Angreifers) bis ~119,5 Mio. USD (Brutto-Marktabfluss); der Großteil verblieb auf Cronos und wurde gelöscht, als die Validatoren die Chain auf ihren Zustand vor dem Exploit zurücksetzten. Weder Tectonic noch Cronos haben eine endgültige Schadenssumme bestätigt.

Highlight der Woche: The Cosmos EVM Exploit Series (nachverfolgt auf der TAC Chain)

Diese Serie wurde ausgewählt für das, was sie über die Offenlegung bei gemeinsam genutzter Infrastruktur zeigt: Da der Fehler fälschlicherweise als keine ernsthafte Sicherheitsbedrohung eingestuft wurde, wurde die Behebung als stiller öffentlicher Patch statt über eine koordinierte private Verteilung ausgeliefert, und ein Fork eines Drittanbieters beschrieb daraufhin den Exploit-Pfad öffentlich, wodurch jede ungepatchte Chain, die das Modul noch betrieb, offengelegt wurde.

Zwischen dem 20.08.2026 und dem 25.08.2026 führten Angreifer eine einzelne Exploit-Kette durch, die zwei Schwachstellen im gemeinsam genutzten cosmos/evm-Modul über sechs Cosmos-EVM-Chains hinweg kombinierte. Beide Fehler befanden sich im Code, der den EVM-Zustand mit dem Cosmos-x/bank-Ledger abgleicht: ein Balance-Unterlauf und ein passender Überlauf, verkettet innerhalb einer einzigen, supply-neutralen Transaktion.

Laut der offiziellen Cosmos-Post-Mortem-Analyse wurde der Fehler im April über das Bounty-Programm gemeldet und zunächst fälschlicherweise als nicht bedrohlich für Produktionsgelder eingestuft, sodass er den Prozess für stille öffentliche Patches durchlief und am 19.08. in v0.6.2 und v0.7.2 ausgeliefert wurde. Am 20.08. beschrieb ein Fork eines Drittanbieters öffentlich den Exploit-Pfad, und die ersten Abflüsse begannen Stunden später, wobei zuerst MANTRA (20.08.) getroffen wurde, dann TAC und KiiChain (22.08.) [1][2]. Über alle sechs Chains hinweg realisierten die Angreifer etwa 5,7 Mio. USD zu Preisen vom 19. August (etwa 2,87 Mio. USD über DEXes verkauft und ~2,85 Mio. USD über zentralisierte Börsen, seither eingefroren) [1].

Dieser Bericht analysiert die TAC Chain im Detail als ausgearbeitetes Beispiel; sie war die am stärksten betroffene Chain der Serie, mit einem nominalen Verlust des Staking-Pools von ~7,5 Mio. USD [3].

Hintergrund

Die TAC Chain betreibt sowohl das Cosmos SDK als auch die EVM. Eine tac1...-Adresse und eine 0x...-Adresse teilen sich dieselben zugrunde liegenden 20 Bytes, sodass eine einzelne Adresse zunächst als Cosmos-Vesting-Konto angelegt und später mit einem EVM-Contract auf dieselbe Adresse bereitgestellt werden kann. Dies sind keine zwei separaten Konten: Dieselbe Adresse trägt gleichzeitig Vesting-Zustand und Contract-Code. Beide laufen nebeneinander, und TAC macht native Cosmos-Aktionen wie Staking über Precompiled Contracts an festen Adressen für EVM-Aufrufer zugänglich, sodass ein EVM-Contract sie wie jeden anderen Aufruf ausführen kann.

Der Bank-Gesamtsaldo eines Vesting-Kontos umfasst gesperrte Token. Der gesperrte Anteil kann vor dem Vesting nicht übertragen werden, während der verfügbare (spendable) Saldo dem entspricht, was nach Abzug des gesperrten Betrags vom Gesamtsaldo übrig bleibt. Wenn die EVM ein Konto lädt, initialisiert sie den StateDB-Saldo aus dem verfügbaren Saldo, und Contract-Übertragungen während der Ausführung operieren auf diesem Saldo.

Am Ende einer Transaktion werden die Saldoänderungen in der StateDB in x/bank, das maßgebliche Ledger, zurückgeschrieben, und nur was dort abgerechnet wird, ist echtes, übertragbares TAC. TAC läuft auf der v0.7.x-Linie, die einen EVM-Saldo direkt in x/bank schreibt, jedoch nur, wenn der Wert eine uint256-zu-int256-Konvertierung übersteht, sodass ein Saldo nahe 2^256 überhaupt nicht abgerechnet werden kann.

Gesperrte Token können nicht übertragen, aber dennoch für Staking delegiert werden. Die Delegation prüft den Bank-Gesamtsaldo, der gesperrte Token einschließt, und behält dann die Vesting-Beschränkung durch DelegatedVesting bei. Für ein vollständig gesperrtes Konto mit total=1 reduziert die Delegation dieser Einheit den Bank-Gesamtsaldo auf 0 und aktualisiert DelegatedVesting, während der verfügbare Saldo sowohl vorher als auch nachher korrekt bei 0 bleibt.

Schwachstellenanalyse

Die fehlerhafte Komponente ist die Saldosynchronisierung im gemeinsam genutzten cosmos/evm-Handler, der bei jedem zustandsverändernden Aufruf des Staking-Precompiles ausgeführt wird, zugänglich über das Staking-Precompile unter 0x0000...0800 und implementiert in [4]. Sie gleicht EVM-Salden mit dem Cosmos-Ledger über ungeprüfte uint256-Arithmetik ab, und dies legt zwei sich ergänzende Fehler offen: einen Balance-Unterlauf auf dem Rückschreibpfad des Stakings und einen passenden Überlauf auf dem normalen Additionspfad. Keiner ist für sich allein gefährlich; das Risiko entsteht aus ihrer Kombination auf einem gemeinsamen arithmetischen Pfad.

Der erste Fehler ist ein Unterlauf beim Zurückschreiben des Saldos. Wenn ein zustandsverändernder Aufruf des Staking-Precompiles ausgeführt wird, läuft die native Cosmos-Aktion zwischen einem BeforeBalanceChange- und einem AfterBalanceChange-Hook, und AfterBalanceChange ist dafür verantwortlich, die native Saldoänderung zurück in die EVM-StateDB zu übertragen.

Die Delegation prüft gegen den Bank-Gesamtsaldo, sodass ein vollständig gesperrtes Konto die Delegationsprüfung bestehen kann, während sein verfügbarer Saldo bei 0 bleibt. Die native Delegation zieht den delegierten Betrag vom Bank-Gesamtsaldo ab und löst ein coin_spent-Ereignis aus. Der Fehler liegt darin, wie AfterBalanceChange dieses Ereignis verarbeitet: Statt den aktuellen verfügbaren Saldo des Kontos neu zu laden und zuzuweisen, spielt es den coin_spent-Betrag als stateDB.SubBalance(spender, amount) erneut ab und zieht ihn vom bestehenden EVM-Saldo ab.

Da SubBalance die Subtraktion mit ungeprüfter uint256-Arithmetik durchführt, läuft jedes Konto, dessen EVM-Saldo kleiner ist als der Ereignisbetrag, unter. Für ein Konto mit EVM-Saldo 0 und einem coin_spent-Betrag von 1 wird 0 - 1 auf MAX_UINT256 umgeschlagen.

Der zweite Fehler ist ein passender Überlauf auf dem Additionspfad. Jede Saldoübertragung führt SubBalance beim Absender und AddBalance beim Empfänger über dieselbe StateDB aus, sodass sich beide Richtungen einen arithmetischen Pfad teilen.

Beide lösen sich zu denselben stateObject-Primitiven auf, bei denen AddBalance und SubBalance new(uint256.Int).Add(s.Balance(), amount) bzw. .Sub(s.Balance(), amount) ohne Bereichsprüfung berechnen. Genau wie die Subtraktion unter 0 unterläuft, überläuft eine ausreichend große Addition über MAX_UINT256 hinaus und schlägt zurück auf niedrige Werte um.

Die beiden Fehler ergänzen sich. Für sich allein erzeugt der Unterlauf einen MAX_UINT256-Saldo, der wirkungslos ist, da ein Wert nahe 2^256 die uint256-zu-int256-Konvertierung, die die Abrechnung in x/bank erfordert, nicht übersteht. Die ungeprüfte Addition ist das Gegenstück: Sie ist der einzige Pfad, der einen solch überdimensionierten Saldo wieder unter diese Abrechnungsobergrenze zurückbringen kann.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xae4e9b...da46fc.

• Schritt 1: In der Transaktion 0x4da591...df1af7 stellte der Angreifer eine CREATE2-Factory bereit, sodass die Angriffs-Contract-Adresse 0x5711...c978 berechnet werden konnte, bevor der Contract bereitgestellt wurde.

• Schritt 2: In der Transaktion 95F43742...6A885BA nutzte der Angreifer MsgCreateVestingAccount, um eine Basiseinheit (1utac) an diese zukünftige Contract-Adresse zu übertragen und zu sperren, wodurch dieser ein Bank-Gesamtsaldo verliehen wurde, der die Delegationsprüfung bestehen konnte, während der verfügbare Saldo bei 0 blieb.

• Schritt 3: In der Transaktion 0x2400f8...c57c81 nutzte der Angreifer CREATE2, um den Angriffs-Contract auf dieselbe 0x5711...c978-Adresse bereitzustellen, wodurch diese sowohl ein Cosmos-Vesting-Konto als auch ein EVM-Contract wurde, sodass ein externes Konto das Gas bezahlen konnte, während die Contract-Adresse der Delegator mit spendable=0 blieb.

• Schritt 4: Der Angriffs-Contract delegierte die gesperrte Basiseinheit über das Staking-Precompile. Der Staking-Ablauf akzeptierte die Delegation gegen den Bank-Gesamtsaldo, und das Zurückschreiben des Saldos ließ dann den EVM-Saldo des Contracts auf MAX_UINT256 umschlagen.

• Schritt 5: Der umgeschlagene MAX_UINT256-Saldo konnte so nicht in das Cosmos-Ledger zurück abgerechnet werden, daher brachte der Angriffs-Contract ihn zunächst auf einen abrechenbaren Wert herunter. Er sendete nahezu den gesamten Saldo an bonded_tokens_pool, das größte Konto der Chain und dasjenige, das das gesamte gestakte TAC hält, wobei der Betrag so gewählt wurde, dass der Saldo des Pools bei der Addition überlief und auf 0 umschlug. Da dieser Betrag vom eigenen MAX_UINT256 des Angriffs-Contracts abgezogen wurde, blieb dem Contract genau der vormalige Saldo des Pools, ohne dass neue Supply geschaffen wurde. Das Nullstellen des Pools nimmt dessen gesamten Saldo, das meiste, was dieser Überlauf ergeben konnte, weshalb der Angreifer von vornherein das größte Konto der Chain ins Visier nahm.

• Schritt 6: Der Angriffs-Contract übertrug diesen Saldo dann, 2.985.651.403,40 TAC, an die Adresse des Angreifers.

Unsere Analyse auf Transaktionsebene stimmt mit der offiziellen Cosmos-Post-Mortem-Analyse überein, die zwei verkettete Schwachstellen beschreibt: der obige Unterlauf erzeugt den anomalen Saldo, und der Überlauf in Schritt 5 der Angriffsanalyse wandelt ihn in echte Gelder des Pools um [1]. Eine frühere KiiChain-Post-Mortem-Analyse, veröffentlicht vor diesem offiziellen Bericht, vertrat die Ansicht, dass mindestens drei Upstream-Fehler beteiligt waren und nur der Unterlauf gepatcht wurde [2]. Unabhängige Presseberichte fassten dieselbe Uneinigkeit darüber zusammen, wie viele Upstream-Fehler noch bestehen [5].

Fazit

Die Grundursache der Cosmos EVM Exploit Series war eine Inkonsistenz darin, wie die EVM- und die Cosmos-Ebene denselben Saldo verbuchten, kombiniert mit Arithmetik, die nie auf Bereichsüberschreitungen geprüft wurde. Wenn zwei Laufzeitumgebungen sich ein Ledger teilen, müssen sie sich bis auf jedes einzelne Konto über die Saldo-Semantik einig sein, und jede Saldoänderung muss auf Über- und Unterlauf geprüft werden. Da der Fehler in einem gemeinsam genutzten Modul und nicht im Code einer einzelnen Chain lag, legte ein Fehler jede Chain offen, die es betrieb, und genau das machte aus einem einzelnen Bug ein Multi-Chain-Ereignis. Über den Code hinaus ist der Vorfall eine Lektion in Schweregradbewertung. Die Schwachstelle wurde zunächst als nicht bedrohlich für Produktionsgelder eingestuft, sodass ihre Behebung als stiller öffentlicher Patch ausgeliefert wurde; bis diese Einschätzung korrigiert wurde, war der Patch bereits öffentlich, und die Offenlegung des Exploit-Pfads durch einen Dritten machte aus der Fehleinschätzung sechs ausgenutzte Chains. Ein Fehler in gemeinsam genutzter Infrastruktur, der echte Gelder bewegen kann, benötigt von Anfang an eine private, koordinierte Verteilung, keinen stillen öffentlichen Patch, den jeder entschlüsseln kann.

Weitere Vorfälle dieser Woche

Moonwell

Am 27.08.2026 wurde Moonwell auf Base für etwa 9,1 Mio. USD ausgenutzt, indem eine Aufblähung der Sicherheitenbuchhaltung mit einer Oracle-Preismanipulation von MAMO, einem Asset mit geringer Liquidität, das in seinem Core Market gelistet ist, kombiniert wurde. Über das Hochtreiben des MAMO-Preises hinaus übertrug der Angreifer MAMO direkt in den mMAMO-Market-Contract, ohne Anteile zu prägen, was die Deckung jedes Anteils erhöhte und den Sicherheitswert zusätzlich zur Preisbewegung aufblähte. Gegen die doppelt aufgeblähten Sicherheiten nahm der Angreifer Bruttokredite von etwa 11,03 Mio. USD über cbBTC, WETH, USDC und wstETH auf, wobei nach Liquidationen etwa 9,13 Mio. USD an verbleibenden Verpflichtungen zurückblieben [6][7].

Schwachstellenanalyse

Der Core Market von Moonwell läuft auf Compound-v2-Code, wo ein Marktanteil (mMAMO) (cash + totalBorrows - totalReserves) / totalSupply wert ist. Zwei Schwächen kombinieren sich hier. Erstens prüft die MAMO-Supply-Obergrenze nur den formalen Mint-Pfad, sodass eine direkte Übertragung von MAMO in den mMAMO-Contract das Cash des Marktes erhöht, ohne Anteile zu prägen; dies hebt den berechneten Wechselkurs (exchangeRateStored()) und erhöht den Sicherheitswert jedes bestehenden Anteils, während die Obergrenze vollständig umgangen wird. Zweitens war MAMO als Sicherheit mit einem Sicherheitenfaktor von 50% gelistet, trotz geringer Liquidität, sodass sein Oracle-Preis mit moderatem Kapital bewegt werden kann. Da der Sicherheitswert als Anteile mal Wechselkurs mal Oracle-Preis berechnet wird, sind sowohl der Wechselkurs als auch der Preis manipulierbare Flächen, und deren gemeinsame Aufblähung vervielfacht die Kreditkapazität gegenüber weitaus liquideren Assets.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x09687d...395593e. Die Operation wurde mit etwa 1,947 Mio. USD (799 ETH, umgewandelt in USDC und zu Base gebrückt) gestartet; das Brutto-Kaufvolumen an MAMO erreichte etwa 7,50 Mio. USD, sobald geliehene Assets recycelt wurden.

• Schritt 1: Der Angreifer stellte MAMO formal bereit, um mMAMO zu prägen, und übertrug dann 53.393.290 MAMO direkt in den mMAMO-Contract in zwei Transaktionen, die kein Mint-Ereignis auslösten, wodurch der berechnete Wechselkurs des Marktes um etwa das 3,68-Fache stieg und die gerade vom Angreifer geprägten mMAMO-Anteile zusammen mit denen aller anderen Inhaber neu bewertet wurden.

• Schritt 2: Der Angreifer kaufte MAMO über DEX-Pools, während die Liquidität dünn war, und trieb den MAMO/USD-Feed von etwa 0,0106 USD auf etwa 0,43 USD hoch.

• Schritt 3: Mit sowohl aufgeblähtem Wechselkurs als auch aufgeblähtem Preis tätigte der Angreifer 18 Kreditaufnahmen über cbBTC, WETH, USDC und wstETH (etwa 11,03 Mio. USD brutto), konvertierte dann und konsolidierte die Erlöse, wobei etwa 8,729 Mio. USDC über CCTP zu Ethereum gebrückt und in etwa 8,728 Mio. DAI umgewandelt wurden.

Fazit

Die Grundursache war, dass Moonwell ein Sicherheiten-Asset mit geringer Liquidität auf zwei unabhängig voneinander manipulierbaren Flächen gleichzeitig bewertete: seinem Oracle-Preis, den dünne Liquidität dem Angreifer erlaubte, mit moderatem Kapital zu bewegen, und seinem Wechselkurs des Empfangs-Tokens, den eine direkte Übertragung des zugrunde liegenden Assets aufblähte, weil die Supply-Obergrenze nur den formalen Mint-Pfad absicherte. Da der Sicherheitswert die beiden multipliziert, vervielfachte die gemeinsame Aufblähung beider die Kreditkapazität gegenüber weitaus liquideren Assets. Ein Kreditmarkt sollte sowohl den Preis als auch die Anteilsbuchhaltung von Sicherheiten als manipulierbar behandeln: unaufgeforderte Übertragungen von der Wechselkursberechnung ausschließen und konservative Sicherheitenfaktoren mit liquiditätsbewusster Preisgestaltung sowie strengen Supply- und Kreditobergrenzen für Assets mit geringer Liquidität kombinieren.

Ajna

Am 28.08.2026 wurde Ajna über sieben Ethereum-Pools hinweg für etwa 775.000 USD durch eine Schwachstelle in der Geschäftslogik seines Liquidationspfads ausgenutzt. Ajna ist ein Kreditprotokoll, das kein externes Oracle nutzt; es bewertet Positionen über den LUP (Lowest Utilized Price), der aus der Bucket-Liquidität abgeleitet wird. Der Angreifer manipulierte zunächst den LUP, um eine schwer insolvente Position zu erzeugen, und ließ das Protokoll dann eine kontrollierte Position zu einem Dutch-Auction-Preis liquidieren, den das Protokoll noch weit über dem Marktpreis hielt, sodass Bucket-Einlageansprüche zu ihrem Nennwert in Quote-Token verbraucht wurden, um Schulden zurückzuzahlen, während der Angreifer im Gegenzug echte Sicherheiten erhielt [8].

Hintergrund

Ajna ist ein genehmigungsfreies Protokoll, bei dem jeder einen Pool aus gepaarten Token zum Bereitstellen und Leihen erstellen kann, ähnlich einem Uniswap-Pool. Jeder Pool ist in Buckets unterteilt, ähnlich den Preis-Ticks in Uniswap V3, wobei jeder Tick einen festen Betrag an Quote-Token pro Einheit Sicherheit darstellt. Kreditgeber wählen einen Bucket entsprechend ihrem bevorzugten Beleihungswert (Loan-to-Value-Verhältnis) und stellen dort Liquidität bereit, wobei sie im Gegenzug LP (einen Anspruch auf die Einlagen dieses Buckets) erhalten. Da es kein externes Oracle gibt, wird der LUP direkt aus der Bucket-Einlagenverteilung und der Gesamtverschuldung abgeleitet.

Eine Position wird liquidierbar, sobald ihr Schwellenpreis (ihre Schulden geteilt durch ihre Sicherheiten) über den LUP steigt. Jeder kann sie dann durch Hinterlegung einer Kaution in die Liquidation kicken, was eine Dutch Auction eröffnet. Der Auktionspreis ist nicht an den Spotmarkt gebunden: Er startet beim 32-Fachen eines Referenzpreises und halbiert sich stündlich, wobei er für die erste Stunde (eine Schonfrist) konstant gehalten wird, bevor er zu verfallen beginnt.

Versteigerte Sicherheiten können auf zwei Arten übernommen werden. Ein Aufrufer kann Sicherheiten durch take() übernehmen, indem er Quote-Token zum aktuellen Auktionspreis bezahlt, oder bucketTake() aufrufen, was die Quote-Einlagen eines gewählten Buckets nutzt, um die versteigerte Sicherheit zu kaufen und den Kreditnehmer zurückzuzahlen. Bei einem bucketTake() wird die Sicherheit diesem Bucket gutgeschrieben, sodass dessen Kreditgeber diejenigen sind, die sie erwerben; für einen Arbitrage-Bucket-Take wird dem Aufrufer zusätzlich eine LP-Belohnung (ein Anspruch auf diesen Bucket) auf die Spanne zwischen dem Bucket-Preis und dem Auktionspreis als Anreiz gezahlt, die Liquidation auszulösen. Das Design geht davon aus, dass ein Taker erst einsteigt, sobald der Auktionspreis auf den Wert der Sicherheit gefallen ist oder darunter liegt: Ohne Oracle ist diese absteigende Auktion die Art, wie Ajna einen fairen Preis ermittelt, und die Kreditgeber eines Buckets profitieren davon, Sicherheiten unterhalb ihres eigenen Bucket-Preises zu erwerben. Die Auktion selbst endet erst, wenn die Schulden des Kreditnehmers beglichen sind oder das Darlehen wieder ausreichend besichert ist; ein separater Abwicklungspfad löst eine Auktion nach einer 72-Stunden-Schonfrist auf, oder früher, sobald keine Sicherheiten mehr übrig sind, wobei etwaige verbleibende faule Schulden absorbiert und übrige Sicherheiten an den Kreditnehmer zurückgegeben werden.

Drei Implementierungsdetails dieses Mechanismus bestimmen die Werte, die ein Take ergibt. Erstens ist der Auktionspreis nicht marktbezogen abgeleitet; er verfällt als 32 * max(kickMomp, neutralPrice) * 2^(-max(elapsedHours - 1, 0)), sodass er während der einstündigen Schonfrist konstant bleibt und erst danach zu fallen beginnt, wobei er kurz nach dieser Frist noch nahe beim 32-Fachen seines Referenzpreises verbleibt.

Zweitens wird ein Kick nur zugelassen, wenn der Kreditnehmer bei seinen Vor-Strafgebühren-Schulden bereits unterbesichert ist: _kick() führt die _isCollateralized()-Prüfung durch und bricht mit BorrowerOk() ab, bevor die Dreimonatszins-Strafgebühr hinzugefügt wird, sodass diese Strafgebühr die erfasste Nach-Kick-Verschuldung erhöht, ohne dass sie geholfen hätte, die Position dafür zu qualifizieren.

Drittens fügt der erste Take einer Auktion dem Schuldenbetrag des Kreditnehmers eine Strafgebühr von 7% hinzu, bevor die Rückzahlungs- und Sicherheitenbeträge für den Take berechnet werden, sodass ein einzelner bucketTake() die Schulden nicht allein tilgen muss.

Schwachstellenanalyse

Der fehlerhafte Contract ist der Ajna-Pool (0xad24...178e); die hier beschriebene Liquidationslogik stammt aus diesem verifizierten Quellcode. Innerhalb von bucketTake() nutzt das Protokoll die Einlageansprüche eines Buckets zu ihrem Nennwert in Quote-Token, um die Schulden eines Auktions-Kreditnehmers zurückzuzahlen, und zahlt bei einem Arbitrage-Bucket-Take dem Taker LP-Belohnungen basierend auf der Spanne zwischen dem Bucket-Preis und dem Auktionspreis.

Es prüft nie den tatsächlichen wiedererlangbaren Wert dieser Einlageansprüche oder ob der Auktionspreis wirtschaftlich angemessen ist; es geht schlicht davon aus, dass die Ansprüche später zum Nennwert eingelöst werden können. Die beiden Preise, auf die es sich stützt, werden unabhängig voneinander berechnet, und keiner wird gegen den anderen validiert: Der LUP folgt der Bucket-Einlagenverteilung und der Gesamtverschuldung des Pools, während der Auktionspreis rein zeitbasiert von einem beim Kick festgelegten Referenzpreis verfällt. Der Nennwert eines Anspruchs kann daher on-chain von dem abweichen, was er tatsächlich wiedererlangen kann, und bucketTake() gleicht Schulden dennoch gegen diesen Nennwert ab.

Intern leitet bucketTake() über _takeBucket() zu _rewardBucketTake() weiter, wo bei einem Arbitrage-Take die LP-Belohnung des Takers als die genommene Sicherheit multipliziert mit der Spanne zwischen dem Bucket-Preis und dem Auktionspreis berechnet wird.

Angriffsanalyse

Das Folgende basiert auf der On-Chain-Analyse des cbETH-Pools, einem der sieben betroffenen, unter Verwendung der Transaktionen 0x8a8793...016e64 und 0x12dfde...14e4f5.

• Schritt 1: In der Setup-Transaktion fügte der Angreifer etwa 49,343 WETH an Quote-Liquidität zum Bucket-Index 2000 hinzu, einem Preis weit über dem Markt. Gestützt auf diesen aufgeblähten Bucket eröffnete der Angreifer eine nahezu unbesicherte Position, indem er etwa 0,001 cbETH verpfändete, um etwa 49,319 WETH zu leihen. Diese Position hält kaum Sicherheiten, sie ist also nicht der eigentliche Gewinn; sie dient zwei Zwecken in der Vorbereitung. Erstens zieht sie als insolvente Schuld den LUP nach unten, sobald der Markt wieder normal ist. Zweitens ist der Bucket 2000, da nahezu alle der 49,343 WETH, die in ihn eingezahlt wurden, nun wieder herausgeliehen sind und nur ein Staubbetrag übrig bleibt, mit einem Einlageanspruch versehen, dessen Nennwert von etwa 49,343 WETH weit über das hinausgeht, was er tatsächlich wiedererlangen kann; dieser beeinträchtigte Anspruch ist die Munition, die der Angreifer später in Schritt 4 zum Nennwert ausgibt.

• Schritt 2: In derselben Setup-Transaktion nutzte der Angreifer eine zweite kontrollierte Adresse, 0x02d329...6f5f, um eine Kreditnehmerposition auf normalem Preisniveau zu eröffnen, wobei etwa 48,128 cbETH an Sicherheiten verpfändet und dagegen etwa 49,319 WETH geliehen wurden. Dies brachte den Marktpreis zurück in einen normalen Bereich, wodurch die erste Position schwer insolvent blieb, während die zweite Position genau um ihre Gesundheitsschwelle herum lag. Diese zweite Position, die die echten Sicherheiten hält, ist diejenige, die der Angreifer tatsächlich zu entleeren beabsichtigt; die insolvente erste Position ist nur der Hebel, der den LUP bewegte.

• Schritt 3: Der Angreifer kickte dann die zweite Position (die von 0x02d329...6f5f eröffnete) in die Auktion, nicht die insolvente erste. Ein Kick wird nur akzeptiert, wenn die Position bei ihren Vor-Strafgebühren-Schulden gegen den aktuellen LUP bereits unterbesichert ist, und die insolvente erste Position hatte den LUP inzwischen so weit heruntergezogen, dass die aufgelaufenen Schulden der zweiten Position diese Schwelle erfüllten. Erst nach der Zulässigkeitsprüfung fügt das Protokoll eine Dreimonatszins-Kick-Strafgebühr hinzu, weshalb die erfasste Nach-Kick-Verschuldung auf etwa 49,362 WETH kommt. Der Kick eröffnete die Dutch Auction der Position.

• Schritt 4: Der Angreifer wartete bis kurz nach der einstündigen Schonfrist, als der Auktionspreis erst zu verfallen begann und immer noch nahe beim 32-Fachen des Referenzpreises lag. Durch Aufruf von bucketTake() auf die zweite Position im Bucket 2000, demselben Bucket, der nun den beeinträchtigten Anspruch hielt, liquidierte er sie zu diesem immer noch hohen, weit über dem Marktpreis liegenden Preis. Da dies der erste Take auf die Auktion war, fügte das Protokoll dem Schuldenbetrag des Kreditnehmers eine Strafgebühr von 7% hinzu, bevor die Rückzahlungs- und Sicherheitenbeträge des Takes berechnet wurden. Die Sicherheit wird zum Auktionspreis bewertet, sodass der Verbrauch von etwa 49,34 WETH der Einlagen des Buckets 2000 nur einen Teil dieser Schulden zurückzahlte und nur etwa 1,51 cbETH an Sicherheiten entfernte, wobei der Großteil der Sicherheiten unangetastet blieb, während der Aufrufer eine große Menge an LP-Belohnungen auf die Spanne einsammelte.

• Schritt 5: Der Angreifer löste diese LP-Belohnungen über removeCollateral() ein und entnahm einen Teil des Gewinns als Sicherheit.

• Schritt 6: Zum Abschluss nahm der Angreifer einen Balancer-Flash-Loan auf und rief Ajnas take() auf, um die von bucketTake() verbliebenen Restschulden zu begleichen, diesmal mit echtem Quote-Token, bis die Schulden des Kreditnehmers null erreichten und die Auktion endete. Ein abschließender Aufruf von repayDebt() entnahm dann die nun unbelastete Sicherheit, etwa 46,51 cbETH, mit quoteRepaid=0: Dafür wurde kein Quote-Token zurückgegeben. Der Gewinn ging auf Kosten des Pools. Der Fehlbetrag verschwand nicht, er verlagerte sich: Mit geschlossener zweiter Position blieb das noch unbeglichene, nahezu unbesicherte Darlehen der ersten Position als faule Schuld im Pool zurück, die von den anderen Kreditgebern getragen wurde.

Fazit

Die Grundursache liegt darin, dass Ajnas Liquidationspfad die Schulden eines Auktions-Kreditnehmers gegen die Einlageansprüche eines Buckets zum Nennwert abgleicht, ohne deren tatsächlichen wiedererlangbaren Wert oder die wirtschaftliche Angemessenheit des Auktionspreises zu prüfen. Diese fehlende Prüfung ermöglichte es, dass ein künstlich erzeugter beeinträchtigter Anspruch zum Nennwert ausgegeben werden konnte, um echte Sicherheiten zu entleeren, und den Fehlbetrag als faule Schuld im Pool zurückließ. Der Liquidationspfad sollte Einlageansprüche nach ihrem tatsächlichen wiedererlangbaren Betrag statt nach dem Nennwert bewerten, vor Abschluss eines Takes bestätigen, dass der Auktionspreis wirtschaftlich angemessen ist, und sich davor schützen, Ansprüche zu verbrauchen, die durch bestehende faule Schulden eines Pools bereits beeinträchtigt sind. Die betroffenen Pool-Contracts sind unveränderlich und bieten keine administrative Pausierfunktion, sodass es, sobald der Abfluss begann, keine Möglichkeit gab, ihn zu stoppen; Nutzer konnten nur auf eigene Faust aussteigen.

The Rain Card Contract Exploit Series (nachverfolgt bei Avici)

Am 28.08.2026 (UTC) wurde eine veraltete Version von Rains gemeinsam genutztem Solana-Kartensicherheiten-Programm durch eine Umgehung der Ed25519-Signaturprüfung ausgenutzt. Indem das Programm dazu gebracht wurde, eine gefälschte Admin-Genehmigung zu akzeptieren, übernahm der Angreifer die Kontrolle über Nutzer-Sicherheitenkonten und entleerte die darin gehaltenen Token-Guthaben. Da der Fehler im Programmcode lag, der über verschiedene von Rain betriebene Kartenprogramme hinweg gemeinsam genutzt wurde, legte ein einzelner Bug alle auf einmal offen: Der Exploit entleerte geschätzt ~1,1 Mio. USD insgesamt, wobei Avici und Tria die beiden größten waren, mit gemeldeten etwa 500.859 USD (1.685 Nutzer) bzw. 431.945 USD (636 Nutzer) [9].

Die folgende Analyse verwendet Avici als ausgearbeitetes Beispiel.

Hintergrund

Auf Solana werden Signaturprüfungen von einem nativen Ed25519-Precompile im Rahmen der Transaktionsverarbeitung durchgeführt: Ist eine referenzierte Signatur ungültig, schlägt die gesamte Transaktion fehl. Ein Business-Programm erhält dieses Ergebnis nicht direkt; es untersucht die anderen Anweisungen in derselben Transaktion (über die Instructions-Sysvar) und verlässt sich darauf, dass die Validierung bestanden wurde. Wenn ein Nutzer eine von Rain betriebene Karte auflädt (wie bei Avici), wird das Guthaben in einem nutzerspezifischen Sicherheitenkonto gehalten, das vom gemeinsam genutzten Rain-Programm verwaltet wird, und die Token-Autorität dieses Kontos wird vom Programm abgeleitet, sodass der Admin des Kontos die Assets in diesem Konto über den Transferablauf des Programms bewegen kann.

Das Ändern des Admins eines Sicherheitenkontos erfordert zwei Signaturen. Eine muss vom protokollbestimmten Admin stammen; der andere Unterzeichner unterliegt keiner besonderen Identitätsanforderung. Dieses Design verlässt sich auf eine Off-Chain-Autorisierung: Sobald der Protokoll-Admin die Admin-Änderungsnachricht signiert hat, behandelt das Programm sie als genehmigt.

Eine Ed25519-Verifizierungsanweisung beginnt mit einem Ein-Byte-Zähler der zu prüfenden Signaturen und einem Padding-Byte, gefolgt von jeweils einer Ed25519SignatureOffsets-Struktur pro Signatur. Jede Struktur gibt nicht nur die Byte-Offsets der Signatur, des Public Keys und der Nachricht an, sondern auch den Anweisungsindex, aus dem jeder dieser Werte gelesen werden soll [10]. Diese Indizes sind ein beabsichtigtes Feature: Sie erlauben es einer Verifizierung, ihre Eingaben aus den Daten einer beliebigen, per Index referenzierten Anweisung innerhalb der Transaktion zu lesen, etwa um eine Signatur über die Daten einer anderen Anweisung zu verifizieren, ohne diese zu kopieren. Der native Verifizierer liest schlicht, worauf die Offsets und Anweisungsindizes verweisen.

Schwachstellenanalyse

Der Fehler liegt im Sicherheiten-Programm (3zVB...yBzDuc): Es vertraut einem Public Key, ohne zu bestätigen, dass genau dieser Key auch der ist, den der Verifizierer tatsächlich geprüft hat. Um den admin-genehmigenden Unterzeichner zu erfassen, liest es einen Public Key aus einer festen Position innerhalb der Ed25519-Verifizierungsanweisung, die es untersucht, und nimmt dann die bloße Anwesenheit einer bestandenen Verifizierung als Beweis dafür, dass der Inhaber dieses Keys die Admin-Änderungsnachricht signiert hat.

Was es nie bestätigt, ist, wohin diese Verifizierung tatsächlich geschaut hat. Da diese Anweisungsindex-Felder vom Aufrufer kontrolliert werden und die Laufzeitumgebung dem nativen Verifizierer die Daten jeder Anweisung übergibt, kann die Verify-Anweisung einen Public Key in ihrem eigenen Body enthalten, während ihre Anweisungsindizes den Verifizierer auf eine andere Anweisung lenken, um eine Signatur unter einem anderen Public Key über eine separat stammende Nachricht zu verifizieren.

Es existieren also zwei Lesungen von "dem Admin-Key", ohne dass etwas sie miteinander verbindet: Das Programm vertraut dem Key, der in der von ihm untersuchten Anweisung steht, während der Verifizierer immer nur das geprüft hat, worauf die Indizes verwiesen. Der Key des Admins kann als Daten in der Transaktion vorhanden sein, obwohl niemals eine unter diesem Key gültige Signatur verifiziert wurde. Diese Entkopplung ist die Schwachstelle, und die fehlende Prüfung ist die Bindung, die erzwingen würde, dass der Public Key und die Nachricht, die der Verifizierer tatsächlich verifiziert hat, dieselben sind wie der Key und die Nachricht, denen das Programm vertraut.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion ZmpBgn...mqWL.

• Schritt 1: Der Angreifer baute eine Transaktion mit zwei Ed25519-Verifizierungsanweisungen, gefolgt von SubmitSignatures. Anweisung 0 trug den eigenen Public Key des Angreifers (cafa…53db) und eine echte Signatur über die Admin-Änderungsnachricht, wodurch die Transaktion eine echt gültige Ed25519-Verifizierung erhielt.

• Schritt 2: Anweisung 1 platzierte den Public Key des Protokoll-Admins (a2fc…959a) im Public-Key-Slot, füllte den Signatur-Slot jedoch mit gefälschten 0x09-Bytes, sodass diese Anweisung fehlschlagen würde, wenn ihre eigenen Daten tatsächlich verifiziert würden.

• Schritt 3: Der Angreifer setzte den Ed25519-Header von Anweisung 1 auf 01003000000010000000700020000000. Nur die drei Anweisungsindex-Felder bewirken die Umleitung, und dekodiert sind sie alle null, sodass die Signatur, der Public Key und die Nachricht alle aus Anweisung 0 gelesen werden (die Byte-Offsets verweisen weiterhin innerhalb der Daten dieser Anweisung):

  num_signatures      = 1,    padding = 0
  signature_offset    = 48,   signature_instruction_index   = 0
  public_key_offset   = 16,   public_key_instruction_index  = 0
  message_data_offset = 112,  message_data_size = 32,  message_instruction_index = 0

  Die zweite Verifizierung las daher Anweisung 0 erneut ein und verifizierte die eigene, gültige Signatur des Angreifers erneut, statt der ungültigen 0x09-Nutzlast in Anweisung 1.

• Schritt 4: Der Angreifer rief SubmitSignatures auf. Das Programm sah zwei erfolgreiche Ed25519-Verifizierungen, aber beim Erfassen des zweiten Unterzeichners las es den in Anweisung 1 eingebetteten Public Key des Protokoll-Admins, sodass es diesen Admin-Key als genehmigten zweiten Unterzeichner akzeptierte.

• Schritt 5: Mit dieser falschen Genehmigung nutzte der Angreifer den Admin-Änderungsablauf, um den Admin des Opfer-Sicherheitenkontos auf den Angreifer zu setzen, wodurch die Umgehung der Verifizierung in direkte Kontrolle über dieses Konto umgewandelt wurde.

• Schritt 6: Nachdem es den Aufrufer als Sicherheiten-Admin validiert hatte, bewegte das Programm Assets aus dem Karten-Sicherheiten-Token-Konto des Nutzers über seinen Transferablauf heraus, wobei es den Transfer mit seiner eigenen programmabgeleiteten Adresse (PDA) als Autorität dieses Token-Kontos aufrief.

Fazit

Die Grundursache der Rain Card Contract Exploit Series war, dass das Sicherheiten-Programm bestätigte, dass eine native Ed25519-Verifizierung gelaufen war, aber nie bestätigte, dass der Public Key und die Nachricht, denen es vertraute, auch diejenigen waren, die der Verifizierer tatsächlich geprüft hatte. Ein Programm, das sich auf native Signaturprüfung stützt, muss die von ihm konsumierten Autorisierungsdaten an diese Verifizierung binden: entweder ein in sich geschlossenes Ed25519-Layout verlangen, das seine Eingaben aus der aktuellen Anweisung liest, oder jede referenzierte Anweisung auflösen und den verifizierten Public Key sowie die Nachricht Byte für Byte mit den Daten vergleichen, auf die es sich stützt. Dass derselbe Fehler unpatched über viele von Rain betriebene Kartenprogramme hinweg lief, ist es, was aus einem Bug ein Multi-Programm-Ereignis machte.

Tectonic

Am 30.08.2026 wurde Tectonic, ein Compound-artiges Kreditprotokoll auf Cronos, ausgenutzt, weil dessen liquiditätsschwacher Governance-Token TONIC mit einem Sicherheitenfaktor von 20% als Sicherheit zugelassen war. Der Angreifer blähte die TONIC-denominierten Sicherheiten auf zwei Flächen gleichzeitig auf: eine Direktübertragungs-Manipulation des tTONIC-Wechselkurses, gepaart mit DEX-Käufen, die den Oracle-Preis nach oben trieben. Gegen die doppelt aufgeblähten Sicherheiten lieh der Angreifer über mehrere Kreditmärkte hinweg. Etwa 6,29 Mio. USD (2.592 ETH) wurden zu Ethereum gebrückt und stellen den realisierten Verlust dar; der Großteil des Abflusses verblieb auf Cronos und wurde gelöscht, als Validatoren die Chain auf einen Zustand vor dem Exploit zurücksetzten. Weder Tectonic noch Cronos haben eine endgültige Schadenssumme bestätigt [11].

Schwachstellenanalyse

Die Grundursache war die Listung von TONIC, einem liquiditätsschwachen Governance-Token, als Sicherheit mit einem Sicherheitenfaktor von 20%. Trotz seiner Governance-Rolle hatte TONIC extrem geringe On-Chain-Liquidität, sodass seine Bewertung mit begrenztem Kapital stark bewegt werden konnte. Wie beim Moonwell-Exploit waren zwei Flächen gleichzeitig manipulierbar: der TONIC/USD-Oracle-Preis und der Wechselkurs des tTONIC-Empfangs-Tokens, den eine einfache Übertragung von TONIC in den Markt anhebt, ohne die entsprechende Schuld auszugleichen [11]. Jeder von Null verschiedene Sicherheitenfaktor wandelte diese aufgeblähte Bewertung dann in Kreditkapazität gegenüber weitaus liquideren Assets um.

Angriffsanalyse

Die folgende Rekonstruktion des Angriffs basiert auf On-Chain-Intelligenz und einer detaillierten Rekonstruktion anhand von Archivknoten [11][12].

• Schritt 1: Der Angreifer stellte Tectonic etwa 5 Mio. USDC als Sicherheit bereit. Während das TONIC/USD-Oracle den Token noch nahe 0,00000001,06 USD bewertete, lieh ein kontrolliertes Konto etwa 376,54 Billionen TONIC und bewegte diese auf ein zweites Konto.

• Schritt 2: Das zweite Konto stellte normal etwa 41,87 Billionen TONIC bereit und erhielt im Gegenzug tTONIC (den Empfangs-Token des Marktes).

• Schritt 3: Der Angreifer übertrug den größten Teil des restlichen geliehenen TONIC direkt in den tTONIC-Market-Contract, ohne die ursprüngliche TONIC-Schuld zurückzuzahlen, wodurch der tTONIC-Wechselkurs stieg und der Sicherheitswert des vom zweiten Konto gehaltenen tTONIC erhöht wurde.

• Schritt 4: Unter Nutzung der aufgeblähten tTONIC-Sicherheit lieh der Angreifer 200.000 USDC und etwa 6,96 Mio. CRO, kaufte dann etwa weitere 16,23 Billionen TONIC über die Pools TONIC/USDC, TONIC/WCRO und TONIC/VVS und leitete diese zurück in den Markt. Dies hob den Wechselkurs weiter an und trieb den DEX-Spotpreis nach oben; Tectonics Off-Chain-TONIC/USD-Feed akzeptierte daraufhin eine Reihe rasch steigender Kurse (von etwa 0,00000001,06 USD um 12:19 UTC auf etwa 0,00000208 USD bis 12:49 UTC). Dies ist die externe Fläche.

• Schritt 5: Weitere Kreditaufnahmen von etwa 3,31 Mio. USDC und 21,21 Mio. CRO kauften weitere 7,68 Billionen TONIC, die wieder in den Markt geleitet wurden, was sowohl den aufgeblähten Wechselkurs als auch den manipulierten Preis unmittelbar vor der Extraktion weiter verstärkte.

• Schritt 6: In der abschließenden Transaktion zog der Angreifer gegen die doppelt aufgeblähte Sicherheit über mehrere Kreditmärkte hinweg, wobei etwa 55,24 Mio. USDC, 45,65 Mio. USDT, 98 WBTC, 1.895 WETH, 16,75 Mio. CRO und andere Assets entnommen wurden. Etwa 6,29 Mio. USD wurden zu Ethereum gebrückt (~2.592 ETH), bevor Validatoren die Chain stoppten. Die Blockproduktion wurde am 30.08.2026 um 23:49 UTC (angekündigt am 31.08.) wieder aufgenommen, nachdem Validatoren den Zustand auf einen Block vor dem Exploit zurückgesetzt hatten, wodurch das On-Cronos-Guthaben gelöscht wurde; nur die gebrückten ~6,29 Mio. USD stellen den realisierten Verlust dar.

Fazit

Wie beim Moonwell-Exploit früher in dieser Woche handelte es sich hier um einen Preismanipulationsangriff auf einen Compound-artigen Markt, der einen liquiditätsschwachen Token als Sicherheit akzeptierte und dessen Wert auf zwei Flächen gleichzeitig aufblähte: dem Oracle-Preis und dem Wechselkurs des Empfangs-Tokens. Kreditprotokolle sollten es vermeiden, liquiditätsschwache Assets als Sicherheit zu listen, strenge Supply- und Kreditobergrenzen anwenden, wo sie unbedingt unterstützt werden müssen, und zeitgewichtete oder liquiditätsbewusste Preisgestaltung nutzen, sodass ein dünner Spotmarkt das Oracle nicht bewegen kann. Die Wechselkursfläche benötigt eine eigene Absicherung: Die Sicherheitenbuchhaltung eines Marktes sollte unaufgeforderte Übertragungen des zugrunde liegenden Assets ausschließen, damit eine Direktübertragung nicht den Wechselkurs des Empfangs-Tokens aufblähen kann, während die entsprechende Schuld ausstehend bleibt. On-Chain-Überwachung anormaler Preis- und Kreditaktivität kann das Reaktionsfenster weiter verkürzen, bevor Werte abgezogen werden.

Referenzen

• [1] Cosmos EVM GHSA-7g4w-cg88-2cq2 Post-Mortem
• [2] KiiChain-Vorfallsoffenlegung
• [3] TAC-Chain-Vorfallsoffenlegung
• [4] cosmos/evm Balance-Handler-Commit
• [5] crypto.news: Cosmos-EVM-Schwachstelle entleert MANTRA, TAC und KiiChain
• [6] Blockaid-Alarm zum Moonwell-Exploit
• [7] Moonwell: Post-Mortem, MAMO-Marktvorfall auf Base
• [8] Defimon-Alarm zum Ajna-Exploit
• [9] crypto.news: Rain-Contract-Exploit entleert 1,1 Mio. USD von Kartennutzern
• [10] Solana-Dokumentation: Ed25519-Programm
• [11] The Defiant: Cronos setzt Chain nach Tectonic-Exploit zurück
• [12] MASTR: Tectonic-Rekonstruktion anhand von Archivknoten

Ü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 und dabei über 20 Millionen US-Dollar gerettet und Kryptowährungen im Milliardenwert abgesichert.

• Offizielle Website: https://blocksec.com/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage stellen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance