Drenaż kart Avici: ponad 600 tys. dolarów, luka w kontrakcie i ważne lekcje dla self-custody

Incydent Avici rozpoczął się 28 sierpnia 2026 r., gdy pojawiły się informacje o odpływie ponad 600 tys. dolarów z kont zabezpieczających salda kart. W miarę śledzenia transakcji w łańcuchu bloków szacunki rosły — od około 600 tys. dolarów do ponad 1 mln dolarów. Późniejsze doniesienia wskazały, że partner Avici odpowiedzialny za wydawanie kart, Rain, wykrył lukę w starszej wersji kontraktu kartowego Solany, a podatne kontrakty zostały zaktualizowane. Dostępne informacje nie pozwalają jednak traktować wszystkich wczesnych szacunków jako ostatecznej kwoty straty. 49 50 53

Najważniejsze rozróżnienie dotyczy zwykłych portfeli self-custodial Avici oraz odrębnych kontraktów wykorzystywanych do obsługi sald kart. Według późniejszych doniesień incydent dotyczył tej drugiej kategorii, a niekoniecznie infrastruktury portfeli, w których użytkownicy przechowywali inne aktywa Solany lub sieci EVM. 50 53

Jak Avici łączyło kryptowaluty z płatnościami Visa

Avici stosowało model karty zabezpieczonej aktywami, a nie klasycznego rachunku bankowego. Zgodnie z dokumentacją platformy mechanizm działał następująco:

1. Użytkownik wpłacał USDC do inteligentnego kontraktu pożyczkowego escrow.
2. Wpłata tworzyła dolarowe saldo kredytowe dla karty.
3. Każda płatność zmniejszała to saldo.
4. Wydane USDC było później rozliczane z kontraktu kartowego, zwykle z opóźnieniem od jednego–dwóch dni do około tygodnia. 35

Dokumentacja Avici wskazywała, że kontrakt zabezpieczający działał w sieci EVM, ale mógł przyjmować wpłaty pochodzące z Solany dzięki automatycznemu mostowaniu. Platforma podkreślała również, że portfel kartowy był oddzielony od smart walleta, a Visa mogła wypłacić środki dopiero po udowodnieniu, że doszło do płatności. 33

To rozwiązanie wyjaśnia zarówno atrakcyjność, jak i ryzyko produktu. Użytkownik mógł płacić kryptowalutami bez przekazywania całego portfela scentralizowanej giełdzie lub bankowi. Jednocześnie środki trafiały do wyspecjalizowanego, programowalnego systemu sald kartowych, który obejmował inteligentne kontrakty, mostowanie między sieciami, infrastrukturę wydawcy karty i mechanizmy autoryzacji transakcji.

Określenie „self-custody” nie oznacza więc, że każdy element przepływu płatności jest równie prosty, niezależny i odporny na awarie.

Co się wydarzyło i jak zmieniała się wersja wydarzeń?

Pierwsze informacje: problem z wypłatami sald kartowych

28 sierpnia Avici potwierdziło problem wpływający na wypłaty sald kartowych, podczas gdy obserwatorzy on-chain informowali o przepływie środków na adresy kontrolowane przez atakującego. Pierwsze doniesienia mówiły o około 600–653 tys. dolarów, ale późniejsze analizy śledziły przez portfel podejrzanego atakującego ponad 1 mln dolarów. Kwoty te mogły dotyczyć różnych etapów lub przepływów i nie należy ich automatycznie sumować. 49 51 54 58

Na tym etapie publiczne informacje nie pozwalały rozstrzygnąć, czy przyczyną był błąd w kontrakcie kartowym, przejęcie mechanizmu autoryzacji lub relay’a, problem z account abstraction albo rejestracją administratora, phishing czy inny element stosu technologicznego.

Późniejsza aktualizacja: Rain wskazał na starszy kontrakt Solany

Późniejsza aktualizacja przypisała incydent odkrytej przez Rain luce w starszej wersji kontraktu Solany używanego przez Avici oraz niewielką liczbę innych projektów. Według tych informacji odpowiednie kontrakty zaktualizowano, a w chwili publikacji aktualizacji nie wykryto dalszej nieautoryzowanej aktywności. Ten sam przekaz wskazywał, że problem był ograniczony do odrębnego kontraktu Solany przechowującego salda kart po doładowaniu. Zwykłe, self-custodial portfele Solany i EVM użytkowników miały pozostać odseparowane. 50 62

W kolejnym rozliczeniu podano stratę w wysokości 500 859,22 dolara dotyczącą 1685 użytkowników. Avici miało obiecać pełny zwrot środków. 53 Ta kwota jest bardziej szczegółowa niż pierwsze szacunki oparte na bieżącej obserwacji łańcucha bloków, ale nadal warto odróżniać wstępne dane z trwającego ataku od późniejszego rozliczenia.

Dlaczego doniesienia o phishingu nadal mają znaczenie

Wyjaśnienie o luce w kontrakcie nie usuwa odrębnego ryzyka phishingu. 28 sierpnia informowano o fałszywych stronach podszywających się pod Avici, które wykorzystywały rzekome airdropy lub funkcje platformy, aby nakłonić użytkowników do podłączenia portfeli i autoryzowania złośliwych transakcji. Doniesienia przypisywały ponad 600 tys. dolarów strat stronie imitującej Avici i wskazywały, że w tamtym momencie nie było publicznych dowodów na wewnętrzne włamanie do platformy. 2 4

Te dwa scenariusze nie muszą się wzajemnie wykluczać. Luka w kontrakcie mogła dotyczyć rachunków z saldami kart, podczas gdy osobna kampania podszywania się pod Avici mogła drenować portfele użytkowników, którzy podpisali złośliwe transakcje. Bez pełnego raportu opisującego adresy, kontrakty, instrukcje transakcji i znaczniki czasu nie można bezpiecznie założyć, że każda zgłoszona strata miała tę samą przyczynę.

Czego nadal brakuje w publicznej dokumentacji

W dostępnych materiałach nadal nie ma odpowiedzi na kilka ważnych pytań technicznych, w tym:

• jaka dokładnie wersja kontraktu była podatna i pod jakimi adresami ją wdrożono;
• jaka instrukcja lub sekwencja transakcji umożliwiała wykorzystanie luki;
• czy atakujący uzyskał nieuprawnione uprawnienia administratora, czy wykorzystał inną ścieżkę autoryzacji;
• jaka była pełna lista dotkniętych kont i sald;
• w jaki sposób wykryto aktywność oraz jak szybko zaktualizowano kontrakty;
• jaki będzie zakres i przebieg procesu zwrotu środków;
• czy użytkownicy muszą zmienić passkeys, sesje, delegowane uprawnienia lub inne dane uwierzytelniające.

Późniejsze wskazanie przez Rain starszego kontraktu kartowego jest istotnym wyjaśnieniem incydentu dotyczącego sald kart. Nie należy jednak rozszerzać go na twierdzenie, że wszystkie odpływy środków związane z Avici wynikały z tej samej luki. Do rozstrzygnięcia tej kwestii potrzebny byłby szczegółowy i niezależnie weryfikowalny raport po incydencie.

Co powinni teraz zrobić użytkownicy?

1. Przerwać korzystanie z podejrzanych linków i dotkniętych kontraktów

Nie należy wchodzić w interakcje z Avici ani kontraktami kartowymi za pośrednictwem linków z prywatnych wiadomości, reklam, odpowiedzi w mediach społecznościowych czy ogłoszeń o rzekomych airdropach. Do czasu potwierdzenia szczegółów działań naprawczych warto korzystać wyłącznie z oficjalnej domeny zapisanej wcześniej w zakładkach lub niezależnie zweryfikowanego kanału pomocy.

2. Odróżnić przejęcie klucza od problemu z uprawnieniami

Jeśli użytkownik wpisał frazę odzyskiwania, ujawnił klucz prywatny, zainstalował niezaufane rozszerzenie portfela albo podpisał nieznaną transakcję, powinien przenieść pozostałe aktywa do nowego portfela, korzystając z czystego urządzenia lub bezpiecznego środowiska portfelowego. Odwołanie zgód nie naprawi przejętej frazy seed ani klucza podpisującego.

3. Sprawdzić uprawnienia w każdej używanej sieci

W portfelach EVM należy przejrzeć zgody na wydawanie tokenów i usunąć nieznane lub nieograniczone uprawnienia dla zewnętrznych adresów. Warto także sprawdzić podejrzane delegowane uprawnienia oraz klucze sesyjne account abstraction, jeśli dany portfel je obsługuje.

W portfelach Solany należy przejrzeć ostatnie podpisane transakcje, podłączone aplikacje, nieznanych delegatów i aktywne sesje. Solana nie korzysta dokładnie z tego samego modelu zgód co sieci EVM, dlatego ogólne narzędzie do „odwoływania zgód tokenów” może nie wykryć każdej istotnej autoryzacji.

4. Zachować dowody

Należy zapisać adresy portfeli, sygnatury transakcji, podejrzane adresy URL, zrzuty ekranu, znaczniki czasu oraz wiadomości lub reklamy, które doprowadziły do interakcji. Takie informacje mogą pomóc Avici, dostawcy portfela lub osobom prowadzącym analizę odróżnić phishing od zdarzenia na poziomie kontraktu.

5. Przygotować się na kolejne oszustwa

Nie należy podpisywać transakcji określanych jako „weryfikacja”, „zwrot” lub „odzyskanie środków”, jeśli pochodzą od nieproszonego nadawcy. Osoby, które już straciły środki, często stają się celem kolejnych oszustów podszywających się pod pracowników platformy i obiecujących odzyskanie kryptowalut.

Co incydent Avici mówi o self-custody?

Self-custody zmienia model ryzyka, ale go nie usuwa. Użytkownik może uniknąć sytuacji, w której scentralizowany depozytariusz ma jednostronną kontrolę nad aktywami, ale nadal jest narażony na błędy w oprogramowaniu portfela, logikę inteligentnych kontraktów, mosty, relay’e, passkeys, delegowane uprawnienia, interfejsy aplikacji, wydawców kart i procesy rozliczeniowe.

Dobrze pokazuje to porównanie z kradzieżą związaną z portfelami Coldcard w 2026 r. Według doniesień około 594 BTC zostało wyprowadzonych z około 500 portfeli w ciągu mniej więcej 25 minut po tym, jak problem z oprogramowaniem układowym osłabił losowość wykorzystywaną do generowania seedów. Błąd dotyczył urządzenia i jego firmware’u, a nie podstawowej kryptografii Bitcoina. 30

Avici reprezentuje inną klasę awarii: produkt płatniczy może pozostawić użytkownikowi kontrolę nad ogólnym portfelem, a jednocześnie przenosić środki przeznaczone na kartę do wyspecjalizowanego systemu kontraktów z własnymi zależnościami. Coldcard pokazuje ryzyko sprzętu i generowania kluczy, natomiast Avici — ryzyko kontraktów, autoryzacji, interfejsu oraz infrastruktury partnera.

Praktyczny wniosek nie brzmi: „self-custody jest z definicji niebezpieczne” ani „scustodial rozwiązania są automatycznie bezpieczniejsze”. Chodzi o to, że bezpieczeństwo płatniczego produktu self-custodial zależy od całej ścieżki transakcji. Przed jego użyciem warto ustalić, które aktywa pozostają w zwykłym portfelu, które trafiają do kontraktu kartowego lub escrow, kto może autoryzować wypłaty, jak zarządzane są aktualizacje i co dzieje się w razie awarii kontraktu albo partnera.