Haftalık Web3 Güvenlik Olayları Özeti | 9 Şubat

Geçtiğimiz hafta boyunca (9 Şubat–15 Şubat 2026), BlockSec üç saldırı olayını tespit ederek analiz etti; toplam tahmini kayıplar yaklaşık 657.000 $'dır. Aşağıdaki tablo bu olayları özetlemekte olup her bir olay için ayrıntılı analizler sonraki alt bölümlerde verilmektedir.

Tarih	Olay	Tür	Tahmini Kayıp
2026/02/10	Bilinmeyen Olay	Hatalı İş Mantığı	~$10K
2026/02/14	`OCA` Olayı	Hatalı İş Mantığı	~$422K
2026/02/14	`SOF` Olayı	Hatalı İş Mantığı	~$225K

1. Bilinmeyen Olay

Kısa Özet

10 Şubat 2026'da BNB Smart Chain üzerindeki 0x560d39 sözleşmesi istismar edildi ve tahmini ~$10K kayıp oluştu. Temel neden, 0xb1a87f2c() fonksiyonundaki hatalı iş mantığıydı; bu durum likidite ekleme sürecini bir sandviç saldırısına karşı savunmasız bıraktı.

Arka Plan

0x560d39 sözleşmesindeki 0xb1a87f2c() fonksiyonu, giriş parametresine göre kullanıcıdan karşılık gelen miktarda USDT aktarır. Alınan USDT işlenir ve toplamın %85'i sonraki likidite işlemleri için ayrılır.

Bu %85'lik kısımdan yarısı, bir PancakeSwap havuzu aracılığıyla AFX ile takas edilir ve elde edilen AFX, 0x671ce4 sözleşmesine aktarılır. Fonksiyon daha sonra 0x671ce4'ten AFX çeker.

Ardından PancakeSwap V2 Router aracılığıyla kalan %85'lik USDT'nin yarısı ve 0x671ce4'ten çekilen AFX, USDT-AFX işlem çiftine likidite eklemek için kullanılır. Kalan USDT veya AFX, kullanıcıya iade edilir.

USDT–AFX likidite eklemesi tamamlandıktan sonra fonksiyon, 0x146933 adresinden ek AFX token'ları alır. 0x146933'ten çekilen AFX miktarı, daha önce 0x671ce4'ten çekilen miktarla eşleşecek şekilde ayarlanır. Sonra fonksiyon, PancakeSwap V2 AFX–AHT likidite havuzundaki mevcut fiyat oranına göre gereken AHT miktarını hesaplar. Ardından 0x146933'ten elde edilen AFX'i ve karşılık gelen AHT miktarını (aynı zamanda 0x146933'ten temin edilen) AFX–AHT işlem çiftine likidite eklemek için kullanır.

Güvenlik Açığı Analizi

Savunmasız sözleşme 0x560d39'dur. 0x146933 sözleşmesi, AFX-AHT likidite eklemesinde kullanılan AFX'in finansman kaynağı olarak görev yapar ve nihai kaybı üstlenir.

Temel neden, 0x560d39'daki 0xb1a87f2c() fonksiyonunun hatalı iş mantığında yatmaktadır. 0x671ce4 sözleşmesi aracılığıyla USDT takasından elde edilen AFX alınırken fonksiyon, takasın öncesinde ve sonrasında 0x671ce4'teki AFX bakiye değişimini doğrulamaz. Bunun yerine 0x671ce4'in elindeki tüm AFX'i çeker.

Bu durum, bir saldırganın önceden 0x671ce4'e büyük miktarda AFX bağışlamasına ve ardından yalnızca küçük miktarda USDT ile 0xb1a87f2c()'yi çağırmasına olanak tanır. 0x146933'ten çekilen AFX miktarı, 0x671ce4'ten çekilen AFX ile eşleşecek şekilde tanımlandığından, 0x671ce4'ten yapılan çekimi şişirmek, 0x146933'ü AFX-AHT likidite eklemesine şişirilmiş miktarda AFX katkıda bulunmaya zorlar.

Saldırgan, 0x560d39'dan kalan USDT ve AFX'in iadesiyle bağışını geri alabilirken 0x146933 aşırı büyük likidite sağlamanın maliyetini üstlenir.

Saldırgan daha sonra AFX-AHT likidite eklemesini sandviçleyerek, kurban işlemi etrafında önce AFX'ten AHT'ye takas yaparak öne geçip ardından AHT'den AFX'e takas yaparak arkadan girerek kâr elde eder.

Saldırı Analizi

Saldırı işleminin temel adımları aşağıdaki gibi özetlenmektedir:

Adım 1: Saldırgan, PancakeSwap V2'de 1.130.500e18 AFX token'ı için flaş kredi kullandı.
Adım 2: Saldırgan, 511.965e18 AFX'i 0x671ce4 sözleşmesine aktardı.
Adım 3: Saldırgan, kalan AFX'i PancakeSwap V2'deki AFX-AHT havuzunda 52.316e18 AHT ile takas etti. AHT bir transfer ücretli token olduğundan, saldırgan sonuçta yalnızca 26.158e18 AHT aldı.
Adım 4: Saldırgan, 0x560d39 sözleşmesini çağırarak 0xb1a87f2c() fonksiyonunu 100 parametresiyle çalıştırdı. Fonksiyon, 0x671ce4'teki tüm AFX'i (saldırganın bağışladığı token'lar dahil) çektiğinden, hem USDT-AFX hem de AFX-AHT çiftlerine orantısız büyük miktarda likidite eklemeye çalıştı. Eşleştirilemeyen kalan USDT ve AFX, saldırgana iade edildi; bu da maliyetlerinin büyük bölümünü geri kazanmalarını sağladı.
Adım 5: Saldırgan, 26.158e18 AHT'yi 1.129.417e18 AFX ile takas etti.
Adım 6: Saldırgan, flaş krediyi geri ödedi ve kalan AFX'i USDT ile takas ederek ~$10K kâr etti.

Sonuç

Bu olay, 0x560d39 sözleşmesinin USDT takası yoluyla elde edilen AFX'i alırken 0x671ce4 sözleşmesindeki AFX bakiyesinin takastan önce ve sonra değişimini doğrulamadan doğrudan tüm AFX'i 0x671ce4'ten çekmesinden kaynaklandı.

2. OCA Olayı

Kısa Özet

14 Şubat 2026'da BNB Smart Chain üzerindeki bilinmeyen bir protokol istismar edildi ve ~$422K kayıp oluştu. Temel neden hatalı iş mantığıydı: bir takas tamamlandıktan sonra protokol, token'ları DEX'ten geri almak ve bunları çağırıcıya ile diğer belirlenen adreslere iade etmek için OCA Token sözleşmesindeki bir geri dönüşüm fonksiyonunu çağırır. Bu tek taraflı OCA Token çekimi, havuzun OCA rezervlerini yapay olarak düşürerek zincir üzerindeki fiyatını şişirir ve bir saldırganın havuzdan tekrar tekrar USDC akıtmasına olanak tanır.

Arka Plan

Protokol sözleşmesi (0xe0d5ec), kullanıcının belirlediği miktarda OCA'yı bir DEX'te USDC karşılığında satan sellOCA() fonksiyonunu (seçici 0x9c1dad28) sunar. OCA, deflasyonist bir "geri dönüşüm" mekanizması içerir: takastan sonra sözleşme, havuza yeni satılan OCA miktarını geri çeker ve bunu çağırıcıya ile diğer belirlenen adreslere yeniden dağıtır. USDC zaten ödenmiş olduğu halde OCA havuzdan çıkarıldığından, havuzun OCA rezervleri düşerken USDC rezervleri de düşük kalmaya devam eder; bu durum zincir üzerindeki OCA fiyatını yapay olarak yukarı iter.

Güvenlik Açığı Analizi

Temel güvenlik açığı, sellOCA()'daki takas sonrası geri alma işleminin tekrarlanabilir bir fiyat manipülasyonu ilkeli oluşturmasıdır. Her çağrının DEX havuzu üzerinde şu net etkisi vardır: havuz takas sırasında USDC kaybeder ve deflasyonist mekanizma havuzdan token'ları geri alırken OCA da kaybeder; çağırıcı ise takas gelirini USDC olarak alır ve yeniden dağıtım yoluyla OCA'yı geri kazanır. Havuzun OCA rezervleri, ticareti dengeleyecek herhangi bir USDC girişi olmaksızın azaldığından, her döngü DEX'teki OCA/USDC fiyatını yapay olarak şişirir. Bir saldırgan, OCA satın alarak, geri almayı tetiklemek için sellOCA()'yı çağırarak ve ardından geri kazanılan OCA'yı şişirilmiş fiyattan satarak bu süreci tekrarlayabilir; böylece havuzdan giderek artan miktarda USDC likidite akıtabilir.

Saldırı Analizi

Saldırı işleminin temel adımları aşağıdaki gibi özetlenmektedir:

Adım 1: 8.704.860e18 USDC için flaş kredi kullandı.
Adım 2: PancakeSwap'ta 8.704.860e18 USDC'yi 940.991e18 OCA ile takas etti.
Adım 3: Tüm 940.991e18 OCA ile sellOCA()'yı çağırdı. Fonksiyon, OCA'yı DEX'te USDC karşılığında takas etti; ardından deflasyonist geri dönüşüm mekanizması, satılan OCA'yı havuzdan geri alarak yeniden dağıttı — OCA'yı çağırıcıya iade etti. Bunun sonucunda saldırgan, takasın USDC gelirini aldı ve aynı zamanda OCA token'larını geri kazandı. Havuzun OCA rezervleri keskin biçimde düştü ve OCA fiyatı şişirildi.
Adım 4: Geri kazanılan 940.991e18 OCA'yı, şu anda şişirilmiş fiyattan PancakeSwap'ta tekrar USDC'ye takas etti ve havuzu aşamalı olarak boşaltmak için 2-4. adımları tekrarladı.
Adım 5: Son iterasyonda saldırgan, yalnızca 9.999e18 OCA'yı 433.238e18 USDC karşılığında takas etti (büyük ölçüde şişirilmiş OCA fiyatını yansıtarak), ardından flaş krediyi geri ödeyerek saldırıyı tamamladı.

Sonuç

Bu saldırının temel nedeni, protokolün sellOCA akışındaki mantık hatasıydı: kullanıcı tarafından sağlanan OCA'yı USDC karşılığında takas ettikten sonra sözleşme, OCA'nın deflasyonist ``kurtarma'' mekanizması aracılığıyla DEX'ten OCA girdisinin esasen tamamını geri alarak çağırıcıya ve diğer belirlenen adreslere yeniden dağıttı. Bu takas sonrası geri alma, likidite havuzunda kalan OCA bakiyesini yapay olarak azalttı ve OCA'nın zincir üzerindeki fiyatının keskin biçimde yükselmesine neden oldu. Saldırgan, "OCA satın al → geri almayı tetiklemek için sellOCA çağır → OCA'yı şişirilmiş fiyattan geri sat" döngüsünü tekrar tekrar uygulayarak nispeten az OCA ile neredeyse tüm USDC likiditesini çekmeyi başardı.

3. SOF Olayı

Kısa Özet

14 Şubat 2026'da BNB Smart Chain üzerindeki SOF token'ı, _update() mantığındaki hatalı beyaz liste mekanizması ve ücret muafiyet sistemi nedeniyle ~$225K'lık bir saldırıya uğradı. Güvenlik açığı, bir saldırganın ücret muaf adres kullanarak satın alma kısıtlamalarını atlamasına olanak tanıdı; bu durum ardından Uniswap V2 (PancakeSwap) havuz rezervlerini manipüle eden bir satışta yakma mekanizmasını tetikledi. Havuzu kendi token'larını bir yakma adresine aktarmaya zorlayarak ve hemen ardından sync() çağırarak saldırgan, token fiyatını yapay olarak şişirdi. Bu sayede manipüle edilmiş kurdan küçük miktarda SOF takas ederek havuzdan USDT akıtılabildi. Saldırı ayrıca tx.origin'i takip etmeyi başaramayan yetersiz bir flaş kredi koruması tarafından kolaylaştırıldı; bu durum saldırının satın alma ve satış aşamalarının birden fazla adres kullanılarak aynı işlem içinde gerçekleşmesine izin verdi.

Arka Plan

SOF, BNB Smart Chain'de dağıtılmış, özel deflasyonist mekanikler ve otomatik ücret yönetimiyle tasarlanmış bir BEP-20 token'dır. Token, işlem kolaylığı için bir Uniswap V2 uyumlu likidite çiftiyle (özellikle USDT ile PancakeSwap) etkileşime girer.

Ücret muaf kullanıcılar için alım ve satım işlemleri ücretsizdir. Diğer tüm kullanıcılar için alım işlemleri kısıtlıdır ve geri döndürülür.

Satım işlemleri sırasında sözleşme, satım miktarının %90'ını doğrudan çiftten _destroyAddress'e aktarır ve azalan bakiyeyi hemen yansıtmak için sync() çağırarak rezervleri günceller.

Güvenlik Açığı Analizi

Temel neden, 0x1f3863 sözleşmesinin 438. satırındaki _update() fonksiyonundaki hatalı beyaz liste mekanizmasından kaynaklanmaktadır. to adresi beyaz listedeyse, herhangi bir from adresi alım işlemini gerçekleştirebilir.

 /// SOF.sol:433-480
433|      function _update(
434|          address from,
435|          address to,
436|          uint256 amount
437|      ) internal override {
438|          if (isExcludedFromFees[to] || isExcludedFromFees[from]) {
439|              super._update(from, to, amount);
440|              return;
441|          }
442|  
443|          require(!_blackList[from] && !_blackList[to], "refuse address");
444|  
445|          if (!inSwap && _isPairs[to]) {
446|              if (feeAmount1 >= swapTokensAtAmount) {
447|                  swapTokenForUsdt(feeAmount1, feeAddress);
448|                  feeAmount1 = 0;
449|              }
450|              if (feeAmount2 >= swapTokensAtAmount) {
451|                  swapTokenForUsdt(feeAmount2, feeAddress2);
452|                  feeAmount2 = 0;
453|              }
454|          }
455|  
456|          bool isSell;
457|          uint256 taxAmount;
458|  
459|          if (_isPairs[from]) {
460|              //buy
461|              revert("not alw buy");
462|          } else if (_isPairs[to]) {
463|              //sell
464|  
465|              isSell = true;
466|              taxAmount = takeFee(from, amount);
467|              super._update(_uniswapV2Pair, _destroyAddress, amount - taxAmount);
468|              IUniswapV2Pair(_uniswapV2Pair).sync();
469|          }
470|  
471|          emit TranserFeeLog(amount, taxAmount);
472|  
473|          if (isSell) {
474|              _antiFlashloanGuard(from, to, false, isSell);
475|          }
476|  
477|          amount = amount - taxAmount;
478|  
479|          super._update(from, to, amount);
480|      }

Saldırı Analizi

Saldırı işleminin temel adımları aşağıdaki gibi özetlenmektedir:

Adım 1: Saldırgan, 2. adım için 315.520.309e18 USDT flaş kredisi kullandı ve 3. adım için 0xc4DB5B adresine 875e18 SOF aktardı.
Adım 2: swapTokensForExactTokens() aracılığıyla 313.567.718e18 USDT'yi 991.223e18 SOF ile takas etti. to adresi, SOF sözleşmesindeki isExcludedFromFees[to] kontrolünü karşılayan ücret muaf bir adresdi; bu sayede alım işlemini geri döndürecek olan _isPairs[from] kontrolü atlandı. Bu, saldırganın 3. adımda havuzdaki neredeyse tüm SOF token'ını yakmasına olanak tanır. Aynı zamanda _antiFlashloanGuard() kontrolünü de atlar — sözleşme bu alım işlemini kayıt etmediğinden 3. adımın engellenmeden ilerlemesine izin verir. Kritik biçimde, bu büyük ölçekli alım, çiftte yalnızca 787e18 SOF bırakacak şekilde tasarlandı (bununla birlikte 313.816.344e18 USDT de bulunmaktaydı).
Adım 3: 0xc4DB5B adresinden, swapExactTokensForTokensSupportingFeeOnTransferTokens() aracılığıyla 875e18 SOF'u USDT karşılığında takas etti. PancakeSwap Router V2 önce SOF.transferFrom() çalıştırır, ardından takası işler. SOF.transferFrom() sırasında _update()'deki satış mantığı, 875e18'in %90'ını (yani 787e18'i) çiftten _destroyAddress'e aktarır — bu, 2. adımda tasarlandığı üzere çiftin neredeyse tüm SOF bakiyesiydi. Bu yakma ve sync() işleminden sonra çift, 313.816.344e18 USDT ve yalnızca 10e9 SOF tutuyordu. SOF fiyatı astronomik biçimde şişirildiğinde, ardından gerçekleştirilen takas büyük miktarda USDT ödemesi sağladı.
Adım 4: Saldırgan flaş krediyi geri ödedi ve ~$225K kâr elde etti.

Sonuç

Bu güvenlik açığı, satıştan önce yakma mekanizmasını destekleyen token'larda, token'ı kimin satın alabileceğini kontrol etmenin kritik önem taşıdığını göstermektedir. Token'ı satma yeteneğine sahip herkes kâr edebilir; bir saldırgan havuzdan token satın alabiliyorsa fiyatı yapay olarak şişirebilir ve tüm havuzu boşaltmak için geri takas yapabilir.

Soruşturmada _antiFlashloanGuard() fonksiyonunun hatalı uygulandığı tespit edildi. Fonksiyon yalnızca aynı msg.sender'ın alım ve satım yapmasını kısıtlamakta; tx.origin'i takip etmemektedir. Bu durum, bir saldırganın alım işlemi sırasında ücret muaf bir adresi to (alıcı) adresi olarak seçerek korumayı atlamasına olanak tanır.

Benzer saldırıları önlemek için geliştiricilerin yalnızca yetkili rollerin havuzdan satın alabilmesini sağlaması gerekir. Ayrıca _antiFlashloanGuard() uygulaması, saldırganların aynı işlem içinde birden fazla adres kullanarak alım ve satım işlemi gerçekleştirmesini önlemek amacıyla hem tx.origin'i hem de kullanıcı adresini kayıt altına almalıdır.

BlockSec Hakkında

BlockSec, tam kapsamlı bir blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin kod denetimi gerçekleştirmesine (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engellenmesine, olayları analiz etmesine, yasadışı fonları izlemesine ve protokollerle platformların tam yaşam döngüsü boyunca AML/CFT yükümlülüklerini karşılamasına yardımcı ürün ve hizmetler geliştiriyoruz.

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenliği 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 saldırıyı engellemiş ve milyarlarca dolarlık kripto parayı güvence altına almıştır.