Haftalık Web3 Güvenlik Olayları Özeti | 2 Mart – 8 Mart 2026

Geçen hafta (2026/03/02 - 2026/03/08) boyunca BlockSec, toplam tahmini kaybı yaklaşık 3,25 milyon dolar olan yedi saldırı olayını tespit etti ve analiz etti. Aşağıdaki tablo bu olayları özetlemekte olup her bir vaka için ayrıntılı analizler aşağıdaki alt bölümlerde sunulmaktadır.

*BUBU2 olayı geçen haftaki raporda atlanmıştı; eksiksizlik amacıyla buraya dahil edilmiştir.

1. BUBU2 Olayı

Kısa Özet

1 Mart 2026'da BNB Chain üzerindeki BUBU2 token'ı istismar edildi ve yaklaşık 19,7 bin dolar kayıpla sonuçlandı. Temel neden bir token tasarım hatasıydı: sözleşme, transfer sırasında AMM çiftinin rezervlerinden doğrudan token düşen, zaman-birikimli bir deflasyon mekanizması içermektedir. Sözleşme sahibi, saldırıdan önce tetik aralığını makul olmayan ölçüde küçük bir değere indirerek yüzlerce yakma turunun tek bir çağrıda birikip çalışmasına neden oldu. Saldırgan bu mekanizmayı tetiklemek için flaş kredi kullandı; böylece çiftin rezervlerini çökertip token fiyatını şişirdi ve ardından bozulmuş fiyat üzerinden tersine takas yaparak kâr elde etti.

Arka Plan

BUBU2, BNB Chain üzerinde konuşlandırılmış deflasyonist bir ERC-20 token protokolüdür. Protokol, burnAndMintSwitch tarafından kontrol edilen periyodik bir deflasyon motoru içermektedir: sahip setBurnAndMintSwitch(true) ile etkinleştirdiğinde, muaf olmayan herhangi bir transfer _update() kancasını tetikleyerek _triggerDailyBurnAndMint() fonksiyonunu çağırır. Bu fonksiyon, son tetiklemeden bu yana geçen TRIGGER_INTERVAL periyot sayısına göre işlem çiftinin BUBU2 bakiyesinden orantılı miktarda token yakar ve rezervleri buna göre günceller.

Güvenlik Açığı Analizi

Temel neden, BUBU2 token sözleşmesindeki (0x3fF3...ee52) bir tasarım hatasıdır. Sözleşme, _update() kancasına periyodik deflasyonist bir mekanizma yerleştirmiştir: tetiklendiğinde, `_triggerDailyBurnAndMint()` son çalışmadan bu yana geçen `TRIGGER_INTERVAL` periyot sayısını hesaplar ve işlem çiftinden ([0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)) orantılı miktarda `BUBU2` yakar; ardından rezervleri güncellemek için sync() çağrısı yapılır. Kritik olarak, sahip herhangi bir kilitleme süresi veya minimum sınır koruması olmaksızın TRIGGER_INTERVAL değerini yeniden yapılandırabilmektedir.

Saldırıdan önce sahip, setBurnAndMintSwitch(true) ve ardından setTriggerInterval(120) çağrısı yaparak aralığı varsayılan 6 saatten 120 saniyeye indirdi. lastTriggerTime değeri hâlâ saatler öncesine kilitli olduğundan, bir sonraki tetiklemede yüzlerce birikmiş tur hesaplandı ve yakma miktarı tur sayısıyla doğrusal olarak ölçeklendi. Bu durum, tek bir transferin çiftten büyük miktarda BUBU2'yi boşaltmasına, rezervlerin çökmesine ve token fiyatının yaklaşık 11 kat şişmesine yol açtı.

Saldırı Analizi

Aşağıdaki analiz, 0x1bc0...141c, 0x191c...1ee4, 0xd6e5...51a6 işlemlerine dayanmaktadır.

• Adım 1: Token sahibi önce setBurnAndMintSwitch(true) ile periyodik deflasyonist mekanizmayı etkinleştirdi, ardından setTriggerInterval(120) ile tetik aralığını varsayılan 6 saatten 120 saniyeye indirdi. Saldırgan daha sonra flaş kredi ile 18 WBNB ödünç alarak havuzdan yaklaşık 18.715.856 BUBU2 ile takas yaptı.

• Adım 2: Saldırgan küçük bir transfer başlatarak _triggerDailyBurnAndMint() fonksiyonunu tetikledi. Havuzun BUBU2 bakiyesi yaklaşık 1.025.988.664e18 token düştü; sync() çalıştıktan sonra rezervde yalnızca 6.493.352e18 BUBU2 kaldı ve bu durum BUBU2 fiyatını yaklaşık 200 kat şişirdi.

• Adım 3: Saldırgan, Adım 1'de edindiği BUBU2'yi şişirilmiş fiyattan havuza geri sattı ve yaklaşık 50 WBNB elde etti. Flaş kredi geri ödendikten sonra net kâr yaklaşık 32 WBNB oldu.

Sonuç

BUBU2 istismarı, token sözleşmesindeki kritik bir tasarım hatasından kaynaklanmıştır. Sahip, makul olmayan ölçüde küçük bir TRIGGER_INTERVAL yapılandırdı; bu da geçen sürenin yüzlerce tura birikmesine ve tek bir çağrıda işlem çiftinin rezervlerinin tükenmesine olanak tanıdı, BUBU2 fiyatında ani bir yükselişe neden oldu.

Gelecekte benzer riskleri azaltmak için:

• TRIGGER_INTERVAL gibi kritik parametreleri sınırlar veya kilitleme süreleriyle koruyun.

• Birikmiş çalıştırma turlarını sınırlayın veya üst sınır koyun.

2. ACPRoute Olayı

Kısa Özet

2 Mart 2026'da Base üzerindeki ACPRoute protokolü istismar edildi ve yaklaşık 58 bin dolar kayıpla sonuçlandı. Temel neden, ödeme yöneticisi sözleşmesindeki hatalı iş mantığıydı: iş durumu, depolama referansı yerine bellek kopyası olarak yüklendi; bu nedenle kümülatif ödeme takibi hiçbir zaman zincir üzerinde kalıcı hale getirilmedi. Bu durum, saldırganın bir iş oluşturmasına, aşama geçişi sırasında otomatik ödeme serbest bırakmasını tetiklemesine ve ardından izinsiz bir talep fonksiyonu aracılığıyla aynı emanet fonları ikinci kez talep etmesine olanak tanıdı.

Arka Plan

ACP (Agent Commerce Protocol), müşteri ve sağlayıcı etkileşimleri için tasarlanmış modüler bir zincir üstü ticaret protokolüdür. Etkinliği üç katmanda yapılandırır: Hesaplar, İşler ve Notlar. İşler sabit bir yaşam döngüsü izler (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED) ve ödemeler, TRANSACTION aşamasında PaymentManager sözleşmesi tarafından emanette tutulur. Bir iş COMPLETED durumuna ulaştığında, protokol releasePayment() fonksiyonu aracılığıyla emanet fonları sağlayıcıya serbest bırakır. Çift talep etmeyi önlemek için protokol, iş başına kümülatif ödemeleri Job yapısındaki amountClaimed alanını kullanarak takip eder. releasePayment() fonksiyonuna yapılan her çağrının, fonların yalnızca bir kez serbest bırakılmasını sağlamak amacıyla talep edilen miktarı amountClaimed ile karşılaştırması beklenmektedir.

Güvenlik Açığı Analizi

Temel neden, PaymentManager sözleşmesinin (0x56c3...0684) releasePayment() fonksiyonunda iş durumunun depolama referansı yerine bellek kopyası olarak yüklenmesidir. Protokol, çift talep etmeyi önlemek amacıyla kümülatif ödemeleri amountClaimed üzerinden takip etmesine karşın, job.amountClaimed += amount artışı yalnızca geçici bir yerel kopya üzerinde işlem yaparak hiçbir zaman zincir üstü depolamaya geri yazılmaz. Sonuç olarak, releasePayment() fonksiyonunun her çağrısında amountClaimed == 0 gözlemlenerek, saldırganın aşama geçişinin releasePayment() fonksiyonunu otomatik olarak tetiklemesinin ardından claimBudget() fonksiyonunu çağırarak kurban sözleşmeyi (0x307e...d6e8) ikinci kez boşaltmasına olanak tanır.

Saldırı Analizi

Aşağıdaki analiz, 0xe94a...f9a0 işlemine dayanmaktadır.

• Adım 1: Saldırgan, sonraki saldırı için sermaye olarak flaş kredi aracılığıyla 97.000e6 USDC ödünç aldı.

• Adım 2: Geri çağrı içinde saldırgan, ACPRouter üzerinde createJob() fonksiyonunu çağırırken fonları almak için yeni bir sağlayıcı sözleşmesi (0x1ee502dd...) konuşlandırdı.

• Adım 3: Saldırgan, COMPLETED aşama geçişi tetiklenene kadar tekrar tekrar createMemo() fonksiyonunu çağırdı ve sağlayıcı sözleşmenin kendi exec() fonksiyonunu çağırarak iş aşamasını ilerletti; aşama geçişi otomatik olarak releasePayment() fonksiyonunu çağırarak tam bakiyeyi sağlayıcı sözleşmeye serbest bıraktı. Bu noktada amountClaimed güncellenmesi gerekirdi, ancak depolamadaki değeri 0 olarak kaldı.

• Adım 4: Saldırgan claimBudget() fonksiyonunu çağırdı ve kâr olarak emanetteki 97.000e6 USDC'yi ikinci kez başarıyla talep etti.

Sonuç

Bu olay, emanet fonların aynı iş yaşam döngüsü içinde iki kez talep edilmesine olanak tanıyan bir durum kalıcılığı hatasından kaynaklanmıştır.

Gelecekte benzer riskleri azaltmak için:

• Kritik durum değişkenlerinin (örn. amountClaimed) depolama referansları kullanılarak güncellendiğinden emin olun.

• Hassas ödeme fonksiyonlarını kısıtlayın veya çalışmadan önce katı durum doğrulaması uygulayın.

3. sDOLA Llamalend Piyasa Olayı

Kısa Özet

2 Mart 2026'da Ethereum üzerindeki sDOLA Llamalend Piyasası istismar edildi ve yaklaşık 239 bin dolar kayıpla sonuçlandı. Temel neden fiyat manipülasyonudur. Özellikle, sDOLA fiyatı donate() aracılığıyla manipüle edilebilen bir ERC4626 tokenıdır. Llamalend, AMM tabanlı bir borç verme piyasasıdır ve LLAMMA'nın mekanizması nedeniyle teminat fiyatı yükseldiğinde bile kullanıcılar likidasyona tabi tutulabilir. Bu nedenle saldırgan, sDOLA fiyatını yukarı itmek, kullanıcıların pozisyon sağlığını sıfırın altına düşürmek ve ardından bu kullanıcıları kâr amacıyla tasfiye etmek için donate() fonksiyonunu kullanabilir.

Arka Plan

LLAMMA (Lending-Liquidating AMM Algorithm), Curve tarafından kullanılan AMM tabanlı bir borç verme piyasasıdır [1]. Geleneksel borç verme protokollerinin aksine LLAMMA, kullanıcı teminatını AMM içindeki fiyat bantlarına yerleştirir. Oracle fiyatı $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ hareket ettikçe, teminat; ani tasfiyeler tetiklemek yerine pozisyonları kademeli olarak riskten arındırarak, bantlar genelinde arbitraj güdümlü takaslar yoluyla teminat tokeni ile crvUSD arasında aşamalı biçimde dönüştürülür (yumuşak tasfiye).

Yumuşak tasfiye bir pozisyonu yeterince hızlı riskten arındıramazsa, sert tasfiye devreye girer [2]; bu, bir pozisyonun sağlığı sıfırın altına düştüğünde tetiklenir. Sağlık, get_x_down() [3] aracılığıyla hesaplanır; bu fonksiyon teminatı yalnızca piyasa değerine göre işaretlemez. Bunun yerine, kurtarılabilir değerini değerlendirmek amacıyla kullanıcının pozisyonunun gidiş-dönüş dönüşümünü simüle eder. Bu gidiş-dönüş iki farklı fiyat çıpası kullanır: biri mevcut $P{}_{oracle}P\backslash \backslash \_\{oracle\}$'dan türetilen (canlı oracle ile birlikte hareket eden) ve diğeri kullanıcının bant sınırlarından türetilen (pozisyon oluşturulduğunda sabit olan).

Güvenlik Açığı Analizi

Hatalı sözleşmeler arasında crvUSD Controller (0xad44...fb86) ve LLAMMA AMM (0x0079...a1f7) bulunmaktadır. Kurban sözleşme ise sDOLA Llamalend piyasasıdır (0x2b08...4fbe).

sDOLA, pay fiyatı toplam varlıkların toplam paylara oranıyla belirlenen bir ERC4626 vault tokenıdır. Herkes donate() çağrısı yaparak vault'a varlık ekleyebildiğinden, pay fiyatı tek bir işlem içinde şişirilebilir. Bu, LLAMMA'nın sağlık fonksiyonunun bağlı olduğu manipüle edilebilir oracle'dır.

Arka Plan bölümünde açıklandığı gibi, get_x_down() sağlığı iki fiyat çıpası üzerinden gidiş-dönüş dönüşümünü simüle ederek hesaplar: biri $P{}_{oracle}P\backslash \backslash \_\{oracle\}$'dan türetilen (dinamik, canlı oracle ile birlikte hareket eden), diğeri kullanıcının bant sınırlarından türetilen (statik, pozisyon oluşturulduğunda sabit). Protokol, $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ okurken herhangi bir gecikme veya akıl sağlığı kontrolü uygulamaz. Bu nedenle oracle fiyatı şişirildiğinde dinamik çıpa yükselirken statik çıpa aynı kalır. Pratikte simülasyon, crvUSD'yi şişirilmiş oracle fiyatından teminata dönüştürür ve orijinal bant fiyatından geri dönüştürür; böylece iki çıpa arasındaki fark büyüdükçe değerlendirilen kurtarılabilir değer küçülür. Bu durum, teminat fiyatı yükselmiş olmasına rağmen sağlığı sıfırın altına düşürür.

Saldırı Analizi

Aşağıdaki analiz, 0xb935...d8a4 işlemine dayanmaktadır.

• Adım 1: LLAMMA durumunu manipüle etmek (büyük takaslar) için active_band'i hareket ettirin ve birçok kullanıcıyı yalnızca x pozisyonuna (yalnızca crvUSD) itin.

• Adım 2: Bağışlar yoluyla sDOLA fiyatını manipüle edin, ardından manipüle edilmiş fiyatı AMM havuzuna yazmak için sıfır miktarlı takas (swap(0)) kullanın.

• Adım 3: users_to_liquidate() -> _health() -> get_x_down() üzerinden sağlık yeniden hesaplamasını tetikleyin.

• Adım 4: get_x_down() kurtarılabilir değeri iki farklılaşan fiyat çıpası üzerinden hesapladığından (dinamik çıpa artık şişirilmiş, statik çıpa değişmemiş), gidiş-dönüş dönüşümü etkin değer üzerinde bir indirim üretir ve birçok pozisyon sıfır sağlığın altına düşer.

• Adım 5: Bu kullanıcıları kâr amacıyla toplu sert tasfiye edin.

Bunlara ek olarak, izde iki create_loan() çağrısı bulunmaktadır. İlk kredi ağırlıklı olarak büyük ölçekli crvUSD takas işlemlerini finanse etmek için kullanıldı. İkinci kredi ise birinci pozisyonun borcunu geri ödemek ve sermayeyi geri dönüştürmek amacıyla crvUSD elde etmek için kullanıldı. Bu iki kredi çoğunlukla finansman/uzlaşma adımlarıdır ve saldırının temel istismar adımları değildir.

Sonuç

Olay, bir teminat fiyatı manipülasyon saldırısıdır. Saldırgan, işlem içinde sDOLA fiyatını manipüle etti ve LLAMMA'nın yol tabanlı sağlık mekanizması nedeniyle kullanıcıları tasfiye koşullarına itti. Önemli bir sonuç olarak, teminat fiyatı artsa bile pozisyonlar tasfiye edilebilir hale gelebilir. Önerilen güçlendirme yöntemleri:

• Tasfiye için gecikmeli veya TWAP teminat fiyatları kullanın.

Referanslar

• [1] Curve crvUSD LLAMMA belgeleri: [https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)

• [2] Curve LLAMMA tasfiye açıklaması: [https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)

• [3] Curve stablecoin teknik raporu: [https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. z0r0z'un V4 Router Olayı

Kısa Özet

3 Mart 2026'da Ethereum üzerindeki z0r0z'un V4 Router'ı istismar edildi ve yaklaşık 42 bin dolar kayıpla sonuçlandı. Saldırı, router'ın ödeyenin msg.sender ile eşleştiğini doğrulamak için satır içi assembly'de sabit bir calldata ofseti kullandığı swap() fonksiyonundaki hatalı yetkilendirme mantığından kaynaklanmaktadır. ABI kodlaması dinamik türler için sabit bir düzen garanti etmediğinden, saldırgan kontrolü atlayan standart dışı ancak geçerli calldata oluşturabildi, daha önce onaylanmış bir kurbanı ödeyici olarak taklit etti ve takas çıktısını saldırgan kontrollü bir adrese yönlendirdi.

Arka Plan

Protokol, Uniswap v4 Router'dan miras alır ve bazı metodlarını geçersiz kılar. Özünde bir takas router'ı olarak işlev görür; kullanıcıların ilgili havuzla doğrudan etkileşime girmek yerine router'ı birleşik bir giriş noktası olarak kullanmasına olanak tanır.

Güvenlik Açığı Analizi

Temel neden, V4 Router sözleşmesindeki (0x0000...ce97) hatalı iş mantığıdır. Kurban sözleşme 0x65a8...7675'tir. swap() fonksiyonu iki parametre kabul eder: data (bytes) ve deadline (uint256). Fonksiyon içinde, bir yetkilendirme kontrolü; data içinde kodlanmış ödeyenin msg.sender ile eşleştiğini sağlamak amacıyla calldataload(164)'ü caller() ile karşılaştırmak için satır içi assembly bloğu kullanır. Protokol, bytes ofsetinin her zaman 0x40 olduğunu varsayarak ödeyeni 164. bayt konumuna (0xa4) yerleştirir.

Ancak ABI kodlaması bu düzeni garanti etmez: dinamik parametreler başlık bölümünde yalnızca bir ofset saklar ve bu ofset calldata içindeki herhangi bir hizalanmış konuma yasal olarak işaret edebilir. Bytes ofsetini 0xc0'a taşıyan geçerli ancak standart dışı bir kodlama oluşturarak, saldırgan başlık ile gerçek kuyruk arasına keyfi dolgu ekleyebilir. Saldırgan, assembly kontrolünü geçmek için kendi adresini 164. bayt konumuna yerleştirirken, yeniden konumlandırılmış kuyruktaki gerçek bytes yükü kurbanın adresini ödeyici olarak kodlar. Router'ı daha önce onaylamış bir kurban seçerek ve alıcıyı kendi adresi olarak ayarlayarak saldırgan, takas çıktısını yönlendirip fon çalabilir.

Saldırı Analizi

Aşağıdaki analiz, 0xfe34...466a işlemine dayanmaktadır.

• Adım 1: Daha önce router'ı onaylamış bir kullanıcıyı hedef olarak seçin.

• Adım 2: Yetkilendirme kontrolünü atlamak için calldata'yı hazırlayın.

• Adım 3: Data içinde kurbanı ödeyici olarak belirtin, saldırganın kendi adresini token alıcısı olarak ayarlayın ve ardından kurbanın varlıklarını çalın.

Sonuç

Bu olay, takas yolunda yetkilendirme için sabit kodlanmış calldata ofsetine güvenmekten kaynaklanmıştır. Dinamik türler için ABI kodlaması sabit bir düzen garanti etmediğinden, saldırgan standart dışı ancak geçerli calldata ile kontrolü atladı, onaylanmış bir kurbanı ödeyici olarak taklit etti ve takas çıktısını yönlendirdi.

Gelecekte benzer riskleri azaltmak için:

• Dinamik ABI kodlamalı parametreler için asla sabit kodlanmış calldata ofsetlerine güvenmeyin.

• Yapılandırılmış girdileri manuel konum varsayımları yerine kurallı ABI kod çözme kullanarak çözümleyin ve doğrulayın.

• Gerçek ödeyicinin, alıcının ve token akışının amaçlanan çağırıcı ve yürütme bağlamına karşı tutarlı biçimde doğrulandığından emin olun.

5. BitcoinReserveOffering Sözleşme Olayı

Kısa Özet

5 Mart 2026'da Ethereum üzerindeki BitcoinReserveOffering sözleşmesi istismar edildi ve yaklaşık 2,7 milyon dolar kayıpla sonuçlandı. Temel neden hatalı iş mantığıydı: tam ERC-3525 SFT yatırma işlemi işlenirken basım mantığı tek bir çağrı içinde iki kez çalıştırıldı; bir kez transfer geri çağrısı sırasında, bir kez de ana akışta. Saldırgan, tekrarlanan yakma-ve-basma döngüleri aracılığıyla bu çift basım davranışından yararlandı, BRO token bakiyesini üstel olarak şişirdi ve ardından fazla miktarı SolvBTC için kullandı.

Arka Plan

BitcoinReserveOffering, ERC-3525 SFT pozisyonlarını aktarılabilir ERC-20 BRO tokenlarına dönüştüren bir sarmalayıcı sözleşmedir. Kullanıcılar uygun SFT'leri yatırmak için mint() fonksiyonunu çağırabilir; sözleşme yapılandırılmış bir döviz kuruna göre karşılık gelen miktarda BRO basar. Kullanıcı bir SFT'nin değerinin yalnızca bir kısmını yatırırsa, sözleşme belirtilen miktarı dahili olarak tuttuğu pozisyona aktarır ve ardından karşılık gelen BRO değerini basar. Kullanıcı tüm bir SFT'yi yatırırsa, sözleşme tam tokeni sarmalayıcı sözleşmeye aktarır ve SFT'nin toplam değerine göre BRO basar. Kullanıcılar daha sonra BRO'yu ilgili ERC-3525 SFT pozisyonuna geri almak için burn() fonksiyonunu çağırabilir; sarmalanmış ERC-20 değerini tekrar SFT pozisyonuna dönüştürür.

Güvenlik Açığı Analizi

Temel neden, BitcoinReserveOffering sözleşmesinin (0x15f7...cfcf) mint() fonksiyonunda tam ERC-3525 SFT yatırma işlemi işlenirken basım mantığını iki kez çalıştırmasıdır. Özellikle, amount_ == sftBalance dalında mint(), tüm SFT'yi güvenli biçimde sözleşmeye aktarmak için ERC3525TransferHelper.doSafeTransferIn() fonksiyonunu çağırır; bu işlem onERC721Received() geri çağrısını tetikler. Bu geri çağrı içinde sözleşme SFT'nin değerini zaten hesaplar ve gönderene BRO basar. Geri çağrı döndükten sonra mint() çalışmaya devam eder, aynı amount_ kullanarak değeri yeniden hesaplar ve ikinci bir _mint(msg.sender, value) işlemi gerçekleştirir. Bu çift basım davranışı, saldırganın yakma-ve-basma döngüsü aracılığıyla BRO bakiyesini tekrar tekrar şişirmesine olanak tanır.

Saldırı Analizi

Aşağıdaki analiz, 0x44e6...958d işlemine dayanmaktadır.

• Adım 1: Saldırgan, başlangıç sermayesi olarak saldırı sözleşmesine 135e18 BRO tokeni aktarır.

• Adım 2: Saldırgan aşağıdaki döngüyü çalıştırır:

1. 135e18 BRO tokenini bir SFT tokenine dönüştürün.

2. Tam SFT değeriyle mint() çağrısı yapın; bu, onERC721Received() geri çağrısını tetikler ve 135e18 BRO tokeni basar; dıştaki mint() ardından çalışmaya devam ederek tekrar _mint() çağırır ve toplamda 270e18 BRO tokeni çift basım ile sonuçlanır.

3. 270e18 BRO tokenini tekrar bir SFT tokenine dönüştürün.

• Adım 3: Adım 2'yi 22 kez tekrarladıktan sonra saldırgan yaklaşık 567.758.816e18 BRO tokeni biriktirir; bunlar sonunda kâr olarak 38e18 SolvBTC ile kullanılır.

Sonuç

Bu olay, tam SFT yatırma işlemleri sırasında çift basım nedeniyle kaynaklanmış; saldırgan tekrarlanan yakma-basma döngüleriyle BRO bakiyesini üstel olarak şişirip fazla miktarı SolvBTC için kullanmıştır.

Gelecekte benzer riskleri azaltmak için:

• Varlık muhasebesi işleminin her yatırma operasyonu için yalnızca bir kez gerçekleştiğinden emin olun.

• Basım miktarlarının temel yatırılan değeri aşmasını önlemek için değişmez kontroller ekleyin.

6. MoltEVM Olayı

Kısa Özet

7 Mart 2026'da Base üzerindeki MoltEVM protokolü istismar edildi ve yaklaşık 127 bin dolar kayıpla sonuçlandı. Temel neden, token sözleşmesindeki hatalı erişim kontrolü mantığıydı: ayrıcalıklı basım fonksiyonu, yalnızca çağıranın belirli bir arayüze sahip bir sözleşme olup olmadığını kontrol eden ve kolayca taklit edilebilen bir değiştirici tarafından korunuyordu. Saldırgan, kontrolü atlatmak için kötü amaçlı bir sözleşme konuşlandırdı, büyük miktarda token bast ve bunları kâr amacıyla likidite havuzu üzerinden sattı.

Arka Plan

MoltEVM, kendi kendini kopyalayan bir token modeli araştıran Base üzerinde konuşlandırılmış deneysel bir ERC-20 token protokolüdür. Sistem, belirli rezerv eşiklerine ulaşıldığında bir tokenın yeni alt tokenlar ("Moltling" tokenleri) oluşturmasına olanak tanır. Yeni bir Moltling oluşturulduğunda, mintFromSpawner() fonksiyonu aracılığıyla başlangıç token arzı dağıtılır ve yeni token için bir işlem piyasası oluşturmak amacıyla otomatik olarak likidite sağlanır. Bu tasarım, protokolün token soyunu özerk biçimde genişletmesini sağlar; her nesil token, daha fazla torun oluşturabilir.

Güvenlik Açığı Analizi

Güvenlik açığı, MoltEVM sözleşmesindeki (0x225d...501f) mintFromSpawner() ve setExemptFromSpawner() fonksiyonlarının erişim kontrolü mantığında yatmaktadır. Her iki fonksiyon da protokol tarafından oluşturulan meşru Moltling sözleşmelerine çağrıları kısıtlamak amacıyla tasarlanan onlySpawnerToken değiştiricisini kullanır.

Ancak değiştirici yalnızca iki zayıf kontrol gerçekleştirir: msg.sender'ın bir sözleşme olduğunu ve çağıran üzerinde initialized() çağrısının true döndürdüğünü doğrular. Bu koşullar aynı arayüzü uygulayan herhangi bir keyfi sözleşme tarafından kolayca sağlanabildiğinden, kontrol meşru spawn token'larının gerçek kimlik doğrulamasını sağlamamaktadır.

Sonuç olarak, saldırgan yalnızca true döndüren bir initialized() fonksiyonu uygulayan minimal bir sözleşme konuşlandırabilir. Konuşlandırıldıktan sonra kötü amaçlı sözleşme, keyfi miktarda token basmak için mintFromSpawner() fonksiyonunu serbestçe çağırabilir ve saldırgan kontrollü adresleri beyaz listeye almak için setExemptFromSpawner() fonksiyonunu da çağırabilir. Bu durum, saldırgana basım yolu üzerinde tam kontrol verir ve yeni basılan tokenlerin kâr amacıyla likidite havuzlarına satılmasına olanak tanır.

Saldırı Analizi

Aşağıdaki analiz, 0x10b7...e03d işlemine dayanmaktadır.

• Adım 1: Saldırgan, onlySpawnerToken değiştirici kontrolünü geçmeye yetecek şekilde true döndürmek üzere sabit kodlanmış tek bir initialized() fonksiyonu uygulayan minimal bir sözleşme konuşlandırdı.

• Adım 2: Saldırganın sözleşmesi, saldırganın adresini vergi muafiyet beyaz listesine eklemek için aynı zayıf onlySpawnerToken değiştiricisiyle korunan setExemptFromSpawner() fonksiyonunu çağırdı. Bu, sonraki büyük ölçekli token satışlarının satış vergisini veya dahili takas mantığını tetiklemeyeceğini, böylece kârın en üst düzeye çıkarılacağını sağladı.

• Adım 3: Saldırgan, önce mEVM'e karşı setExemptFromSpawner() + mintFromSpawner() fonksiyon dizisini tekrarladı, ardından CSPAWN, CCUTTL, LWORM ve NHYDRA dahil birden fazla Moltling alt tokenına karşı toplu token bast ve bunları kâr elde etmek için ilgili likidite havuzlarına sattı.

Sonuç

Bu olay, ayrıcalıklı basım ve yapılandırma fonksiyonlarındaki yetersiz erişim kontrolünden kaynaklanmış; saldırganın meşru bir spawn'ı taklit edip kâr amacıyla keyfi tokenlar basmasına olanak tanımıştır.

Gelecekte benzer riskleri azaltmak için:

• Ayrıcalıklı basım veya yapılandırma fonksiyonları için katı erişim kontrolü uygulayın.

• Yetkilendirme için kolayca taklit edilebilen sözleşme kontrollerine güvenmekten kaçının.

• Çağıran kimliğini açık beyaz listeler veya güvenilir sözleşme kayıtları aracılığıyla doğrulayın.

7. LEDS Olayı

Kısa Özet

8 Mart 2026'da BNB Chain üzerindeki LEDS tokeni istismar edildi ve yaklaşık 64 bin dolar kayıpla sonuçlandı. Temel neden hatalı iş mantığıydı: token sözleşmesi, her biri likidite çiftinden doğrudan token yakabilen ve hiçbiri erişim kontrolü veya bekleme süresiyle korunmayan birden fazla bağımsız deflasyonist mekanizma sunmaktadır. Saldırgan, tüm yakma yollarını tek bir işlem içinde zincirleyerek WBNB rezervi sağlamken çiftin LEDS rezervini neredeyse sıfıra indirdi; ardından dengesizleşmiş havuzu boşaltmak için tersine takas yaptı ve kâr elde etti.

Arka Plan

LEDS, dahili transfer ücreti mekaniğine sahip BNB Chain üzerinde deflasyonist bir tokendir. _transfer() fonksiyonu, arzı kademeli olarak azaltmak ve fiyatı desteklemek için tasarlanmış birden fazla yakma mekanizması uygular: günlük yakma fonksiyonu triggerDailyBurnAndMint(), satışlarda stor_18 birikimi yoluyla ertelenmiş yakma ve takas alıcısı PancakeSwap Router'a ayarlandığında 0xdead adresine token yakan özel dal. Token ayrıca kullanıcıların LEDS basmak ve likidite sağlamak için BNB gönderdiği bir deposit() fonksiyonuna sahiptir; LP ödülleri bir dağıtıcı aracılığıyla talep edilebilir.

Güvenlik Açığı Analizi

Temel neden, LEDS token sözleşmesindeki (0xfb62...a48f) hatalı iş mantığıdır. Kurban, LEDS/WBNB çiftidir (0xd109...6f3f). Token birden fazla deflasyonist mekanizma uygular: triggerDailyBurnAndMint(), satış yolu stor_18 birikimi ve _transfer() içindeki to == router yakma dalı. Bunların her biri bağımsız olarak likidite çiftinden LEDS kaldırır ve rezervleri güncellemek için sync() çağırır.

Tek tek ele alındığında bu mekanizmalar kademeli deflasyon araçları olarak işlev görse de tek bir işlem içinde birlikte zincirlenebilir ve etkileri birleşebilir. Bunlara ek olarak, 0x17a06174() adlı genel fonksiyon herkesin birikmiş stor_18 bakiyesinin tamamını dilediğinde boşaltmasına olanak tanır; erişim kontrolü veya hız sınırlaması yoktur. Bu yakma yollarını sırayla yığarak saldırgan, WBNB rezervine dokunmadan çiftin LEDS rezervini neredeyse sıfıra indirebilir ve tersine takaslarla istismar edilebilir aşırı bir fiyat bozulması yaratabilir.

Saldırı Analizi

Aşağıdaki analiz, 0x2608...79da işlemine dayanmaktadır.

• Adım 1: Saldırgan, flaş krediler aracılığıyla büyük miktarda WBNB elde etti (Moolah + Venus teminat borçlanması + Aave + PancakeSwap V4).

• Adım 2: LP ödüllerini biriktirmek için birden fazla deposit() çağrısı yaptı, ardından triggerDailyBurnAndMint() fonksiyonunu tetikledi; bu, çiftden bir miktar LEDS yaktı ve ödülleri dağıtıcıya göndererek havuzdaki LEDS rezervini azalttı.

• Adım 3: Birikmiş LEDS token ödüllerini talep etmek için 0xde1b1942() fonksiyonunu çağırdı.

• Adım 4: Talep edilen LEDS'i WBNB için sattı. Satış sonrası çiftin LEDS bakiyesi eşiği aştığından, aktarılan miktar stor_18'e (bekleyen yakma) biriktirildi.

• Adım 5: Alıcı olarak Router adresi belirlenerek PancakeSwap üzerinden LEDS satın alındı. Bu, _transfer() içindeki özel dalı tetikleyerek satın alınan LEDS'i doğrudan çiftten 0xdead adresine yaktı ve havuzun LEDS rezervini daha da azalttı.

• Adım 6: 0x17a06174() fonksiyonu çağrılarak Adım 4'te biriken stor_18 bakiyesinin tamamı çiftten 0xdead adresine yakıldı ve sync() çağrısı yapılarak havuzun LEDS rezervi yalnızca 2 wei'ye indirildi.

• Adım 7: Artık büyük ölçüde dengesizleşen havuzdan WBNB boşaltmak için tersine takaslar yapıldı, tüm flaş krediler geri ödendi ve 104,56 WBNB ($64K) kâr elde edildi.

Sonuç

Bu olay, tek bir işlem içinde zincirlenebilen birden fazla korumasız deflasyonist mekanizmanın likidite çiftinin rezervlerini felakete uğratacak biçimde tüketmesinden kaynaklanmıştır.

Deflasyonist veya otomatik yakma mekanizması uygulayan herhangi bir token sözleşmesi için geliştiriciler şunları yapmalıdır:

• Çift yakma fonksiyonlarını uygun erişim kontrolü, hız sınırlaması veya bekleme süresi uygulaması olmadan asla açıkta bırakmayın.

• Birden fazla bağımsız yakma mekanizmasının tek bir işlem içinde sırayla tetiklenmesine izin vermekten kaçının.

BlockSec Hakkında

BlockSec, tam yığın blockchain güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin tam protokol ve platform yaşam döngüsü boyunca kod denetimi (akıllı sözleşmeler, blockchain ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engelleme, olayları analiz etme, yasadışı fonları izleme ve AML/CFT yükümlülüklerini yerine getirme konularında yardımcı olan ürünler ve hizmetler geliştiriyoruz.

BlockSec, prestijli konferanslarda birden fazla blockchain güvenlik makalesi yayımlamış, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırılarını raporlamış, birden fazla hack girişimini engelleyerek 20 milyonun üzerinde dolar kurtarmış ve milyarlarca dolar değerinde kripto parayı 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 Uygulaması: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk