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

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

Haftanın Öne Çıkanı: KelpDAO

İstismar sonrası zincirleme etkiyi, Arbitrum'un zincir üstü kurtarma mekanizmasını ve daha geniş yönetişim çıkarımlarını ele alan özel bir rapor için bkz.: Merkeziyetsizlik İkilemi: KelpDAO Krizinde Basamaklı Risk ve Acil Durum Yetkisi

Bu olay; akıllı sözleşme istismarı yerine tek DVN'ye yönelik RPC zehirlenmesi biçimindeki özgün altyapı düzeyi saldırı vektörü, DeFi bileşilebilirliği aracılığıyla birden fazla zincirde yarattığı zincirleme etki ve Arbitrum'un çalınan fonları kurtarmak için uyguladığı zorunlu durum geçişinin gündeme getirdiği yönetişim soruları nedeniyle öne çıkmaktadır.

18 Nisan 2026'da KelpDAO'nun rsETH LayerZero OFT köprüsü, devlet destekli bir aktöre —büyük olasılıkla DPRK'nın Lazarus Grubu'na— atfedilen bir saldırıyla yaklaşık 290 milyon dolar zarara uğratıldı [1]. Temel neden, KelpDAO'nun zincirler arası mesaj doğrulamasını tek bir başarısızlık noktasına indirgeyen 1'e 1 DVN yapılandırmasıydı. Saldırgan, LayerZero Labs DVN'nin güvendiği RPC altyapısını zehirledi; DVN'yi sahte bir zincirler arası mesajı onaylamaya zorladı ve böylece Unichain tarafında herhangi bir kaynak olayı olmaksızın Ethereum'da 116.500 rsETH'nin serbest bırakılmasına neden oldu.

Arka Plan

