~11,3 Milyon Dolar Kayıp: Multicall Router, Nostra

Geçtiğimiz hafta (2026/09/14 - 2026/09/20), toplam tahmini kaybı yaklaşık 11,3 milyon $ olan 2 güvenlik olayı gözlemledik.

Tarih	Olay	Tür	Tahmini Kayıp
2026/09/15	Unknown Multicall Router	Improper Access Control	~7,8 milyon $
2026/09/17	Nostra Finance	Flawed Oracle Configuration	~3,5 milyon $

Haftanın Öne Çıkan Olayı: Unknown Multicall Router

Bu olay, iç içe router çağrıları arasında yaşanan ince bir çağıran kimliği değişikliğinin, özel modüller çalıştıran bir Safe cüzdanındaki yetkilendirmeyi aşarak önemli miktarda varlığın çekilmesine olanak tanıması nedeniyle seçilmiştir.

15 Eylül 2026'da, Yoink adıyla faaliyet gösteren bir MEV botu, varlıklarını özel strateji modülleri aracılığıyla yöneten bir Safe cüzdanına yönelik denenen bir istismarın önüne geçti (front-run) ve yaklaşık 7,8 milyon $ tahmini kayıp ortaya çıktı [1]. İstekler bu modüllere bir multicall router üzerinden ulaşıyordu; iç içe çağrılardaki bir yetkilendirme hatası, güvenilmeyen talimatların modül zincirine geçmesine izin verirken, yeniden kullanılabilir bir izin de yetkisiz işlem için ek destek sağladı.

Arka Plan

Bir Safe cüzdanı bir Safe modülünü etkinleştirebilir. Etkinleştirildikten sonra modül, cüzdana çoklu imza onayı olmadan işlemleri yürütmesi talimatını vermek için execTransactionFromModule() fonksiyonunu çağırabilir; dolayısıyla etkinleştirilmiş bir modül, cüzdanın varlıkları üzerinde kalıcı bir ayrıcalıktır. Mağdur Safe cüzdanı iki strateji bileşenini etkinleştirmişti: Gateway modülü ve LP modülü.

Gateway modülü, her biri mağdur Safe cüzdanının gerçekleştirmesine izin verilen bir işlemi tanımlayan ve somut değerleri yürütme anında doldurulan yeniden kullanılabilir komut şablonları tanımlıyordu. Komutları yalnızca kendi yetkili çağıran listesindeki çağıranlardan kabul ediyordu. Her yürütmenin ayrıca, çağrılan komut şablonunu doğrulayan ve saklanan bir köke karşı kontrol edilen bir Merkle kanıtı taşıması gerekiyordu. Bazı şablonlar cüzdana, cüzdanın varlıklarını kullanarak Uniswap v4 likidite işlemleri gerçekleştiren LP modülünü çağırma talimatı veriyordu. Bu nedenle kontrol, bir modülden diğerine doğrudan geçmek yerine cüzdanın kendisi üzerinden geri dönüyordu:

Authorized Caller
       |
       v
Gateway module -- verify(command, Merkle proof, root)
       |
       | execTransactionFromModule(...)
       v
Safe wallet context
       |
       v
   LP module --> mintPosition(...)

Bu olaydaki operatörler Gateway modülünü doğrudan çağırmıyordu. İstekler, toplu çağrıları onların adına dağıtan bir multicall router üzerinden geliyordu. Router, meşru bir isteği ilettiğinde doğrudan çağıran olduğu için, Gateway modülünün yetkili çağıran listesi router'ın kendisini de içeriyordu.

Bu yol üzerinden mağdur Safe cüzdanı, yatırılan rsETH için Aave makbuz tokeni olan aEthrsETH'i bir Uniswap v4 havuzuna yatırabiliyor ve cüzdana bir pozisyon NFT'si basılıyordu. aEthrsETH sahibi herhangi biri, bunu Aave üzerinden yakarak altta yatan rsETH'i çekebilirdi.

Mağdur Safe cüzdanı ayrıca bu Aave teminatına karşı borçlanmıştı. Bu nedenle Aave, teminat değerinin borca oranı olan bir sağlık faktörünü (health factor) takip ediyordu ve faktörü 1'in altına düşürecek bir teminat transferini reddediyordu.

Zafiyet Analizi

0x4f00...8ebC adresindeki router'ın kaynak kodu doğrulanmamıştır. Bu nedenle aşağıdaki anlatım, yetkili kaynak düzeyindeki adlar yerine dağıtılmış bytecode'a, decompile edilmiş mantığa, işlem izlerine ve kamuya açık bir fork-test yeniden yapılandırmasına dayanmaktadır.

Router'ın dağıtım mantığı, izin listesinde bulunan veya router'ın kendi adresi olan bir hedefi kabul ediyor, ardından o hedefin yetkili çağıran listesini mevcut çağrının msg.sender değerine karşı kontrol ediyordu. Router'ın kendi kendine yaptığı bir çağrı boyunca orijinal harici çağıranın kimliğini koruyan hiçbir şey yoktu.

Router kendini çağırdığında, iç çağrı msg.sender olarak router'ı görüyordu. Yetkilendirme yardımcısı, kendi kendini hedefleme durumunda router'ı kabul ediyor, aksi halde mevcut msg.sender değerinin bir sonraki hedefin yetkili çağıran listesinde yer alıp almadığını kontrol ediyordu. Sonuç olarak, Gateway modülünü hedefleyen bir iç çağrı, harici çağırandan değil, zaten yetkili olan router'dan geliyormuş gibi değerlendiriliyordu. Bu, güvenilmeyen bir kaynaktan gelen talimatların iç içe yol üzerinden Gateway'in çağıran yetkilendirmesini karşılamasına olanak tanıdı.

İkinci bir kusur kanıt kontrolünün kendisindeydi. Kanıt komut şablonunu doğruluyordu, ancak onunla birlikte sağlanan çalışma zamanı parametrelerini bağlayan bir kontrol yoktu. Daha önceki meşru bir komut için verilmiş geçerli bir kanıt, somut yürütme değerleri değiştirildikten sonra bile kullanılabilir durumda kalıyordu. Yeniden kullanılan kanıt kullanılabilir bir izin sağladı, ancak güvenilmeyen bir çağıranın Gateway modülüne erişmesini sağlayan şey iç içe yetkilendirme atlatmasıydı.

Saldırı Analizi

Aynı komut şablonu için daha önce verilmiş bir Merkle kanıtı, farklı çalışma zamanı değerleriyle kullanılabilir durumda kaldı. Bu özellik Gateway'in çağıran yetkilendirmesini tek başına atlatmadı, ancak iç içe router yolu bu yetkilendirme kontrolünü karşıladıktan sonra kullanılabilir bir izin sağladı.

Aşağıdaki analiz 0x0e7680...a8705 işlemine dayanmaktadır.

Başarılı işlemden önce, asıl saldırgan bir saldırı kontratı, saldırgan kontrolündeki bir PAT tokeni ve daha sonra PAT takasını gerçekleştirecek ikinci bir kontrat dağıttı.

Sonraki blokta saldırgan, bir PAT/aEthrsETH Uniswap v4 havuzu oluşturmak ve başlatmak için prepare() fonksiyonunu çağırdı.

Yoink MEV botu bekleyen istismarı tespit etti ve hazırlanmış saldırı kontratını çağırarak asıl saldırganın önüne geçti. Ortaya çıkan çağrı router'a girdi, router'ın kendini çağırmasına neden oldu ve ardından msg.sender olarak router ile Gateway modülüne ulaştı. Etkinleştirilmiş bir modül olduğu için Gateway, mağdur Safe cüzdanına sağlanan işlemi çoklu imza onayı olmadan yürütttürebildi.

Talimat, mağdur Safe cüzdanının yaklaşık 2.900 aEthrsETH'i, [10, 20] tick aralığında, saldırgan kontrolündeki PAT/aEthrsETH havuzuna likidite olarak sağlamasına neden oldu. İşlem ayrıca ilgili Uniswap v4 pozisyon NFT'sini cüzdana basarak işlemin beklenen likidite akışı içinde görünmesini sağladı. Bu, cüzdanın tüm aEthrsETH bakiyesini almadı: miktar, Aave'nin sağlık faktörü kontrolünün yine de geçilmesi için sınırlandırılmıştı ve cüzdan 1.001182484056805114 sağlık faktöründe bırakıldı.

Saldırı kontratı daha sonra, ikinci kontrat üzerinden saldırgan kontrolündeki PAT karşılığında yatırılan aEthrsETH'in neredeyse tamamını aldı. Elde edilen makbuz tokenlerini Aave üzerinden yaktı ve karşılık gelen miktarda rsETH çekti. Yoink botuna ulaşan yaklaşık 2.900 rsETH'in yaklaşık 2.882,37 rsETH'i kâr alıcısına gitti, yaklaşık 17,63 rsETH ise ETH ile takas edildi ve elde edilen ETH'in neredeyse tamamı blok oluşturucuya ödendi.

Sonuç

Temel neden, tek bir Safe cüzdanına bağlı özel altyapıdaki bir yetkilendirme kusuruydu ve bu kusur, tüm yürütme parametrelerini bağlamayan bir izinle daha da ağırlaştı. Bu durum Safe, Aave, Uniswap v4 veya Kelp'in çekirdek kontratlarına atfedilmemelidir.

Başkaları adına çağrı ileten bir bileşen, yetkilendirmeyi çağrı zincirinin yol boyunca edindiği bir kimlikten değil, orijinal harici çağırandan karara bağlamalı ve kendi hedefi olarak erişilebilir olmamalıdır. Benzer şekilde bir izin, yalnızca işlemin ait olduğu şablonu değil, işlemin yürütüleceği somut değerleri de bağlamalıdır.

Bu Haftaki Diğer Olaylar

Nostra Finance

17 Eylül 2026'da Nostra'nın Starknet üzerindeki para piyasası, şişirilmiş bir NSTR oracle fiyatı aracılığıyla istismar edildi ve fazla değerlenmiş teminata karşı yaklaşık 3,5 milyon $ değerinde varlığın borçlanılmasına olanak sağladı. Temel neden, çok az fiyatlama kaynağını kabul eden bir oracle entegrasyon yapılandırmasıydı; bu, manipüle edilmiş ince havuz fiyatının toplulaştırılmış fiyatı önemli ölçüde etkilemesine izin verdi. Nostra piyasalarını durdurdu [2]; Pragma ise saldırganın adresinin dondurulduğunu ve kurtarma çalışmalarının sürdüğünü bildirdi [3]. Nihai kayıp ve olası kurtarmalar bilinmiyordu.

Arka Plan

Nostra, Starknet üzerinde kullanıcıların desteklenen teminatları yatırabildiği ve teminatın oracle kaynaklı değerine göre diğer varlıkları borç alabildiği bir para piyasası işletiyordu.

Nostra, NSTR fiyatını kendi fiyat besleme kontratı üzerinden alıyordu; bu kontrat, Starknet'te toplulaştırılmış fiyatlar yayımlayan bir oracle olan Pragma'dan okuyan ana bir oracle kontratına yetki devrediyordu. Yayıncılar Pragma'ya AVNU ve GECKOTERMINAL dahil adlandırılmış kaynaklar altında gözlemler gönderiyordu ve belgelenmiş NSTR yapılandırması bunlardan üçü üzerinde bir medyanı tanımlıyordu [4][5]. Her oracle yanıtı bir fiyat, ondalık hassasiyeti, zaman damgası ve katkıda bulunan kaynak sayısını içeriyordu [6]. Ana oracle kontratı, katkıda bulunan kaynakların yapılandırılabilir asgari sayısı olan MinAggregatedSources değerini saklıyordu.

Dağıtılmış toplulaştırma uygulaması doğrudan incelenmedi. Buna rağmen iki bağımsız gösterge aynı yönü işaret ediyor: Pragma'nın açık kaynak kodu, girdi sayısı çift olduğunda ortadaki iki girdinin ortalamasını döndürüyor [6] ve bu olayda gözlemlenen MEDIAN yanıtı, katkıda bulunan iki gözleminin aritmetik ortalamasına eşitti.

Bu kaynakların ardındaki sayılar piyasadan geliyordu. Bir GECKOTERMINAL gözlemi zincir üstü havuzlardan türetilebiliyordu ve Starknet'teki bu tür platformlardan biri, Uniswap v3'e benzer şekilde yoğunlaştırılmış likidite kullanan merkeziyetsiz bir borsa olan Ekubo'dur. Likidite sağlayıcıları varlıkları seçilen tick aralıklarına yerleştirir, takaslar havuz fiyatını aktif aralıklar boyunca hareket ettirir; aktif likiditesi olmayan boşluklar ise önemli ölçüde farklı fiyatlara yerleştirilmiş pozisyonları birbirinden ayırabilir.

Nostra, yatırılan teminatı değerlemek ve hesabın borçlanma kapasitesini hesaplamak için bu oracle yolundan elde edilen NSTR fiyatını kullanıyordu.

Zafiyet Analizi

Nostra'nın para piyasası NSTR fiyatlarını, belgelerinde NSTR fiyat beslemesi olarak listelenen 0x6838...5bf0 kontratından okuyordu [7]. Bu kontrat, belirlediği ana oracle olan 0x7b05...f0ab kontratına yetki devrediyordu ve bu kontratta MinAggregatedSources değeri 1 olarak yapılandırılmıştı. Pragma en az üç fiyatlama kaynağı önermektedir ve olaydan sonra, uygulanan üç kaynaklı bir asgari sınırın burada kabul edilen yanıtı reddedeceğini bildirmiştir [3].

Dolayısıyla iki geçerli gözlem içeren bir yanıt, yapılandırılmış eşiği aşıyordu. İki gözlem için MEDIAN hesaplaması aritmetik ortalamalarına dönüştüğünden, diğer gözlem geçerli piyasa fiyatına yakın kalsa bile tek bir uç fiyat sonucu önemli ölçüde çarpıtabiliyordu.

Bu, ondalık ölçekleme veya medyan uygulaması hatasından ziyade bir entegrasyon yapılandırma zayıflığıydı. Pragma her iki hesaplamada da bir kusur bulmamıştır [3]. Yetersiz kaynak eşiği, yeterince çeşitlendirilmemiş bir girdi kümesinin doğru hesaplanmış çıktısının teminat değerini ve borçlanma kapasitesini belirlemesine izin verdi.

Saldırı Analizi

Saldırı, yeni oluşturulmuş, az fonlanmış yoğunlaştırılmış likidite havuzunun manipüle edilebilirliğine dayanıyordu. Mevcut kanıtlar, saldırganın havuzu doldurmasının ve tekrarlanan etkinliğinin GECKOTERMINAL gözlemi için kullanılan havuzu etkilemiş olabileceğini göstermektedir, ancak havuz seçimindeki tam nedensellik belirlenmemiştir.

Aşağıdaki analiz 0x2460fd...cdf00e işlemine dayanmaktadır.

Saldırgan önce bir Ekubo NSTR/SolvBTC havuzu oluşturdu ve daha düşük, aktif olmayan bir fiyat aralığında tek taraflı likidite olarak 1,5 SolvBTC sağladı. Ardından normal piyasa fiyatı çevresine yaklaşık 1.900 NSTR ve 0,0001514751 SolvBTC ekledi ve havuzda tekrarlanan takaslar gerçekleştirdi.

Sonra saldırgan, normal fiyatın çok üzerinde dar bir aralığa tek taraflı likidite olarak 190 NSTR yerleştirdi. Normal piyasa fiyatı çevresindeki likiditeyi çektikten sonra, bu yüksek fiyatlı pozisyonun önünde boş likiditeli bir boşluk bıraktı.

Yalnızca 0,00000001 SolvBTC içeren bir takas boş aralığı geçti ve havuzu yüksek fiyatlı pozisyonun sınırında, -6645400 tick'ine taşıdı. Manipüle edilen havuz değeri daha sonra 99,02439975 $ tutarında bir GECKOTERMINAL NSTR/USD gözlemi olarak gönderildi.

AVNU altında gönderilen diğer katkıda bulunan gözlem, NSTR'yi 0,00596118 $ olarak değerliyordu. Yapılandırılmış üçüncü kaynaktan bu yanıtta hiçbir gözlem görünmüyor; bu da toplulaştırmaya ulaşan tek değerlerin bu ikisi olmasını sağlıyor [4].

İki değerle MEDIAN yanıtı, NSTR başına yaklaşık 49,51518046 $ olan aritmetik ortalamalarıydı. Nostra ortaya çıkan değerlemeyi kabul etti ve saldırganın NSTR mevduatını önemli miktarda borçlanma için yeterli teminat olarak değerlendirdi.

Tespit edilen ilk çıkarımda saldırgan, NSTR teminatı tutan ayrı bir hesap kullanarak şişirilmiş değerlemeyle yaklaşık 939,386010 ETH borç aldı [4]. Nostra, borçlanma dizisinin tamamının ayrıca STRK, USDC, USDT, WBTC ve DAIv1'i de içerdiğini ve toplam borçlanılan değerin yaklaşık 3,5 milyon $ olduğunu bildirdi [2].

Sonuç

Olay, Pragma'nın ondalık işleme veya toplulaştırma hesaplamasındaki bir hatadan değil, Nostra'nın entegrasyonundaki yetersiz oracle kaynak eşiğinden kaynaklandı. Bir gözlem son derece manipüle edilebilir bir havuzdan gelse de iki kaynaklı bir yanıt geçerli kalmaya devam etti.

Nostra, en az üç katkıda bulunan fiyatlama kaynağı şartı koşmalı ve fiyatı teminat değerlemesi veya borçlanma için kullanmadan önce kaynak sayısı bu eşiğin altında kalan her oracle yanıtını reddetmelidir. Teminat uygunluğu ve maruziyet limitleri de, mevcut piyasa likiditesini ve her varlığın altta yatan fiyat kaynaklarını manipüle etmek için gereken derinliği yansıtmalıdır.

Kaynaklar

[1] https://x.com/Phalcon_xyz/status/2099741447776096270

[2] https://x.com/nostrafinance/status/2100577538053493076

[3] https://www.pragma.build/updates/nostra-nstr-incident

[4] https://x.com/Phalcon_xyz/status/2100818035082952751

[5] https://www.pragma.build/asset/NSTR-USD?network=mainnet

[6] https://github.com/Astraly-Labs/pragma-oracle

[7] https://docs.nostra.finance/lend-and-borrow/deployed-contracts/money-market-mainnet

BlockSec Hakkında

BlockSec, tam kapsamlı bir blokzincir güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokollerin ve platformların tüm yaşam döngüsü boyunca kod denetimi (akıllı kontratlar, blokzincir ve cüzdanlar dahil) gerçekleştirmesine, saldırıları gerçek zamanlı olarak engellemesine, olayları analiz etmesine, yasa dışı fonları izlemesine ve AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürünler ve hizmetler geliştiriyoruz.

BlockSec, saygın konferanslarda birçok blokzincir güvenliği makalesi yayımlamış, DeFi uygulamalarına yönelik birkaç sıfırıncı gün saldırısını bildirmiş, 20 milyon doların üzerinde varlığı kurtarmak için birçok saldırıyı engellemiş ve milyarlarca kripto para birimini güvence altına almıştır.