Haftalık Web3 Güvenlik Olayları Özeti | 23 Mart – 29 Mart 2026

Geçen hafta (2026/03/23 - 2026/03/29), BlockSec sekiz saldırı olayını tespit ederek analiz etti; toplam tahmini kayıplar yaklaşık 1,53 milyon dolar olarak gerçekleşti. Aşağıdaki tablo bu olayları özetlemekte olup her bir olayın ayrıntılı analizi ilerleyen alt bölümlerde sunulmaktadır.

1. Bilinmeyen Olay 1

Kısa Özet

23 Mart 2026'da, Ethereum üzerindeki doğrulanmamış bir sözleşme, dağıtım mantığındaki tamsayı taşması nedeniyle yaklaşık 97K$ zarara uğratıldı. 0x317de4f6() fonksiyonu, taşma koruması olmadan kullanıcı kontrollü token miktarlarını topladığından saldırgan, bir sarma (wraparound) tetikleyerek yalnızca 1 wei USDT ödeyip claim() fonksiyonu aracılığıyla sözleşmenin tüm USDT bakiyesini çekmeyi başardı.

Güvenlik Açığı Analizi

Temel neden, 0xF0a105...568C97 sözleşmesinin 0x317de4f6() fonksiyonundaki tamsayı taşmasıydı. Fonksiyon, her biri bir hesap ve bir miktar içeren kayıt dizisini kabul eder ve dizi üzerinde yineleyerek tüm miktarları totalAmount içinde toplar. Birikim taşma denetiminden yoksun olduğundan saldırgan, miktarları uint256 değerini saran şekilde tasarlanmış kayıtlar sağlayarak totalAmount'u keyfi biçimde küçültürken bireysel tahsisleri büyük tutabildi.

Saldırı Analizi

Aşağıdaki analiz, 0x73bd1384...630b053 işlemine dayanmaktadır.

• Adım 1: Saldırgan, saldırı için başlangıç sermayesi olarak Uniswap V4'ten 1 wei USDT aldı.

  

• Adım 2: Saldırgan, kurban sözleşmenin USDT bakiyesini sorguladı ve ardından özel hazırlanmış bir diziyle 0x317de4f6() fonksiyonunu çağırdı. Miktarlardan biri uint256 üst sınırına yakın, diğeri ise kurban sözleşmenin USDT bakiyesine eşit olarak ayarlandı. Toplamları 1'e taştı ve böylece saldırgan, kurbanın tam USDT bakiyesine eşit bir tahsis kaydettirirken yalnızca 1 wei USDT ödedi.

  

• Adım 3: Saldırgan, kurban sözleşmeden 97.812e6 USDT çekmek için claim() fonksiyonunu çağırdı.

  

• Adım 4: Saldırgan, Uniswap V4'ten ödünç aldığı 1 wei USDT'yi geri ödedi ve kalan USDT'yi WETH ile takas ederek saldırıyı tamamladı.

Sonuç

Bu olay, 0.8.0 öncesi Solidity sürümlerinde denetlenmemiş aritmetik kullanmanın risklerini gözler önüne sermiştir. Tüm kritik finansal hesaplamalar, sarma sorunlarını önlemek için açıkça taşma güvenli aritmetik (ör. SafeMath veya Solidity >=0.8.x) kullanmalıdır.

2. Bilinmeyen Olay 2

Kısa Özet

23 Mart 2026'da, Ethereum üzerindeki doğrulanmamış bir sözleşme, yeniden giriş güvenlik açığı nedeniyle yaklaşık 11K$ zarara uğratıldı. 0xbe16634e() fonksiyonu, uzlaşmadan önce likiditeyle ilgili muhasebeyi güncelledi ve herhangi bir yeniden giriş koruması olmaksızın harici bir geri çağırma fonksiyonu tetikledi. Saldırgan, önceki çağrı tamamlanmadan önce fonksiyona defalarca yeniden girerek kayıtlı likiditesini şişirdi ve sonunda yatırdığından daha fazla USDC ile WETH çekmeyi başardı.

Güvenlik Açığı Analizi

Temel neden, 0x39Ed37...9C6b08 sözleşmesinin 0xbe16634e() fonksiyonundaki yeniden giriş sorunudur. Bu fonksiyon, uzlaşmadan önce kullanıcı likiditesi ve tick rezervleri de dahil olmak üzere likiditeyle ilgili durumu güncellemekte ve herhangi bir yeniden giriş koruması olmaksızın msg.sender.call() aracılığıyla harici bir geri çağırma fonksiyonu tetiklemektedir. Bakiye denetimi çağrı bazında gerçekleştirildiğinden saldırgan, iç likidite muhasebesini şişirmek için fonksiyona yinelemeli olarak yeniden girebilmekte; en derin çağrıdaki tek bir token transferi ise iç içe geçmiş yürütme akışını karşılamaya yetmektedir.