LayerZero, modüler bir güvenlik mimarisi üzerine inşa edilmiş bir zincirler arası mesajlaşma protokolüdür. Temelinde, zincirler arası mesaj bütünlüğü; bir kaynak zincirde gönderilen mesajın, hedef zincirde yürütülmeden önce gerçekten gerçekleştiğini bağımsız olarak doğrulamakla sorumlu zincir dışı varlıklar olan Merkezi Olmayan Doğrulayıcı Ağları (DVN'ler) tarafından sağlanır. LayerZero üzerinde dağıtım yapan 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 yapılandırmasını kendisi belirler. Bu modülerlik, uygulamalara güvenlik modelleri üzerinde tam denetim sağlar; ancak tam sorumluluk da onlara aittir: zayıf bir yapılandırmanın açığını protokolün kendisi kapatamaz.

KelpDAO'nun rsETH'si, Unichain (kaynak) ile Ethereum ana ağı (hedef) arasında bir köprü rotasıyla LayerZero üzerinde OFT (Zincirler Arası Değiştirilebilir Token) olarak dağıtılmıştır. OFT standardı, tokenların kaynak zincirde yakılmasına ve hedef zincirde bir kilit mekanizmasından serbest bırakılmasına olanak tanır; bu süreçte zincirler arası mesaj, serbest bırakma için tek yetkilendirme unsuru olarak işlev görür. Ethereum tarafındaki adaptör (0x85d456...e98ef3), geçerli bir zincirler arası mesaj doğrulanıp iletildiğinde alıcılara rsETH göndermekten sorumludur. Kritik biçimde KelpDAO, bu rotayı 1'e 1 DVN yapılandırmasıyla kurmuş ve LayerZero Labs'ı tek doğrulayıcı olarak belirlemiştir. Bu, tek bir DVN onayının herhangi bir token serbest bırakımını yetkilendirmeye yettiği ve ikinci bir görüşe gerek duyulmadığı anlamına gelir.

Doğrulama görevlerini yerine getirebilmek için LayerZero Labs DVN, kaynak zincirde 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 öz işletilen altyapıyı hem de harici sağlayıcıları kapsar; DVN, bir onay imzalamadan önce bunların toplu yanıtlarına güvenir. Bu sürecin bütünlüğü, sorgulanan düğümlerin çoğunluğunun doğru veri döndürdüğü varsayımına dayanır.

Güvenlik Açığı Analizi

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

Birincisi, KelpDAO'nun 1'e 1 DVN yapılandırması doğrulama katmanındaki tüm yedekliliği ortadan kaldırdı. LayerZero'nun önerilen güvenlik duruşu, bağımsız doğrulayıcılara sahip çok DVN'li kurulumları açıkça zorunlu kılmaktadır; böylece hiçbir tek DVN tek başına bir mesajı yetkilendiremez. 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ırakımını yetkilendirmeye yeteceği bir durum yarattı.

İkincisi, DVN'nin yük devretme mekanizması, doğrulama sorgularını erişilebilir kalan RPC düğümlerine yönlendirir. Bu tasarım, düğüm erişilemezliğinin kasıtsız olduğunu varsayar. Ancak bu durum, saldırganın tüm veri kaynaklarını ele geçirmesine gerek kalmadığı bir koşul yaratır: sağlıklı düğümleri DDoS ile çevrimdışı bırakarak ve zehirlenmiş düğümleri erişilebilir tek alternatif olarak hazır tutarak saldırgan, DVN'nin aldığı veriler üzerinde tam denetim elde edebilir.

Üçüncüsü, RPC düğümlerindeki op-geth yürütülebilir dosyasının değiştirilmesi, 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 denetlenmesindeki ortak bir zayıflığa işaret edebilir.

Bu üç koşul bir araya gelerek tam bir saldırı zinciri oluşturdu: birincisi onaylanan mesajı çapraz denetleyecek bağımsız bir DVN bulunmamasını sağladı, ikincisi saldırganın tek DVN'nin aldığı veriler üzerinde tam denetim kurmasına olanak tanıdı, üçü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'e 1 yapılandırma olmasaydı, bağımsız altyapıyı sorgulayan ikinci bir DVN sahte mesajı reddederdi. Yük devretme davranışı olmasaydı, sağlıklı düğümler zehirlenmiş düğümleri oylama yoluyla geçersiz kılardı. Sunucu ele geçirme olmadan saldırganın sahte veri enjekte edecek herhangi 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, yüksek değerli bir istihbarat hedefi oluşturuyordu; zira tam düğümleri bilmek, saldırganın geniş çaplı bir altyapı saldırısı yerine cerrahi bir operasyon planlamasına olanak tanıdı.

• Adım 2: Saldırgan, iki RPC düğümüne işletim sistemi düzeyinde yazma erişimi elde etti 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ı olmayan bağımsız kümeler üzerinde çalıştığı belirtildi; bu durum, ilk erişim vektörünün paylaşılan bir yukarı akış bağımlılığını (örn. ele geçirilmiş dağıtım kimlik bilgileri, bir CI/CD hattı veya her iki sisteme erişimi olan bir operatörün sosyal mühendislikle kandırılması) içerdiğini 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ı: yalnızca DVN'nin IP adresine sahte işlem verisi döndürürken LayerZero'nun kendi izleme altyapısı, blok tarayıcılar ve tarama hizmetleri de dahil olmak üzere diğer tüm sorgulayıcılara 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ı; dış perspektiften bakıldığında kaynak zincir normal görünüyordu.

• Adım 4: DVN'nin dahili konsensüsü, hem zehirlenmiş hem de ele geçirilmemiş RPC düğümleri arasında uzlaşı gerektiriyordu. Bu çatışmayı çözmek için saldırgan, saldırı penceresi boyunca (Pasifik Saati ile 10:20 - 11:40) kalan sağlıklı düğümlere DDoS saldırısı düzenledi; böylece DVN'nin yük devretme mantığını tetikleyerek onu 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 gerçek verileri döndürecekti.

• Adım 5: DVN artık yalnızca saldırgan tarafından kontrol edilen verileri alırken, 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â maksimum giden nonce olarak 307'yi raporladığı teyit edildi).

• Adım 6: Geçerli biçimde onaylanmış bir mesaj alan Ethereum tarafındaki rsETH adaptörü, saatler önce Tornado Cash aracılığıyla önceden fonlanan saldırganın alıcı adresine (0x8b1b6c...0d3b) 116.500 rsETH serbest bıraktı. Çalınan tokenlar hemen yedi alt cüzdana dağıtıldı ve Aave teminat pozisyonları, doğrudan ETH takasları 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, tamamlanmasının ardından kendini yok etme rutinini çalıştırdı; kendisini tüm yerel günlükler ve yapılandırma dosyalarıyla birlikte sildi. Bu durum, olay sonrası adli kurtarmayı önemli ölçüde zorlaştırdı ve saldırganın operasyonel karmaşıklığını gözler önüne serdi.

• Adım 8: Saldırganın aynı yolu kullanarak ek 40.000 rsETH (~95 milyon dolar) için yaptığı ikinci girişim, KelpDAO'nun anomaliyi tespit ederek Ethereum ana ağı ve L2'lerdeki tüm ilgili sözleşmeleri duraklatmasının ardından engellendi [2].

Daha Geniş Etki

Hasar, 290 milyon dolarlık ilk köprü istismarasının çok ötesine geçti. Saldırgan, yaklaşık 89.567 rsETH (~221 milyon dolar) tutarında varlığı E-Mode'un %93 LTV'siyle birden fazla Aave pazarına teminat olarak yatırdı ve 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 kabul edildi. Bunun sonucunda oluşan WETH rezerv dondurma işlemi Ethereum, Arbitrum, Base, Mantle ve Linea genelinde yayıldı; rsETH'ye hiçbir maruziyeti olmayan kullanıcıları da etkiledi. Tek bir köprü yapılandırma hatasından çok zincirli borç verme piyasası kesintisine uzanan bu zincirleme yayılma, DeFi bileşilebilirliğinin tek bir başarısızlık noktasının hem erişimini hem de maliyetini nasıl artırdığını gözler önüne serdi.

Sonrasında yaşananlar, merkeziyetsizliğin operasyonel gerçekliğine ilişkin eşit derecede önemli sorular da gündeme getirdi. LayerZero Labs, DVN'sinin artık 1'e 1 yapılandırma kullanan uygulamalar için mesaj imzalamayacağını duyurdu [1]; bu durum, protokol düzeyi merkeziyetsizliğinin tek başına uygulama düzeyi 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 uyguladı. BlockSec'in analizinde [5] belirtildiği üzere bu işlem, zincir düzeyinde zorunlu 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 adresini taklit eden imzasız bir L1'den L2'ye mesaj enjekte etti ve orijinal uygulamayı geri yükledi; tüm bunlar, hesap sahibinin imzası gerekmeksizin yapıldı [3].

Bu eylem, şeffaf biçimde ve kolluk kuvvetleriyle koordineli olarak yürütülen, yönetişim tarafından tanımlanmış acil durum yetkilerinin meşru bir kullanımıydı. Bununla birlikte, L2 zincirlerinin tasarım gereği merkezi müdahale kapasitelerini koruduğunu da göstermektedir: Arbitrum One üzerindeki herhangi bir varlık, prensipte Güvenlik Konseyi tarafından aynı mekanizma aracılığıyla taşınabilir. Bir sistemin teorik güven modeli ile gerçek güven sınırı arasındaki boşluk —bu olayın her katmanda gösterdiği gibi— en kritik 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 çalıştı; güvenlik açığı tamamen onun üzerindeki operasyonel katmanda bulunuyordu. Temel ders, zincir dışı doğrulama altyapısının güven sınırının bir parçası olduğu ve güvenlik duruşunun koruduğu değerle örtüşmesi gerektiğidir.

Üç hafifletici önlem bu sonucu tek başına önleyebilirdi:

• Çok DVN yapılandırması: Birden fazla bağımsız DVN arasında konsensüs gerektirmek, tek bir DVN'nin ne kadar tamamen kandırıldığından bağımsız olarak bir mesajı yetkilendirmeye yetmeyeceği bir durum yaratırdı.

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

• RPC altyapısı sertleştirmesi: Üretim ortamındaki bir RPC düğümünde çalışan bir yürütülebilir dosyayı değiştirebilme kapasitesi, altta yatan sunucularda yetersiz erişim denetimlerine işaret etmektedir. DVN'lerin kaynak zincir gerçeği için bel bağladığı altyapı, DVN imzalama örnekleriyle aynı güvenlik sınırına tabi olmalıdır.

Daha geniş bir perspektiften bakıldığında, zincir dışı onaylamaya 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ütümüne kadar uzanan tam veri hattını denetlemelidir. Yüzlerce milyon dolar ona bağlı olduğunda RPC altyapısının varsayılan olarak güvenilir olduğu varsayımı artık savunulamaz.

Kaynaklar

[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 Haftaki Diğer Olaylar

Rhea Finance

16 Nisan 2026'da Rhea Finance bünyesindeki NEAR tabanlı bir borç verme ve marjin ticareti protokolü olan Burrowland, marjin ticareti modülündeki bir iş mantığı açığı nedeniyle yaklaşık 18,4 milyon dolar zarara uğratıldı. Kaldıraçlı bir pozisyon açarken protokol, pozisyonu kabul etmeden önce beklenen takas çıktısını doğrulamak için verify_token_out() fonksiyonuna güvenir. Ancak bu fonksiyon, token nihai çıktı tokenıyla eşleştiğinde token_out miktarlarını ara takas adımlarından hatalı biçimde biriktirdi; 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 döngüsel bir takas yolu kurguladı; böylece protokolden yaklaşık 18,4 milyon dolar drenledi.

Arka Plan

Burrowland, NEAR üzerinde açık kaynaklı bir borç verme ve marjin ticareti protokolüdür. Standart arz ve borç işlevlerine ek olarak marjin ticaretini de destekler ve kullanıcının kaldıraçlı pozisyonunu temsil etmek için üç temel değişken tanımlar: token_c (teminat), token_d (borç varlığı) ve token_p (pozisyon varlığı).

Uzun pozisyonda kullanıcı, token_c'yi teminat olarak yatırır ve seçtiği bir kaldıraçla (örn. 5x) token_d borç alır. Borç alınan token_d, ardından bir DEX'te kullanıcının maruz kalmak istediği varlık olan token_p'ye takas 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 elinde tutarken borç alınan token_d'yi borç olarak kaydeder.

Kısa pozisyonda kullanıcı benzer biçimde token_c'yi yatırır ve kaldıraçla token_d (açığa satmak istediği varlık) borç alır. Borç alınan token_d, başka bir varlıkla (token_p) takas edilerek token_d'ye kısa bir maruziyet elde edilir. Yine takasın, normal piyasa koşullarında değeri koruyacağı beklentisi vardır.

Pozisyonun yaşam döngüsü boyunca token_p, protokol bünyesinde muhafaza edilir ve kullanıcı bunu doğrudan çekemez. Kâr ya da zararı gerçekleştirmek için pozisyonun kapatılması gerekir; bu noktada borcu ödemek amacıyla token_p, token_d'ye geri takas edilir.

Marjin pozisyonu açma işlemi internal_margin_open_position() tarafından yönetilir; bu fonksiyon pozisyon parametrelerini kurar ve borcu DEX'e iletir.

Protokol yeni bir pozisyonu kabul etmeden önce dört korumayı sırayla değerlendirir: is_min_amount_out_reasonable(), kayma payını sınırlamak amacıyla kullanıcının beyan ettiği min_token_p_amount'u Pyth oracle'ın ima ettiği takas çıktısıyla çapraz denetler; is_open_position_liquidatable(), beklenen pozisyon ve teminat değerinin tasfiye sınırını geçip geçmediğini doğrular; is_open_position_forcecloseable(), hesabın kâğıt üzerinde zaten ödeme güçsüzü olup olmadığını denetler; get_open_position_lr() ise token_d / token_c değerinin maksimum kaldıraç oranını aşmamasını sağlar.

Takas henüz gerçekleşmediğinden ve kullanılacak gerçekleşmiş bir miktar bulunmadığından dört kontrol de pozisyon varlığının değeri olarak min_token_p_amount'u kullanır. Dolayısıyla her geçidin doğruluğu, min_token_p_amount'un DEX'in gerçekte teslim edeceği değere bağlı olmasına dayanır. Bu bağlantıyı tam olarak verify_token_out() —RefV1TokenReceiverMessage::get_token_out() aracılığıyla uygulanır— kullanıcının sunduğu takas mesajında sağlaması gerekmektedir.

Güvenlik Açığı Analizi

Açık, verify_token_out() fonksiyonunun içindedir. Fonksiyon, son takas adımının token_out'unu nihai çıktı tokeni olarak seçer; ardından her böyle üretimin nihai çıktıya katkıda bulunduğu varsayımıyla aynı tokeni üreten her takas adımının beyan edilen min_amount_out'unu toplar. Bu, gerçek bir çok yollu (bölünmüş rota) takas 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ı takip eden B->A adımında harcanıp Burrowland'e hiçbir zaman ulaşmasa bile toplama dahil edilmesine yol açar. verify_token_out()'un onayladığı toplanmış min_amount_out artık DEX'in gerçekte döndüreceği miktarı temsil etmez.

verify_token_out() atlatıldıktan sonra şişirilmiş min_token_p_amount, internal_margin_open_position() boyunca gerçek veri olarak kabul edilir. Güvensiz bir açılışı durdurmak için tasarlanan her ödeme gücü geçidi, uydurma bir sayıya göre hesaplama yapar; böylece pozisyon kabul edilir ve protokol, döngüsel takas mesajı eklenmiş biçimde 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 marjin ticareti özelliğini kullanarak token_c olarak meşru değerli bir varlıkla ve token_d olarak gerçek bir rezerv varlıkla kaldıraçlı bir pozisyon açtı; eylem listesi Aşama 1'deki saldırgan kontrolündeki havuzlar üzerinden yönlendirilen A->B->A->B gidiş-dönüş bir takas mesajı ekledi.

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

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

• Adım 4: Döngüsel takas, yalnızca toz miktarında token_p döndürdü; on_open_trade_return() bunu herhangi bir yeniden kontrol yapmaksızın deftere işledi ve pozisyonu başlangıçtan itibaren ödeme güçsüzü bıraktı.

• Adım 5: Borç alınan token_d, yol boyunca saldırgan kontrolündeki havuzlara yerleşti; saldırgan bunu remove_liquidity() çağrısıyla geri çekti.

• Adım 6: Borç kaldıraçlı olduğundan, çekilen token_d yatırılan token_c'den daha değerliydi. Aradaki fark her döngü için net kârdı; tahsil edilemeyen borç ise protocol_debts altına zorla kapatıldı. Saldırgan, yaklaşık 18,4 milyon dolar dreninceye 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şen her ara çıktıyı bu miktarların nihai çıktı olarak kalacağını varsayarak hatalı biçimde topladı. Ancak döngüsel takas yolları bu varsayımı bozar; zira bu tokenlar yol içinde yeniden kullanılıp tüketilebilir. Sonuç olarak hesaplanan min_token_p_amount yapay biçimde şişirilebilir; bu durum tüm sonraki ödeme gücü kontrollerinin hatalı bir değere dayanmasına ve gerçekte alınan miktarı doğrulamaksızın sahte bir sağlık durumuna karşı pozisyon açılmasına yol açar.

Üretim ortamındaki marjin ticareti 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 ele almalı 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 takas yollarını açıkça reddetmelidir (hedef üzerinden döngü olmamalıdır).

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

Hyperbridge

13 Nisan 2026'da Ethereum üzerinde zincirler arası bir mesajlaşma köprüsü olan Hyperbridge, MMR (Merkle Dağ Silsilesi) kanıt doğrulama mantığındaki eksik girdi doğrulaması nedeniyle yaklaşık 242 bin dolar zarara uğratıldı. MerkleMountainRange.VerifyProof() fonksiyonu leaf_index < leafCount koşulunu zorunlu kılmadığından saldırgan zincirler arası bir kanıtı taklit edebildi ve 1.000.000.000 DOT tokeni basma da dahil olmak üzere 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 üzerinde HandlerV1 sözleşmesi, sağlanan kanıtları depolanan overlayRoot'a karşı doğrular; kanıt kabul edilirse mesajı TokenGateway sözleşmesi gibi hedef modüllere dağıtır.

TokenGateway sözleşmesi, ayrıcalıklı bir varlık yönetimi 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 stilinde 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 durum, tüm varlık köprüsünün güvenliğinin HandlerV1 içindeki kanıt doğrulama yolunun doğruluğuna bağlı olduğu anlamına gelir. Sahte bir mesaj doğrulamayı geçebilirse, aşağı akış modülleri saldırgan tarafından kontrol edilen yükleri otantik zincirler arası talimatlar olarak kabul edecektir.

Güvenlik Açığı Analizi

Temel sorun, HandlerV1 sözleşmesindeki (0x6c84ed...6d64) MMR kanıt doğrulama akışında yatmaktadı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ğrulamasını 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 denetler; 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 katmadan doğrudan zirve kökünü döndürmesine yol açar. Bu durum, mesaj ile kanıt arasındaki bağı koparır ve keyfi yüklerin geçmiş bir overlayRoot'a karşı geçerli olarak sunulmasına olanak tanır.

Saldırı Analizi

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

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

• Adım 2: 0x31a1...ca9AB yardımcı sözleşmesi, HandlerV1 içindeki 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ş bir overlayRoot'la eşleşti.

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

• Adım 4: Yardımcı sözleşme 1.000.000.000e18 adet DOT tokeni basti.

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

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

Sonuç

Bu olay, Hyperbridge'in MMR doğrulama mantığındaki yetersiz kanıt doğrulamasından kaynaklandı. leaf_index < leafCount koşulu zorunlu kılınmadığından saldırgan, taahhüdü hesaplanan köke hiçbir zaman dahil edilmemiş bir mesajı taklit edebilirken geçmiş bir durum köküne karşı doğrulamayı geçebildi. Hafifletici önlemler, kanıt doğrulamasından önce leaf_index < leafCount gibi katı sınır kontrollerini zorunlu kılmalıdır.

Kaynaklar

[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ş bir sürekli vadeli işlemler DEX'i olan Dango, eksik işaret kontrolü nedeniyle yaklaşık 1,5 milyon dolar zarara uğratıldı. 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 girerek sigorta fonunu kendi marjin pozisyonuna drenetmesine olanak tanıdı.

Arka Plan

Dango, Cosmos AppChain olarak inşa edilmiş bir sürekli vadeli işlemler DEX'idir. Kullanıcılar, USDC'yi teminat olarak perps sözleşmesine yatırır ve zincir üstü Merkezi Limit Emir Defteri (CLOB) aracılığıyla BTC, ETH ve SOL gibi varlıklarda 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 takip edilir.

Likidite sağlayıcılarını (LP) kötü borç kayıplarından korumak amacıyla protokol bir sigorta fonu tutar: tasfiye edilen bir pozisyonun teminatı borcunu tamamen karşılamaya yetmediğinde ortaya çıkan açığı kapatan, perps sözleşmesi bünyesinde tutulan bir USDC rezervi. Bu fon olmadan söz konusu açıklar doğrudan LP'lere sosyalize edilirdi. Herhangi bir kullanıcı, perp hesabından marjin katkısında bulunabilirdi.

Güvenlik Açığı Analizi

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

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

Her iki koruma da geçildikten sonra 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; toplama işlemi ise sigorta fonunu azaltır; böylece amaçlanan fon akışı tamamen tersine döner.

Saldırı Analizi

İşlemler:

Aşama 1:

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

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

• Adım 2: Saldırgan, negatif bir amount (yani -1500000) ile replenish_insurance_fund() fonksiyonunu çağırdı. Yetersiz doğrulama nedeniyle negatif amount kabul edildi; böylece sigorta fonundan varlıklar saldırganın marjin pozisyonuna drenlendi.

• Adım 3: Saldırgan, marjin pozisyonundaki tüm varlıkları çekti ve 1.500.000 dolar değerinde USDC elde etti.

Aşama 2:

İşlem 2-8'de saldırgan, çalınan varlıkları Ethereum'a köprülemek için transfer_remote() fonksiyonunu çağırdı. Bunun sonucunda 410.000 dolar değerinde USDC Ethereum'a köprülendi.

Sonuç

Bu saldırının özü, işaretsiz bir bağlamda işaret koruması olmaksızın 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() kullanılması, herhangi bir çağrıcının fon akışının yönünü tersine çevirmesine —USDC'yi sigorta fonundan kendi marjinine drenlemesine— olanak tanıyan tek sözcüklük bir boşluk bıraktı. Saldırgan tüm saldırıyı tek bir işlemde (1 dolar yatır, 1,5 milyon dolar dren et, 1.500.001 dolar çek) gerçekleştirdi ve ardından fonları yavaş yavaş köprüledi. Köprünün hız sınırı hasarı sınırlayan tek mekanizmaydı: bu sınır olmadan tüm ~1,5 milyon dolar geri dönüşü olmaksızın Ethereum'a köprülenmiş olurdu.

BlockSec Hakkında

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

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenliği makalesi yayımlamış, çeşitli DeFi uygulamalarına yönelik sıfırıncı gün saldırılarını raporlamış, 20 milyonun üzerinde doları kurtarmak için birden fazla saldırıyı engellemiş ve milyarlarca dolarlık kripto varlığını 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 Uyum