Back to Blog

Haftalık Web3 Güvenlik Olayları Özeti | 23 Şub – 1 Mar 2026

Code Auditing
March 4, 2026
12 min read

Geçen hafta (2026/02/23 - 2026/03/01), BlockSec toplamda yedi saldırı olayını tespit edip analiz etti; toplam tahmini kayıplar yaklaşık 13 milyon dolar'dır. Aşağıdaki tablo bu olayları özetlemekte olup her bir olayın ayrıntılı analizi sonraki alt bölümlerde sunulmaktadır.

Tarih Olay Tür Tahmini Kayıp
2026/02/22 LAXO Olayı Token tasarım hatası ~$137K
2026/02/22 YieldBloxDAO Olayı Oracle yanlış yapılandırması ~$10M
2026/02/23 STO Olayı Token tasarım hatası ~$16,1K
2026/02/25 HedgePay Olayı Hatalı iş mantığı ~$15,7K
2026/02/26 Ploutos Olayı Oracle yanlış yapılandırması ~$390K
2026/02/26 FOOMCASH Olayı Hatalı iş mantığı ~$2,26M
2026/02/27 Bilinmeyen Olay Hatalı girdi doğrulaması ~$180K

1. LAXO Olayı

Kısa Özet

22 Şubat 2026'da BNB Smart Chain üzerindeki LAXO ERC20 token'ı istismar edildi ve LAXO-USDT çiftinden yaklaşık 137.320 dolarlık kayba yol açıldı. Temel neden, LAXO doğrudan PancakeSwap çiftine transfer edildiğinde tetiklenen hatalı bir yakma mekanizmasıydı. Router beyaz listeye alındığından transfer() içindeki yakma mantığını tetiklemediği için saldırgan bunu devre dışı bıraktı: LAXO'yu çifte gönderdi ve ardından çiftin düşük seviyeli swap() fonksiyonunu çağırdı; bu işlem çift token'larını yaktı ve sync() fonksiyonunu çağırarak fiyatı yapay olarak şişirdi. Ardından saldırgan kâr elde etmek için USDT'ye geri dönüştürdü.

Arka Plan

LAXO token'ı bir yakma mekanizması uygular. Bir transferin alıcısı USDT–LAXO PancakeSwap çift adresi olduğunda, token bunu bir satış olarak değerlendirir: çiftten karşılık gelen miktarda token'ı yakar ve rezervleri güncellemek için sync() fonksiyonunu çağırır.

Ayrıca LAXO token'ı, belirli adresleri (ör. takas yönlendiricileri) yakma mekanizmasından ve ücretlerden muaf tutmak için bir beyaz liste (_isExcludedFromFee) uygular.

Güvenlik Açığı Analizi

Olayın temel nedeni, LAXO token'ındaki hatalı yakma mekanizmasıydı. Özellikle, LAXO'nun doğrudan çifte transfer edilmesi yakmayı tetikleyerek LAXO'yu çiftten kaldırır ve fiyatını yapay olarak şişirir. Sonuç olarak, bir saldırgan bunu fiyat manipülasyonu saldırıları yoluyla kâr elde etmek için kullanabilir.

Saldırı Analizi

Saldırı analizi, 0xd58f3ef6...d98ac7d3 işlemine dayanmaktadır.

  1. Saldırgan, PancakeSwap V3'ten 350.000e18 USDT flash kredi aldı.

  2. Saldırgan, PancakeSwap Router aracılığıyla USDT'yi LAXO'ya dönüştürdü. İşlem kısıtlamalarını (buyEnabled = false) ve ücret mantığını aşmak için saldırgan bir BNB–LAXO V2 çifti oluşturdu ve işlemleri bu çift üzerinden yönlendirdi.

  1. Saldırgan, elindeki tüm LAXO'yu doğrudan USDT–LAXO çiftine transfer etti. Bu işlem, havuzdaki LAXO rezervini azaltırken USDT rezervi neredeyse değişmedi ve USDT–LAXO çiftinde LAXO fiyatı dramatik biçimde yükseldi.

  2. Saldırgan, manipüle edilmiş fiyat üzerinden burnAmount kadar LAXO'yu yaklaşık 487.500e18 USDT ile takas etti.

  3. Saldırgan flash krediyi geri ödedi ve kalan USDT'yi kâr olarak elde tuttu.

Sonuç

Bu olayın temel nedeni, saldırganların fiyat manipülasyonu saldırıları yoluyla havuzdan USDT çekmesine olanak tanıyan LAXO'nun hatalı yakma mekanizmasıdır. Sonuç olarak olay, yaklaşık 137,3 bin dolarlık toplam kayba yol açmıştır. Bu tür sorunları azaltmak için proje, potansiyel fiyat manipülasyonu saldırılarını önlemek adına yakma mekanizmalarını kapsamlı biçimde test etmelidir.


2. YieldBloxDAO Olayı

Kısa Özet

22 Şubat 2026'da Stellar'ın Blend V2 üzerinde YieldBlox DAO tarafından işletilen bir borç verme havuzu istismar edildi ve 10 milyon doları aşan kayıplara yol açıldı [1]. Olay, akıllı sözleşmelerdeki bir açıktan değil, havuz operatörünün (YieldBlox DAO) yanlış yapılandırmasından kaynaklandı.

Özellikle saldırgan, SDEX'teki USTRY/USDC piyasasını manipüle etti. Havuzun yapılandırılmış Reflector oracle yolu manipüle edilmiş fiyatı kabul etti; bu durum USTRY'yi teminat olarak aşırı değerlendirdi ve saldırganın USDC ve XLM dahil olmak üzere havuz varlıklarını boşaltmasına olanak tanıdı.

Arka Plan

Stellar blok zincirinde Blend V2, kullanıcıların izole borç verme havuzları oluşturmasına olanak tanıyan bir likidite protokolüdür. Bu havuzlar, desteklenen bir dizi varlık için kullanıcılar arasında borç verme ve borç almayı kolaylaştırır. Özellikle bu olaydaki kurban havuz, kullanıcıların USTRY'yi teminat olarak kullanarak XLM ve USDC borçlanmasına izin vermektedir. Ayrıca havuz oluşturucu, oluşturma sırasında oracle sağlayıcısı olarak Reflector oracle [2]'ı belirtir. Reflector oracle tarafından sağlanan USTRY fiyatı, Stellar DEX'teki (yani SDEX) USTRY/USDC piyasasına göre her beş dakikada bir güncellenir [3].

Güvenlik Açığı Analizi

Temel neden, SDEX'teki likidite düşük USTRY/USDC piyasasındaki fiyat manipülasyonuydu; bu durum Reflector oracle'daki USTRY fiyatının savunmasız biçimde güncellenmesine yol açtı. Özellikle, USTRY/USDC piyasasındaki son derece sığ likidite nedeniyle saldırgan, normal emirleri tüketerek ve anormal emirler vererek USTRY fiyatını 100 kat şişirebildi. Bu şişirilmiş USTRY fiyatı daha sonra Reflector oracle'a yayıldı ve saldırganın aşırı değerlendirilmiş USTRY'yi teminat göstererek kurban havuzdaki tüm varlıkları (yani XLM ve USDC) borçlanmasına olanak tanıdı.

Saldırı Analizi

  1. (İşlem 1, 2) Saldırgan, SDEX'teki USTRY fiyatını 1,06 dolar'dan yaklaşık 107 dolar'a çıkardı. SDEX'teki USTRY/USDC piyasası son derece sığ olduğundan, saldırgan tüm normal emirleri tüketti ve ardından anormal emirler vererek piyasa fiyatını hızla yükseltti.
  1. (İşlem 3) Reflector oracle, manipüle edilmiş fiyatı SDEX'ten çekti ve fiyat akışını buna göre güncelledi.
  1. (İşlem 4, 5) Saldırgan, 12.881e7 USTRY teminat göstererek 1.000.196e7 USDC borçlandı. 7.png
  2. (İşlem 6, 7) Saldırgan, 14.987.610e7 USTRY teminat göstererek 6.124.927.810e7 XLM borçlandı.
  1. (İşlem 8, 9, 10) Son olarak saldırgan, boşalttığı varlıkları Base, BSC ve Ethereum dahil olmak üzere birden fazla zincire köprüledi.

Aşağıdaki tablolar, ilgili temel istismar işlemlerini ve dahil olan adresleri özetlemektedir.

Sonuç

YieldBloxDAO olayı önemli kayıplara yol açmış olsa da temel sorun karmaşık değildir: teminat değerlemesi, manipülasyona açık bir fiyata bağlıdır. Bu olay, borç verme protokollerinde fiyat bağımlılığının dikkatli biçimde seçilmesi ve izlenmesi gerektiğini hatırlatmaktadır.

Kaynaklar

[1] https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain

[2] https://reflector.network/

[3] SDEX'teki USTRY/USDC Piyasası


3. STO Olayı

Kısa Özet

23 Şubat 2026'da BNB Smart Chain üzerindeki PancakeSwap'ta bulunan bir STO-WBNB havuzu boşaltıldı ve yaklaşık 16,1 bin dolarlık kayba neden oldu. Temel neden, STO token'ındaki hatalı yakma mekanizmasıydı. Özellikle, kullanıcılar havuzda STO token'larını sattığında yakma mekanizması tetikleniyor, havuzdan STO token'larını yakıyor ve token fiyatını yapay olarak şişiriyordu. Sonuç olarak saldırgan, havuzdan WBNB token'larını boşaltmak için bu açıktan yararlandı.

Arka Plan

STO token'ı, PancakeSwap V2 havuzunu hedef alan bir yakma mekanizması sunar. Bu mekanizma yalnızca STO token'ının satış fonksiyonu etkinleştirildiğinde (yani sellEnabled == true) ve pendingBurnFromSell > 0 olduğunda tetiklenir. Bir kullanıcı STO token'larını sattığında mekanizma, havuzdan STO token'larını yakar. Özellikle, bir önceki işlemde satılan STO token'larının %94'ü yakma işlemi sırasında yakılır.

Güvenlik Açığı Analizi

Olayın temel nedeni, STO token'ındaki hatalı yakma mekanizmasıdır. Özellikle, bir kullanıcı STO token'larını sattığında, yakma mekanizması havuzdan belirli miktarda STO token'ı kaldırırken rezervleri güncellemek için çift sözleşmesinin sync() fonksiyonunu da çağırır. Bu yakma mekanizması, havuzdaki STO token'ının fiyatını şişirir. Sonuç olarak saldırganlar, bu mekanizmadan fiyat manipülasyonu saldırısı gerçekleştirerek kâr elde edebilir.

Saldırı Analizi

Aşağıdaki analiz, 0x8ba17bea...5a54020c işlemine dayanmaktadır.

  1. Saldırgan, flash kredi aracılığıyla 360.894e18 WBNB borçlandı.

  2. Saldırgan, STO token'ının alım ve satım işlevselliğini etkinleştirmek için initializeLiquidity() fonksiyonunu çağırdı.

  1. Saldırgan, 360.894e18 WBNB'yi 7.848.832e18 STO ile takas etti.

  2. Saldırgan, çiftin rezervlerini manipüle etmek (yani STO token'ının fiyatını artırmak) için yakma mekanizmasını tetikleyen transfer() fonksiyonunu çağırdı ve bir sonraki işlemde yakılacak STO token miktarını 173.391e18 olarak belirledi.

  1. Saldırgan, STO'yu WBNB ile takas etmek için swap() fonksiyonunu çağırdı. Bu adım, saldırganın manipüle edilmiş fiyat üzerinden kâr elde etmesini sağladı.

  2. Saldırgan, havuzun WBNB'sini boşaltmak için 4. ve 5. adımları tekrarladı.

  3. Saldırgan flash krediyi geri ödedi ve 26e18 WBNB kâr elde etti.

Sonuç

Bu olayın temel nedeni, saldırganların havuzdan WBNB çekmesine olanak tanıyan STO'nun hatalı yakma mekanizmasından kaynaklanmaktadır. Bu tür sorunları azaltmak için proje, sistem içinde uygun erişim kontrolleri uygulamalı ve potansiyel fiyat manipülasyonu saldırılarını önlemek amacıyla yakma mekanizmasını kapsamlı biçimde test etmelidir.


4. HedgePay Olayı

Kısa Özet

25 Şubat 2026'da BNB Smart Chain üzerindeki HedgePay protokolü istismar edildi ve yaklaşık 15,7 bin dolarlık kayba yol açıldı. Temel neden, HedgePay protokolünün stake sözleşmesindeki hatalı iş mantığıydı. Özellikle, savunmasız stake sözleşmesinin (yani 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) forceExit() fonksiyonu, kullanıcıların stake edilmiş bakiyelerini güncellemeden stake edilmiş varlıklarını çekmelerine olanak tanıyordu. Sonuç olarak saldırgan, sözleşmenin HPAY token'larını boşaltmak için forceExit() fonksiyonunu defalarca çağırabildi.

Arka Plan

HedgePay protokolü, kullanıcıların HPAY token'larını stake ederek ödül kazanmalarına olanak tanıyan bir stake protokolüdür. forceExit() fonksiyonu, kullanıcıların stake edilmiş varlıklarını çekmelerine imkân tanır.

Güvenlik Açığı Analizi

Olayın temel nedeni, forceExit() fonksiyonundaki hatalı iş mantığıdır. Özellikle, kullanıcılar stake() fonksiyonu aracılığıyla HPAY token'larını stake ettiğinde, stake edilen miktarları (yani _balances[msg.sender]) buna göre güncellenir. Ancak kullanıcılar forceExit() fonksiyonu aracılığıyla stake edilmiş HPAY token'larını çektiğinde, sözleşme _balances[msg.sender]'ı güncellemeyi başaramaz. Sonuç olarak saldırgan, forceExit() fonksiyonunu defalarca çağırarak stake sözleşmesindeki HPAY token'larını boşaltabilir.

Saldırı Analizi

Aşağıdaki analiz, 0x5f2ea6cb...46ed137f işlemine dayanmaktadır.

  1. Saldırgan, flash kredi aracılığıyla 1.247.859e18 HPAY borçlandı. Flash kredi geri çağırma fonksiyonunda:

    a.Saldırgan, stake() fonksiyonu aracılığıyla 1.197.944e18 HPAY stake etti.

    b.Saldırgan, sözleşmenin HPAY token'larını boşaltmak için forceExit() fonksiyonunu defalarca çağırdı.

  1. Saldırgan flash krediyi geri ödedi ve 57.389.615e18 HPAY'i 26e18 WBNB ile takas etti (yani 26e18 WBNB kâr etti).

Sonuç

Bu olayın temel nedeni, forceExit() fonksiyonunun kullanıcının _balances[msg.sender]'ını güncellememiş olmasıydı; bu da saldırganın stake sözleşmesindeki HPAY token'larını boşaltmasına olanak tanıdı. Bu tür sorunları önlemek için proje, durum değişmezlerinin her fonksiyonda doğru biçimde korunduğundan emin olmak amacıyla uygun durum odaklı testler gerçekleştirmelidir.


5. Ploutos Olayı

Kısa Özet

26 Şubat 2026'da Ethereum üzerindeki Ploutos protokolüne ait bir havuz, oracle yanlış yapılandırması nedeniyle yaklaşık 390.000 dolarlık kayba uğradı. Özellikle oracle, USDC için yanlışlıkla bir BTC/USD Chainlink fiyat akışı kullanacak şekilde ayarlandı. Sonuç olarak saldırgan, bu yanlış yapılandırmayı kullanarak yalnızca 8 USDC teminat göstererek 187 ETH borçlandı.

Güvenlik Açığı Analizi

Ploutos, birden fazla ağa dağıtılmış Aave v3.0.2'nin bir çatalıdır. Olay, borç verme havuzundaki (0xD060...F945D2) hatalı oracle yapılandırmasından kaynaklandı.

24538896 numaralı blokta, USDC için fiyat oracle'ı yanlışlıkla USDC/USD akışı yerine bir BTC/USD Chainlink akışına referans verecek şekilde yapılandırıldı. Sonraki blokta (24538897) saldırgan yanlış yapılandırmayı fark etti ve istismarı gerçekleştirdi. Sonuç olarak saldırgan, yaklaşık 8,88 USDC teminat göstererek yaklaşık 187,3 ETH kâr elde etti.

Saldırı Analizi

  1. Saldırgan, Ploutos protokolünün oracle yapılandırma işlemlerini izledi; bu işlemler 0xcfedf6...bd193ab6 işleminde USDC'nin oracle kaynağını yanlışlıkla Chainlink BTC/USDC Fiyat Akışı olarak belirledi.

  2. Saldırgan anında bir işlem gönderdi (0xa17dc37e...705f8474); bu işlem, oracle yanlış yapılandırması nedeniyle saldırganın yalnızca ~8,8 USDC teminat göstererek ~187,3 ETH borçlanmasına olanak tanıdı.

  3. Saldırgan, blok oluşturucuya ~5,6 ETH rüşvet ödedi ve net olarak ~181,7 ETH kâr elde etti.

Sonuç

Olayın temel nedeni, oracle yanlış yapılandırmasıydı ve yaklaşık 390.000 dolarlık kayba yol açtı. Bu olay, Oracle yapılandırması gibi hassas işlemlerin potansiyel kayıpları önlemek amacıyla çoklu imza cüzdanları veya zaman kilidi tarafından korunması gerektiğini hatırlatmaktadır.

Kaynaklar

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


6. FOOMCASH Olayı

Kısa Özet

26 Şubat 2026'da FOOMCASH protokolü, savunmasız bir Groth16 kanıt doğrulaması [1] nedeniyle istismar edildi ve toplam 2,26 milyon doları aşan kayıplara yol açıldı.

Arka Plan

FOOMCASH protokolü, çekim doğrulamaları için Groth16 kanıtlarını kullanan Base ve Ethereum üzerindeki bir piyango protokolüdür. FoomLottery sözleşmesinde collect() fonksiyonu, WithdrawG16Verifier.verifyProof() fonksiyonunu çağırarak sağlanan kanıtı (yani _pA, _pB ve _pC) doğrular. Özellikle doğrulama, WithdrawG16Verifier sözleşmesindeki güvenilir kuruluma (yani gamma ve delta) göre gerçekleştirilir. Kanıt geçerli olarak doğrulandıktan sonra collect() fonksiyonu, kullanıcı girdilerine (ör. _recipient ve _rewardbits) göre varlıkları (yani FOOM token'larını) transfer eder.

Güvenlik Açığı Analizi

Olayın temel nedeni, savunmasız bir Groth16 kurulumuydu. Özellikle WithdrawG16Verifier sözleşmesinde gamma (γ\gamma) ve delta (δ\delta) değişkenleri aynı değeri (yani G_2G\_{2}) paylaşıyordu; bu durum saldırganın rastgele girdilerle geçerli kanıtlar oluşturmasına olanak tanıdı. Sonuç olarak saldırgan, WithdrawG16Verifier sözleşmesindeki Groth16 kanıt doğrulamasını atladı ve kötü amaçlı girdilerle FoomLottery sözleşmesindeki tüm varlıkları boşalttı.

Saldırı Analizi

Saldırı analizi, 0xce204482...4e275e48 işlemine dayanmaktadır.

Saldırgan, geçerli bir kanıt ve kötü amaçlı girdiler oluşturmak için kötü amaçlı bir sözleşme oluşturdu. Kötü amaçlı sözleşmenin geri çağırma mantığında:

  1. Geçerli bir kanıt oluşturdu.

  2. FoomLottery sözleşmesinin collect() fonksiyonunu geçerli bir kanıt ve kötü amaçlı girdilerle (ör. _recipient ve _rewardbits) çağırdı.

a. collect() fonksiyonunun çağrısında, kanıt doğrulaması (yani WithdrawG16Verifier.verifyProof()) atlandı ve varlıklar (yani FOOM token'ları) saldırgana transfer edildi.

  1. 1-2. adımları 30 kez tekrarladı ve toplamda 19.695.576.757.802e18 FOOM token'ı boşalttı.

Sonuç

Olayın temel nedeni, savunmasız bir Groth16 doğrulama kurulumuydu ve yaklaşık 2,26 milyon dolarlık kayba yol açtı. Bu durum, karmaşık kriptografik kurulumların dağıtımdan önce kapsamlı biçimde incelenmesi ve denetlenmesi gerektiğini vurgulamaktadır.

Kaynaklar

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


7. Bilinmeyen Olay

Kısa Özet

27 Şubat 2026'da BNB Smart Chain üzerindeki bilinmeyen bir sözleşme istismar edildi [1] ve yaklaşık 180 bin dolarlık kayba yol açıldı. Bu olayın temel nedeni, hatalı girdi doğrulamasıydı. Özellikle, kurban sözleşmenin _verifySignatures() fonksiyonu boş liste kontrolü gerçekleştirmedi; bu durum saldırganın imza ve imzalayanlar sağlamadan imza doğrulamasını atlamasına olanak tanıdı. Sonuç olarak saldırgan, bu açığı kullanarak kurban sözleşmedeki tüm USDT token'larını boşalttı.

Güvenlik Açığı Analizi

Bu olayın temel nedeni, imza doğrulama akışındaki hatalı doğrulamadır. Özellikle _verifySignatures() fonksiyonu yalnızca allSigners.length == signatures.length kontrolü yapar ve her iki dizinin de boş olmadığını zorunlu kılmaz. Sonuç olarak her iki dizi de boş olduğunda saldırgan, imza doğrulamasını atlayarak varlıkları çekebilir.

Saldırı Analizi

Aşağıdaki analiz, 0x91f45260...41cfd784 işlemine dayanmaktadır.

  1. Saldırgan, kötü amaçlı sözleşmelerinin 0x2d0cb456() fonksiyonunu çağırdı. Bu çağrıda,

a. Kötü amaçlı sözleşme, boş allSigners ve signatures girdileriyle poolWithdraw() fonksiyonunu çağırdı ve amaçlanan imza doğrulama mantığını atlattı.

b. İmza doğrulama mantığını atladıktan sonra kurban sözleşme, USDT'yi saldırgana transfer etti.

Sonuç

Bu olayın temel nedeni, hatalı girdi doğrulamasıydı ve yaklaşık 180 bin dolarlık kayba yol açtı. Olay, girdiler için boş olmayan kontroller gibi temel sınır denetimlerinin önemini vurgulamaktadır.

Kaynaklar

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


BlockSec Hakkında

BlockSec, tam yığın bir blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokoller ve platformların tüm yaşam döngüsü boyunca kod denetimi (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil) yapmasına, 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ünler ve hizmetler geliştiririz.

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenlik makalesi yayımlamış, DeFi uygulamalarına yönelik birkaç sıfır gün saldırısını bildirmiş, 20 milyonun üzerinde dolarlık varlığı kurtarmak için birden fazla saldırıyı engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit