Haftalık Web3 Güvenlik Olayları Özeti | 6 Nis – 12 Nis 2026

Geçen hafta (2026/04/06 - 2026/04/12), BlockSec dört saldırı olayı tespit edip analiz etti; toplam tahmini kayıplar yaklaşık $928.6K olarak gerçekleşti. Aşağıdaki tablo bu olayları özetlemekte olup her bir olayın ayrıntılı analizleri sonraki alt bölümlerde sunulmaktadır.

*Denaria olayı geçen haftaki raporda ele alınmamış olup bütünlük açısından burada yer verilmektedir.

Bu haftadan itibaren her raporun başında bir olayı öne çıkarıyoruz. Seçim mutlaka kayıp miktarına göre yapılmıyor — özgün protokol tasarımı, akıllıca saldırı tekniği veya topluluk için daha geniş dersler sunması nedeniyle seçilebilir.

Haftanın Öne Çıkanı: Denaria Olayı

Sürekli DEX Denaria, karmaşık kod mantığına dayanan özgün muhasebe mekanizmaları sundu. Ancak denetim sonrası yapılan bir yeniden düzenleme, ince bir uç durum üretebilecek bir yuvarlama asimetrisi ortaya çıkardı; bu uç durum negatif bir değere yol açtı ve sonunda güvensiz bir tür dönüşümüne çarparak astronomik düzeyde değer çekilmesine olanak tanıdı.

5 Nisan 2026'da Denaria'nın Linea üzerindeki sürekli DEX'i yaklaşık $165.6K kayıpla istismar edildi. Temel neden, getLpLiquidityBalance() içindeki iki bileşik kusurdu: denetim sonrası LP bakiye muhasebesine yapılan yeniden düzenleme, hafifçe negatif bir ara değer üretebilen bir yuvarlama asimetrisi ortaya çıkardı ve güvensiz int256-to-uint256 dönüşümü, negatif bir değer yerine geri dönüş yapmak yerine sessizce neredeyse maksimum işaretsiz tam sayıya sarmaladı. Saldırgan bunu tek taraflı bir LP yatırımı ve uzun bir işlem aracılığıyla istismar etti, ardından kasadan yapay olarak şişirilmiş PnL çekti.

Arka Plan

Denaria, dinamik bir sanal AMM üzerine kurulu Linea'daki bir sürekli DEX'tir. İşlem yapma ve uzlaşmayı iki bileşene ayırır. PerpPair piyasası kullanıcı pozisyonlarını ve LP muhasebesini yönetirken Vault teminatı tutar ve gerçekleşmiş PnL'yi uzlaştırır.

PerpPair içindeki LP sahipliği açık bir token bakiyesiyle temsil edilmez. Bunun yerine protokol, her LP'nin durumunu iki defter tutma bileşeninden oluşan dahili bir muhasebe matrisinden yeniden oluşturur; burada bunlara varlık tarafı ve sabit taraf adı verilmektedir. Varlık tarafı, LP'nin havuzun fiyat hareketlerine maruziyetindeki payını takip ederken sabit taraf, havuzun sabit para cinsinden değerindeki payını takip eder. Bu iki bileşen birlikte, bir LP'nin değerinin nasıl takip edildiğini ve uzlaştırıldığını ortak olarak belirler.

Bu bileşenler statik anlık görüntüler olarak saklanmaz. Her işlem gerçekleştiğinde PerpPair, küresel likidite durumunu günceller ve her LP'nin yeniden oluşturulan bakiyesi, kümülatif küresel değerler ile LP'nin giriş noktası anlık görüntüsü arasındaki farktan türetilir. Bu muhasebe mekanizması, orijinal pay tabanlı biriktiricinin doğrudan bakiye takibiyle değiştirildiği denetim sonrası bir yeniden düzenlemede tanıtıldı. Ancak yeniden düzenlenen çıkarma yolu, belirli işlem dizileri altında yeniden oluşturulan LP bileşenlerinin hafifçe negatif hale gelmesine neden olabilecek bir yuvarlama asimetrisi ortaya çıkardı.

Güvenlik Açığı Analizi

Savunmasız PerpPair sözleşmesi (0xb683...36ae17) iki bileşik kusur içermektedir.

1. Yeniden düzenlenen muhasebede yuvarlama asimetrisi. Doğrudan bakiye takibini tanıtan denetim sonrası yeniden düzenleme, çıkarma tabanlı yeniden yapılandırma yolunda bir yuvarlama asimetrisi yarattı. Belirli işlem dizileri altında, yuvarlamadan sonra küresel kümülatif değer LP'nin giriş noktası anlık görüntüsünden marjinal olarak daha küçük hale gelebilir; bu da çıkarmanın sıfır yerine küçük bir negatif sonuç üretmesine neden olur. Teorik olarak bu değer sıfır veya sıfıra yakın olmalıydı; asimetri, genel olarak çıkarma muhasebesinin doğasında olan bir özellik değil, bu yeniden düzenlenen uygulamaya özgü bir kusurdu.

2. Güvensiz işaretli-işaretsiz tür dönüşümü. getLpLiquidityBalance() içinde, yeniden oluşturulan bir LP bakiye bileşeni doğrulama yapılmadan int256'dan uint256'ya dönüştürüldü. Solidity'de negatif bir int256'yı uint256'ya dönüştürmek geri dönüş yapmaz; değeri 2^256 modülüne göre sarmalayarak -1 gibi küçük bir negatif sayıyı neredeyse maksimum işaretsiz tam sayıya (2^256 - 1) dönüştürür. Bu yeniden oluşturulan bakiye uzlaşma için calcPnL()'e beslendiğinden, herhangi bir negatif girdi devasa bir LP pozisyonu olarak yorumlanır ve bir saldırganın yapay olarak şişirilmiş kar elde etmesine ve kasadan fon çekmesine olanak tanır.

Hiçbir kusur tek başına istismar edilebilir olmazdı. Yuvarlama asimetrisi yalnızca hafifçe negatif bir değer üretti; bu değer normal int256 aritmetiği altında yalnızca ihmal edilebilir bir hatayı temsil ederdi. Ancak bu negatif değer korumasız dönüşüme ulaştığında neredeyse maksimum işaretsiz tam sayıya sarmalandı. Ardından gelen bir sınır denetimi, sarmalanan değeri havuzun toplam varlık tarafı likiditesiyle sınırlandırdı ve taşmayı etkin biçimde piyasanın tüm varlık tarafı üzerinde bir talebe dönüştürdü.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemine dayanmaktadır: 0xcb0744...0c606447.

• Adım 1: Saldırgan, Aave flash loan aracılığıyla 60.000 USDC ödünç aldı.

• Adım 2: Yardımcı bir adres teminat olarak 30.000 USDC yatırdı ve 19.980 sabit token tutarında yalnızca sabit taraflı LP pozisyonu ekledi. Yalnızca sabit tarafta yatırım yaparak yardımcı, varlık tarafı LP bileşeninin sıfıra yakın başlamasını sağladı ve bu da onu yuvarlama nedeniyle negatife geçmeye daha duyarlı hale getirdi.

• Adım 3: İkinci bir yardımcı adres 15.000 USDC yatırdı ve 100.000 nominal uzun pozisyon açtı; bu, temel yuvarlama hatasını ortaya çıkaran bir liquidityM güncellemesine neden oldu. Havuzun likiditesine göre büyük nominal boyut, işlem başına yuvarlama etkisini güçlendirerek birinci yardımcının yeniden oluşturulan varlık tarafı bakiyesini sıfırın hafifçe altına itti.

• Adım 4: Birinci yardımcı ardından realizePnL() çağırdı. LP bakiyesi yeniden oluşturulurken negatif lpAssetBalance, neredeyse maksimum uint256'ya sarmalandı. Bu büyük değer daha sonra piyasanın tam varlık tarafı likiditesiyle sınırlandırıldı ve son derece şişirilmiş bir kar üretti. Etkili biçimde protokol, LP'nin piyasanın tüm varlık tarafına sahip olduğuna inandı.

• Adım 5: Saldırgan, kasadan şişirilmiş PnL'yi çekti.

Kalan kasa likiditesi tükenene kadar aynı örüntü tekrarlandı. Flash loan geri ödendikten sonra saldırgan yaklaşık $165.6K kar elde etti.

Sonuç

Bu istismar nihayetinde işaretliden işaretsize dönüşümde eksik sınır doğrulamasından kaynaklandı. Acil düzeltme basittir: çıplak dönüşümü, negatif girişi sarmak yerine geri döndüren SafeCast.toUint256() ile değiştirin.

Daha geniş bir perspektiften bakıldığında, bu olay harici incelemeyi atlayan denetim sonrası yeniden düzenlemelerin riskini göstermektedir. Resmi olay sonrası rapora göre yuvarlama asimetrisi, ekibin orijinal biriktiricinin yerini doğrudan bakiye takibiyle değiştirdiği son harici denetimden sonra tanıtıldı. Yeniden düzenleme bir taşma endişesini çözmüş olsa da dahili testlerin yakalayamadığı yeni bir uç durum yarattı. Protokoller temel muhasebe mantığını yeniden düzenlediğinde, özellikle yeniden oluşturulan değerler doğrudan PnL uzlaşmasına veya para çekme mantığına beslendiğinde, yeni kod yolu güvenlik açısından kritik olarak ele alınmalı ve yeniden denetlenmelidir.

HB Token Olayı

7 Nisan 2026'da BNB Chain üzerinde gömülü alım/satım kancalarına sahip özel bir ERC-20 token olan HB, yaklaşık $193K kayıpla istismar edildi. Temel neden hatalı ödül uzlaşma mantığıydı: tetiklendiğinde swapBack() çağrıldı; bu fonksiyon HB rezervlerini doğrudan PancakeSwap çiftinden kaldırdı ve ardından havuzu yeniden fiyatlandırmak için sync() çağırdı. Saldırgan çiftin HB'sinin büyük bölümünü satın aldıktan sonra, ardından gelen swapBack() çalıştırması kalan likiditeli azalttı ve spot fiyatı keskin biçimde şişirdi. Saldırgan daha sonra bozulmuş havuza çok az miktarda HB satarak orantısız büyüklükte USDT aldı ve çift boşalana kadar döngüyü tekrarladı.

Arka Plan

HB, _transfer() içine gömülü alım ve satım kancaları olan BNB Chain üzerindeki özel bir ERC-20 tokenıdır. Kullanıcılar AMM çiftinden satın aldığında _handleBuy() maliyet bazı bilgilerini kaydeder. Kullanıcılar sattığında ise _handleSell(), çiftin durumuna bağlı olarak farklı vergi ve uzlaşma yollarına ayrılır.

Token ayrıca swapBack() tetikleyebilen bir ödül uzlaşma mekanizması içerir. Normal bir router aracılı takas gerçekleştirmek yerine swapBack(), HB'yi doğrudan PancakeSwap çiftinden PROOF adresine aktarır, ardından çifti sync() aracılığıyla yeniden senkronize etmeye zorlar. Bu, sözleşmenin çiftin HB rezervlerini normal AMM işlem akışlarının dışında küçültmesine ve havuzu anında yukarı doğru yeniden fiyatlandırmasına olanak tanır.

Güvenlik Açığı Analizi

HB token sözleşmesindeki (0x62ce...87a4b0) temel kusur, swapBack()'in ödülleri bir hazineden veya router aracılı takas yoluyla değil, doğrudan AMM çiftinden token çekerek temin etmesiydi. swapBack() ödül uzlaşma yolu üzerinden erişilebildiğinden, ticari olmayan bir kod yolu çift rezervlerini doğrudan değiştirebilir ve spot fiyatı değiştirebilirdi.

Çiftin HB rezervleri düşük olduğunda, swapBack() çağrısı kalan HB'yi daha da azaltır ve fiyat bozulmasını güçlendirir; bu da son derece şişirilmiş fiyatlardan çok az miktarda HB satmayı mümkün kılar.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemine dayanmaktadır: 0x19671f...d71594ed.

• Adım 1: Saldırgan, Venus'tan büyük miktarda fon ödünç aldı.

• Adım 2: Saldırgan, token sözleşmesine yaklaşık 1.496 HB aktararak sözleşmenin HB bakiyesini artırdı; böylece sonraki swapBack() çiftten daha büyük miktarda çekebilir hale geldi.

• Adım 3: PancakeSwap çiftine az miktarda HB aktararak saldırgan _swapAndLiquify() işlevini tetikledi; bu işlev token sözleşmesinin elindeki yaklaşık 4.163 HB'yi 10 USDT ile takas etti ve saldırganın talep edebileceği HB ödüllerini artırdı.

• Adım 4: Saldırgan daha sonra 73.608.753 HB satın almak için 72.117.360 USDT harcadı ve çiftte çok az HB likiditesi bıraktı.

• Adım 5: Ardından saldırgan ödül açığı yolunu tetikledi. Ödülleri karşılamak için token swapBack() çağırdı; bu fonksiyon PancakeSwap çiftinden ek HB çekti ve sync() çağırarak HB fiyatını keskin biçimde artırdı.

• Adım 6: Saldırgan, çiftin USDT rezervlerini yenilemek için doğrudan çifte USDT aktardı, ardından bozulmuş fiyattan yalnızca 0.000582 HB satarak 37.582.322 USDT elde etti.

Bozulmuş fiyattan HB token satmak için 6. Adımı tekrarlayan saldırgan havuzdaki neredeyse tüm USDT'yi çıkardı.

Sonuç

HB token olayı, ödül mantığının AMM rezervlerini doğrudan değiştirmesine izin vermenin ne kadar tehlikeli olduğunu göstermektedir. Rezervleri etkileyen fonksiyonlar hiçbir zaman ödül uzlaşma yollarından erişilebilir olmamalı; protokoller güvenlik açısından kritik kontrol akışında dahili token bakiyelerini AMM rezerv muhasebesıyla karıştırmaktan kaçınmalıdır. Havuzu dahili olarak bozduktan sonra spot AMM fiyatlandırmasına dayanan her tasarım, özünde fiyat manipülasyonuna karşı savunmasızdır.

Squid Multicall Olayı

7 Nisan 2026'da bir Squid kullanıcısı onay ile ilgili bir olayda birden fazla zincirde yaklaşık $517K kaybetti. Kullanıcı yanlışlıkla amaçlanan Squid Router yerine bir SquidMulticall sözleşmesini onayladı. Bu durum, saldırganın keyfi harici çağrılar gerçekleştirmek için izinsiz bir SquidMulticall.run() fonksiyonu çağırmasına olanak tanıdı. Saldırgan bu sayede sözleşmeye onaylanan herhangi bir izni, onu onaylayan kullanıcılara karşı token transferFrom() çağrıları gerçekleştirmek için kullanabildi.

Arka Plan

Squid'in normal akışında kullanıcılar Squid Router'ı onaylamalı; SquidMulticall ise yalnızca bir çalıştırma yardımcısı olarak işlev görmelidir. Yardımcı sözleşme, yönlendirme mantığının bir parçası olarak toplu çağrılar gerçekleştirmek üzere tasarlanmıştır ancak kullanıcıların token transferleri için doğrudan onayladığı harcayıcı olmamalıdır.

ERC-20 izin kontrolleri yalnızca harcayıcı adresine karşı gerçekleştirildiğinden, kullanıcı onaylarını kısıtsız keyfi çağrı yetenekiyle birleştiren her sözleşme tehlikeli bir onay havuzu oluşturur: bir kez onaylandığında, o sözleşme herhangi biri yaptığı çağrıları kontrol edebiliyorsa genel bir token çekme vektörü haline gelebilir.

Güvenlik Açığı Analizi

Bu olay bir akıllı sözleşme güvenlik açığından kaynaklanmadı. Kayıp, iki koşulun bir arada gerçekleşmesinden doğdu: SquidMulticall'ı Router yerine hedefleyen yanlış bir onay ve run()'ın herhangi bir çağırandan keyfi hedefler ve calldata kabul eden izinsiz tasarımı.

SquidMulticall, Router akışının aşağı akış adımı olarak toplu çağrılar gerçekleştirmek üzere tasarlanmıştır; burada girdiler güvenilir yönlendirme mantığı tarafından oluşturulur. Amaçlandığı şekilde kullanıldığında izinsiz tasarım herhangi bir risk oluşturmaz. Ancak yanlış yerleştirilmiş bir onay bunu tamamen değiştirir: bir MEV botu canlı izni tespit etti, kurbanın onayladığı tokenları her zincirde kurbanın herhangi bir ek işlemi olmaksızın boşaltmak üzere transferFrom(kurban, saldırgan, miktar) çağırmak için hazırlanmış calldata ile run() çağırdı.

Saldırı Analizi

Olay bir kullanıcıyı BNB Chain, Arbitrum, Optimism, Avalanche ve Base üzerinde etkiledi. Aşağıdaki analiz, saldırı işlemine dayanmaktadır: 0x81d0c4...9b1301e9.

• Adım 1: Kurban (0xacc0...f40e98) yanlışlıkla amaçlanan Squid Router yerine SquidMulticall'ı onayladı.

• Adım 2: Bir MEV botu bu izni tespit ederek hazırlanmış calldata ile SquidMulticall.run() çağırdı.

• Adım 3: Keyfi çağrı aracılığıyla SquidMulticall, transferFrom(kurban, saldırgan, miktar) çağırdı ve onaylanan varlıkları kurbanın cüzdanından transfer etti.

Sonuç

Bu olay, izinsiz keyfi çağrı sözleşmelerinin kullanıcıya yönelik onay akışlarıyla bir arada bulunmasının riskini göstermektedir. Anlık neden yanlış bir onaylama olsa da SquidMulticall kısıtsız çağıranları, keyfi hedefleri ve keyfi calldata'yı kabul ettiğinden, yanlışlıkla ona yönlendirilen her onay anında ve tamamen istismar edilebilir hale geldi. Çalıştırma yardımcısı sözleşmeleri kullanan protokoller, yanlış yerleştirilmiş bir onayın önemsiz biçimde silahlandırılamaması için çağıran kısıtlamaları eklemeyi veya bu tür fonksiyonlara izin verilen çağrı hedeflerini sınırlamayı düşünmelidir.

XBIT Olayı

11 Nisan 2026'da BNB Chain üzerindeki XBIT token yaklaşık $53K kayıpla istismar edildi. Temel neden, XBITVault içindeki başarısız-açık erişim kontrolü kusurundan kaynaklandı: transfer() fonksiyonunun yetkilendirme denetimi koşuluydu — yalnızca xbitContract sıfırdan farklı olduğunda msg.sender == xbitContract zorunluluğunu uyguluyordu; aksi takdirde sessizce geçiyordu. bindXBIT() sözleşmeyi başlatmak için hiçbir zaman çağrılmadığından bu kusur kalıcı olarak açıkta kaldı ve keyfi çağıranların XBIT/USDT PancakeSwap çifti dahil herhangi bir adresten XBIT bakiyelerini hareket ettirmesine olanak tanıdı. Saldırgan bunu çiftten XBIT boşaltmak için kullandı, ardından havuza tekrar tekrar az miktarda XBIT satarak orantısız büyüklükte USDT elde etti.

Arka Plan

XBITVault, pasif bir hazine sözleşmesi değildir. XBIT token sistemi için bakiye ve izin arka ucudur; transfer(), approve() ve mintForXBIT() gibi token benzeri fonksiyonlar sunar. Amaçlanan tasarım altında, sahibin önce kasayı başlatmak için bindXBIT() çağırması, xbitContract, pancakePair, pairContract ve xbitDecimals değerlerini ayarlaması gerekir. Başlatmadan sonra, hassas durum değiştirici fonksiyonların yalnızca bağlı XBIT sözleşmesi tarafından çağrılabilir olması gerekiyordu. Başka bir deyişle, kasanın güvenlik modeli kamuya açık kullanımdan önce başarılı başlatmaya bağlıydı.

Güvenlik Açığı Analizi

Kritik kusur, erişim kontrolünün savunmasız XBITVault sözleşmesinde (0xc879...42391a) koşullu olmasıdır. transfer() fonksiyonu msg.sender == xbitContract kontrolünü yalnızca xbitContract != address(0) olduğunda gerçekleştirir. Bu, xbitContract ayarlanmamış olduğunda fonksiyonun geri dönüş yapmadığı ve bunun yerine herkes tarafından kamuya açık hale geldiği anlamına gelir. Bakiyeler _balances içinde depolandığından, kaynak adresin yeterli bakiyesi olduğu sürece herhangi bir harici çağıran XBIT'i herhangi bir adresten başka bir adrese taşıyabilir.

Amaçlanan başlatma yolu bindXBIT() idi, ancak hiçbir zaman çağrılmadığı için kasa başlatılmamış ve başarısız-açık durumda kaldı. Sonuç, etkili biçimde kısıtsız bir keyfi bakiye transfer ilkeliydi.

Saldırı Analizi

Aşağıdaki analiz, saldırı işlemine dayanmaktadır: 0xbc877f...4df1b694.

• Adım 1: Kısıtsız transfer() fonksiyonu aracılığıyla saldırgan, karşılığında herhangi bir USDT sağlamaksızın XBIT/USDT çiftinden 1.526.216.569 XBIT çıkardı.

• Adım 2: Saldırgan, çiftin XBIT rezervlerini yalnızca 1-2 birime düşürmek için sync() çağırdı.

• Adım 3: Çifte sıfıra yakın XBIT likiditesi kaldıktan sonra saldırgan tekrar tekrar XBIT sattı ve çiftten yaklaşık 53.112 USDT çekti.

Sonuç

Bu olay, başarısız-açık başlatmaya bağımlı bir erişim kontrolü denetiminden kaynaklandı. xbitContract ayarlanmamış olduğunda transfer() kısıtsızdı ve bindXBIT() hiçbir zaman çağrılmadığından kasa kalıcı olarak kamuya açık bir keyfi bakiye transfer ilkelini ortaya koydu. Ayrıcalıklı fonksiyonlar başlatma tamamlanana kadar geri dönüş yapmalı ve dağıtım zamanı bağlama adımları, operasyonel varsayımlar değil zincir üstünde zorunlu kılınan ön koşullar olmalıdır.

BlockSec Hakkında

BlockSec, tam yığın blockchain güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokollerin ve platformların tam yaşam döngüsü boyunca kod denetimi (akıllı sözleşmeler, blockchain ve cüzdanlar dahil) gerçekleştirmesine, saldırıları gerçek zamanlı olarak engellenmesine, 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 birçok blockchain güvenlik makalesi yayımlamış, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırılarını raporlamış, 20 milyonun üzerinde dolar kurtarmak için birden fazla hack girişimini engellemiş ve milyarlarca dolarlık 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 Security Uygulaması: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk