~$18M Kaybedildi: jaredFromSubway, Aztec ve Daha Fazlası

Geçen hafta (2026/06/15 - 2026/06/21) toplam yaklaşık 18,3 milyon dolar kayıpla sonuçlanan 3 önemli güvenlik olayı gözlemledik.

Tarih	Olay	Tür	Tahmini Kayıp
2026/06/18	Aztec	Hatalı Genel Girdi Bağlaması	~2,2 Milyon Dolar
2026/06/20	LABUBU Token	Yanlış Yapılandırma	~1,1 Milyon Dolar
2026/06/20	jaredFromSubway	Hatalı Onay Yönetimi	~15 Milyon Dolar

Aztec: Protokolün üç gün içinde ikinci kez, bu sefer kaçış kapısı devresi aracılığıyla istismar edilmesi ve tekrarlayan ZK kanıt bağlama sorunlarını vurgulaması nedeniyle seçildi.
jaredFromSubway: MEV botunun sözleşmesinin, tüketimi doğrulamadan veya artık izinleri iptal etmeden güvenilmeyen token sözleşmelerine onay vermesi ve saldırganın ~15 milyon dolar biriktirip ele geçirmesine olanak tanıması nedeniyle seçildi.

Haftanın Öne Çıkanı: jaredFromSubway

Saldırganların güvenilen DeFi sözleşmelerindeki açıklardan yararlanarak kullanıcıların bu sözleşmelere onayladığı varlıkları boşalttığı geleneksel onay istismarlarının aksine, bu saldırı ters yönü hedef almaktadır: MEV botu, arbitraj operasyonlarının bir parçası olarak kendi varlıkları üzerindeki onayları proaktif biçimde güvenilmeyen üçüncü taraf sözleşmelere verdi. Saldırgan, sahte takas havuzlarının gerçek Swap ve Sync olayları yayarken sahte tokenların verilen izinleri hiç tüketmediği sahte bir işlem ortamı (temelde bir tuzak) kurdu; bu dışa dönük onayları biriktirdi ve ardından hasat etti. Bildirilen toplam kayıp ~15 milyon dolardır.

20 Haziran 2026'da Ethereum'da bir MEV botu operatörü olan jaredFromSubway yaklaşık 15 milyon dolar kaybetti [1]. Zincir içi analize göre temel neden, bot sözleşmesindeki hatalı onay yönetimiydi: güvenilmeyen sarmalayıcı sözleşmelere verilen onaylar hiç tüketilmedi ve saldırgan bu tüketilmemiş izinleri tek bir işlemde botun gerçek bakiyelerini boşaltana kadar biriktirdi.

Arka Plan

jaredFromSubway, Ethereum'da sandwich saldırıları ve zincir içi arbitrajda uzmanlaşmış, iyi bilinen bir MEV botu operatörüdür. Kurban sözleşmesi (0x1f2f...f387), WETH, USDC ve USDT'de büyük çalışma sermayesi bakiyeleri tutan işletme cüzdanlarından biridir.

Bu tür MEV botları, zincirde beliren rastgele yeni tokenlar ve havuzlarla dinamik olarak etkileşim kurmak zorundadır. Bant genişliğini izler, işlemleri simüle eder ve arbitraj fırsatlarını yakalamak için token etkileşimlerini otomatik olarak onaylarlar. Bu operasyonel model, tokenların beklendiği gibi davranacağı varsayımına dayanır: bir takas gerçekleştirildiğinde, token sözleşmesi transferFrom çağrısı yaparak verilen izni tüketir.

Güvenlik Açığı Analizi

Temel neden, MEV botunun güvenilmeyen sözleşmelerle etkileşimde bulunurken hatalı onay yönetimidir.

Bot, Uniswap havuzları ve yönlendiricileri üzerinden çeşitli arbitraj yolları yürütür. Çoğu etkileşimde bot, tokenları doğrudan transfer yoluyla havuzlara iter; burada botun kendisi msg.sender olduğundan onay gerekmez. Ancak sarmalayıcı tarzı token sözleşmeleriyle etkileşimler bir çekme modelini takip eder: bot wrapper.wrapTo() çağrısı yapar ve bu çağrının içinde sarmalayıcı sözleşme, botun gerçek tokenlarını çekmek için realToken.transferFrom(bot, wrapper, amount) çağrısı yapar. transferFrom sırasında msg.sender bot değil sarmalayıcı sözleşme olduğundan, önceden bir approve gereklidir:

<real_token>.approve(tokenContract, amount) — gerçek token üzerinde sarmalayıcı sözleşmeye izin ver
tokenContract.wrapTo() → havuzlar üzerinden çok adımlı swap() → tokenContract.unwrap() — gerçek tokeni sar, havuzlardan yönlendir ve gerçek tokene geri sar

Bot, iyi huylu bir sarmalayıcı sözleşmenin yapacağı gibi wrapTo() çağrısının transferFrom aracılığıyla izni tüketeceğini varsaydı. Ancak bot, işlem sonrasında iznin gerçekten tüketilip tüketilmediğini hiçbir zaman doğrulamadı ve artık kalan izni iptal etmedi. wrapTo(), transferFrom çağrısı yapmazsa tam izin işlemden sağ çıkar ve kalıcı bir saldırı yüzeyine dönüşür — böyle bir izne sahip herhangi bir sözleşme, botun gerçek varlıklarını taşımak için daha sonra transferFrom çağrısı yapabilir.

Saldırı Analizi

Zincir içi yeniden yapılandırmaya göre saldırgan, yukarıda açıklanan güvenlik açığından yararlanmak için üç bileşenden oluşan sahte bir işlem ortamı kurdu:

Sahte sarmalayıcı tokenlar: Her sahte token, gerçek tokenın adını kullanırken sembolün başına f ekledi (örneğin USDC için fUSDC sembolüyle USD Coin adı). Meşru bir sarmalayıcıyı taklit etmek için wrapTo() ve unwrap() ile birlikte tüketilmemiş izinleri transferFrom aracılığıyla boşaltan, yalnızca saldırgana açık bir withdraw() işlevi uyguladı.
Sahte takas havuzları: Saldırgan, kendi dağıttığı bir fabrika aracılığıyla yaklaşık 44 adet Uniswap V2 tarzı havuz dağıttı. Bu havuzlar, inandırıcı takas rotaları oluşturmak için sahte tokenları birbirleriyle eşleştirdi. swap() çağrıldığında, havuzlar meşru işlemlerden ayırt edilemeyen gerçek Sync ve Swap olayları yaydı.
Saldırgan tarafından oluşturulan kârlar: unwrap() sırasında sahte token, transfer aracılığıyla bota küçük miktarda gerçek token gönderdi. Bot gerçek kâr elde etti; ancak bu kâr piyasa arbitrajından kazanılmış değil, saldırgan tarafından kasıtlı olarak oluşturulmuştu.

Saldırgan, bu bileşenleri harici bir sözleşmedeki blok başına getStatus() anahtarı aracılığıyla kontrol etti. getStatus(), aktivasyon işlemiyle aynı blokta çağrıldığında 1 değerini (_getStatus = block.number ayarlandığında) ve aksi hâlde 0 değerini döndürdü. getStatus() == 0 olduğunda, wrapTo() normalde transferFrom çağrısı yaptı ve izin tüketildi. getStatus() == 1 olduğunda, wrapTo() transferFrom çağrısını atladı — izin tüketilmedi — buna karşın unwrap() bota saldırgan tarafından oluşturulan tokenları geri göndermeye devam etti. Saldırgan, izinleri biriktirmek istediğinde aktivasyon işlemini botun işlemiyle aynı bloğa yerleştirmek için muhtemelen inşaatçı rüşvetleri kullandı.

Saldırı üç aşamada gerçekleşti:

1. Aşama: Saldırı altyapısını dağıt

Adım 1: Saldırgan, altyapıyı 25354424'ten 25354519'a kadar olan bloklar boyunca kurdu. Bu süreçte sahte bir token fabrikası sözleşmesi (0x81f2...0091) dağıtıldı, kendi dağıttığı fabrika aracılığıyla ~44 adet sahte Uniswap V2 havuzu oluşturuldu, swap() çağrılarının başarılı olması için havuzlara başlangıç token bakiyeleriyle fon sağlandı ve hasat sözleşmesine (0xb84d...df52) gaz ve inşaatçı rüşveti için 0,01 ETH gönderildi.
Adım 2: Saldırgan, her biri gerçek bir tokeni taklit eden (gerçek adı kullanan ancak sembolün başına f ekleyen) ve saldırgana kısıtlı bir withdraw() işlevi taşıyan sahte sarmalayıcı tokenları CREATE2 aracılığıyla toplu olarak üretti. CREATE2, hasat sözleşmesinin üzerinde döngü kurabilmesi için deterministik adresler sağladı.

2. Aşama: Güven oluştur ve onayları biriktir

Adım 3 (başlangıç güveni): İlk işlemlerde (örneğin 25354425 nolu blokta 0x542d...362b), sahte tokenların getStatus() anahtarı yoktu — wrapTo() doğrudan transferFrom çağrısı yaparak izni tüketti. Bot normal şekilde onayladı, sardı, takas etti, çıkardı ve kâr etti. Bu durum sahte tokenları kârlı işlem fırsatları olarak kabul ettirdi.
Adım 4 (güvenin sürdürülmesi): Sonraki işlemlerde (örneğin 0x085e...37e51), getStatus() anahtarı dağıtılmıştı ancak 0 döndürüyordu (aktivasyon işleminden farklı blok). wrapTo() yine de transferFrom çağrısı yaparak izni tüketti. Bot kâr etmeye devam etti ve etkileşimlerini sürdürdü.
Adım 5 (birikim): 25360519 nolu blokta 0x8560...1915 işlemiyle başlayarak saldırgan, getStatus()'ın 1 döndürmesine neden olmak için inşaatçı rüşveti aracılığıyla aktivasyon işlemini botun işlemiyle aynı bloğa yerleştirdi. Bu modda wrapTo() transferFrom çağrısını atladı — izin tüketilmedi — ancak unwrap() yine de bota küçük miktarda gerçek token gönderdi. Bot kârlı bir işlem gördü ve onayı yerinde bıraktı. Yaklaşık 600 blok (~13 işlem) boyunca bot, WETH, USDC ve USDT genelinde bu kalıbı tekrarlayarak üç gerçek varlığın tamamında tüketilmemiş izinler biriktirdi.

3. Aşama: Hasat

Adım 6: Saldırgan, hasat işlemi 0x2be870...cf3e65'te tüm sahte tokenlar üzerinde withdraw() çağrısı yaparak tüketilmemiş izinleri kullandı ve transferFrom aracılığıyla botun gerçek bakiyelerini saldırgana taşıdı. Blok dahil edilmesini sağlamak için 0,01 ETH inşaatçı rüşveti eklendi. Hasat, yalnızca kurban sözleşmesinden 1.474,58 WETH + 2.870.573 USDC + 2.035.760 USDT (~7,5 milyon dolar) çıkardı.

Tespit edilen saldırı işlemi ~7,5 milyon dolar kayba yol açmaktadır ve jaredFromSubway'in açıklamasına [1] göre toplam kayıp yaklaşık 15 milyon dolardır.

Sonuç

Bu olayın temel nedeni, MEV botunun güvenilmeyen sözleşmelerle etkileşimde bulunurken hatalı onay yönetimiydi. Saldırganların güvenilen DeFi sözleşmelerindeki açıklardan yararlanarak kullanıcı onaylı varlıkları boşalttığı geleneksel onay istismarlarının aksine, bu saldırı ters yönde çalışır: bot, arbitraj operasyonlarının bir parçası olarak kendi varlıklarını proaktif biçimde güvenilmeyen üçüncü taraf sözleşmelere onayladı. Saldırgan, bu dışa dönük tüketilmemiş onayları biriktirerek tek bir işlemde hasat etti.

Gelecekte benzer riskleri azaltmak için güvenilmeyen token sözleşmeleriyle etkileşim kuran bot sözleşmeleri, her işlem sonrasında onayların tüketildiğini doğrulayarak artık kalan izinleri iptal etmelidir. Başarılı görünen bir işlem sonrasında tüketilmemiş izinler, kötü amaçlı token davranışının güçlü bir işaretidir.

Bu Haftaki Diğer Olaylar

Aztec

18 Haziran 2026'da Aztec'in kaçış kapısı ZK devresindeki eksik eşitlik kısıtlaması, bir saldırganın Ethereum üzerindeki eski RollupProcessor sözleşmesinden yaklaşık 2,2 milyon dolar (1.158 ETH, 150 bin DAI ve ~0,47 renBTC) çekmesine olanak tanıdı [2], [3]. Bu, üç gün içinde yaşanan ikinci Aztec istismarıydı (ilki, önceki raporumuzda ele alınan ve yükseltilmiş RollupProcessorV3'ü hedef alan istismar) ve ilgili bir ZK devre genel girdi bağlama hatası aracılığıyla gerçekleşti.

Arka Plan

Aztec'in eski RollupProcessor'ı bir escapeHatch işlevi içerir: rollup operatörü işlemeyi durdurduğunda herkesin tek işlemli bir kanıt göndermesine olanak tanıyan bir güvenlik mekanizması. Yetkili bir sağlayıcı gerektiren processRollup'ın aksine, kaçış kapısı blok numarasına dayalı periyodik pencerelerde açılır ve herkes tarafından çağrılabilir:

function escapeHatch(
    bytes calldata proofData,
    bytes calldata signatures,
    bytes calldata viewingKeys
) external override whenNotPaused {
    (bool isOpen, ) = getEscapeHatchStatus();
    require(isOpen, 'Rollup Processor: ESCAPE_BLOCK_RANGE_INCORRECT');
    processRollupProof(proofData, signatures, viewingKeys);
}

Kaçış kapısı, özel bir ZK devresi (escape_hatch_circuit) kullanır. Bu devre, Merkle ağacından girdi notlarını tüketen ve çıktı notları oluşturan bir birleştirme-bölme işlemi gerçekleştirir. Devre, girdi notlarının mevcut veri ağacında var olduğunu doğrulamalıdır (Merkle üyeliği için old_data_root kullanarak), ardından aynı kökü L1 sözleşmesinin zincir içi duruma karşı doğrulaması için genel bir girdi olarak açığa çıkarmalıdır.

Güvenlik Açığı Analizi

Güvenlik açığı, kaçış kapısı devresindedir (escape_hatch_circuit.cpp). old_data_root değeri, aralarında hiçbir eşitlik kısıtlaması olmaksızın iki bağımsız tanığa dönüştürülür.

İlk tanık (satır 33), birleştirme-bölme devre bileşenine aktarılır; burada girdi notlarının veri ağacında var olduğunu doğrulamak için Merkle üyeliği kanıtlarında kullanılır:

join_split_inputs inputs = {
    // ...
    witness_ct(&composer, tx.js_tx.old_data_root),        // satır 33: birinci tanık
    // ...
};
auto outputs = join_split_circuit_component(composer, inputs);

İkinci tanık (satır 50) bağımsız olarak oluşturulur ve genel girdi olarak açığa çıkarılır (satır 88); Solidity sözleşmesi bunu zincir içi veri köküne karşı çıkarır ve kontrol eder:

auto old_data_root = field_ct(witness_ct(&composer, tx.js_tx.old_data_root));  // satır 50: ikinci tanık
// ...
composer.set_public_input(old_data_root.witness_index);    // satır 88: genel girdi olarak açığa çıkarıldı

Bir ZK devresinde her witness_ct çağrısı bağımsız bir değişken oluşturur. Satır 33 ile 50 arasında açık bir assert_equal olmaksızın, kanıtlayıcı bu iki tanığa farklı değerler atayabilir. Solidity tarafında validateMerkleRoots, yalnızca satır 50'deki genel girdiden gelen değeri kullanarak require(oldDataRoot == dataRoot) kontrolü yapar; satır 33'te kullanılan değere hiçbir erişimi yoktur.

Aynı bağlama sorunu input_owner ve output_owner için de mevcuttur: bu değerler satır 38–39'da (sahiplik doğrulaması için join_split_circuit_component'e aktarılan) ve yeniden satır 111–112'de (bağımsız genel tanıklar olarak açığa çıkarılan) tanıklanmaktadır. Ancak bu boşluk için pratik bir istismar yolu tespit edemedik.

Saldırı Analizi

Kaçış kapısı devresi aztec-connect kod tabanından kaldırıldı [4], ancak dağıtılmış doğrulayıcı sözleşmesi hâlâ EscapeHatchVk doğrulama anahtarını içerdiğinden, savunmasız devre ile oluşturulan kanıtlar zincir içi doğrulamayı geçmeye devam edebilir. Saldırı sırasında sözleşme 142 gündür sessizdi ve kaçış kapısı penceresi açıktı. Saldırganın adresi, Union Chain [2] aracılığıyla istismardan yalnızca 14 saat önce oluşturulmuştu. Saldırı üç temel adımdan oluşmaktadır:

Adım 1: Saldırgan, isteğe bağlı değerlerde kendi sahip olduğu notları içeren sahte bir Merkle ağacı oluşturdu. Bu notlar gerçek zincir içi veri ağacında (tüm geçerli notları saklayan Merkle ağacı) mevcut değildi.
Adım 2: Saldırgan, yukarıda açıklanan bağlanmamış tanıkları istismar eden bir kaçış kapısı kanıtı oluşturdu. Satır 33'ün tanığı (birleştirme-bölme bileşeninde Merkle üyeliği için kullanılan), sahte Merkle köküne ayarlandı (üyelik kontrolü başarılı oldu çünkü uydurma notlar sahte ağaçta mevcuttu ve sahiplik kontrolleri başarılı oldu çünkü saldırgan imzalama anahtarlarını elinde bulunduruyordu). Satır 50'nin tanığı (Solidity tarafından kontrol edilen genel girdi olarak açığa çıkarılan), gerçek zincir içi veri köküne ayarlandı (Solidity'nin require(oldDataRoot == dataRoot) kontrolü başarılı oldu çünkü bu değer sözleşmenin depoladığı kökle eşleşiyordu).
Adım 3: Hem devre hem de Solidity kontrolleri karşılandığından kanıt başarıyla doğrulandı. Sözleşme kaçış kapısı işlemini meşru olarak işledi ve fonları serbest bıraktı.

Saldırgan bu süreci üç işlem boyunca tekrarladı (0x9e1d6a...6b03ca, 0xab306c...59c2b5, 0x5c196c...4705c3); farklı varlıkları hedef alarak sırasıyla 1.158 ETH, 150 bin DAI ve ~0,47 renBTC çıkardı ve toplamda yaklaşık 2,2 milyon dolara ulaştı.

Sonuç

Bu olayın temel nedeni, kaçış kapısı devresinde old_data_root için iki tanık arasındaki eksik eşitlik kısıtlamasıydı. Bir tanık, birleştirme-bölme bileşeni içinde özel not üyeliği doğrulaması için kullanılırken, diğeri Solidity tarafından kontrol edilen genel girdi olarak açığa çıkarıldı. Onları bağlayan bir kısıtlama olmaksızın, saldırgan L1 sözleşmesi geçerli bir zincir içi kök görürken sahte bir Merkle ağacına karşı uydurma notların sahipliğini kanıtladı. Önemli bir husus olarak, savunmasız devrenin kaynaktan kaldırılması hâlihazırda dağıtılmış doğrulayıcı sözleşmesini etkisiz hâle getirmedi — eski RollupProcessor üzerindeki escapeHatch işlevi, blok numarası penceresi açık olduğunda çağrılabilir olmaya devam etmektedir.

Gelecekte benzer riskleri azaltmak için, aynı mantıksal değer bir ZK devresinde birden fazla noktada göründüğünde tüm örnekler açıkça eşit olacak şekilde kısıtlanmalıdır — aynı değer için bağımsız witness_ct çağrıları bir bağlama boşluğudur. Devre denetimleri, her genel girdinin temsil ettiği devre içi değere bağlı olduğunu sistematik biçimde doğrulamalıdır.

Kaynaklar

BlockSec Hakkında

BlockSec, tam yığın blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokoller 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 birçok blok zinciri güvenlik makalesi yayımlamış, çeşitli DeFi uygulamalarına yönelik sıfır gün saldırılarını raporlamış, 20 milyon doların üzerinde varlığı kurtarmak için birçok saldırıyı engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.