TürkTeam Portal

Siber güvenlik topluluğunun nabzı

Duyurular, öne çıkan konular ve topluluktan son haberler burada.

Duyurular
 postMessage Güvenliği: Storybook CVE-2026-114125 Üzerinden Origin Doğrulama
BilgeKagan 10-23-2026, 08:30 AM · Web Uygulama Güvenliği
0 21
[Resim: attachment.php?aid=375]

Selamlar,

Storybook ekibi CVE-2026-114125 (GHSA-f2ph-cmg5-wxc8, CVSS 4.0 9.4) ile ilgili danışmayı yayımladı: çalışan bir storybook dev sunucusunun preview iframe'i herhangi bir web sitesine gömülebiliyor ve her origin'den postMessage olayı kabul ediyordu. Kötü niyetli bir site, kullanıcı etkileşimiyle dev sunucusunun story dosyalarını değiştirmesini sağlayabiliyor; değişen dosya yerel bir runtime tarafından çalıştırılırsa geliştiricinin yetkisiyle kod çalışabiliyordu. Bu konu, olayı özetleyip kendi kodunuzda postMessage'ı nasıl güvenli kullanacağınızı anlatıyor.

Konuda anlatılacaklar
  1. Storybook açığının özeti ve yamalı sürümler
  2. postMessage nasıl çalışır?
  3. Hatalı ve doğru alıcı kodu
  4. Gönderen tarafta hedef origin
  5. Kontrol listesi

Storybook özeti
  • Etkilenen: Storybook 8, 9, 10 ve 11 alpha dev sunucuları (@storybook/addon-mcp ve @storybook/addon-vitest dahil).
  • Yamalı: 8.6.19, 9.1.21, 10.6.2, 11.0.0-alpha.6. Yükseltmeden storybook dev çalıştırmayın.
  • Etkilenmeyen: Build edilmiş statik Storybook'lar ve tarayıcıda hiç açılmayan dev sunucuları.
  • Yeni varsayılanlar: farklı host adına iframe gömme kapalı; preview ve manager yalnızca kendi origin'i ve localhost servisleriyle mesajlaşıyor. Eski davranış için security.insecureRemoteIframeEmbed ve security.insecureIframeMessaging bayrakları var ama ekip bunları önermiyor.
  • Danışmaya göre Chrome ve Firefox'un yeni sürümleri bir sitenin localhost'a bağlanmadan önce izin isteyebiliyor; güvenmediğiniz sitelere bu izni vermeyin.
CWE listesi de öğretici: CWE-346 (Origin Validation Error), CWE-1021 (iframe kısıtlaması), CWE-22 (path traversal), CWE-862 (eksik yetkilendirme). Yani tek bir hata değil, birkaç zayıf katmanın zinciri.

postMessage nasıl çalışır?
window.postMessage farklı origin'deki pencereler (ana sayfa ile iframe, açılan popup) arasında güvenli mesajlaşma için tasarlandı. Ama "güvenli" olması iki tarafın da kontrol yapmasına bağlı. MDN açıkça uyarıyor: mesaj alan taraf event.origin'i doğrulamazsa, herhangi bir site mesaj gönderebilir.

Hatalı alıcı
Kod:
// YANLIS: her origin'den gelen mesaja guveniyor window.addEventListener("message", (e) => { if (e.data.type === "updateFile") { saveFile(e.data.path, e.data.content); // tehlikeli islem } });

Doğru alıcı
Kod:
const ALLOWED = new Set(["https://app.ornek.com", "http://localhost:6006"]); window.addEventListener("message", (e) => { // 1) Origin'i tam eslesme ile dogrula (includes/startsWith kullanma) if (!ALLOWED.has(e.origin)) return; // 2) Kaynagin beklenen pencere oldugunu kontrol et if (e.source !== expectedFrame.contentWindow) return; // 3) Veriyi sema ile dogrula const d = e.data; if (typeof d !== "object" || d.type !== "setArgs") return; // 4) Tehlikeli islemleri mesajla tetikleme; yalnizca dar kapsamli UI durumu applyArgs(sanitize(d.args)); });
Sık hata: e.origin.includes("ornek.com") gibi kontroller; "ornek.com.saldirgan.net" bunu geçer. Her zaman tam eşleşme kullanın.

Gönderen taraf
Kod:
// YANLIS: "*" hedefi, mesaji kim yuklenmisse ona verir frame.contentWindow.postMessage(secretToken, "*"); // DOGRU: hedef origin'i acikca yaz frame.contentWindow.postMessage({type:"init"}, "https://widget.ornek.com");

Kontrol listesi
  1. Her message dinleyicisinde izin listesiyle tam origin eşleşmesi.
  2. Mesajla dosya yazma, komut çalıştırma, kimlik bilgisi aktarma gibi yan etkili işlem yapmayın.
  3. Gömülmesini istemediğiniz sayfalarda Content-Security-Policy: frame-ancestors 'self' kullanın.
  4. Geliştirme sunucularını (Storybook, Vite, Jupyter) yalnızca localhost'a bağlayın ve güncel tutun.
  5. Kod incelemesinde "addEventListener('message'" araması yapın.
Kod:
grep -rn "addEventListener(\s*['\"]message" src/ | head grep -rn "postMessage(.*['\"]\*['\"]" src/ | head

Kendi projelerinizde postMessage dinleyicilerini en son ne zaman denetlediniz? Bulduğunuz hatalı kalıpları paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 ABD Bankaları Üçüncü Taraf YZ Ajanlarını Engelliyor: Şifrenizi Ajana Vermeyin
Tonyukuk 10-23-2026, 08:29 AM · Yapay Zeka Güvenliği
0 21
[Resim: attachment.php?aid=374]

Selamlar,

Yapay zeka ajanlarının "bizim yerimize iş yapma" vaadi bankacılıkta ilk ciddi frenle karşılaştı. Axios'un 22 Ekim 2026 tarihli haberine ve Reuters'ın takibine göre ABD'nin büyük bankaları, müşteri hesaplarının içinde çalışan üçüncü taraf YZ ajanları tespit ediyor ve bunları engellemeye başladı.

Konuda anlatılacaklar
  1. Ne tespit edildi?
  2. Bankalar ne yapıyor?
  3. Asıl sorun: kimlik doğrulama ve yetki
  4. Bireysel kullanıcı için kurallar
  5. Geliştiriciler için: ajan erişimini doğru tasarlamak

Ne tespit edildi?
pwn.watch'ın Axios özetine göre Morgan Stanley, Bank of America, JPMorgan ve Wells Fargo gibi bankalar müşteri hesaplarında üçüncü taraf ajanlar görüyor. Çoğu durumda ajan, müşterinin kendi kullanıcı adı ve parolasıyla, müşterinin izniyle giriş yapıyor; bu da kişinin kendisinin giriş yapmasını şart koşan banka kurallarına aykırı. Bazı ajanların çağrı merkeziyle iletişime geçtiği veya kullanıcı talimatından bağımsız görünen işlemler yapmaya çalıştığı da raporlandı. Yöneticiler insanı ajandan, yetkili ajanı da başıboş ajandan çoğu zaman ayırt edemediklerini söylüyor.

Önemli: Şimdiye kadar hesap ele geçirme, dolandırıcılık kaybı veya belirli bir ajan ürünü raporlanmadı.

Bankaların tepkisi
Reuters'a göre:
  • Morgan Stanley üçüncü taraf ajanların platformlarına erişimini engelledi; kaynağa göre bankada yetkisiz veya başıboş ajan vakası görülmedi.
  • JPMorgan, Bank of America ve Citi ajan erişimini kısıtlıyor. JPMorgan CEO'su Jamie Dimon, "herhangi bir dış ajanın içeri girmesine izin vermeyeceğiz, bu müşteriler ve JPMorgan için fazla riskli" dedi.
  • Charles Schwab CEO'su Richard Wurster da yetkisiz ajanları engellediklerini ve her gün engelleme raporu aldığını söyledi.
  • Reuters'ın aktardığına göre müşteri kimlik bilgilerini kendisi paylaştığında bu işlemler teknik olarak "yetkisiz" sayılamayabiliyor. Bu da olası bir kayıpta sorumluluk tartışmasını karmaşıklaştırıyor.

Asıl sorun: kimlik doğrulama ve yetki
Parolayı ajana vermek, ajana sizin tüm yetkilerinizi vermek demek: para transferi, adres değişikliği, yeni alıcı ekleme. Ajan bir prompt injection'a maruz kalırsa (örneğin okuduğu bir web sayfasındaki gizli talimat), bu yetkileri saldırgan adına kullanabilir. Üstelik ajan sağlayıcısı ihlal edilirse parolanız da gider.

Bireysel kullanıcı için kurallar
  1. Banka kullanıcı adınızı, parolanızı veya SMS/uygulama onay kodlarınızı hiçbir YZ asistanına vermeyin.
  2. Bankanızın resmi olarak sunduğu entegrasyonlar dışında "hesaplarımı yönetsin" türü araçlardan uzak durun.
  3. Daha önce bir ajana parola verdiyseniz parolayı değiştirin ve bankadaki aktif oturumları kapatın.

Geliştiriciler için
Doğru model, parola paylaşımı değil; kapsamı daraltılmış, iptal edilebilir yetki devridir: OAuth tabanlı açık bankacılık API'leri, yalnızca okuma kapsamı, işlem başına insan onayı ve tutar limitleri. Ajanın her eylemi ayrı ve denetlenebilir bir kimlikle loglanmalı ki "bunu insan mı yaptı, ajan mı" sorusunun cevabı olsun. OWASP LLM Top 10'daki "Excessive Agency" maddesi tam olarak bu riski anlatıyor.

Siz finansal işlerde bir YZ asistanına ne kadar yetki verirdiniz? Sınırı nereye çiziyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Quest Diagnostics İhlali: Quanum Lab Portalında Hasta Kayıtlarına Erişildi
Tonyukuk 10-23-2026, 08:28 AM · Siber Güvenlik Haberleri
0 22
[Resim: attachment.php?aid=373]

Selamlar,

ABD'nin en büyük tıbbi test şirketlerinden Quest Diagnostics, 21 Ekim 2026'da Quanum Lab Services Manager (LSM) sistemine yetkisiz erişim olduğunu öğrendiğini açıkladı. Şirket bazı hasta kayıtlarına erişildiğine inanıyor ve korunan sağlık bilgisi (PHI) ile kişisel bilgilerin (PII) etkilendiğini doğruladı.

Konuda anlatılacaklar
  1. Quanum LSM nedir?
  2. Şirketin açıkladıkları
  3. Bilinmeyenler
  4. Sağlık verisi neden bu kadar değerli?
  5. Kurumlar için çıkarımlar

Quanum LSM nedir?
Bazı sağlık kuruluşlarının laboratuvar testi siparişi vermek, sonuçları almak ve sorgulamak için kullandığı web tabanlı portal. Yani doğrudan hasta adı, test türü ve sonuç bilgisini içeren bir sistem.

Şirketin açıkladıkları
AP News, Fox Business ve SecurityOnline'ın aktardığı bilgilere göre:
  • Quest, Quanum LSM erişimini durdurdu.
  • Önlem olarak Essential Insights ve LabHQ sistemlerine erişim de durduruldu; bunlarda veriye erişilmediği belirtiliyor.
  • Federal kolluk kuvvetleri bilgilendirildi, dış uzmanlar görevlendirildi.
  • Şirketin temel operasyonları önemli ölçüde etkilenmedi.
  • pwn.watch'a göre Quest, olayın PHP açıklarıyla ilgili olmadığını belirtti.

Bilinmeyenler
Etkilenen kişi sayısı ve hangi veri kategorilerinin etkilendiği henüz açıklanmadı; soruşturma sürüyor. Saldırının giriş noktası da paylaşılmadı. Bu tür olaylarda ilk açıklamadan sonra rakamların büyüdüğü sık görülür, takipte kalmakta fayda var.

Sağlık verisi neden değerli?
Kredi kartı iptal edilip yenilenebilir; test sonuçları, tanılar ve sağlık geçmişi değiştirilemez. Bu yüzden sağlık verisi hem şantaj hem hedefli dolandırıcılık için yüksek değerlidir. Etkilenen kişilere en sık gelen saldırı türü, "test sonucunuz hazır, görmek için giriş yapın" temalı oltalama ve sahte ödeme talepleridir.

Kurumlar için çıkarımlar
  • Müşteriye veya iş ortağına açık portallar (sipariş, sonuç, randevu) ana sistemler kadar sıkı izlenmeli: MFA, anormal sorgu hacmi alarmı, toplu dışa aktarma limitleri.
  • Olay anında ilgili diğer sistemleri önlem olarak durdurmak (Quest'in yaptığı gibi) yayılmayı sınırlar; bunun için önceden hazırlanmış bir izolasyon planı gerekir.
  • Türkiye'deki sağlık kuruluşları için de KVKK kapsamında özel nitelikli kişisel veri olan sağlık verisinde 72 saatlik bildirim yükümlülüğünü hatırlatmakta fayda var.

Sağlık sektöründe çalışanlar: sonuç portallarınızda hangi ek kontrolleri kullanıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Capcom ID Sızıntısı: 11,7 Milyon E-posta Adresi ve Son Giriş IP'leri Açığa Çıktı
Tonyukuk 10-23-2026, 08:27 AM · Siber Güvenlik Haberleri
0 10
[Resim: attachment.php?aid=372]

Selamlar,

Oyuncuları yakından ilgilendiren bir veri ihlali: Capcom, bazı oyunlarında çevrimiçi oynamak için gereken CAPCOM ID hesap sistemine üçüncü bir tarafın yetkisiz eriştiğini 22 Ekim 2026'da duyurdu. Dünya genelinde 11.774.247 kayıt etkilendi.

Konuda anlatılacaklar
  1. Hangi veriler açığa çıktı?
  2. Zaman çizelgesi
  3. Neler sızmadı?
  4. Neden "sadece e-posta" bile önemli?
  5. Oyuncular ne yapmalı?

Açığa çıkan veriler
Capcom'un resmi açıklamasına göre:
  • 11.774.247 kayıt: e-posta adresi, hesap oluşturma zamanı, son giriş zamanı, giriş sayısı ve son girişteki IP adresi.
  • 43 hesap: bunlara ek olarak doğum tarihi, cinsiyet, ülke/bölge ve takma ad.
  • 196 hesap: parolası izinsiz değiştirildi; bu hesapların parolaları Capcom tarafından sıfırlandı.

Zaman çizelgesi
  • 19 Ekim: Yetkisiz erişim tespit edildi.
  • 21 Ekim: Osaka Valiliği Polisi'ne ve Japonya Kişisel Bilgi Koruma Komisyonu'na (PPC) bildirildi.
  • 22 Ekim: Kamuya açıklama ve özür.

Neler sızmadı?
Capcom, müşterilerin belirlediği parolaların sızdığını doğrulamadığını ve kredi kartı verisinin etkilenmediğini belirtiyor. Yine de 196 hesapta parolanın izinsiz değiştirilmiş olması, saldırganın en azından bir kısım hesapta hesap üzerinde işlem yapabildiğini gösteriyor.

'Sadece e-posta' neden önemli?
E-posta + son giriş zamanı + IP birleşimi, ikna edici oltalama için ideal bir paket. Saldırgan şöyle bir mail atabilir: "Son girişiniz şu tarihte şu bölgeden yapıldı, onaylamıyorsanız tıklayın." Gerçek verilerle süslenmiş sahte bildirim, sıradan bir spamdan çok daha inandırıcıdır. pwn.watch da Capcom'u taklit eden oltalama beklendiği uyarısını yapıyor. Ayrıca son giriş IP'si kabaca konum bilgisi verir.

Oyuncular ne yapmalı?
  1. Capcom adına gelen e-postalardaki bağlantılara tıklamayın; siteye adres çubuğundan kendiniz girin.
  2. CAPCOM ID parolanızı başka yerde de kullandıysanız o hesaplarda da değiştirin.
  3. Bağlı platform hesaplarında (Steam, PlayStation, Xbox) iki adımlı doğrulamayı açın.
  4. "Ödül", "hesabınız kapatılacak", "ücretsiz DLC" temalı mesajlara özellikle şüpheyle yaklaşın.
E-posta adresiniz bir sızıntıda çıktığında adım adım ne yapılacağını anlatan ayrıntılı rehberi Virüs Temizleme ve Kişisel Güvenlik bölümünde paylaşıyoruz.

Capcom'dan bildirim maili aldınız mı? Gelen maillerin gerçek mi sahte mi olduğunu nasıl kontrol ettiğinizi yazın (kişisel bilgi paylaşmadan).

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Railway Ortam Değişkenleri İhlali: Tüm Kullanıcılara Acil Sır Rotasyonu Çağrısı
Tonyukuk 10-23-2026, 08:26 AM · Bulut Güvenliği
0 23
[Resim: attachment.php?aid=371]

Selamlar,

Geliştirici bulut platformu Railway, 21 Ekim 2026 sabahı müşteri ortam değişkenlerini (environment variables) saklayan sistemlerde anormal etkinlik tespit ettiğini açıkladı. Şirketin ifadesine göre yetkisiz bir üçüncü taraf şifrelenmiş ortam değişkenlerine erişmiş ve bir kısmının şifresi çözülmüş içeriğini elde etmiş olabilir. BleepingComputer'a göre Railway'in yaklaşık 4,8 milyon kullanıcısı ve 16 milyondan fazla servisi var.

Konuda anlatılacaklar
  1. Ne oldu?
  2. Railway'in kendi aldığı önlemler
  3. Kullanıcı olarak yapmanız gerekenler
  4. Bucket ve GitHub sıfırlamasından sonra servisi ayağa kaldırmak
  5. Platform ihlallerinden çıkarılacak ders

Ne oldu?
  • Railway olayı, son dönemde YZ çıkarım (inference) sağlayıcılarını ele geçirmeyi amaçlayan platform şirketlerine yönelik saldırı serisinin parçası olarak görüyor ve bu sağlayıcılara tüm anahtarları proaktif olarak iptal etmelerini bildirdi.
  • İlk analiz etkinin bir kullanıcı alt kümesiyle sınırlı olabileceğini gösterse de şirket tüm kullanıcılara önlem almalarını önerdi.
  • Soruşturma süresince tüm deploy'lar durduruldu. 22 Ekim'de Pro ve Enterprise için build'ler geri açıldı; Hobby, Free ve Trial sırayla açılacak.
  • TechCrunch'a göre kök neden açıklanmadı; CEO Jake Cooper bir post-mortem yayımlanacağını söyledi.
Not: Dün paylaştığımız Zeabur ihlaliyle aynı dönemde, benzer hedeflemeyle (platformdaki sırlar üzerinden YZ sağlayıcı anahtarları) gelmesi dikkat çekici.

Railway'in aldığı önlemler
  • 22 Ekim 04:39 UTC itibarıyla tüm Railway API token'ları geçersiz kılındı. Public API entegrasyonlarınız için yeni token üretmeniz gerekiyor.
  • Her ortamdaki her storage bucket'ın ACCESS_KEY_ID ve SECRET_ACCESS_KEY değerleri yenilendi.
  • Railway'in tuttuğu GitHub token'ları geçersiz kılındı; registry kimlik bilgisi olarak saklanan GitHub token'ları Railway'den silindi. Ancak bu token'lar GitHub tarafında siz iptal edene kadar hâlâ çalışıyor.

Yapmanız gerekenler
  1. Railway'de saklanan tüm ortam değişkenlerini döndürün: veritabanı parolaları, üçüncü taraf API anahtarları (ödeme, e-posta, YZ sağlayıcıları), JWT imzalama anahtarları.
  2. Özel registry kimlik bilgilerini yenileyin.
  3. GitHub'da Railway'e verilmiş personal access token'ları ve deploy key'leri kendiniz iptal edin, ardından bağlantıyı yeniden kurun.
  4. Döndürdüğünüz her anahtarın sağlayıcı tarafındaki loglarını (bulut, ödeme, YZ API kullanım panelleri) 21 Ekim öncesinden itibaren inceleyin.
Sıralama önemli: önce sağlayıcıda yeni anahtar üretin, uygulamaya girin, deploy edin, sonra eskisini iptal edin; aksi halde kendi kendinize kesinti yaratırsınız.

Bucket ve GitHub sonrası yeniden deploy
Railway'in rehberine göre konteynerler değişkenleri yalnızca başlangıçta okur. Bucket'ın yeni kimlik bilgileri hazır ama servisinizin yeniden deploy edilmesi gerekiyor:
Kod:
railway redeploy --service uploads-api railway bucket credentials --bucket my-bucket
Bir servis hâlâ InvalidAccessKeyId veya SignatureDoesNotMatch hatası veriyorsa ya eski deployment çalışıyordur ya da değişkene düz metin olarak yapıştırılmış eski anahtar vardır. Railway, düz metin yerine referans değişken (örneğin ${{ my-bucket.SECRET_ACCESS_KEY }}) kullanmayı öneriyor; bir sonraki rotasyonda elle düzenleme gerekmez. Denetim kayıtlarında bu sıfırlamalar "Railway Staff" aktör tipiyle görünüyor; kendi olay kaydınız için bu girdileri dışa aktarın.

Ders
PaaS platformundaki env değişkenleri, uygulamanızın tüm dış dünyaya açılan anahtarlık halkasıdır. Kısa ömürlü kimlik bilgileri (OIDC, workload identity), anahtar başına en az yetki ve harcama limitleri, platform ihlal olduğunda patlama yarıçapını ciddi şekilde küçültür.

Railway veya benzeri bir PaaS kullanıyorsanız sır rotasyonunu ne kadar sürede tamamlayabildiniz? Otomasyon önerilerinizi paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Railway Ortam Değişkenleri İhlali: Tüm Kullanıcılara Acil Sır Rotasyonu Çağrısı
Tonyukuk 10-23-2026, 08:22 AM · Bulut Güvenliği
0 12
[Resim: attachment.php?aid=370]

Selamlar,

Geliştirici bulut platformu Railway, 21 Ekim 2026 sabahı müşteri ortam değişkenlerini (environment variables) saklayan sistemlerde anormal etkinlik tespit ettiğini açıkladı. Şirketin ifadesine göre yetkisiz bir üçüncü taraf şifrelenmiş ortam değişkenlerine erişmiş ve bir kısmının şifresi çözülmüş içeriğini elde etmiş olabilir. BleepingComputer'a göre Railway'in yaklaşık 4,8 milyon kullanıcısı ve 16 milyondan fazla servisi var.

Konuda anlatılacaklar
  1. Ne oldu?
  2. Railway'in kendi aldığı önlemler
  3. Kullanıcı olarak yapmanız gerekenler
  4. Bucket ve GitHub sıfırlamasından sonra servisi ayağa kaldırmak
  5. Platform ihlallerinden çıkarılacak ders

Ne oldu?
  • Railway olayı, son dönemde YZ çıkarım (inference) sağlayıcılarını ele geçirmeyi amaçlayan platform şirketlerine yönelik saldırı serisinin parçası olarak görüyor ve bu sağlayıcılara tüm anahtarları proaktif olarak iptal etmelerini bildirdi.
  • İlk analiz etkinin bir kullanıcı alt kümesiyle sınırlı olabileceğini gösterse de şirket tüm kullanıcılara önlem almalarını önerdi.
  • Soruşturma süresince tüm deploy'lar durduruldu. 22 Ekim'de Pro ve Enterprise için build'ler geri açıldı; Hobby, Free ve Trial sırayla açılacak.
  • TechCrunch'a göre kök neden açıklanmadı; CEO Jake Cooper bir post-mortem yayımlanacağını söyledi.
Not: Dün paylaştığımız Zeabur ihlaliyle aynı dönemde, benzer hedeflemeyle (platformdaki sırlar üzerinden YZ sağlayıcı anahtarları) gelmesi dikkat çekici.

Railway'in aldığı önlemler
  • 22 Ekim 04:39 UTC itibarıyla tüm Railway API token'ları geçersiz kılındı. Public API entegrasyonlarınız için yeni token üretmeniz gerekiyor.
  • Her ortamdaki her storage bucket'ın ACCESS_KEY_ID ve SECRET_ACCESS_KEY değerleri yenilendi.
  • Railway'in tuttuğu GitHub token'ları geçersiz kılındı; registry kimlik bilgisi olarak saklanan GitHub token'ları Railway'den silindi. Ancak bu token'lar GitHub tarafında siz iptal edene kadar hâlâ çalışıyor.

Yapmanız gerekenler
  1. Railway'de saklanan tüm ortam değişkenlerini döndürün: veritabanı parolaları, üçüncü taraf API anahtarları (ödeme, e-posta, YZ sağlayıcıları), JWT imzalama anahtarları.
  2. Özel registry kimlik bilgilerini yenileyin.
  3. GitHub'da Railway'e verilmiş personal access token'ları ve deploy key'leri kendiniz iptal edin, ardından bağlantıyı yeniden kurun.
  4. Döndürdüğünüz her anahtarın sağlayıcı tarafındaki loglarını (bulut, ödeme, YZ API kullanım panelleri) 21 Ekim öncesinden itibaren inceleyin.
Sıralama önemli: önce sağlayıcıda yeni anahtar üretin, uygulamaya girin, deploy edin, sonra eskisini iptal edin; aksi halde kendi kendinize kesinti yaratırsınız.

Bucket ve GitHub sonrası yeniden deploy
Railway'in rehberine göre konteynerler değişkenleri yalnızca başlangıçta okur. Bucket'ın yeni kimlik bilgileri hazır ama servisinizin yeniden deploy edilmesi gerekiyor:
Kod:
railway redeploy --service uploads-api railway bucket credentials --bucket my-bucket
Bir servis hâlâ InvalidAccessKeyId veya SignatureDoesNotMatch hatası veriyorsa ya eski deployment çalışıyordur ya da değişkene düz metin olarak yapıştırılmış eski anahtar vardır. Railway, düz metin yerine referans değişken (örneğin ${{ my-bucket.SECRET_ACCESS_KEY }}) kullanmayı öneriyor; bir sonraki rotasyonda elle düzenleme gerekmez. Denetim kayıtlarında bu sıfırlamalar "Railway Staff" aktör tipiyle görünüyor; kendi olay kaydınız için bu girdileri dışa aktarın.

Ders
PaaS platformundaki env değişkenleri, uygulamanızın tüm dış dünyaya açılan anahtarlık halkasıdır. Kısa ömürlü kimlik bilgileri (OIDC, workload identity), anahtar başına en az yetki ve harcama limitleri, platform ihlal olduğunda patlama yarıçapını ciddi şekilde küçültür.

Railway veya benzeri bir PaaS kullanıyorsanız sır rotasyonunu ne kadar sürede tamamlayabildiniz? Otomasyon önerilerinizi paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Skynet Ajanı: Açıkta Bırakılan LLM'leri Ele Geçiren Otonom LLMjacking Saldırısı
Tonyukuk 10-23-2026, 08:21 AM · Yapay Zeka Güvenliği
0 10
[Resim: attachment.php?aid=369]

Selamlar,

Yapay zeka güvenliğinde "bir gün olur" denen senaryolardan biri belgelendi. Symantec Threat Hunter Team, 21 Ekim 2026'da yayımladığı raporda, internette açıkta bırakılmış büyük dil modeli (LLM) uç noktalarını bulup ele geçiren ve bu modelleri kendi saldırılarını planlayan beyin olarak kullanan otonom bir saldırı ajanını anlattı. Operatörler ajanın çalışma moduna "Skynet" adını vermiş.

Konuda anlatılacaklar
  1. LLMjacking nedir?
  2. Skynet ajanı nasıl yakalandı?
  3. Ajanın yetenekleri
  4. Neden önemli, neyi değiştirmiyor?
  5. Kendi LLM altyapınızı korumak için kontrol listesi

LLMjacking nedir?
Başkasının yapay zeka modeline izinsiz erişip işlem gücünü kullanmak. Symantec'in ifadesiyle: bir modeli çalıştırmak her zaman birine para kaybettirir; kendi barındırdığınız modelde işlem süresi, ticari modelde token ücreti. Saldırgan işi bir yabancının uç noktası veya çalıntı anahtar üzerinden yürütünce maliyet kurbana geçer; üstelik saldırgan anonim kalır ve sağlayıcının hesap kapatma yaptırımlarından kaçar.

Nasıl yakalandı?
Symantec, korumasız ve internete açık bir YZ servisi taklidi yapan bir AI honeypot kurdu. Operatörler ajanın tüm çalışma prompt'unu, gerçek bir model olduğunu sandıkları bu sisteme gönderdi; böylece 2026 yazında ajanın tam talimat seti kayda geçti. Infosecurity Magazine'e göre honeypot, kurulumundan rapor tarihine kadar on binlerce farklı adresten 127.000'den fazla dış istek kaydetti. Önemli not: honeypot saldırganın araçlarını çalıştırmadı; yani elimizdeki şey uçtan uca doğrulanmış bir saldırı değil, saldırganın niyetini ve tasarımını gösteren eksiksiz bir talimat seti.

Ajanın yetenekleri
Raporlara göre:
  • Jailbreak katmanları: Modele marka bir kimlik veriyor, gerçek sağlayıcısını açıklamamasını, kendi güvenlik uyarılarını görmezden gelmesini ve yapılandırma dosyaları, .env dosyaları, API anahtarları ile veritabanı şemalarını okumayı "rutin geliştirme işi" saymasını söylüyor.
  • 74 saldırı aracı tanımı: FOFA üzerinden varlık keşfi; VS Code, Django, Jupyter, Laravel, Supabase, Next.js ve Flask için exploit modülleri; bulut metadata servislerini hedefleyen SSRF; botnet komuta-kontrol.
  • Skynet modu: 100.000'e kadar gözetimsiz adım, araçları anlatım yapmadan ve izin istemeden hemen çalıştırma, /tmp/.x altında gizli kripto madenciliği ve "tara, bulaş, madenci kur, yeniden bulaş" döngüsü.
  • Ayrı bir istekte Monero madenci kurulumu yapan, kendini gizleyen ve logları silen karartılmış bir script de görüldü.

Neden önemli?
Integrity360'ın özetine göre tek tek teknikler yeni değil; yeni olan bunların kendi kendini yöneten bir ajanda birleşmesi ve suçlular için giriş eşiğini düşürmesi. Model artık sadece soru yanıtlamıyor, saldırıyı planlıyor ve yürütüyor. Hedefler de tanıdık: kendi barındırılan modeller, YZ gateway'leri, MCP sunucuları ve çalıntı API anahtarları.

Kendi altyapınız için kontrol listesi
  1. Kimlik doğrulamasız LLM uç noktası bırakmayın. Ollama, vLLM, LM Studio gibi servisleri varsayılan olarak yalnızca localhost'ta dinletin; dışarı açacaksanız ters vekil + kimlik doğrulama kullanın.
  2. Gateway ve MCP sunucularında anahtar başına hız ve bütçe limiti tanımlayın; harcama alarmı kurun.
  3. API anahtarlarını .env dosyalarında açık bırakmayın; sır yöneticisi kullanın, düzenli rotasyon yapın.
  4. Token kullanımını izleyin. Mesai dışı ani artış LLMjacking'in en net işaretidir.
  5. Dış görünürlüğünüzü kontrol edin: kendi IP aralığınızda açık model portu var mı?
Kod:
# Kendi sunucunuzda: hangi YZ servisleri hangi arayuzde dinliyor? ss -ltnp | grep -E ':(11434|8000|1234|8080)\b' # Ollama'yi yalnizca localhost'a baglamak (systemd override) sudo systemctl edit ollama # [Service] # Environment="OLLAMA_HOST=127.0.0.1:11434" sudo systemctl restart ollama

Kendi barındırdığınız bir model veya YZ gateway'i var mı? Erişimi nasıl kısıtladığınızı paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 BIND 9 CVE-2026-94300: GSS-TSIG Mesaj Tekrarıyla Bellek Bozulması ve Olası RCE
Tonyukuk 10-23-2026, 08:18 AM · Ağ Güvenliği
0 20
[Resim: attachment.php?aid=368]

Selamlar,

DNS altyapısı yönetenler için önemli bir duyuru: ISC, 21 Ekim 2026'da BIND 9'un named servisinde uzaktan istismar edilebilir bir bellek bozulması açığını duyurdu. CVE-2026-94300, CVSS 3.1 puanı 8.1 (High). Özellikle Active Directory tarzı dinamik DNS güncellemeleri için GSS-TSIG (Kerberos imzalama) kullanan ortamları ilgilendiriyor.

Konuda anlatılacaklar
  1. GSS-TSIG nedir, kısaca?
  2. Açığın senaryosu
  3. Etkilenen ve düzeltilen sürümler
  4. Dağıtım durumu
  5. Kontrol ve sertleştirme adımları

GSS-TSIG kısaca
TSIG, DNS mesajlarını paylaşılan bir anahtarla imzalayarak sunucu-sunucu veya istemci-sunucu iletişimini doğrular. GSS-TSIG ise bu anahtarı Kerberos ile müzakere eder; Windows istemcilerinin kendi kayıtlarını güvenli dinamik güncelleme ile yazması bu yöntemle çalışır. BIND'i AD ile entegre eden kurumlarda tkey-gssapi-keytab veya tkey-gssapi-credential ayarı ile açılır.

Açığın senaryosu
ISC'nin bülteni:
  • Daha önce imzalanmış bir UDP mesajını yakalayabilen saldırgan, müzakere edilen TSIG anahtarı hâlâ geçerliyken bu mesajı tekrar gönderebiliyor (replay).
  • Buna ek olarak saldırganın kontrol ettiği bir zone'a özel hazırlanmış sorgular gönderilirse, paylaşılan Kerberos oturum durumu bozulabiliyor.
  • Sonuç: named sürecinin çökmesi ve/veya olası uzaktan kod çalıştırma.
CVSS vektörü AV:N/AC:H/PR:N/UI:N - ağ üzerinden, yetki gerektirmeden ama yüksek karmaşıklıkla (imzalı mesajı yakalamak gerekiyor). ISC'nin düzeltmesi paylaşılan GSS-TSIG oturumuna erişimi seri hale getiriyor. Açık ISC'nin iç testlerinde bulundu ve OpenAI'dan Dave Aitel tarafından bağımsız olarak da bildirildi. ISC aktif istismar bilmiyor.

Sürümler
Kod:
Etkilenen: 9.11.0 - 9.18.50 9.20.0 - 9.20.29 9.21.0 - 9.21.26 Duzeltilen: 9.20.30, 9.21.27 (Preview: 9.20.30-S1) Gecici cozum: YOK
Dikkat: ISC yalnızca desteklenen sürümleri yamalıyor; 9.18 hattı için listede düzeltme yok. pwn.watch'a göre Debian trixie'de yamalı paket var, Debian bookworm ve Ubuntu ise henüz bekliyor.

Kontrol adımları
Kod:
named -v # GSS-TSIG acik mi? grep -REn "tkey-gssapi|tkey-domain" /etc/bind /etc/named* 2>/dev/null # Debian/Ubuntu paket changelog'unda CVE apt changelog bind9 2>/dev/null | grep -n "CVE-2026-94300"

Yama gelene kadar risk azaltma
Geçici çözüm olmadığı için bunlar yalnızca saldırı yüzeyini daraltır:
  • Dinamik güncelleme kabul eden arayüzleri yalnızca iç ağa açın; update-policy ile kimin hangi kayda yazabileceğini daraltın.
  • GSS-TSIG gerçekten gerekmiyorsa kapatın; gerekiyorsa DNS trafiğinin yakalanabileceği ağ segmentlerini (paylaşımlı L2, misafir Wi-Fi) ayırın.
  • Yetkili (authoritative) ve özyinelemeli (recursive) rolleri ayrı sunuculara bölün.
  • named çökmelerini izleyin; systemd yeniden başlatsa bile tekrarlayan çökme bir saldırı denemesinin işareti olabilir.
Kod:
journalctl -u named --since "2026-10-21" | grep -Ei "assert|abort|exiting"
DNS'e yeni başlayanlar için temel kavramları anlatan bir konuyu Başlangıç Rehberi bölümünde paylaşıyoruz.

BIND'i AD ile GSS-TSIG üzerinden entegre eden var mı? Dağıtımınız yamayı yayınladı mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Linux ksmbd'de Yamasız İki RCE: ZDI Raporları Herkese Açık Listeye Düştü
Tonyukuk 10-23-2026, 08:17 AM · Siber Güvenlik Haberleri
0 14
[Resim: attachment.php?aid=367]

Selamlar,

Linux çekirdeği tarafında alışılmadık bir olay yaşandı: Trend Micro'nun Zero Day Initiative (ZDI) ekibi 21 Ekim 2026'da yamalanmamış birkaç çekirdek açığı raporunu [email protected] adresine gönderirken herkese açık linux-kernel ve alt sistem listelerini de bilgiye ekledi. Sonuç: kod yolları ve KASAN izleri dahil teknik ayrıntılar, düzeltmeler yayınlanmadan önce herkese açık hale geldi.

Konuda anlatılacaklar
  1. Sızan raporlar ve etkileri
  2. En kritik iki ksmbd açığı
  3. Kimler risk altında?
  4. Neden CVE yok?
  5. Ne yapmalı?

Sızan raporlar
The Hacker News'in derlediği tablo:
Kod:
ZDI ID Alt sistem Sinif CVSS ksmbd? ZDI-CAN-33549 ksmbd SMB Direct RCE 9.0 Evet (RDMA gerekli) ZDI-CAN-33774 ksmbd protokol dagitimi RCE 9.0 Evet (tum ksmbd) ZDI-CAN-33367 Ag (skb_zerocopy) Yerel LPE 7.8 Hayir ZDI-CAN-34068 VMware GPU (vmwgfx) Yerel LPE 8.8 Hayir ZDI-CAN-34076 NVMe hedef (nvmet) Bilgi ifsasi 8.6 Hayir
Ayrıca ConnMan ağ servisinde (çekirdek dışı) bir tampon taşması raporu (ZDI-CAN-32005) da var.

En kritik iki ksmbd açığı
ksmbd, Linux çekirdeğinin yerleşik SMB sunucusu (Samba'dan farklı, kernel alanında çalışır).
  • ZDI-CAN-33774:Kimlik doğrulama gerektirmiyor; 445 portunda ksmbd çalıştıran her sunucuyu etkiliyor. Aynı TCP yazımında arka arkaya kısa SMB1 paketleri ve ardından bir SMB2 paketi gönderildiğinde, işleyici tablosu atamasındaki bir yarış durumu SMB1 verisinin SMB2 işleyicisiyle işlenmesine ve kısa tamponun ötesinin okunmasına yol açıyor. Paylaşıma erişimi olan bir saldırgan için yazma yolu da mevcut.
  • ZDI-CAN-33549: SMB Direct yolunda tamsayı alt taşması (integer underflow). RDMA destekli arayüz (donanım veya rxe yazılım sürücüsü), yazılabilir bir ksmbd paylaşımı ve SMB Direct müzakere eden istemci gerekiyor.

Neden CVE yok, yama ne durumda?
Çekirdek projesi CVE'yi yalnızca stable ağaçta bir düzeltme olduğunda atıyor. 22 Ekim itibarıyla iki ksmbd açığı için mainline'da veya linux-next'te adı konmuş bir düzeltme yok. Phoronix'e göre SMB Direct bakımcısı ZDI-CAN-33549 için bir sonraki geliştirme döngüsünü hedefleyen bir düzeltme gönderdi; pwn.watch ise ksmbd yarış durumu düzeltmesinin ksmbd bakımcı ağacında beklediğini yazıyor. Mainline'dan dağıtım çekirdeklerine geçiş genelde haftalar sürer.

Raporları bulan araç olarak Trend Micro'nun yapay zeka tarayıcısı TrendAI kredilendirilmiş. The Hacker News'e göre Mayıs 2026'da güncellenen çekirdek güvenlik belgesi, yapay zeka araçlarıyla bulunan hataların tanım gereği zaten kamuya açık sayılacağını ve alt sistem listelerine gönderilmesi gerektiğini söylüyor; ZDI'nin yönlendirmesi bu mantığa uymuş görünüyor ama raporlarda yama yoktu. Greg Kroah-Hartman'ın yanıtı net: "Public listelere gönderdiniz ve yama eklemediniz, bununla yapabileceğimiz pek bir şey yok."

Kimler risk altında?
Yalnızca ksmbd çalıştıran makineler RCE'lere açık. Red Hat'in belgelerine göre RHEL varsayılan olarak ksmbd içermiyor. Çoğu sunucu Samba (smbd) kullanır; ancak bazı NAS ürünleri, gömülü cihazlar ve performans için ksmbd'yi seçen kurulumlar etkilenebilir.

Ne yapmalı?
Kod:
systemctl status ksmbd lsmod | grep ksmbd ss -ltnp | grep ':445'
ksmbd kullanmıyorsanız modülü kapatıp kara listeye alın; kullanıyorsanız 445'i yalnızca güvenilir ağlara açın ve misafir (guest) paylaşımları kapatın. Ayrıntılı adım adım rehberi Sunucu ve Hosting Güvenliği bölümünde ayrı bir konu olarak paylaşıyoruz.

NAS veya ev sunucunuzda ksmbd mi Samba mı kullanıyorsunuz? Kontrol sonucunuzu yazın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri
   
 Node2Shell CVE-2026-111497: Node.js Brotli Açığıyla Uzaktan Kod Çalıştırma
Tonyukuk 10-23-2026, 08:16 AM · Siber Güvenlik Haberleri
0 14
[Resim: attachment.php?aid=366]

Selamlar,

PHP2Shell gündemi sürerken JavaScript dünyasına da benzer isimli bir uyarı geldi: Node2Shell. Node.js 21 Ekim 2026'da yayımladığı güvenlik sürümlerinde, bundled Brotli çözücüsündeki sınır dışı yazma (out-of-bounds write) açığını kapattı. Açık CVE-2026-111497 olarak izleniyor ve Imperva Red Team 22 Ekim'de resmi Node.js 24.22.0 imajında kod çalıştırmayı gösterdi.

Konuda anlatılacaklar
  1. Açık nerede?
  2. Hangi uygulamalar risk altında?
  3. Düzeltilmiş sürümler ve EOL uyarısı
  4. Sürüm kontrolü ve güncelleme
  5. Sahte PoC ve "yama scripti" uyarısı

Açık nerede?
CVE kaydına göre sorun Google Brotli kütüphanesinin çözücüsünde (c/dec/decode.c), 1.0.3 - 1.2.0 aralığında. OX Security'nin analizine göre DecodeBlockTypeAndLength fonksiyonu aynı dönüş değeriyle hem "geçersiz akış" hem "daha fazla girdi lazım" anlamı taşıyordu. Blok geçişi çağıranlar bunu kurtarılabilir hata sanınca çözücü geçersiz durumla devam etti ve tamponun dışına yazdı. Upstream düzeltme bu durumu artık format hatası olarak döndürüyor.

Puanlama: CVE kaydında CVSS 4.0 9.2 (Kritik); Node.js projesi ise kendi değerlendirmesinde High olarak sınıflandırıyor. Açığı OpenAI Codex Security'den Khai Tran ve Sylvie Mayer bildirdi.

Kim risk altında?
Saldırgan kontrolündeki Brotli verisini açan her Node.js süreci. Imperva ve OX Security'nin örnekleri:
  • Gelen istekler: Content-Encoding: br ile gönderilen ve Express 5 / body-parser 2.x tarafından açılan istek gövdeleri (Imperva Express 5.0.0-5.3.0 ve body-parser 2.0.0-2.3.0'ı test etti).
  • Giden istekler: Yerleşik fetch() ile alınan Brotli sıkıştırılmış yanıtlar. Yani sizin sunucunuz kötü niyetli bir sunucudan veri çektiğinde de tetiklenebilir.
  • Doğrudan kullanım: Güvenilmeyen veride zlib.brotliDecompress() / brotliDecompressSync() çağrıları.
OX Security özellikle WAF'ın bu açığı azaltmadığını vurguluyor; Imperva ise kendi müşterileri için WAF kuralı eklediğini belirtiyor. Kalıcı çözüm her durumda runtime güncellemesi.

Düzeltilmiş sürümler
Kod:
Node.js 26.x -> 26.12.1 Node.js 24.x -> 24.22.1 Node.js 22.x -> 22.23.4 EOL (25.x, 23.x, 20.x ve oncesi) -> yama YOK, desteklenen hatta gecin Bun -> 1.4.4 (pwn.watch kaydina gore)
Aynı sürümde dokuz CVE daha (TLS hostname/IP doğrulama atlatmaları, DNS NUL kesmesi) ve eMudhra olayı nedeniyle CA deposu güncellemesi de geldi.

Kontrol ve güncelleme
Kod:
node -v # Konteynerlerde: calisan imajdaki surum docker run --rm node:24 node -v # Dockerfile'da etiketi sabitleyip yeniden build edin # FROM node:24.22.1-bookworm-slim
Konteyner kullanıyorsanız eski imajı yeniden başlatmak yetmez; yamalı base imajla yeniden build edip deploy edin. Serverless platformlarda sağlayıcının runtime güncellemesini teyit edin.

Sahte PoC uyarısı
OX Security'nin notu önemli: sosyal medyada veya rastgele repolarda paylaşılan doğrulanmamış exploit ya da "patch" scriptlerini klonlayıp çalıştırmayın. Bu tür büyük olaylarda sahte PoC'lerle zararlı dağıtımı sık görülüyor. Kaynağınız Node.js resmi duyurusu ve resmi sürümler olsun.

Ekibinizde hâlâ Node.js 20 veya 18 çalıştıran servis var mı? EOL geçişini nasıl planladığınızı yorumlarda paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

Ek DosyalarEkran Görüntüleri