Term Finance, oparty na Ethereum protokół pożyczkowy prowadzący rynki pożyczkowe o stałym oprocentowaniu i stałym terminie, stracił szacunkowo 8,5 mln USD po tym, jak napastnik zdobył siłę głosu i wykorzystał ją do przeforsowania złośliwej akcji zarządczej. Exploit, opisany 24 sierpnia 2026 r., obejmował wyprowadzenie środków kontrolowanych przez protokół, a nie wykorzystanie błędu na poziomie kodu — to samo zarządzanie stało się wektorem ataku.

Jak przebiegał exploit Term Finance

Incydent dotknął stosu pożyczkowego Term Finance na Ethereum, a strata w tym ataku opartym na mechanizmie zarządzania została oszacowana na około 8,5 mln USD. Zarzewiem nie była luka typu reentrancy ani manipulacja wyrocznią (oracle), lecz zakup siły głosu przez napastnika jeszcze przed atakiem.

Gromadząc wystarczającą wagę głosów w zarządzaniu, napastnik zdołał wpłynąć na kontrolowane przez mechanizm zarządczy uprawnienia protokołu, donosi CoinDesk. W zdecentralizowanych finansach samo zarządzanie staje się w ten sposób wektorem ataku: kto kontroluje głosowanie, może w zasadzie dotrzeć do wszystkiego, do czego to głosowanie jest uprawnione.

Dlaczego ataki związane z zarządzaniem podnoszą ryzyko protokołów

Przejęcie kontroli nad zarządzaniem zasadniczo różni się od błędu w smart-kontrakcie. Exploit kodu wykorzystuje niezamierzony defekt logiki kontraktu; atak na zarządzanie wykorzystuje zamierzony system uprawnień protokołu dokładnie tak, jak został zaprojektowany — po tym, jak napastnik zgromadzi wystarczającą liczbę głosów, by nim kierować.

Własna dokumentacja Term Finance opisuje warstwę zarządzania jako mechanizm administrujący parametrami protokołu i funkcjami uprzywilejowanymi — zgodnie z dokumentacją zarządzania projektu. Gdy siłę głosu można kupić na otwartym rynku, a akcje uprzywilejowane kryją się za zwykłym głosowaniem, ryzyko koncentracji staje się ryzykiem niewypłacalności.

Protokoły łagodzą to ryzyko zwykle za pomocą timelocków między zatwierdzeniem głosowania a jego wykonaniem, wymogów kworum i progów dla wniosków, multisigowych Strażników mogących zawetować lub wstrzymać działania oraz opóźnionych okien aktywacji, dających społeczności czas na reakcję. Takie zabezpieczenia stały się standardem w dużych protokołach DeFi po wcześniejszych incydentach związanych z zarządzaniem. Najczęściej przywoływanym z nich jest Beanstalk Farms, który w kwietniu 2022 r. stracił około 182 mln USD, gdy napastnik użył flash loana — pożyczki bez zabezpieczenia, zaciągniętej i spłaconej w obrębie jednej transakcji — by kupić siłę głosu i przeforsować wrogi wniosek wykonany natychmiast, bez żadnej zwłoki. Kontrakty typu Governor, takie jak w Compound i Uniswap, wymuszają około dwudniową przerwę między zatwierdzeniem głosowania a wykonaniem on-chain właśnie po to, by otworzyć takie okno reakcji. Kluczowe pytanie dla pożyczkodawców brzmi: czy mechanizmy Term Finance obejmowały timelock wystarczająco długi, by wychwycić wrogi wniosek, zanim przemieściły się środki.

Co użytkownicy i protokół będą obserwować dalej

Dla pożyczkodawców i depozytariuszy najbliższą kwestią jest ekspozycja: które vaulty lub rynki zostały dotknięte, czy otwarte pozycje pozostają wypłacalne oraz czy protokół wstrzyma funkcje uprzywilejowane na czas śledztwa i komunikowania kolejnych kroków. Publiczne komunikaty Term Finance ukazują się na oficjalnym kanale protokołu na X.

Prawdopodobny pakiet działań odzwierciedla inne incydenty związane z zarządzaniem: wstrzymanie dotkniętych kontraktów, zaostrzenie progów wniosków lub długości timelocków oraz ponowny audyt tego, do jakich funkcji może sięgnąć zarządzanie. Te kroki stały się znanym scenariuszem działania dla zespołów DeFi reagujących na incydenty bezpieczeństwa — podobnie jak inne projekty, w tym The Sandbox, który poinformował o powstrzymaniu ataku na bridge, radziły sobie z podobnymi zdarzeniami. Odrodzenie może też wykraczać poza łatanie: Beanstalk ostatecznie wznowił działanie po rundzie finansowania zorganizowanej przez społeczność — jednym z precedensów odbudowy protokołu po awarii mechanizmu zarządzania.

Transparentność po incydencie jest tu zmienną, która najsilniej wpływa na wiarygodność protokołu. Jasne przedstawienie sposobu gromadzenia głosów przez napastnika, dokładnej funkcji, którą wykorzystano, oraz harmonogramu działań naprawczych okaże się dla zachowania pozostałej płynności ważniejsze niż sama kwota straty z nagłówka.