Saldırı Analizi

Aşağıdaki analiz, 0x1382e898...fad993 işlemine dayanmaktadır.

• Adım 1: Saldırgan, saldırı için başlangıç sermayesi olarak Uniswap V4'ten 100e8 USDC ve 10e18 WETH aldı.

  

• Adım 2: Saldırgan, likidite eklemek için 0xbe16634e() fonksiyonunu çağırdı. Yürütme sırasında kurban sözleşme, saldırganın 0x7c65be42() fonksiyonunu çağırdı; bu fonksiyon ise önceki çağrı tamamlanmadan 0xbe16634e() fonksiyonuna yeniden girdi.

  

• Adım 3: Saldırgan bu yeniden giriş akışını defalarca tekrarlayarak kayıtlı likiditesini sürekli artırdı. En derin çağrıda saldırgan, iç içe geçmiş bakiye denetimlerini karşılamaya yetecek miktarda token bir kez transfer etti.

  

• Adım 4: Kayıtlı likiditesini şişirdikten sonra saldırgan, havuz durumunu kontrol etti ve yaklaşan çekimi karşılayacak yeterli USDC ve WETH bulunmasını sağlamak için havuza ek fon transfer etti.

  

• Adım 5: Saldırgan, likiditeyi kaldırmak için 0xbe16634e() fonksiyonunu tekrar çağırdı ve şişirilmiş muhasebeye dayanarak havuzdan USDC ile WETH çekti.

  

• Adım 6: Saldırgan Uniswap V4'e borcunu ödedi, kalan USDC'yi WETH ile takas etti ve saldırıyı tamamladı.

  

Sonuç

Bu olay, uzlaşmadan önce likidite muhasebesini güncellerken korumasız bir harici geri çağırma fonksiyonu tetiklemenin tehlikelerini ortaya koymaktadır. Benzer saldırıları önlemek için protokoller, kontroller-etkiler-etkileşimler (checks-effects-interactions) örüntüsüne sıkı sıkıya uymalı ve harici geri çağırma fonksiyonlarını yeniden giriş koruyucularıyla güvence altına almalıdır.

3. Cyrus Finance Olayı

Kısa Özet

23 Mart 2026'da, BNB Chain üzerindeki bir getiri çiftçiliği protokolü olan Cyrus Finance, havuzun mevcut anlık fiyatına bağlı hatalı bir likidite kaldırma formülü nedeniyle yaklaşık 512K$ zarara uğratıldı. Protokol, PancakeSwap V3 likiditesinin oransal payını temsil etmek için CYRP NFT pozisyonlarını kullanmakta; ancak kullanıcı payından temel likiditesine dönüşüm, aynı işlem içinde manipüle edilebilen slot0() değerini okumaktadır. Saldırgan, flaş kredi destekli bir takas aracılığıyla fiyatı kaydırarak NFT pozisyonunun likidite değerini şişirdi ve hak ettiğinden fazlasını çekmeyi başardı.

Arka Plan

Cyrus Finance, BNB Chain üzerinde PancakeSwap V3 havuzlarındaki likidite pozisyonlarını yöneten bir getiri çiftçiliği protokolüdür. Kullanıcılar, protokolün birden fazla PancakeSwap V3 pozisyonundaki likiditedeki paylarını temsil eden CYRP NFT pozisyonları almak için USDT yatırır. Kullanıcılar, exit() fonksiyonu aracılığıyla anaparalarını ve ödüllerini çekebilir.

Güvenlik Açığı Analizi

Güvenlik açığı, CyrusTreasury (0xb042Ea...0aE10b) içindeki withdrawUSDTFromAny() fonksiyonunda bulunmaktadır. Bir çekme işlemi gerçekleştirilirken fonksiyon, PancakeSwap V3 havuzunun slot0() değerinden (yani mevcut anlık fiyattan) sqrtPriceX96 bilgisini alır ve protokolün tam pozisyon likiditesinin o anda ne kadar amount0 / amount1 temsil ettiğini tahmin etmek için bunu getAmountsForLiquidity() fonksiyonuna geçirir.

Ardından bu anlık fiyat bazlı değerlemeden availableUSDT değerini türetir ve talep edilen çekim için ne kadar likiditenin kaldırılması gerektiğini belirlemek amacıyla şu formülü kullanır:

$liquidityToUse=liquidity\cdot remaining\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

Diğer bir deyişle, sözleşme sabit bir sahiplik payını doğrudan geri ödememektedir. Bunun yerine önce canlı havuz fiyatını kullanarak pozisyonun mevcut USDT karşılığı değerini tahmin eder ve ardından talep edilen USDT miktarını oransal bir likidite miktarına geri dönüştürür.

slot0() aynı işlem içinde manipüle edilebildiğinden bu yöntem güvensizdir. Havuz fiyatını geçici olarak hareket ettiren bir saldırgan availableUSDT değerini bozabilir ve bu durum hesaplanan liquidityToUse değerini doğrudan etkiler.

Saldırı Analizi

Aşağıdaki analiz, 0x85ac5d15...46d452 işlemine dayanmaktadır.

• Adım 1: Saldırgan, bir PancakeSwap V3 havuzundan yaklaşık 1.798 ETH ödünç alarak flaş kredi başlattı.

• Adım 2: Saldırgan, protokolün likidite tuttuğu hedef havuzda büyük bir ETH'den USDT'ye takas gerçekleştirerek havuz fiyatını ve mevcut tick değerini kasıtlı olarak kaydırdı. Eş zamanlı olarak saldırgan, safeTransferFrom() aracılığıyla 0x01737d...6ffa3 adresinden saldırı sözleşmesine CYRP NFT pozisyonu #15505'i transfer etti.

• Adım 3: Saldırgan, CyrusTreasury üzerinde exit(15505) fonksiyonunu çağırdı. Yürütme sırasında withdrawUSDTFromAny(), PancakeSwap V3 havuzundan slot0() değerini okudu ve manipüle edilmiş anlık fiyata dayanarak availableUSDT hesapladı. Bozulan tick değeri nedeniyle protokol, NFT payına karşılık gelen likidite değerini olduğundan yüksek tahmin etti. Ardından decreaseLiquidity() ve collect() fonksiyonlarını çağırarak Cyrus pozisyonunun adil değerinin ötesinde fazladan USDT serbest bıraktı.

  

• Adım 4: Saldırgan havuz durumunu eski haline getirdi, flaş krediyi geri ödedi ve kalan kârı (~512K$) 0xf96EB1...3b63b EOA adresine transfer etti.

Sonuç

Çözüm olarak, likiditesini çekilebilir USDT'ye dönüştürmeden önce anlık slot0() fiyatlandırmasının, manipülasyona dirençli fiyatlandırmayla değiştirilmesi gerekmektedir (yeterli gözlem penceresi üzerinden TWAP veya Chainlink gibi harici bir oracle).

4. BCE Token Olayı

Kısa Özet

23 Mart 2026'da, BNB Chain üzerindeki PancakeSwap BCE-USDT havuzu, BCE tokenındaki hatalı yakma mekanizması nedeniyle yaklaşık 679K$ zarara uğratıldı. Saldırgan, BCE'nin alım/satım limitlerini aşmak için iki kötü amaçlı sözleşme konuşlandırdı ve likidite havuzu rezervlerine karşı token yakmalarını tetikleyerek havuzun fiyatını manipüle etti ve USDT'sini boşalttı.

Güvenlik Açığı Analizi

Güvenlik açığı, BCE tokenının (0xcdb189...999999) hatalı yakma mekanizmasından kaynaklanmaktadır. Temel sorun, kullanıcı etkisindeki bir durum değişkeni olan scheduledDestruction'ın, kullanıcının kendi bakiyesi yerine doğrudan PancakeSwap çiftinin adresinden token yakmak için kullanılmasıdır. Satış işlemleri sırasında sözleşme, işlem hacmine ve mevcut havuz rezervlerine dayanarak scheduledDestruction içinde bir imha miktarı biriktirir. Bu değer satıcıdan düşülmez; bunun yerine daha sonra çiftten token yakan ve sync() çağrısı yapan ayrı bir kod yolu aracılığıyla çalıştırılır.

Saldırgan işlem hacmini kontrol edebildiğinden ve havuz rezervlerini manipüle edebildiğinden, scheduledDestruction değerini keyfi bir değere ayarlayabilir ve çiftin BCE rezervini sıkıştıran, havuz fiyatını kendi lehine bozan bir yakma tetikleyebilir.

Saldırı Analizi

Aşağıdaki analiz, 0x85ac5d15...46d452 işlemine dayanmaktadır.

• Adım 1: Saldırgan, birden fazla flaş kredi ve bir borç havuzu aracılığıyla 123,5 milyon USDT ödünç almak için kötü amaçlı bir sözleşme (MC1) çalıştırdı.

• Adım 2: Saldırgan ikinci bir kötü amaçlı sözleşme (MC2) konuşlandırdı ve ödünç alınan tüm USDT'yi MC2'ye transfer etti.

• Adım 3: Saldırgan (MC2 aracılığıyla) BCE-USDT havuzunda 2,222 milyon USDT'yi 5,529 milyon BCE ile takas etti.

• Adım 4: Saldırgan, 5,529 milyon BCE'yi MC2'den MC1'e transfer etti (MC1.drain() aracılığıyla); yakma mekanizması nedeniyle MC1, 2,764 milyon BCE aldı.

• Adım 5: Saldırgan (MC1 aracılığıyla) 2,488 milyon BCE'yi 1,368 milyon USDT ile takas ederek havuz rezervlerine ve takas miktarına dayanarak scheduledDestruction değişkenini yaklaşık 174K olarak güncelledi. Bu değer daha sonra yakma miktarı olarak kullanıldı.

• Adım 6: Saldırgan (MC2 aracılığıyla) 34,9 milyon USDT'yi 3,484 milyon BCE ile takas ederek BCE rezervini daha da ~174K'ya doğru manipüle etti.

• Adım 7: Saldırgan, 3,484 milyon BCE'yi ve kalan USDT'yi MC2'den MC1'e transfer etti. scheduledDestruction değeri 0'dan büyük olduğundan (yaklaşık 174K), BCE transferi BCE rezervini ~10.000'e sıkıştıran yakmaları tetikledi.

• Adım 8: Saldırgan, kalan BCE'yi manipüle edilmiş fiyattan USDT ile takas etti.

• Adım 9: Saldırgan tüm kredileri geri ödedi ve yaklaşık 679K$ kâr elde etti.

Sonuç

Bu olay, kullanıcı etkisindeki bir durum değişkeninin kullanıcının kendi bakiyesi yerine likidite havuzunun bakiyesini değiştirmek için kullanıldığı token'ın ekonomik mantığındaki temel bir kusurdan kaynaklandı. Sözleşme, işlem faaliyetinden elde edilen imhanın kullanıcı maliyetini yansıtacağını örtük olarak varsaydı; ancak uygulamada bu durum, saldırganlara LP rezervlerine karşı uzlaştırılan ertelenmiş bir yakma oluşturma imkânı tanıdı. Sonuç olarak saldırganlar, sınırlı sermaye riskiyle havuz derinliğini ve fiyatlandırmasını manipüle ederek likidite sağlayıcılarından değer çekebildi.

5. Bilinmeyen Olay 3

Kısa Özet

25 Mart 2026'da, BNB Chain üzerindeki doğrulanmamış bir staking sözleşmesi, birden fazla staking modundaki tutarsız muhasebe nedeniyle yaklaşık 1,2K$ zarara uğratıldı. Sözleşme, bu fonksiyonlar farklı token sepetlerini ve oranlarını işlemesine karşın aynı pozisyon değişkenini stake2()/withdraw2() ve stake3()/withdraw3() arasında paylaştırdı. Saldırgan, daha hafif stake2() modu aracılığıyla yatırım yaparak daha ağır withdraw3() modu üzerinden çekim gerçekleştirdi ve defalarca fazla token çıkardı.

Arka Plan

Bu, birden fazla stake ve çekim moduna sahip bir staking sözleşmesidir. Standart stake() ve withdraw() yolu, Pangolin, Bzzt ve Bzzone'u ödül muhasebesi mantığıyla birlikte işleyen tam staking modudur. stake3() ve withdraw3() yolu aynı üç token sepetini ve aynı yatırım/çekim oranını kullanmakta; ancak ek ödül muhasebesi akışını atlamaktadır. Buna karşın stake2() ve withdraw2() yolu, yalnızca Pangolin ve Bzzt'yi işleyen daha hafif bir moddur ve bu nedenle diğer iki moddan farklı bir token kombinasyonu ile oran kullanmaktadır.

Güvenlik Açığı Analizi

Temel neden, 0x29d36c...774137 sözleşmesindeki tutarsız muhasebeydi. stake2()/withdraw2() ve stake3()/withdraw3() farklı token sepetlerini işlemesine karşın hepsi aynı _exit[msg.sender] ve _totalSupply değişkenlerini güncelledi. Sonuç olarak, daha hafif stake2() modu aracılığıyla oluşturulan bir pozisyon, daha ağır withdraw3() modu üzerinden çekilebilir hale geldi.

Pratikte stake2(amount) yalnızca amount kadar Pangolin ve amount kadar Bzzt çekerken withdraw3(amount) amount kadar Pangolin, 10 * amount kadar Bzzt ve 10 * amount kadar Bzzone geri transfer etti. Bu, stake2() aracılığıyla 20e18 Pangolin ve 20e18 Bzzt stake etmenin, withdraw3() aracılığıyla 20e18 Pangolin, 200e18 Bzzt ve 200e18 Bzzone çekmek için kullanılabilecek bir _exit bakiyesi oluşturduğu anlamına geliyordu. Saldırgan bu uyumsuzluğu tekrarlayarak sözleşmeden sürekli fazla token çıkardı.

Saldırı Analizi

Aşağıdaki analiz, 0x7fcd5882...323f8d işlemine dayanmaktadır.

• Adım 1: Saldırgan, 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302 adresine bir sözleşme konuşlandırdı; sözleşmeyi 0,05 BNB ile finanse etti, fonları WBNB'ye sardı, tam olarak 20e18 Pangolin, 20e18 Bzzt ve 200e18 Bzzone için takas yaptı ve staking sözleşmesinin edinilen tokenları harcamasına izin verdi.

  

• Adım 2: Saldırgan, 20e18 girdisiyle stake2() fonksiyonunu çağırdı; bu işlem 20e18 Pangolin ve 20e18 Bzzt'yi staking sözleşmesine transfer etti ve saldırganın paylaşılan _exit bakiyesini 20e18 artırdı.

  

• Adım 3: Saldırgan ardından 20e18 girdisiyle withdraw3() fonksiyonunu çağırdı. withdraw3() yalnızca paylaşılan _exit bakiyesini kontrol ettiğinden, pozisyon stake2() aracılığıyla oluşturulmuş olsa dahi sözleşme 20e18 Pangolin, 200e18 Bzzt ve 200e18 Bzzone geri transfer etti.

  

• Adım 4: Saldırgan, aynı işlem içinde stake2() -> withdraw3() döngüsünü defalarca tekrarladı. Her turda geri dönen Pangolin ve geri dönen Bzzt'nin küçük bir kısmı bir sonraki stake2() çağrısı için yeniden kullanılırken Bzzone, sonraki withdraw3() çağrılarının başarılı olmaya devam edebilmesi için staking sözleşmesine geri gönderildi. Bu döngü sayesinde saldırgan, Bzzt bakiyesini 20e18'den 16.400e18'e yükseltti.

• Adım 5: Saldırgan, edinilen tokenları WBNB'ye geri takas etti, fonları BNB'ye dönüştürdü ve yaklaşık 2,007e18 BNB'yi saldırgan EOA'ya transfer ederek saldırıyı tamamladı.

  

Sonuç

Benzer saldırıları önlemek için staking sözleşmeleri her mod için muhasebeyi ayrı tutmalı ve her çekim yolunun ilgili yatırım yolunun tam varlık bileşimiyle ve oranıyla eşleşmesini sağlamalıdır.

6. MYX Olayı

Kısa Özet

25 Mart 2026'da, Ethereum üzerindeki MYX Network'ün sMYX sözleşmesi saldırıya uğradı; havuzdan yaklaşık 6,67 milyon MYX tokeni boşaltıldı (~3,6K$ kâr). Temel neden, sMYX sözleşmesindeki transfer fonksiyonunun arz muhasebesi ile temettü dağıtım mantığı arasındaki hatalı etkileşimdi. Saldırgan, kontrol ettiği hesaplar arasında defalarca sMYX transfer ederek hisse başına kâr değişkenini şişirdi, karşılıksız temettüler üretti ve başlangıçta yatırdığından daha fazla MYX çekti.

Arka Plan

sMYX sözleşmesi (0x404328...d27F66), temettü dağıtım token modelini takip etmektedir. Kullanıcılar bir satın alma fonksiyonu aracılığıyla MYX tokeni yatırır ve paylarını temsil eden sMYX hisseleri alır. Temettüler, stor_11 içinde saklanan küresel bir biriktirici (hisse başına kâr) kullanılarak izlenir. Her kullanıcının talep edebileceği temettüler, birikmiş kârın oransal payı ile kayıtlı ödeme tabanı arasındaki fark olarak hesaplanır. Bu model, gelen değerin mevcut tutucular arasında yeniden dağıtıldığı daha önceki yansıma tarzı tokenlara kavramsal olarak benzemektedir.

Güvenlik Açığı Analizi

Güvenlik açığı, arz muhasebesi ile temettü dağıtım mantığı arasındaki hatalı etkileşimden kaynaklanmaktadır. Transfer fonksiyonu, transfer edilen miktarı mevcut toplam arza bölerek küresel hisse başına kâr değişkenini artırmakta ve bu suretle hatalı biçimde yeni temettüler ortaya çıkarmaktadır. Bu işlem herhangi bir gerçek MYX tokeni girişiyle desteklenmemekte; yani temettüler gerçek ekonomik faaliyetten değil, iç muhasebeden oluşturulmaktadır. Eş zamanlı olarak fonksiyon, hiçbir token fiilen yakılmamış olsa da çıkarma yardımcısının tersine çevrilmiş semantiği nedeniyle kayıtlı toplam arzı transfer edilen miktar kadar azaltmaktadır.

Sonuç olarak, aynı transfer miktarı giderek küçülen bir toplam arza bölündüğünden her sonraki transfer, hisse başına kâr değerine daha büyük bir artış sağlamaktadır.

Saldırı Analizi

Aşağıdaki analiz, 0x843c9ea7...a55b90 işlemine dayanmaktadır.

• Adım 1: Saldırgan, flaş takas aracılığıyla sermaye sağladı ve MYX'e dönüştürdü; ardından temettü sistemi içinde baskın bir pay pozisyonu elde etmek ve gelecekteki ödül dağıtımının büyük çoğunluğunu kontrol altına almak için sMYX sözleşmesine yatırdı.

• Adım 2: Saldırgan, pozisyonunu kontrol ettiği iki sözleşmeye böldü ve temettü gerçekleştirme ile durum manipülasyonu arasında dönüşümlü olarak geçen koordineli bir döngü başlatarak güvenlik açığı bulunan muhasebe yolunun defalarca geçilmesine olanak tanıdı.

• Adım 3: Kontrol edilen hesaplar arasında tekrarlanan transferler aracılığıyla saldırgan, kayıtlı toplam arzı eş zamanlı olarak azaltırken protokolün hisse başına kâr değişkenini yapay olarak şişirdi; böylece karşılıksız temettüler oluşturdu ve dağıtım oranlarını artırdı.

• Adım 4: Her manipülasyon döngüsünden sonra sürekli çekim yaparak saldırgan, bu uydurma ödüllerin büyük çoğunluğunu çıkardı ve böylece yeni sermaye getirmeksizin protokolden MYX rezervlerini fiilen boşalttı.

• Adım 5: Saldırgan tüm pozisyonlardan çıktı, çıkarılan MYX'i WETH'e takas etti, flaş krediyi geri ödedi ve kalan bakiyeyi kâr olarak elinde tuttu.

Sonuç

Bu olay yalnızca Ponzi benzeri bir ekonomik tasarımın sonucu değil, temettü muhasebesinin uygulanmasındaki kritik bir hatadır. Benzer güvenlik açıklarını azaltmak için transfer işlemleri toplam arzı etkilememeli veya temettü dağıtımını tetiklememeli; hisse başına kâr güncellemeleri ise yalnızca gerçek varlıklar sisteme girdiğinde gerçekleşmelidir.

7. Bilinmeyen Olay 4

Kısa Özet

26 Mart 2026'da, BNB Chain üzerindeki yönlendirici ödüllü bir TUR staking sözleşmesi yaklaşık 133,5K$ zarara uğratıldı. Stake sözleşmesi, tek bir işlem içinde manipüle edilebilen canlı AMM anlık fiyatlarını kullanarak yatırım değerini hesapladı. Saldırgan, TUR'un fiyatını şişirmek için flaş kredi kullandı, şişirilmiş pencere sırasında stake yaptı ve kendisi tarafından kontrol edilen yönlendirici hesaplar aracılığıyla orantısız TUR ödülleri çekti.

Arka Plan

Stake sözleşmesi (0x03D809...415Abe), yönlendirici ödüllü bir TUR staking sözleşmesidir. Kullanıcılar önce bind() aracılığıyla bir üst hattı bağlar, ardından stake() fonksiyonunu çağırır; bu fonksiyon stake edilen TUR'u yakar (0xdead adresine gönderir) ve kullanıcıya dahili power değeri atar; bu, kullanıcının daha sonra ne kadar TUR ödülü talep edebileceğini belirleyen bir ağırlıktır.

power sabit bir oranda atanmaz. Bunun yerine getPowerAmount(), yatırılan TUR'u USDT cinsinden bir değere dönüştürmek için iki canlı AMM fiyatını zincirleme kullanır: Her ikisi de mevcut çift rezervlerinden okunan TUR/NOBEL ve NOBEL/USDT. Sözleşme aynı zamanda _distributeRefPower() aracılığıyla birinci ve ikinci kademe yönlendiricilere bonus güç verir.

Güvenlik Açığı Analizi

Temel neden, Stake sözleşmesindeki güvensiz anlık fiyat bağımlılığıydı. Her yatırımda stake(), uValue = getPowerAmount(amount) değerini hesaplar, bunu _power = _uValue * 100 değerine dönüştürür, stake sahibinin muhasebesini günceller ve ardından üst yönlendiricilere ekstra güç yaymak için _distributeRefPower() fonksiyonunu çağırır.

Özellikle uValue şu şekilde hesaplanmaktadır:

$uValue=getPowerAmount(amount)uValue\; =\; getPowerAmount(amount)$

burada getPowerAmount() şuna karşılık gelir:

$amount\times \text{TUR/NOBEL anlık fiyatı}\times \text{NOBEL/USDT anlık fiyatı}amount\; \backslash times\; \backslash text\{TUR/NOBEL\; anlık\; fiyatı\}\; \backslash times\; \backslash text\{NOBEL/USDT\; anlık\; fiyatı\}$

Uygulama, bu fiyatları getReserves() aracılığıyla doğrudan mevcut çift rezervlerinden okuduğundan staking değerlemesi, manipülasyona dirençli bir oracle veya TWAP yerine tamamen aynı işlemdeki anlık fiyatlara dayanmaktadır.

Bu durum, saldırganın TUR'un zincir üzerindeki değerlemesini geçici olarak şişirmesine, manipüle edilen pencerede stake yapmasına ve abartılı uValue ile power almasına olanak tanır. Yönlendirici mantığı hasarı artırır: _distributeRefPower(), stake sahibinin gücünün %20'sini birinci yönlendiriciye ve %5'ini ikinci yönlendiriciye verir; ancak bu ekstra tahsisler, söz konusu yönlendiriciler için karşılık gelen bir rewardDebt güncellemesiyle eşleştirilmez. Sonuç olarak saldırganın kontrol ettiği yönlendirici hesaplar, Stake sözleşmesinden orantısız TUR ödüllerini anında talep edebilmektedir.

Saldırı Analizi

Aşağıdaki analiz, 0x96c9ce3c...81e348 işlemine dayanmaktadır.

• Adım 1: Saldırgan, flaş kredi sermayesi olarak ListaDAO'nun Moolah sözleşmesinden 1.900.000e18 USDT ödünç aldı.

• Adım 2: Saldırgan, ödünç aldığı sermayeyi NOBEL-USDT ve TUR-NOBEL havuzlarını manipüle etmek için kullandı ve TUR'un anlık değerlemesini geçici olarak keskin biçimde yukarı itti.

• Adım 3: Manipüle edilen pencerede saldırgan, Stake sözleşmesine 7.770.707e18 TUR stake etti. İşlem, 8.283.864e18 gibi devasa şişirilmiş bir uValue ve buna karşılık gelen 828.386.488e18 power değerini gösteren bir StakeEvent yayımladı.

• Adım 4: Saldırgan, kendisi tarafından kontrol edilen yönlendirici hesapları önceden düzenlediğinden _distributeRefPower(), bu hesaplara manipüle edilmiş stakeden türetilen ekstra ödül gücü verdi. Birinci ve ikinci yönlendiriciler beklenen %20 ve %5 yönlendirici tahsislerini aldı.

• Adım 5: Güçlendirilen yönlendirici hesaplar ardından Stake sözleşmesinden TUR ödülleri talep etti. Aynı işlemde Stake, 0xFd11...AcEaB adresine 15.238.941e18 TUR ve 0x9007...E550B adresine 3.809.924e18 TUR transfer etti; her iki adres de aynı miktarları hemen saldırgana iletti. 4:1 ödeme oranı, sözleşmenin %20'ye karşı %5 yönlendirici güç dağılımıyla örtüşmektedir.

• Adım 6: İşlem aynı zamanda Stake'ten 0xb302...89923 fon cüzdanına akan talep ücretlerini de göstermektedir; bu durum, claim() uygulamasının ödülleri talep edenlere göndermeden önce %3 TUR ücreti tahsil etmesiyle tutarlıdır.

• Adım 7: Artırılmış TUR ödüllerini çıkardıktan sonra saldırgan, gelirlerini USDT'ye takas etti, 1.900.000 USDT'lik flaş krediyi geri ödedi ve kâr olarak 0xEf67...4e5898 adresine 133.490e18 USDT transfer etti.

Sonuç

Bu olay, TUR tokenının ayrı LP temettü muhasebesinden değil, Stake sözleşmesindeki manipüle edilebilir ödül değerleme modelinden kaynaklandı. Staking gücünü ve yönlendirici ödülleri canlı AMM rezerv oranlarına bağlayan sözleşme, flaş kredi destekli bir saldırganın TUR'un anlık fiyatını şişirmesine, aşırı ödül gücü üretmesine ve kendisi tarafından kontrol edilen yönlendirici hesaplar aracılığıyla staking sözleşmesinden TUR boşaltmasına olanak tanıdı. Daha güvenli bir tasarım, anlık rezerv fiyatlandırmasını manipülasyona dirençli bir oracle veya yeterince uzun TWAP ile değiştirmeli ve herhangi bir yönlendirici güç artışının tutarlı ödül borcu muhasebesini beraberinde getirmesini sağlamalıdır.

8. EST Token Olayı

Kısa Özet

27 Mart 2026'da, BNB Chain üzerindeki BNBDeposit sözleşmesi iki sorun nedeniyle yaklaşık 92,3K$ zarara uğratıldı: BNBDeposit'teki anlık fiyat bağımlılığı ve EST tokenındaki hatalı yakma mekanizması. Fiyat bağımlılığı saldırganın büyük miktarda EST edinmesine olanak tanırken hatalı yakma mekanizması, saldırganın sandviç tarzı bir manipülasyon aracılığıyla EST-WBNB havuzunu boşaltmasına izin verdi.

Güvenlik Açığı Analizi

Olayın temel nedeni iki yönlüdür:

1. BNBDeposit sözleşmesindeki (0xE71547...d29A61) onTokenReceived() fonksiyonu, kullanıcıların talep edebileceği miktarı sözleşmenin bakiyesine ve EST'nin anlık fiyatına dayanarak hesapladı; her ikisi de kolayca manipüle edilebilir.

   

2. EST tokeni (0xD4524B...498a91), bir saldırganın EST'yi doğrudan havuza transfer ederek EST-WBNB havuzundaki EST'yi yakmasına olanak tanıyan hatalı bir yakma mekanizması uyguladı.

   

Sonuç olarak saldırgan, her iki güvenlik açığından yararlanarak bir sandviç saldırısı gerçekleştirdi ve EST-WBNB havuzundan WBNB sifon etti.

Saldırı Analizi

Aşağıdaki analiz, 0x2f1c33ea...bd1626 işlemine dayanmaktadır.

• Adım 1: Saldırgan, Moolah aracılığıyla 250.000e18 WBNB ödünç aldı ve saldırı için 15e18 WBNB'yi BNB'ye dönüştürdü.

• Adım 2: Saldırgan, BNBDeposit'e 34 kez 0,3e18 BNB transfer etti (toplam 10,2e18 BNB). Her doğrudan transfer, yatırım mantığını tetikledi. Bu adımda saldırgan, yaklaşık 9.100e18 LP tokeni (sanal muhasebede) ve bonus olarak 2,65e18 WBNB aldı.

• Adım 3: Saldırgan, 400e18 WBNB'yi yaklaşık 822Me18 EST ile takas etti ve alıcı olarak BNBDeposit'i belirledi; böylece hem BNBDeposit'in EST bakiyesini hem de havuzdaki EST fiyatını şişirdi.

• Adım 4: Saldırgan, talep mekanizmasını tetiklemek için BNBDeposit'e 1e18 EST transfer etti; şişirilmiş fiyat ve bakiyeye dayanarak 20Me18 EST aldı.

• Adım 5: Saldırgan, 245.000e18 WBNB'yi yaklaşık 330Me18 EST ile takas etti ve alıcı olarak BNBDeposit'i belirledi.

• Adım 6: Saldırgan, EST-WBNB havuzundaki EST'yi sürekli yakmak için yaklaşık 150 kez transfer-skim işlemi gerçekleştirdi.

• Adım 7: Saldırgan, kalan EST'yi 245.560e18 WBNB ile takas etti.

• Adım 8: Saldırgan flaş krediyi geri ödedi ve 150 WBNB kâr elde etti.

Sonuç

Bu olay iki sorundan kaynaklandı: anlık fiyat bağımlılığı ve hatalı yakma mekanizması. Benzer riskleri azaltmak için projeler, dağıtımdan önce güvenilir fiyat oracle'larını ve sağlam token yakma mantığını güvence altına almalıdır.

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 gerçekleştirmesine (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engellemesine, olayları analiz etmesine, yasadışı fonları takip etmesine ve AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürün ve hizmetler geliştiriyoruz.

BlockSec, saygın konferanslarda birden fazla blok zinciri güvenlik makalesi yayımlamış, DeFi uygulamalarının birkaç sıfır gün saldırısını raporlamış, 20 milyon doların üzerinde fonu kurtarmak için birden fazla saldırıyı 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 UYGULAMASI: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk