Haftalık Web3 Güvenlik Olayları Özeti | 13 Nisan – 19 Nisan 2026

Geçen hafta (2026/04/13 - 2026/04/19), BlockSec dört saldırı olayını tespit edip analiz etti; tahmini toplam kayıplar yaklaşık 310 milyon dolar'dır. Aşağıdaki tablo bu olayları özetlemekte olup her bir olay için ayrıntılı analizler sonraki alt bölümlerde sunulmaktadır.

Haftanın Öne Çıkanı: KelpDAO

İstismar sonrası zincirleme etkileri, Arbitrum'un zincir üstü kurtarma mekanizmasını ve daha geniş yönetişim çıkarımlarını ele alan özel bir rapor için şuraya bakınız: Merkeziyetsizlik İkilemi: KelpDAO Krizinde Zincirleme Risk ve Acil Durum Gücü

Bu olay; akıllı sözleşme istismarı yerine tek DVN'e karşı uygulanan RPC zehirlenmesiyle yeni bir altyapı düzeyinde saldırı vektörü, DeFi bileşenliği aracılığıyla birden fazla zincirde yarattığı zincirleme etki ve Arbitrum'un çalınan fonları kurtarmak için uyguladığı zorla durum geçişinin gündeme taşıdığı yönetişim soruları nedeniyle öne çıkarılmıştır.

18 Nisan 2026'da KelpDAO'nun rsETH LayerZero OFT köprüsü, devlet destekli bir aktöre, büyük olasılıkla Kuzey Kore'nin Lazarus Grubu'na atfedilen bir saldırıda yaklaşık 290 milyon dolarlık istismara uğradı [1]. Temel neden, KelpDAO'nun 1-of-1 DVN yapılandırmasıydı; bu yapılandırma, zincirler arası mesaj doğrulamasını tek bir hata noktasına indirgemişti. Saldırgan, LayerZero Labs DVN tarafından güvenilen RPC altyapısını zehirledi ve DVN'i, Unichain'de karşılık gelen bir kaynak tarafı olayı olmaksızın Ethereum'da 116.500 rsETH'nin serbest bırakılmasına yol açan sahte bir zincirler arası mesajı onaylamaya zorladı.

Arka Plan

LayerZero, modüler bir güvenlik mimarisi üzerine inşa edilmiş bir zincirler arası mesajlaşma protokolüdür. Temel düzeyde, zincirler arası mesaj bütünlüğü; bir kaynak zincirde gönderilen bir mesajın gerçekten gerçekleştiğini, hedef zincirde yürütülmeden önce bağımsız olarak doğrulamaktan sorumlu zincir dışı varlıklar olan Merkezi Olmayan Doğrulayıcı Ağları (DVN'ler) tarafından sağlanmaktadır. LayerZero üzerinde dağıtılan her uygulama, hangi DVN'lere güvenileceği, kaçının gerekli olduğu ve hangi konsensüs eşiğinin karşılanması gerektiği de dahil olmak üzere kendi DVN kurulumunu yapılandırır. Bu modülerlik, uygulamalara güvenlik modelleri üzerinde tam kontrol sağlar; ancak tam sorumluluk da onlara aittir: Zayıf bir yapılandırma, protokolün kendisi tarafından telafi edilemez.

KelpDAO'nun rsETH'si, Unichain (kaynak) ile Ethereum ana ağını (hedef) birbirine bağlayan bir köprü rotasıyla LayerZero üzerinde OFT (Omnichain Fungible Token) olarak dağıtılmıştır. OFT standardı, tokenların kaynak zincirde yakılmasına ve hedef zincirdeki bir kilitten serbest bırakılmasına olanak tanır; zincirler arası mesaj, serbest bırakma için tek yetkilendirme olarak işlev görür. Ethereum tarafındaki adaptör (0x85d456...e98ef3), geçerli bir zincirler arası mesaj doğrulanıp iletildikten sonra alıcılara rsETH serbest bırakmaktan sorumludur. Kritik olarak, KelpDAO bu yolu 1-of-1 DVN kurulumunyla yapılandırmış ve tek doğrulayıcı olarak LayerZero Labs'ı belirlemiştir. Bu, herhangi bir token serbest bırakmasını yetkilendirmek için tek bir DVN onayının yeterli olduğu ve ikinci bir görüşün gerekmediği anlamına gelir.

Doğrulama görevlerini yerine getirmek için LayerZero Labs DVN, kaynak zincirde bir zincirler arası gönderme olayının gerçekten gerçekleştiğini teyit etmek amacıyla birden fazla RPC düğümünü sorgular. Bu RPC düğümleri hem kendi işlettiği altyapıyı hem de harici sağlayıcıları kapsar ve DVN, bir onay imzalamadan önce bunların toplu yanıtlarına dayanır. Bu sürecin bütünlüğü, sorgulanan düğümlerin çoğunluğunun doğru veri döndüreceği varsayımına bağlıdır.

Güvenlik Açığı Analizi

Güvenlik açığı, birbiriyle birleşen üç zayıflıktan oluşan, altyapı ve yapılandırma düzeyinde sistemik bir başarısızlıktır.

Birincisi, KelpDAO'nun 1-of-1 DVN yapılandırması, doğrulama katmanındaki tüm yedekliliği ortadan kaldırmıştır. LayerZero'nun önerilen güvenlik duruşu, hiçbir tek DVN'nin bir mesajı tek taraflı olarak yetkilendiremeyeceği şekilde, bağımsız doğrulayıcılarla çok-DVN kurulumlarını açıkça gerektirmektedir. KelpDAO, yalnızca LayerZero Labs DVN'ye güvenerek, o tek doğrulayıcının herhangi bir şekilde ele geçirilmesinin keyfi bir token serbest bırakmasını yetkilendirmek için yeterli olacağını garanti etmiş oldu.

İkincisi, DVN'nin yük devretme mekanizması, doğrulama sorgularını erişilebilir kalan RPC düğümlerine yönlendirir. Bu tasarım, düğüm kullanılamama durumunun kasıtlı değil, tesadüfi olduğunu varsayar. Ancak bu durum, bir saldırganın tüm veri kaynaklarını ele geçirmesine gerek olmayan bir koşul yaratır: sağlıklı düğümleri DDoS aracılığıyla çevrimdışı bırakıp zehirlenmiş düğümleri tek erişilebilir alternatif olarak hazır tutarak saldırgan, DVN'nin aldığı veriler üzerinde tam kontrol elde edebilir.

Üçüncüsü, RPC düğümlerindeki op-geth yürütülebilir dosyasını değiştirmek, altta yatan sunuculara işletim sistemi düzeyinde erişim gerektiriyordu. Kesin ilk erişim vektörü açıklanmadı; ancak ayrı kümeler üzerindeki iki bağımsız düğümün ele geçirilmesi, bu sunuculara erişimin nasıl kontrol edildiğine dair ortak bir zayıflığa işaret edebilir.

Bu üç koşul birlikte eksiksiz bir saldırı zinciri oluşturdu: Birincisi, onaylanan mesajı çapraz kontrol edecek bağımsız bir DVN olmamasını sağladı; ikincisi, saldırganın tek DVN'nin aldığı veriler üzerinde tam kontrol sahibi olabilmesini sağladı; üçüncüsü ise veri manipülasyonunu mümkün kılan ilk tutunma noktasını sağladı. Tek başına hiçbir zayıflık yeterli olmazdı. 1-of-1 yapılandırması olmasa, bağımsız altyapıyı sorgulayan ikinci bir DVN sahte mesajı reddederdi. Yük devretme davranışı olmasa, sağlıklı düğümler zehirlenmiş olanları oylama ile geçersiz kılardı. Sunucu ele geçirme olmasa, saldırganın başlangıçta sahte veri enjekte etmenin hiçbir yolu olmazdı.

Saldırı Analizi

Aşağıdaki analiz, 0x1ae232...4222 işlemine ve LayerZero Labs'ın resmi olay açıklamasına dayanmaktadır.

• Adım 1: Saldırgan, LayerZero Labs DVN tarafından güvenilen belirli RPC düğümlerinin listesini edindi. Bu liste, tam olarak hangi düğümlerin bilinmesinin saldırganın geniş çaplı bir altyapı saldırısı yerine cerrahi bir operasyon planlamasına olanak tanıması nedeniyle yüksek değerli bir istihbarat hedefi oluşturuyordu.

• Adım 2: Saldırgan, RPC düğümlerinden ikisine işletim sistemi düzeyinde yazma erişimi kazandı ve çalışan op-geth ikili dosyalarını kötü amaçlı sürümlerle değiştirdi. Bu iki düğümün birbirleriyle doğrudan bağlantısı bulunmayan bağımsız kümeler üzerinde çalıştığı belirtildi; bu durum, ilk erişim vektörünün her ikisine de erişimi olan bir operatörün ortak bir yukarı akış bağımlılığını (örn. ele geçirilmiş dağıtım kimlik bilgileri, bir CI/CD ardışık düzeni veya sosyal mühendislik) kapsadığını düşündürmektedir. Kesin ilk erişim yöntemi LayerZero Labs tarafından açıklanmadı. Bu adım, sonraki tüm veri manipülasyonunun ön koşuluydu.

• Adım 3: Kötü amaçlı op-geth ikili dosyası hedefli yanıt mantığı uyguladı: DVN'nin IP adresine özel olarak sahte işlem verileri döndürürken, LayerZero'nun kendi izleme altyapısı, blok gezginleri ve tarama hizmetleri de dahil olmak üzere diğer tüm istek sahiplerine gerçek blok zinciri durumunu sundu. Bu seçici zehirleme, saldırıyı mevcut tüm gözlemlenebilirlik sistemleri için görünmez kıldı; her dış bakış açısından kaynak zincir normal görünüyordu.

• Adım 4: DVN'nin iç konsensüsü, zehirlenmiş ve ele geçirilmemiş RPC düğümleri arasında anlaşma gerektiriyordu. Bu çatışmayı çözmek için saldırgan, saldırı penceresi boyunca (Pasifik saatiyle sabah 10:20 ile 11:40 arası) kalan sağlıklı düğümlere DDoS saldırısı düzenleyerek DVN'nin yük devretme mantığını tetikledi ve DVN'yi yalnızca zehirlenmiş altyapıya güvenmeye zorladı. Bu adım gerekliydi; çünkü aksi takdirde sağlıklı düğümler, sahte yanıtlarla çelişen doğru verileri döndürürdü.

• Adım 5: DVN artık yalnızca saldırgan kontrolündeki veriler aldığında, sahte bir LayerZero zincirler arası mesajı geçerli olarak sunuldu. DVN, Ethereum hedef uç noktasında nonce 308'i onayladı; bu nonce'un Unichain üzerinde karşılık gelen bir giden olayı yoktu (kaynak uç noktasının hâlâ 307'lik maksimum giden nonce bildirdiği doğrulandı).

• Adım 6: Ethereum tarafındaki rsETH adaptörü, geçerli biçimde onaylanmış bir mesaj alarak, saatler önce Tornado Cash aracılığıyla önceden finanse edilmiş olan saldırganın alıcı adresine (0x8b1b6c...0d3b) 116.500 rsETH serbest bıraktı. Çalınan tokenlar hemen yedi dal cüzdana dağıtıldı ve Aave teminat pozisyonları, doğrudan ETH swapları ve Arbitrum'a yeniden köprüleme yoluyla nakde çevrildi; nihai gelirler Ethereum'da 0x5d3919...7ccc adresinde ve Arbitrum'da karşılık gelen bir toplayıcıda toplandı.

• Adım 7: Kötü amaçlı ikili dosya tamamlandıktan sonra tüm yerel günlükler ve yapılandırma dosyalarıyla birlikte kendini silerek kendi kendini yok etme rutini çalıştırdı. Bu durum, olay sonrası adli kurtarmayı önemli ölçüde engelledi ve saldırganın operasyonel gelişmişliğini gözler önüne serdi.

• Adım 8: Saldırganın aynı yolu kullanarak ek 40.000 rsETH (~95 milyon dolar) elde etmeye yönelik sonraki girişimi, KelpDAO anomaliyi tespit edip Ethereum ana ağı ve L2'lerdeki tüm ilgili sözleşmeleri durdurduktan sonra engellendi [2].

Daha Geniş Etki

Hasar, başlangıçtaki 290 milyon dolarlık köprü istismarasının çok ötesine geçti. Saldırgan, birden fazla piyasada Aave'e yaklaşık 89.567 rsETH (~221 milyon dolar) yatırarak E-Mod'un %93 LTV oranıyla WETH borç aldı [4]. Aave, meşru biçimde köprülenmiş rsETH'yi sahte bir mesaj aracılığıyla serbest bırakılan tokenlardan ayırt edemediğinden, "zehirlenmiş" teminat tamamen geçerli olarak işlem gördü. Ortaya çıkan WETH rezerv dondurma işlemi Ethereum, Arbitrum, Base, Mantle ve Linea'ya yayıldı ve rsETH'ye hiç maruziyeti olmayan kullanıcıları etkiledi. Tek bir köprü yapılandırma açığından çok zincirli borç verme piyasası aksaklığına uzanan bu zincirleme yayılma, DeFi bileşenliğinin tek bir hata noktasının hem erişimini hem de maliyetini nasıl büyüttüğünü gözler önüne sermektedir.

Sonraki gelişmeler, merkeziyetsizliğin operasyonel gerçekliğine ilişkin eşit derecede önemli soruları da gündeme taşıdı. LayerZero Labs, DVN'sinin artık 1-of-1 yapılandırması kullanan uygulamalar için mesaj imzalamayacağını duyurdu [1]; bu durum, protokol düzeyindeki merkeziyetsizliğin tek başına uygulama düzeyindeki yapılandırma zayıflıklarını telafi edemeyeceğini ima etmektedir.

Zincir düzeyinde ise Arbitrum Güvenlik Konseyi, saldırganın Arbitrum One üzerinde tuttuğu 30.766 ETH'yi dondurmak için acil durum eylemi gerçekleştirdi. BlockSec'in analizine göre [5], bu işlem zincir düzeyinde zorla bir durum geçişiyle gerçekleştirildi: Güvenlik Konseyi, Ethereum gelen kutusu sözleşmesini geçici olarak yükseltti, saldırganın adresinin kimliğine bürünen imzasız bir L1'den L2'ye mesaj enjekte etti ve orijinal uygulamayı geri yükledi; tüm bunlar, sahipten imza alınmadan gerçekleştirildi [3].

Bu eylem, şeffaf bir şekilde ve kolluk kuvvetleriyle koordineli biçimde yürütülen, yönetişim tarafından tanımlanmış meşru bir acil durum yetkisi kullanımıydı. Yine de L2 zincirlerinin tasarım gereği merkezi müdahale yeteneklerini koruduğunu da ortaya koymaktadır: Arbitrum One üzerindeki herhangi bir varlık prensipte aynı mekanizma aracılığıyla Güvenlik Konseyi tarafından taşınabilir. Bir sistemin teorik güven modeli ile fiili güven sınırı arasındaki uçurum, bu olayın her katmanda gösterdiği üzere, en belirleyici risklerin barındığı yerdir.

Sonuç

Bu olay, köprü güvenliğinin yalnızca protokol doğruluğuna indirgenemeyeceğini göstermektedir. LayerZero protokolü tasarlandığı gibi işlev gördü; güvenlik açığı tamamen onun üzerindeki operasyonel katmanda yer alıyordu. Temel ders şudur: Zincir dışı doğrulama altyapısı güven sınırının bir parçasıdır ve güvenlik duruşu, koruduğu değerle örtüşmek zorundadır.

Üç önlem bu sonucu ayrı ayrı engelleyebilirdi:

• Çok-DVN yapılandırması: Birden fazla bağımsız DVN arasında konsensüs gerektirmek, o DVN ne kadar tam olarak aldatılırsa aldatılsın, tek bir DVN'nin ele geçirilmesini bir mesajı yetkilendirmek için yetersiz kılardı.

• Yük devretmeye duyarlı RPC seçimi: Aktif bir doğrulama penceresi sırasında erişilebilir düğüm sayısındaki ani düşüş, rutin bir kullanılabilirlik olayı olarak değil, olası bir saldırı sinyali olarak değerlendirilmelidir. DVN uygulamaları, azaltılmış bir düğüm kümesiyle devam etmek yerine durmalı veya uyarı vermelidir.

• RPC altyapısının güçlendirilmesi: Üretim ortamındaki bir RPC düğümünde çalışan bir yürütülebilir dosyayı değiştirebilme yetisi, altta yatan sunucularda yetersiz erişim denetimlerine işaret etmektedir. DVN'lerin kaynak zincir gerçek verileri için bağımlı olduğu altyapı, DVN imzalama örneklerinin kendisiyle aynı güvenlik sınırına tabi tutulmalıdır.

Daha genel olarak, zincir dışı onaya dayanan herhangi bir köprü veya zincirler arası protokol, yalnızca akıllı sözleşme katmanını değil, kaynak zincir olayından hedef zincir yürütmesine uzanan tam veri ardışık düzenini denetlemelidir. RPC altyapısının varsayılan olarak güvenilir olduğu varsayımı, yüz milyonlarca dolar buna bağlıyken artık savunulamaz bir durumdur.

Referanslar

[1] LayerZero Labs, "KelpDAO Olay Açıklaması," 20 Nisan 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "18 Nisan Olayı: Ek Bağlam," 21 Nisan 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Güvenlik Konseyi Acil Durum Eylemi," 21 Nisan 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, "rsETH Olay Raporu," 20 Nisan 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Arbitrum Güvenlik Konseyi Dondurma Mekanizması Analizi," 21 Nisan 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Bu Haftanın Diğer Olayları

Rhea Finance

16 Nisan 2026'da, Rhea Finance bünyesinde NEAR üzerinde faaliyet gösteren bir borç verme ve marjinli işlem protokolü olan Burrowland, marjinli işlem modülündeki bir iş mantığı açığı nedeniyle yaklaşık 18,4 milyon dolarlık istismara uğradı. Kaldıraçlı bir pozisyon açılırken protokol, pozisyonu kabul etmeden önce beklenen swap çıktısını doğrulamak için verify_token_out() fonksiyonuna dayanır. Ancak bu fonksiyon, token nihai çıktı tokenıyla eşleştiğinde ara swap adımlarından gelen token_out miktarlarını yanlış biçimde biriktirdi ve bu ara miktarların daha sonra token_in olarak yeniden kullanıldığını hesaba katmadı. Saldırgan sahte tokenlar ve havuzlar oluşturdu, ardından algılanan çıktı miktarını şişiren ve ödeme gücü kontrollerini geçen dairesel bir swap yolu kurarak protokolden yaklaşık 18,4 milyon dolar aktardı.

Arka Plan

Burrowland, NEAR üzerinde açık kaynaklı bir borç verme ve marjinli işlem protokolüdür. Standart arz ve borçlanma işlevlerine ek olarak marjinli işlemleri destekler ve kullanıcının kaldıraçlı pozisyonunu temsil eden üç temel değişken sunar: token_c (teminat), token_d (borç varlığı) ve token_p (pozisyon varlığı).

Uzun bir pozisyonda kullanıcı, token_c'yi teminat olarak yatırır ve seçilen bir kaldıraçla (örn. 5x) token_d borç alır. Alınan token_d daha sonra bir DEX üzerinde, kullanıcının maruz kalmak istediği varlık olan token_p'ye swap edilir. Normal koşullarda alınan token_p'nin değeri, harcanan token_d'nin değerine yaklaşık olarak eşittir. Protokol, kullanıcı adına token_p'yi tutarken alınan token_d'yi borç olarak kaydeder.

Kısa bir pozisyonda kullanıcı benzer şekilde token_c yatırır ve kaldıraçla token_d (kısa pozisyon almak istediği varlık) borç alır. Alınan token_d, başka bir varlıkla (token_p) swap edilerek etkin biçimde token_d'ye kısa maruz kalma sağlanır. Yine, swap'ın normal piyasa koşullarında değeri koruması beklenir.

Pozisyonun yaşam döngüsü boyunca token_p, protokol içinde saklı kalır ve kullanıcı onu doğrudan çekemez. Kâr veya zararı gerçekleştirmek için pozisyonun kapatılması gerekir; bu noktada borcu ödemek amacıyla token_p tekrar token_d'ye swap edilir.

Marjin pozisyonu açma işlemi internal_margin_open_position() tarafından gerçekleştirilir; bu fonksiyon pozisyon parametrelerini ayarlar ve borçlanmayı DEX'e iletir.

Protokol yeni bir pozisyonu kabul etmeden önce sırayla dört korumayı değerlendirir: is_min_amount_out_reasonable(), kayma payını sınırlamak için kullanıcı tarafından beyan edilen min_token_p_amount'ı Pyth oracle'ın ima ettiği swap çıktısıyla çapraz kontrol eder; is_open_position_liquidatable(), beklenen pozisyon ve teminat değerinin tasfiye sınırını aştığını doğrular; is_open_position_forcecloseable(), hesabın kâğıt üzerinde zaten iflas etmediğini doğrular; get_open_position_lr() ise token_d / token_c değerinin maksimum kaldıraç oranını aşmadığını zorunlu kılar.

Swap henüz yürütülmediğinden ve kullanılacak gerçekleşmiş bir miktar olmadığından, dört kontrol de pozisyon varlığının değeri olarak min_token_p_amount'ı kullanır. Bu nedenle her kapı noktasının doğruluğu, min_token_p_amount'ın DEX'in fiilen ileteceklerine bağlı olmasına dayanır. Bu bağlama, kullanıcının gönderdiği swap mesajında RefV1TokenReceiverMessage::get_token_out() aracılığıyla uygulanan verify_token_out()'ın zorunlu kılması gereken tam olarak budur.

Güvenlik Açığı Analizi

Açık verify_token_out() içindedir. Fonksiyon, son swap adımının token_out'unu nihai çıktı tokenı olarak seçer, ardından aynı tokenı üreten her swap adımının beyan edilen min_amount_out'unu toplar; bu üretimlerin her birinin nihai çıktıya katkıda bulunduğu varsayımıyla. Bu, gerçek bir çok yollu (bölünmüş rota) swap için doğrudur; ancak token_out'u bir sonraki adımın token_in'i olarak hemen tüketen adımları dışlamaz. A->B->A->B gibi gidiş-dönüş bir yol, her ->B adımının çıktısı sonraki B->A adımında harcanıp Burrowland'e hiçbir zaman ulaşmasa bile her ->B adımının toplama sayılmasına neden olur. verify_token_out()'un onayladığı toplam min_amount_out, DEX'in gerçekte döndüreceği değeri artık temsil etmez.

verify_token_out() atlatıldıktan sonra, şişirilmiş min_token_p_amount, internal_margin_open_position() boyunca gerçek değer olarak kabul edilir. Güvensiz bir açılışı durdurmak için tasarlanan her ödeme gücü kapısı uydurma bir değere karşı hesap yapar; bu nedenle pozisyon kabul edilir ve protokol, dairesel swap mesajı ekli olarak borç alınan token_d'yi DEX'e iletir.

Saldırı Analizi

Aşağıdaki analiz, GcXEKm...fnFT işlemine dayanmaktadır.

Aşama 1: Sahte Token ve Havuz Dağıtımı

Saldırgan üç sahte token dağıttı ve beş sahte havuz oluşturdu.

1. Sahte Token Kimlikleri:

   1. Sahte1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Sahte2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Sahte3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. Sahte Havuz Kimlikleri:

   1. Zec-Sahte1: 7509

   2. Sahte1-Sahte2: 7510

   3. USDC-Sahte2: 7511

   4. Sahte2-Sahte3: 7512

   5. Sahte3-USDC: 7513

Aşama 2: Marjin Pozisyonu Açma

• Adım 1: Saldırgan, Burrowland'in marjinli işlem özelliğini kullanarak token_c olarak gerçek değeri olan bir varlık ve token_d olarak gerçek bir rezerv varlıkla kaldıraçlı bir pozisyon açtı; işlem listesi tamamen Aşama 1'deki saldırgan kontrolündeki havuzlar üzerinden yönlendirilen A->B->A->B gidiş-dönüş swap mesajı eklendi.

• Adım 2: verify_token_out(), terminal çıktıyla eşleşen token_out'a sahip her adım için min_amount_out'u topladığından, gidiş-dönüş yolu saldırganın beyan edilen min_token_p_amount'ı keyfi bir değere şişirmesine olanak tanıdı.

• Adım 3: Şişirilmiş min_token_p_amount, internal_margin_open_position()'daki her açılış zamanı sağlık kontrolünden geçti; böylece pozisyon kabul edildi ve protokol, token_d'yi Ref-Finance'a iletti.

• Adım 4: Dairesel swap yalnızca küçük bir miktar token_p döndürdü; on_open_trade_return() bunu yeniden kontrol etmeden kaydetti ve pozisyonun oluşturulduğu andan itibaren iflas etmesine yol açtı.

• Adım 5: Alınan token_d, yol boyunca saldırgan kontrolündeki havuzlara yerleşti; saldırgan bunu remove_liquidity() aracılığıyla çıkardı.

• Adım 6: Borçlanma kaldıraçlı olduğundan, çekilen token_d, yatırılan token_c'den daha değerlidir. Bu fark, her döngü başına net kârdır ve tahsil edilemeyen borç protocol_debts'e zorla kapatılır. Saldırgan, yaklaşık 18,4 milyon dolar tükenene kadar bu yapıyı tekrarladı.

Sonuç

Bu olay, Burrowland'in marjin açma yolundaki bir iş mantığı açığından kaynaklandı. RefV1TokenReceiverMessage::get_token_out() fonksiyonu, nihai tokenla eşleştiğinde ara çıktıları yanlış biçimde topladı ve bu miktarların nihai çıktı olarak kalacağını varsaydı. Ancak dairesel swap yolları bu varsayımı bozar; çünkü bu tokenlar yol içinde yeniden kullanılıp tüketilebilir. Sonuç olarak, hesaplanan min_token_p_amount yapay biçimde şişirilebilir; bu da sonraki tüm ödeme gücü kontrollerinin yanlış bir değere dayanmasına ve gerçekte alınan miktarı doğrulamadan pozisyonların uydurma bir sağlık durumuna karşı açılmasına neden olur.

Üretim ortamındaki marjinli işlem sözleşmeleri için geliştiriciler şunları yapmalıdır:

• Kullanıcı tarafından beyan edilen min_amount_out'u doğrulanmamış girdi olarak değerlendirmeli ve ya yalnızca son adımın min_amount_out'unu almalı ya da daha önce üretilmiş bir token_out'u yeniden tüketen swap yollarını (hedefe yönelik döngüler olmadan) açıkça reddetmelidir.

• Beyan edilen kayma payını oracle'ın ima ettiği swap çıktısına göre hem alt hem de üst bir zarfla sınırlandırmalı; böylece bir saldırgan ödeme gücü yüklemlerini atlatmak için beyan edilen değeri tek taraflı olarak şişiremesin.

Hyperbridge

13 Nisan 2026'da, Ethereum üzerinde zincirler arası mesajlaşma köprüsü olan Hyperbridge, MMR (Merkle Mountain Range) kanıt doğrulama mantığındaki eksik girdi doğrulaması nedeniyle yaklaşık 242 bin dolarlık istismara uğradı. MerkleMountainRange.VerifyProof() fonksiyonu leaf_index < leafCount koşulunu zorunlu kılmadığından, saldırgan zincirler arası bir kanıtı taklit ederek 1.000.000.000 DOT token basmak dahil ayrıcalıklı işlemler gerçekleştirebildi.

Arka Plan

Hyperbridge, zincirler arası mesajlar için Ethereum tarafında bir doğrulayıcı ve dağıtıcı modeli kullanır. Ethereum'da HandlerV1 sözleşmesi, sağlanan kanıtları depolanan overlayRoot'a karşı doğrular ve kanıt kabul edilirse mesajı TokenGateway sözleşmesi gibi hedef modüllere iletir.

TokenGateway sözleşmesi ayrıcalıklı bir varlık yönetim modülüdür. Normal varlık köprülemenin yanı sıra varlık oluşturma, kayıt silme ve yönetici yönetimi gibi yönetişim tarzı işlemleri de destekler. ERC6160Ext20 olarak uygulanan köprülenmiş varlıklar için yönetici, changeAdmin() fonksiyonunu çağırarak basım yetkisini doğrudan devredebilir; yeni yönetici ise mint() fonksiyonu aracılığıyla keyfi miktarda arz basabilir.

Bu, tüm varlık köprüsünün güvenliğinin HandlerV1'deki kanıt doğrulama yolunun doğruluğuna bağlı olduğu anlamına gelir. Sahte bir mesaj doğrulamayı geçebilirse, alt akıştaki modüller saldırgan kontrolündeki yükleri gerçek zincirler arası talimatlar olarak değerlendirecektir.

Güvenlik Açığı Analizi

Temel sorun, HandlerV1 sözleşmesindeki (0x6c84ed...6d64) MMR kanıt doğrulama akışındadır. Giriş fonksiyonu handlePostRequests(), önce saldırgan tarafından sağlanan girdilere dayanarak MmrLeaf(leaf.kIndex, leaf.index, commitment) oluşturur. Ardından kanıt doğrulamayı gerçekleştirmek için MerkleMountainRange.VerifyProof() çağrılır.

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

Ancak VerifyProof() yalnızca root == CalculateRoot(proof, leaves, mmrSize) koşulunu kontrol eder ve her leaf.index'in aralık içinde olduğunu (yani leaf.index < leafCount) doğrulamaz. Saldırgan leafCount = 1 ve leaf_index = 1 seçerek CalculateRoot()'un sahte istek taahhüdünü hesaplanan köke katlamayı atlamasına ve tepe kökünü doğrudan döndürmesine neden olur. Bu, mesaj-kanıt bağlamasını bozar ve keyfi yüklerin geçmişte bir overlayRoot'a karşı geçerli olarak kabul edilmesine olanak tanır.

Saldırı Analizi

Aşağıdaki analiz, 0x240aeb...1109 işlemine dayanmaktadır [1].

• Adım 1: Saldırgan EOA 0xC513...F8E7, aynı işlemde yardımcı sözleşmeler 0x518A...8f26 ve 0x31a1...ca9AB'yi dağıttı.

• Adım 2: Yardımcı sözleşme 0x31a1...ca9AB, HandlerV1'deki savunmasız doğrulama yolu aracılığıyla sahte bir istek gönderdi. VerifyProof() sınır dışı leaf_index'i reddetmediğinden, sahte istek taahhüdü kök hesaplamasından çıkarıldı; ancak kanıt yine de geçmişteki bir overlayRoot'la eşleşti.

• Adım 3: Sahte mesaj kabul edildikten sonra HandlerV1, mesajı TokenGateway'e ileterek ChangeAssetAdmin eylemini çalıştırdı. Bu, DOT tokenının yöneticisini saldırgan kontrolündeki yardımcı sözleşme 0x31a1...ca9AB olarak değiştirdi.

• Adım 4: Yardımcı sözleşme 1.000.000.000e18 DOT token bastı.

• Adım 5: Yardımcı sözleşme, yeni basılan DOT tokenlarını Odos Router V3 aracılığıyla 108,2 ETH ile değiştirdi.

• Adım 6: Saldırgan, 108,2 ETH'yi EOA hesabına aktardı.

Sonuç

Bu olay, Hyperbridge'in MMR doğrulama mantığındaki hatalı kanıt doğrulamadan kaynaklandı. leaf_index < leafCount koşulu zorunlu kılınmadığından, saldırgan taahhüdü hiçbir zaman hesaplanan köke dahil edilmemiş bir mesajı taklit edebildi; ancak yine de geçmiş bir durum köküne karşı doğrulamayı geçti. Azaltıcı önlemler, kanıt doğrulamadan önce leaf_index < leafCount gibi katı sınır kontrollerini zorunlu kılmalıdır.

Referanslar

[1] BlockSec, "Hyperbridge Saldırı Analizi," 13 Nisan 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

13 Nisan 2026'da, Cosmos AppChain olarak inşa edilmiş sürekli vadeli işlem DEX'i Dango, eksik işaret kontrolü nedeniyle yaklaşık 1,5 milyon dolarlık istismara uğradı. replenish_insurance_fund() fonksiyonu, girdi miktarını doğrulamak için is_positive() yerine is_non_zero() kullandı; bu durum saldırganın negatif bir UsdValue sağlamasına ve sigorta fonunu kendi marjin pozisyonuna aktarmasına olanak tanıdı.

Arka Plan

Dango, Cosmos AppChain olarak inşa edilmiş bir sürekli vadeli işlem DEX'idir. Kullanıcılar, perps sözleşmesine teminat olarak USDC yatırır ve zincir üstü bir Merkezi Limit Emir Defteri (CLOB) aracılığıyla BTC, ETH ve SOL gibi varlıklar üzerinde kaldıraçlı uzun veya kısa pozisyonlar açar. Her kullanıcının teminat bakiyesi, perps sözleşmesi içinde bir marjin hesabı olarak izlenir.

Likidite sağlayıcılarını (LP) kötü borç kayıplarından korumak için protokol bir sigorta fonu tutar: Tasfiye edilen bir pozisyonun teminatı borcunu tam olarak karşılamaya yetmediğinde açığı kapatan, perps sözleşmesi içinde tutulan bir USDC rezervi. Bu fon olmasaydı, söz konusu açıklar doğrudan LP'lere yayılırdı. Herhangi bir kullanıcı, perp hesabındaki marjini sigorta fonuna katkıda bulunabiliyordu.

Güvenlik Açığı Analizi

Temel neden, 0x90bc84...bea4f sözleşmesinin replenish_insurance_fund() fonksiyonunun negatif girdi miktarlarını reddetmemesinde yatmaktadır. Fonksiyonun iki koruması vardır; ancak hiçbiri negatif bir amount'u durdurmaz:

1. ensure!(amount.is_non_zero()), miktarın sıfır olmadığını kontrol eder; ancak pozitif olduğunu kontrol etmez.
2. ensure!(user_state.margin >= amount), kullanıcının yeterli marjine sahip olduğunu kontrol eder; ancak herhangi bir pozitif marjin >= negatif_sayı koşulunu sağlar.

Her iki koruma da geçildiğinde fonksiyon user_state.margin.checked_sub_assign(amount) ve state.insurance_fund.checked_add_assign(amount) işlemlerini çalıştırır. amount negatif olduğunda, çıkarma işlemi kullanıcının marjinini artırır ve ekleme işlemi sigorta fonunu azaltır; böylece amaçlanan fon akışı tamamen tersine döner.

Saldırı Analizi

İşlemler:

Aşama 1:

Tx 1'de saldırgan, Dango'nun sigorta fonundan varlıkları aktarmak için aşağıdaki adımları uyguladı:

• Adım 1: Saldırgan, 1e6 USDC yatırarak bir marjin pozisyonu açtı. Bu, replenish_insurance_fund() fonksiyonunu çağırmak için bir ön koşuldu.

• Adım 2: Saldırgan, negatif bir amount (yani -1500000) ile replenish_insurance_fund() fonksiyonunu çağırdı. Hatalı doğrulama nedeniyle negatif amount kabul edildi ve sigorta fonundan varlıklar saldırganın marjin pozisyonuna aktarıldı.

• Adım 3: Saldırgan, marjin pozisyonundaki tüm varlıkları çekerek 1.500.000 dolar USDC kazandı.

Aşama 2:

Tx 2-8'de saldırgan, çalınan varlıkları Ethereum'a köprülemek için transfer_remote() fonksiyonunu çağırdı. Sonuç olarak 410.000 dolar USDC Ethereum'a köprülendi.

Sonuç

Bu saldırının özü, işaret koruması olmadan işaretsiz bir bağlamda kullanılan işaretli tamsayı türüdür. UsdValue türü tasarımı gereği işaretlidir (perps kâr/zararı negatif olabilir); ancak sigorta fonu bağış yolu yalnızca pozitif katkılar için anlam ifade eder. is_positive() yerine is_non_zero() kullanmak, herhangi bir çağırıcının fon akışının yönünü tersine çevirmesine ve sigorta fonundan USDC'yi kendi marjinine aktarmasına olanak tanıyan tek kelimelik bir boşluk bıraktı. Saldırgan tüm saldırıyı tek bir işlemde (1 dolar yatır, 1,5 milyon dolar aktar, 1.500.001 dolar çek) gerçekleştirdi ve ardından fonları yavaşça köprüledi. Köprü hız sınırı hasarı kısıtlayan tek mekanizmaydı: Olmasa, tüm ~1,5 milyon dolar geri dönüşü olmayan şekilde Ethereum'a köprülenirdi.

BlockSec Hakkında

BlockSec, tam kapsamlı bir blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokollerin ve platformların tam yaşam döngüsü boyunca kod denetimi (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil) yapmasına, saldırıları gerçek zamanlı olarak engellemesine, olayları analiz etmesine, yasa dışı fonları takip etmesine ve AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürünler ve hizmetler geliştiriyoruz.

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenlik makalesi yayımlamış, çeşitli DeFi uygulamalarının sıfırıncı gün saldırılarını bildirmiş, 20 milyonun üzerinde doları kurtarmak için birden fazla hacklemeyi engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.

• Resmi web sitesi: https://blocksec.com/

• Resmi Twitter hesabı: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Denetim Hizmeti : Talep gönderin

• 🔗 Phalcon Security Uygulaması: Demo rezervasyonu yapın

• 🔗 Phalcon Compliance