Haftalık Web3 Güvenlik Olayları Özeti | 16 Mart – 22 Mart 2026

Geçtiğimiz hafta (2026/03/16 - 2026/03/22) boyunca BlockSec, toplam tahmini ~82,7M$ kayıpla sonuçlanan yedi saldırı olayını tespit etti ve analiz etti. Aşağıdaki tablo bu olayları özetlemekte olup her bir olay için ayrıntılı analizler takip eden alt bölümlerde sunulmaktadır.

*Venus olayı geçen haftanın raporunda yer almamıştı; eksiksizlik amacıyla buraya dahil edilmiştir.

1. Venus Olayı

Kısa Özet

15 Mart 2026'da, Venus Protocol'ün BNB Chain üzerindeki THE (Thena) piyasası, bağış saldırısı ve piyasa manipülasyonunun bir arada kullanılması sonucunda yaklaşık ~2,15M$ tutarında kötü borçla karşı karşıya kaldı. THE piyasasının arz tavanı yalnızca mint yoluna uygulanırken, doğrudan piyasaya yapılan token bağışları cash değerini artırmaya ve exchangeRate'i şişirmeye devam etti. Saldırgan daha sonra bu şişirilmiş teminat değerinden yararlanarak likit varlıklar ödünç aldı, daha fazla THE edindi ve THE tokeninin piyasa fiyatını yükseltti; nihayetinde pozisyonun zorla tasfiyesinin ardından protokol kötü borçla baş başa kaldı.

Arka Plan

Venus, bir Compound V2 çatalı borç verme protokolüdür. THE piyasasında kullanıcılar THE yatırarak vTHE tokeni alır. exchangeRate, piyasanın dayanak varlıklarından her bir vTHE'nin ne kadarını temsil ettiğini belirler ve temel formülü şöyledir:

exchangeRate = (cash + borrows - reserves) / totalSupply

Burada cash piyasanın dayanak token bakiyesi, borrows toplam ödenmemiş borç, reserves protokole ait rezervler ve totalSupply ise toplam vTHE arzıdır. THE piyasasında ayrıca toplam teminat riskini sınırlamaya yönelik bir arz tavanı bulunmaktadır.

Güvenlik Açığı Analizi

Bu olay, vTHE piyasa sözleşmesine (0x86e0...739f) karşı iki birleşik saldırı vektörünü içermiştir.

Bağış Saldırısı

Protokol, cash değerini doğrudan piyasa sözleşmesinin ham token bakiyesinden türetmekte olup bu durum onu bağış saldırılarına karşı doğası gereği savunmasız kılmaktadır. vTHE piyasa sözleşmesine yapılan herhangi bir doğrudan THE transferi cash değerini ve dolayısıyla exchangeRate'i artırır. Saldırgan, exchangeRate'i yaklaşık 3,81× şişirmek ve mevcut vTHE pozisyonunun teminat değerini yükseltmek için bu açıktan yararlandı.

Piyasa Manipülasyonu

THE tokeninin zincir üzerinde sığ likiditesi bulunmaktaydı; bu da spot fiyatını görece mütevazı alım baskısıyla manipülasyona açık hâle getiriyordu. Protokolün Oracle'ı, bir referans değerden çok sapan fiyatları reddetmek üzere tasarlanmıştı; bu sayede saldırı sırasında yaklaşık 37 dakika boyunca aşırı fiyatlar doğru biçimde reddedildi. Ancak süregelen alım baskısı nihayetinde THE tokeninin fiyatını saldırı öncesi fiyatının yaklaşık iki katı olan ~0,51$'a taşıdı ve oracle bu fiyatı sonunda kabul etti.

Bu iki vektör birbirini güçlendirdi. Bağış saldırısından kaynaklanan şişirilmiş exchangeRate, her bir vTHE biriminin teminat değerini büyütürken manipüle edilmiş THE token fiyatı borçlanma kapasitesini daha da artırdı. Bu ikisi bir arada, saldırganın arz tavanının 3,67×'i olan bir pozisyona karşılık ~14,9M$ tutarında borç biriktirmesine olanak tanıdı.

Saldırı Analizi

Aşağıdaki analiz, örnek saldırı işlemi olan 0xce6e3e...1f5fb0e'ye dayanmaktadır.

• Adım 1: Saldırganla bağlantılı bir cüzdan, yaklaşık dokuz ay boyunca 77 adet TornadoCash ile ilişkili işlem aracılığıyla 7.447 ETH aldı. Bu ETH, Aave'ye yatırıldı ve yaklaşık 14,5M THE arz tavanının ~%84'ü olan yaklaşık 12,2M THE'lik vTHE pozisyonu oluşturmak için ~9,92M$ tutarında stablecoin ödünç alındı.

• Adım 2: İlk saldırı işleminde, altı adres yaklaşık 36M THE'yi doğrudan vTHE piyasa sözleşmesine aktardı. Saldırı sözleşmesi ayrıca 1,58M USDC ödünç aldı, yeniden sağladı ve ardından yaklaşık 4,6M THE ödünç alarak doğrudan vTHE'ye aktardı. Bu işlem exchangeRate'i yaklaşık 3,81 kat artırdı.

• Adım 3: Sonraki işlemlerde saldırgan, CAKE, BNB, BTCB ve USDC dahil olmak üzere likit varlıklar ödünç aldı. Saldırgan, ödünç aldığı varlıklarla THE almayı ve daha fazla THE'yi vTHE'ye bağışlamayı sürdürerek hem pozisyon borçlanma gücünü hem de THE tokeninin piyasa fiyatını artıran bir döngü oluşturdu.

• Adım 4: THE tokeninin fiyatı yaklaşık 0,2${}^{\mathrm{\prime }}dany\ddot{u}kseldi;Binancefiyatkayna\breve{g}\mathrm{ı}k\mathrm{ı}sas\ddot{u}reli\breve{g}ine4\text{'}dan\; yükseldi;\; Binance\; fiyat\; kaynağı\; kısa\; süreliğine\; 4$'a yaklaştı. Protokolün oracle'ı yaklaşık 37 dakika boyunca aşırı fiyatları reddetti ve nihayetinde yaklaşık 0,51$ fiyatı kabul etti.

• Adım 5: UTC+8 20:42 itibarıyla saldırganın pozisyonu, arz tavanının yaklaşık 3,67×'i olan yaklaşık 53,2M THE'ye ulaştı; toplam borç riski ise yaklaşık ~14,9M$ oldu.

• Adım 6: Pozisyon ardından büyük tasfiyeye girdi. 254 tasfiye adrесinden gelen 8.048 tasfiye işlemi aracılığıyla yaklaşık 42M THE teminat tasfiye edildi. Satışların sürmesiyle THE tokeni yaklaşık 0,22${}^{\mathrm{\prime }}ageriledi\mathrm{.}Tasfiyegelirleriborcuntamam\mathrm{ı}n\mathrm{ı}kar\stackrel{\backslash c}{s}\mathrm{ı}layamad\mathrm{ı}veVenu{s}^{\mathrm{\prime }}ta2,15M\text{'}a\; geriledi.\; Tasfiye\; gelirleri\; borcun\; tamamını\; karşılayamadı\; ve\; Venus\text{'}ta\; ~2,15M$ net kötü borç kaldı.

Sonuç

Bu olayda yeni bir güvenlik açığı tespit edilmedi. İyi bilinen bir saldırı vektörünün metodolojik biçimde uygulandığında, her katmanın diğerlerinin tutacağını varsaydığı durumlarda protokolün tüm risk yığınını nasıl alt üst edebildiğini ortaya koydu. Zincir üzerindeki uyarı sinyalleri aylardır görünür hâldeydi; ancak tespit ile müdahale arasındaki boşluk giderilmedi. Bu boşluğu likidite duyarlı risk parametreleri, otomatik devre kesiciler ve pozisyon düzeyinde izleme aracılığıyla kapatmak, bu olayın diğer borç verme protokollerine bıraktığı temel derstir.

Ayrıntılı analiz için derinlemesine inceleme yazımıza [1] bakınız.

Kaynaklar

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. dTRINITY Olayı

Kısa Özet

17 Mart 2026'da Ethereum üzerindeki Aave V3 çatalı borç verme protokolü dTRINITY, dLEND borç verme piyasası aracılığıyla istismar edilerek yaklaşık 257,3K$ kayba uğradı. Temel neden, Aave V3 çatallarına özgü boş piyasa güvenlik açığıydı. Bir rezervde neredeyse sıfır likidite bulunduğunda, tekrarlanan flaş kredi prim tahakkuku liquidityIndex'i aşırı bir değere taşır. Rezerv muhasebesi bozulduktan sonra saldırgan, teminatı olduğundan fazla göstermek, dUSD ödünç almak ve yatırılan cbBTC'yi net kâr elde ederek geri almak için hassasiyet kaybından yararlandı.

Arka Plan

dTRINITY, dUSD stablecoin sistemini ve Aave V3'ten çatallanmış bir borç verme piyasası olan dLEND'i bünyesinde barındırmaktadır. Çekirdek L2Pool sözleşmesinde (0xfda3...e19e84) her varlığın kendi rezervi bulunur ve rezerv muhasebesi, ölçeklendirilmiş bakiyeler ile rezerv düzeyindeki liquidityIndex'e dayanır. Kullanıcının güncel dayanak bakiyesi, ölçeklendirilmiş bakiyenin rezervin normalleştirilmiş geliriyle çarpılmasıyla elde edilir.

Flaş kredi primleri, cumulateToLiquidityIndex() aracılığıyla rezerv muhasebesine eklenir; burada:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

totalLiquidity son derece küçük hâle geldiğinde, her bir prim tahakkuku liquidityIndex'i anormal biçimde hızlı şekilde yukarı itebilir.

Güvenlik Açığı Analizi

Saldırının temel koşulu, dLEND-cbBTC piyasasındaki (0x504d...3acc) neredeyse boş rezervdi. Rezerv tek bir ölçeklendirilmiş paya sıkıştırıldıktan sonra, flaş kredi primleri anlamlı bir arz tabanına yayılamaz hâle geldi. Tekrarlanan flaş krediler bu nedenle liquidityIndex'in son derece hızlı yükselmesine yol açtı.

liquidityIndex şişirildikten sonra, dayanak değerden ölçeklendirilmiş dönüşüm aşırı yuvarlama rejimine girdi. Bu durumda, küçük bir yatırım bir ek pay basabilirken çok daha büyük bir çekim yalnızca bir pay yakabiliyordu. Bu asimetri, saldırganın aCbBTC teminatını olduğundan fazla göstermesine ve farklı bir rezervden gerçek dUSD ödünç almasına olanak tanıdı; zira sağlık kontrolleri Pool düzeyinde gerçekleştirildi ve bozulan cbBTC rezervi çapraz varlık borçlanma gücünü doğrudan etkiledi.

Saldırı Analizi

İstismar iki işlemden oluştu: 0x8d33d6...40ae7139 ve 0xbec4c8...4fc33260.

İşlem 1: liquidityIndex manipülasyonu

• Adım 1: Morpho Blue'dan cbBTC ödünç al.

• Adım 2: 100 ölçeklendirilmiş pay basmak için cbBTC'yi dLEND-cbBTC'ye yatır.

• Adım 3: 99 pay birimi çekerek yalnızca 1 pay kalsın; dLEND-cbBTC rezervini neredeyse boş bir ölçeklendirilmiş arz durumuna sıkıştır.

• Adım 4: dLEND-cbBTC aToken'ına 80.000.000 birim cbBTC (yani 0,8 cbBTC) doğrudan transfer et.

• Adım 5: Primi rezerv muhasebesine biriktirmek ve liquidityIndex'i 6.226.621.999.999.999.999.999.999.979.728.276 değerine yükseltmek için 150 adet Pool.flashLoan() çağrısı gerçekleştir.

• Adım 6: Artık rezerv nakit değerini çıkarmak için tekrarlanan yatırma ve çekme döngüleri çalıştır.

• Adım 7: Flaş krediyi geri öde.

İşlem 2: kâr gerçekleştirme

• Adım 1: Morpho Blue'dan tekrar cbBTC ödünç al.

• Adım 2: Halihazırda manipüle edilmiş rezerve ~7,72 cbBTC yatırarak şişirilmiş bir aCbBTC teminat pozisyonu oluştur.

• Adım 3: Şişirilmiş teminatı kullanarak dLEND-dUSD piyasasından 257.328 dUSD ödünç al.

• Adım 4: Tekrarlanan yatırma/çekme döngüleriyle cbBTC çıkarmaya devam et.

• Adım 5: Morpho flaş kredisini geri öde ve ödünç alınan dUSD'yi saldırgan EOA'sına transfer et.

Sonuç

Bu olay, Aave V3 çatallarında iyi belgelenmiş olan boş piyasa saldırısının bir örneğidir. Bu model birçok protokolde görülmüştür ve çözümü iyi bilinmektedir. Rezerv başlatma sırasında minimum arz eşiği zorunlu kılınması, rezervin indeks büyümesinin kontrolden çıktığı bir duruma girmesini önler. Aave V3'ü çatallayan protokoller bu nedenle rezerv başlatmayı kritik bir operasyon olarak ele almalı ve indeksi istikrara kavuşturmak için organik yatırım akışına güvenmek yerine dağıtım sırasında anlamlı likiditenin kilitlenmesini sağlamalıdır.

3. Fun.xyz Olayı

Kısa Özet

17 Mart 2026'da Polygon üzerindeki ödeme altyapısı protokolü Fun.xyz, yaklaşık 85,7K$ tutarında bir istismarla karşı karşıya kaldı. Temel neden, eski CheckoutPool'un bridge() fonksiyonunu erişim kontrolü olmaksızın ve köprü çağrı verisini amaçlanan alıcıyla bağlamadan açık bırakmasıydı. Bu güvenlik açığı, saldırganın yürütmeyi güvenilir tasfiye yoluna yönlendirmesine ve fonları saldırgan kontrolündeki bir akıllı hesaba aktarmasına olanak tanıdı.

Arka Plan

CheckoutPool, Fun.xyz'nin ödeme altyapısındaki çekirdek tasfiye sözleşmesidir. Normal akışta kullanıcı deposit() aracılığıyla bir ödeme oluşturur; güvenilir bir operatör ise bunu bridge() ve execute() gibi tasfiye yollarından geçirir. Köprü işlemlerinde bridge(), çağrıcı tarafından sağlanan bridgeParams.target ve bridgeParams.callData'ya dayalı olarak harici bir çağrı gerçekleştirir.

Güvenlik Açığı Analizi

Temel neden, eski CheckoutPool'un (0x1304...2ec01a) hassas tasfiye yönlendirme yolunu bridge() fonksiyonu aracılığıyla uygun erişim kontrolü olmaksızın açıkta bırakması ve harici olarak sağlanan köprü çağrı verisini amaçlanan alıcıya karşı doğrulamamasıdır. Özellikle:

• Eski uygulama bridge() üzerinde onlyOperator denetimini zorunlu kılmadı; bu nedenle herhangi bir harici çağrıcı deposit() aracılığıyla bir ödeme oluşturduktan sonra fonksiyonu çağırabildi.

• bridge(), çağrıcı tarafından sağlanan bridgeParams'ı alıcıyı ödeme kaydına karşı doğrulamadan harici çağrı gerçekleştiren _bridgeToRecipient()'a iletti.

Ek bir operasyonel koşul istismarı pratik hâle getirdi: eski CheckoutPool, istismar sırasında CheckoutPaymaster'da hâlâ operatör ayrıcalıklarını elinde bulunduruyordu. Bu durum, hazırlanan bridge() çağrısının CheckoutPaymaster.activateAndCall()'a ulaşmasına olanak tanıdı; bu da daha yeni CheckoutPool.execute() yolunu çağırarak fonları saldırgan kontrolündeki bir adrese aktardı.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemi 0x957bcf...1f4f5a'ya dayanmaktadır.

• Adım 1: ERC-4337 akıllı hesabı 0xb648'i oluştur ve harici UserOperation'da hem gönderen hem de ödeme yapan olarak belirle.

• Adım 2: Hem eski hem de yeni CheckoutPool'da deposit() çağrısı yaparak yeni CheckoutPool'da 85.730 USDC tasfiye tutarıyla bir ödeme kaydı oluştur.

• Adım 3: Eski CheckoutPool'da kötü niyetli bridgeParams ile bridge() çağrısı yap: bridgeParams.target'ı CheckoutPaymaster olarak ayarla ve bridgeParams.callData'yı, harici UserOperation'ı dahili yük olarak taşıyan activateAndCall() çağrısı olarak kodla.

• Adım 4: Yeni CheckoutPool'daki (0x1929...0215) execute() fonksiyonuna ulaş; bu fonksiyon 85.730 USDC'yi harici UserOperation'ın ops[0].sender'ında belirtilen adres olan 0xb648'e transfer eder.

• Adım 5: EntryPoint.handleOps()'a gir: 0xb648 hem gönderen hem de ödeme yapan olarak görev yaptığından, hem hesap doğrulaması hem de ödeme yapan doğrulaması saldırgan kontrolünde kalmakta; bu da saldırganın 85.730 USDC kâr elde etmesine olanak tanımaktadır.

Sonuç

Bu olay, eski CheckoutPool'un bridge() yolunda hem erişim kontrolü hem de çağrı verisi-alıcı bağlamasının eksikliğinden kaynaklanmış ve ~85,7K$ kayba yol açmıştır. Benzer olayları önlemek için protokoller hassas yönlendirme ve tasfiye akışlarında sıkı erişim kontrolü uygulamalı, harici olarak sağlanan yüklerin protokol kaynaklı alıcılarla tutarlı kalmasını sağlamalı ve yamalanmış yerine geçenlerin devreye alınmasının ardından eski sözleşmeleri güvenilir ayrıcalık ilişkilerinden kaldırmalıdır.

4. Keom Olayı

Kısa Özet

18 Mart 2026'da Polygon zkEVM üzerindeki Compound V2 çatalı borç verme protokolü Keom, yaklaşık 35K$ tutarında bir istismarla karşı karşıya kaldı. Temel neden, redeemUnderlying() tarafından çağrılan redeemFresh() fonksiyonundaki hatalı muhasebe mantığıydı. Fonksiyon, pay azaltmayı kullanıcının gerçek bakiyesiyle sınırlandırdı; ancak dayanak çekim tutarını buna göre yeniden hesaplamadı. Bu uyumsuzluk, saldırganın paylarının izin vermesi gerekenden çok daha fazla varlık kullanmasına olanak tanıdı.

Arka Plan

Keom, Compound V2'den çatallanmış bir borç verme protokolüdür. Kullanıcılar piyasaya ETH sağlar ve karşılığında kETH alır. Kullanıcı kullandırım talebinde bulunduğunda, protokol mevcut döviz kurundan yararlanarak kETH paylarını tekrar ETH'ye dönüştürür. Protokolde iki kullandırım giriş noktası mevcuttur: pay miktarına göre kullandırım için redeem() ve istenen dayanak miktara göre kullandırım için redeemUnderlying().

Güvenlik Açığı Analizi

Hata, redeemUnderlying() tarafından çağrılan kETH piyasasının (0x4c6e...0403) redeemFresh() fonksiyonundaydı. Kullanıcı kontrolündeki redeemAmountIn, önce redeemAmount'a atanır ve ardından mevcut döviz kuru üzerinden redeemTokens'ı hesaplamak için kullanılır. redeemTokens, kullanıcının bakiyesini aşarsa fonksiyon bunu accountTokens[redeemer] ile sınırlandırır. Ancak redeemAmount, bu sınırlandırmanın ardından yeniden hesaplanmaz ve orijinal redeemAmountIn değerine eşit kalmaya devam eder. Bu durum, kullanıcının yalnızca ilgili payların küçük bir kısmını yakarak dayanak varlıkların tüm redeemAmount'unu çekmesine olanak tanır.

Aşağıdaki kod parçacığında gösterildiği üzere, redeemFresh() ayrıca redeemAllowed() aracılığıyla bir sağlık kontrolü gerçekleştirir. Compound V2 tasarımında redeemAllowed(), markets[cToken].accountMembership[redeemer]'ı kontrol eder ve likidite kontrolünü yalnızca hesap bu cToken piyasasına girdiğinde çağırır; aksi takdirde kontrol tamamen atlanır. redeemAmountIn saldırgan kontrolünde olduğundan ve keyfi büyüklükte ayarlanabildiğinden, kETH hâlâ teminat olarak sayılıyorsa likidite kontrolü başarısız olur. Bu, muhasebe hatasının tek başına, sağlık kontrolü önceden atlanmadan doğrudan istismar edilemeyeceği anlamına gelir.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemi 0x4ccde7...03d9dfd8'e dayanmaktadır.

• Adım 1: Yalnızca 0,001 ETH ile mint() çağrısı yaparak minimal kETH bakiyesi edin.

• Adım 2: Hesabın kETH piyasasındaki üyeliğini temizlemek için exitMarket() çağrısı yap; böylece redeemAllowed(), likidite kontrolünü tamamen atlar (Güvenlik Açığı Analizi bölümünde açıklandığı gibi).

• Adım 3: Piyasanın tüm ETH bakiyesini (~38,6 ETH) çekmek için redeemUnderlying() çağrısı yaparak hatalı muhasebeden yararlan ve ETH'yi piyasadan boşalt.

Sonuç

Bu olay, redeemTokens'ın kullanıcının gerçek bakiyesiyle sınırlandırılmasının ardından redeemAmount'u yeniden hesaplamayan bir muhasebe güvenlik açığından kaynaklandı ve yaklaşık 35K$ kayba yol açtı. Kullandırım mantığı, pay-dayanak değişmezini korumak için herhangi bir sınırlandırma veya düzeltmenin ardından tüm bağımlı değerleri yeniden hesaplamalıdır. Compound V2 çatalları bu yolu dikkatli biçimde gözden geçirmeli; zira benzer hatalar diğer türevlerde de mevcut olabilir.

5. ShiMama Olayı

Kısa Özet

18 Mart 2026'da BNB Chain üzerindeki deflasyonist token protokolü ShiMama, yaklaşık 35K$ tutarında bir istismarla karşı karşıya kaldı. Temel neden, executePairBurn() fonksiyonu üzerinde erişim kontrolünün bulunmamasıydı; bu durum herhangi bir kullanıcının çift rezerv çekimini ve yakımını tetiklemesine, dolayısıyla fiyat manipülasyonunu mümkün kılmasına olanak tanıdı.

Arka Plan

ShiMama Protokolü, AMM çiftinden token çekip yakmayı amaçlayan zincir üzeri bir deflasyon mekanizması içermektedir. Bu mekanizma, ShiMama Protokolü ve ShiMama Token genelinde uygulanmaktadır. ShiMama Protokolü'ndeki executePairBurn() fonksiyonu, çağrıcı tarafından sağlanan referenceIn parametresinden bir çekme miktarı hesaplar:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Ardından ShiMama Token'ın forcePullFromPair() fonksiyonunu çağırır, pair.sync() gerçekleştirir ve çekilen tokenleri yakar.

Güvenlik Açığı Analizi

Temel neden, ShiMamaProtocol sözleşmesindeki (0x5049...0b49a) executePairBurn() fonksiyonunda erişim kontrolünün bulunmamasıdır. Fonksiyon kısıtlama olmaksızın harici olarak çağrılabilir; dolayısıyla herhangi bir kullanıcı ayrıcalıklı rezerv hareketini ve çift senkronizasyonunu tetikleyebilir. referenceIn de çağrıcı tarafından kontrol edilmekte olup gerçek bir satış miktarına bağlı değildir. ShiMamaToken.forcePullFromPair() içinde protokol, herhangi bir kısıtlama olmaksızın Pancake çiftinden bakiyeleri doğrudan taşıyabilmekte; bu da keyfi rezerv çıkarımını ve anlık senkronizasyonu, dolayısıyla spot fiyat manipülasyonunu mümkün kılmaktadır.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemi 0x13959b...3c20e001'e dayanmaktadır.

• Adım 1: Moolah flaş kredisinden WBNB ödünç al.

• Adım 2: Önceki bir işlemde önceden temin edilen 30,78e18 ShiMama'yı saldırı sözleşmesine transfer et. Pancake çiftinden doğrudan ShiMama alımları devre dışı bırakıldığından, saldırgan saldırıdan önce ShiMama Protokolü'nde likidite sağlayıp çekerek ShiMama temin etti.

• Adım 3: 1.311.349.143,96 ShiMama tokenini Pancake çiftinden çekip yakmak, böylece ShiMama fiyatını etkin biçimde şişirmek için executePairBurn() çağrısı yap.

• Adım 4: Saldırgan, şişirilmiş fiyattan PancakeSwap'te 30,78e18 ShiMama'yı 52,98e18 WBNB ile takas etti.

• Adım 5: Flaş krediyi geri öde; net kâr olarak 52,98 WBNB elde et.

Sonuç

Bu olay, havuz rezervlerini değiştirmek için yetkisiz bir yol açan executePairBurn() üzerindeki erişim kontrolü eksikliğinden kaynaklandı. Rezervleri değiştiren herhangi bir fonksiyon ekonomik açıdan hassastır ve kesinlikle izne bağlı olmalıdır. Çağrıcı tarafından kontrol edilen girdiler, rezerv çıkarımı amplifikasyonunu önlemek için protokol kaynaklı değerlere bağlanmalıdır.

6. BlindBox Olayı

Kısa Özet

19 Mart 2026'da BNB Chain üzerindeki GameFi bahis protokolü BlindBox, yaklaşık 99K$ tutarında bir istismarla karşı karşıya kaldı. Temel neden, saldırganın sonucu tahmin etmesine ve %100 kazanma oranı elde etmesine olanak tanıyan zayıf rastgelelikti. Bunun yanı sıra getTwapPrice(), gerçek bir zaman ağırlıklı ortalama yerine manipüle edilebilir spot fiyatına dayanıyordu; bu da saldırganın önceden havuz fiyatını şişirerek protokolün amaçlanan sınırlarından daha büyük bahisler oynamasına imkân tanıdı.

Arka Plan

BlindBox, kullanıcıların ATM tokenlerini ölü adrese transfer ederek bahis oynamasına olanak tanıyan bir GameFi protokolüdür. Protokol, sonucu sonraki bir blok karmasının eşlik durumuna göre belirler. Bahis kazanılırsa BlindBox, ölü adres bankrolünden orijinal ATM miktarının 1,95 katını öder. Protokol, her bahsin büyüklüğünü sınırlamak için getTwapPrice() kullanır.

Güvenlik Açığı Analizi

BlindBox sözleşmesi (0x1F83...734c59) iki güvenlik açığı içermektedir:

1. Zayıf rastgelelik: Tasfiye süresi 256 bloku aştığında, blockhash(bet.blockNum + 2) sıfır döndürür. Protokol bu durumda block.prevrandao, betId ve block.timestamp'tan türetilen rastgeleliğe geri döner. Bu girdiler işlem gönderilmeden önce zincir dışında simüle edilebildiğinden, saldırgan settle() çağrısını yalnızca hesaplanan sonucun lehine olduğu durumlarda gerçekleştirebilir; böylece deterministik bir kazanım sağlar.

2. Manipüle edilebilir fiyat sınırı: Protokol, bahis büyüklüğünü kısıtlamak için getTwapPrice() kullanır. Ancak bu fonksiyon gerçek bir zaman ağırlıklı ortalama fiyat uygulamaz; bunun yerine ATM/USDT havuzundaki spot fiyatı okur. Bu durum, saldırganların bahislerini oynamadan önce havuz fiyatını manipüle ederek sınırı aşmalarına olanak tanır.

Saldırı Analizi

Aşağıdaki adımlar saldırı örüntüsünü göstermektedir. 2. ve 3. adımlar eşleştirilmiş bir dizi oluşturdu (örn. betId=5.284) ve saldırgan kâr biriktirmek için bu çifti birden fazla kez tekrarladı.

• Adım 1: ATM/USDT havuzunu manipüle ederek ATM spot fiyatını şişir; böylece getTwapPrice() bir sonraki adımda daha büyük bir bahis boyutuna izin versin.

• Adım 2: Şişirilmiş izin miktarındaki ATM tutarını ölü adrese transfer ederek büyük bahis oyna (örn. 0x4be049...3af12c).

• Adım 3: 256'dan fazla blok geçmesini bekle; böylece blockhash sıfır döndürsün ve geri dönüş yolu aktif olsun. Saldırgan ardından sonuçları zincir dışında simüle etti ve settle() çağrısını yalnızca hesaplanan sonucun lehine olduğu blokta gerçekleştirdi (örn. 0x68eedc...718ce8).

Sonuç

Bu olay, manipüle edilebilir spot fiyatının TWAP girdisi olarak kullanılmasıyla birleşen tahmin edilebilir rastgelelikten kaynaklandı ve yaklaşık 99K$ kayba yol açtı. Benzer riskleri azaltmak için protokol, blockhash penceresi dolduktan sonra tahmin edilebilir hâle gelen herhangi bir tasfiye yolunu kaldırmalı ve getTwapPrice() yerine kısa vadeli rezerv manipülasyonuna dayanıklı bir fiyatlama kaynağıyla değiştirmelidir.

7. Resolv Olayı

Kısa Özet

22 Mart 2026'da Ethereum üzerindeki stablecoin protokolü Resolv, ayrıcalıklı takas-sonuçlandırma mantığının yetkisiz biçimde yürütülmesini mümkün kılan bir altyapı anahtarı ele geçirme olayı yaşadı. Olayda saldırgan, ayrıcalıklı fonksiyonu kötüye kullanarak 80 milyonun üzerinde teminatsız USR bastı. Etkisi doğrudan basım olayının ötesine geçti; ortaya çıkan USR depeg'i, Resolv varlıklarının teminat olarak kullanıldığı borç verme protokollerinde daha geniş bir bulaşmayı tetikledi.

Arka Plan

Resolv, USR ihracının teminat destekli takas tasfiyesine bağlı olduğu bir stablecoin protokolüdür. completeSwap() -> mint() -> transfer() takas tamamlama ardışık düzeni, USR'nin dolaşımdaki arzını doğrudan etkiler ve bu nedenle hem yetkilendirme bütünlüğüne hem de teminat bütünlüğüne bağlıdır. Normal işleyişte Resolv sözleşmesindeki (0xa27a...5861) completeSwap(), yalnızca ilgili teminat yatırışı doğrulandıktan sonra ayrıcalıklı bir altyapı anahtarı (kodda SERVICE_ROLE olarak adlandırılır) tarafından çağrılabilir.

Güvenlik Açığı Analizi

Olay, güvenilir tasfiye mantığını çağıran ve eşdeğer bir teminat girişi olmaksızın USR basım yoluna ulaşan ele geçirilmiş bir ayrıcalıklı anahtara dayanıyordu. Saldırgan ayrıcalıklı imzalama yetkisinin kontrolünü ele geçirdiğinde, completeSwap() yolu zincir üzerinde basım ön koşulu zorlaması sağlamıyordu; teminat doğrulaması tamamen zincir dışı yetkilendirmeye bağımlıydı. Bu durum, bir kontrol düzlemi güvenlik açığını doğrudan bir arz bütünlüğü başarısızlığına dönüştürdü.

Saldırı Analizi

• Adım 1: İstismardan önce saldırgan, 0x590b5c...de732c89 işleminde bir takas talebi göndererek sonraki kötü niyetli takas tamamlaması için gerekli durumu hazırladı.

• Adım 2: Ele geçirilmiş ayrıcalıklı anahtarı kullanarak saldırgan, üç işlem aracılığıyla 80.000.000'den fazla USR basmak için completeSwap() çağrısı yaptı: 0xfe37f2...dc33743, 0x41b6b9...db1f18f ve 0x7f9143...53a931d.

Sonuç

Bu olay, stablecoin güvenliğinin yalnızca güvenilir operatör rollerine değil, zincir üzerinde kesin basım ön koşullarına bağlı olduğunu vurgulamaktadır. Bu olayın etkisinin 80M$'lık yetkisiz USR basımının çok ötesine geçtiğini belirtmek gerekir. Resolv varlıkları birden fazla borç verme protokolünde teminat olarak yaygın biçimde kullanıldığından, depeg daha geniş bir bulaşmayı tetikledi. Chaos Labs'ın aktardığına göre, otomatik getiri arayışı tahsisi kullanan zincir üzeri küratörler gerçek zamanlı risk kontrollerinden yoksundu ve halihazırda zarar görmüş piyasalara taze sermaye yönlendirmeye devam etti. Yerelleşmiş bir istismar olarak başlayan olay, protokoller arası bir bulaşma olayına hızla dönüştü ve borç verme protokollerini milyonlarca dolarlık kötü borçla baş başa bıraktı.

BlockSec Hakkında

BlockSec, tam kapsamlı bir blok zinciri güvenlik ve kripto uyumluluk sağlayıcısıdır. Müşterilerin kod denetimi gerçekleştirmesine (akıllı sözleşmeler, blok zincirleri ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engellemesine, olayları analiz etmesine, yasadışı fonları izlemesine ve protokollerin ile platformların tüm yaşam döngüsü boyunca AML/CFT yükümlülüklerini karşılamasına yardımcı olan ürün ve hizmetler geliştiriyoruz.

BlockSec, saygın konferanslarda birden fazla blok zinciri güvenlik makalesi yayımlamış, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırılarını bildirmiş, 20 milyonun üzerinde doları 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 Güvenlik UYGULAMASI: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk