<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Web Geliştirme]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:37 +0000 MyBB <![CDATA[Node.js EOL Sürüm Tuzağı: Node2Shell Sonrası Desteklenen Sürüme Güvenli Geçiş]]> https://www.turkteam.org/konu-node-js-eol-surum-tuzagi-node2shell-sonrasi-desteklenen-surume-guvenli-gecis.html Fri, 23 Oct 2026 11:32:53 +0300 BilgeKagan]]> https://www.turkteam.org/konu-node-js-eol-surum-tuzagi-node2shell-sonrasi-desteklenen-surume-guvenli-gecis.html [Resim: attachment.php?aid=379]
Selamlar,

Node.js'in 21 Ekim 2026 güvenlik sürümleri (Node2Shell, CVE-2026-111497 dahil) yalnızca 22.x, 24.x ve 26.x hatlarına geldi. Node.js'in kendi uyarısı net: güvenlik sürümü çıktığında EOL (ömrü dolmuş) sürümler her zaman etkilenmiş kabul edilir. OX Security de 25.x, 23.x ve 20.x ile öncesinin düzeltme almayacağını vurguluyor. Bu konu, eski bir Node sürümünde kalmış projeyi güvenli ve tekrarlanabilir şekilde taşımanın pratik adımlarını anlatıyor.

Konuda anlatılacaklar
  1. Hangi sürüm hattındayım?
  2. nvm ile yerel geçiş
  3. .nvmrc ve engines ile sürümü sabitlemek
  4. Docker ve CI tarafı
  5. Geçiş sonrası test kontrol listesi

1. Envanter
Kod:
node -v npm -v # Projede beklenen surum tanimli mi? cat .nvmrc 2>/dev/null; grep -A2 '"engines"' package.json # Sunucuda birden fazla node kurulu mu? which -a node
Kural: tek sayılı hatlar (23, 25) kısa ömürlüdür; üretimde çift sayılı LTS hatlarını (22, 24, 26) tercih edin. Güncel destek takvimi için Node.js'in "Previous Releases" sayfasına bakın.

2. nvm ile yerel geçiş
Kod:
# nvm kurulu varsayiliyor (github.com/nvm-sh/nvm) nvm ls-remote --lts | tail -5 nvm install 24.22.1 nvm use 24.22.1 nvm alias default 24.22.1 node -v # v24.22.1
Native modül kullanan projelerde (bcrypt, sharp, sqlite3) node_modules'u silip yeniden kurun; ABI değiştiği için eski derlenmiş modüller çalışmaz.
Kod:
rm -rf node_modules npm ci

3. Sürümü sabitlemek
Kod:
echo "24.22.1" > .nvmrc
package.json içinde:
Kod:
"engines": { "node": ">=24.22.1 <25" }
.npmrc içine engine-strict=true eklerseniz yanlış sürümde kurulum hata verir. Böylece ekipte biri eski sürümle çalışınca hemen fark edilir.

4. Docker ve CI
Kod:
# Yanlis: yuzen etiket, ne zaman ne gelecegi belirsiz FROM node:20 # Dogru: yamali surum + sabit dagitim tabani FROM node:24.22.1-bookworm-slim
Daha da sıkı kontrol isterseniz imajı digest ile sabitleyin (dün bu konuyu ayrıca işlemiştik). CI'da:
Kod:
# GitHub Actions ornegi - uses: actions/setup-node@v4 with: node-version-file: .nvmrc
Konteynerde eski imajı yeniden başlatmak yetmez; yeniden build edip deploy edin.

5. Geçiş sonrası test
  1. Birim ve entegrasyon testleri yeni sürümde geçiyor mu?
  2. npm audit ve npm outdated çıktısı temiz mi?
  3. Brotli kullanan yollar (Content-Encoding: br kabul eden body parser, fetch ile çekilen yanıtlar) yeni runtime'da test edildi mi?
  4. Üretimde node -v gerçekten yeni sürümü gösteriyor mu? (PM2 veya systemd eski binary'yi tutuyor olabilir.)
Kod:
pm2 restart all --update-env && pm2 describe app | grep "node.js version"

En eski Node sürümünü hangi projede gördünüz ve geçişte en çok ne sorun çıkardı?

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

.png   13-b03-node-eol-nvm.png (Dosya Boyutu: 117.25 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=379]
Selamlar,

Node.js'in 21 Ekim 2026 güvenlik sürümleri (Node2Shell, CVE-2026-111497 dahil) yalnızca 22.x, 24.x ve 26.x hatlarına geldi. Node.js'in kendi uyarısı net: güvenlik sürümü çıktığında EOL (ömrü dolmuş) sürümler her zaman etkilenmiş kabul edilir. OX Security de 25.x, 23.x ve 20.x ile öncesinin düzeltme almayacağını vurguluyor. Bu konu, eski bir Node sürümünde kalmış projeyi güvenli ve tekrarlanabilir şekilde taşımanın pratik adımlarını anlatıyor.

Konuda anlatılacaklar
  1. Hangi sürüm hattındayım?
  2. nvm ile yerel geçiş
  3. .nvmrc ve engines ile sürümü sabitlemek
  4. Docker ve CI tarafı
  5. Geçiş sonrası test kontrol listesi

1. Envanter
Kod:
node -v npm -v # Projede beklenen surum tanimli mi? cat .nvmrc 2>/dev/null; grep -A2 '"engines"' package.json # Sunucuda birden fazla node kurulu mu? which -a node
Kural: tek sayılı hatlar (23, 25) kısa ömürlüdür; üretimde çift sayılı LTS hatlarını (22, 24, 26) tercih edin. Güncel destek takvimi için Node.js'in "Previous Releases" sayfasına bakın.

2. nvm ile yerel geçiş
Kod:
# nvm kurulu varsayiliyor (github.com/nvm-sh/nvm) nvm ls-remote --lts | tail -5 nvm install 24.22.1 nvm use 24.22.1 nvm alias default 24.22.1 node -v # v24.22.1
Native modül kullanan projelerde (bcrypt, sharp, sqlite3) node_modules'u silip yeniden kurun; ABI değiştiği için eski derlenmiş modüller çalışmaz.
Kod:
rm -rf node_modules npm ci

3. Sürümü sabitlemek
Kod:
echo "24.22.1" > .nvmrc
package.json içinde:
Kod:
"engines": { "node": ">=24.22.1 <25" }
.npmrc içine engine-strict=true eklerseniz yanlış sürümde kurulum hata verir. Böylece ekipte biri eski sürümle çalışınca hemen fark edilir.

4. Docker ve CI
Kod:
# Yanlis: yuzen etiket, ne zaman ne gelecegi belirsiz FROM node:20 # Dogru: yamali surum + sabit dagitim tabani FROM node:24.22.1-bookworm-slim
Daha da sıkı kontrol isterseniz imajı digest ile sabitleyin (dün bu konuyu ayrıca işlemiştik). CI'da:
Kod:
# GitHub Actions ornegi - uses: actions/setup-node@v4 with: node-version-file: .nvmrc
Konteynerde eski imajı yeniden başlatmak yetmez; yeniden build edip deploy edin.

5. Geçiş sonrası test
  1. Birim ve entegrasyon testleri yeni sürümde geçiyor mu?
  2. npm audit ve npm outdated çıktısı temiz mi?
  3. Brotli kullanan yollar (Content-Encoding: br kabul eden body parser, fetch ile çekilen yanıtlar) yeni runtime'da test edildi mi?
  4. Üretimde node -v gerçekten yeni sürümü gösteriyor mu? (PM2 veya systemd eski binary'yi tutuyor olabilir.)
Kod:
pm2 restart all --update-env && pm2 describe app | grep "node.js version"

En eski Node sürümünü hangi projede gördünüz ve geçişte en çok ne sorun çıkardı?

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

.png   13-b03-node-eol-nvm.png (Dosya Boyutu: 117.25 KB / İndirme Sayısı: 6) ]]> <![CDATA[npm ci ve Sabit Release'ler: JS Tedarik Zincirinde Tekrarlanabilir Kurulum]]> https://www.turkteam.org/konu-npm-ci-ve-sabit-release-ler-js-tedarik-zincirinde-tekrarlanabilir-kurulum.html Wed, 21 Oct 2026 11:32:37 +0300 KulTigin]]> https://www.turkteam.org/konu-npm-ci-ve-sabit-release-ler-js-tedarik-zincirinde-tekrarlanabilir-kurulum.html [Resim: attachment.php?aid=335]
Selam,

Ekim 2026'da OVHcloud CLI release'lerinin zehirlenmesi, "CI yeşil ama artifact değişti" sınıfını tekrar gündeme getirdi. JavaScript tarafında günlük savunma: npm ci, kilit dosyası ve mümkünse immutable releases. Bu yazı pratik alışkanlık listesi.

npm install vs npm ci
  • npm install: lock'u güncelleyebilir, sürpriz minor/patch alabilir
  • npm ci: temiz kurulum; package-lock.json / npm-shrinkwrap.json ile birebir; CI için tasarlandı

Kod:
# CI job iskeleti npm ci --ignore-scripts # mümkünse; postinstall riskini azaltır npm test # scripts lazımsa: önce audit, sonra bilerek çalıştır

GitHub immutable releases
GitHub dokümantasyonundaki Immutable releases, yayımlanmış release asset'lerinin sonradan değiştirilmesini engellemeye yardımcı olur. OVHcloud olayında immutability kapalı olduğu için privileged hesap mevcut release'leri değiştirebildi. Org ayarlarınızda bunu açın; imzalama (Sigstore) ekleyin.

Ek kontroller
  • package-lock'u commit'leyin; --no-package-lock kullanmayın
  • .npmrc'de audit=true; kritik yollarda --dry-run
  • Özel registry / Verdaccio ile internal mirror
  • Dependabot/Renovate + insan incelemesi
  • postinstall çalıştıran paketleri gözden geçirin

Yasal uyarı
Başkalarının paketlerine zararlı kod enjekte etmek suçtur. Bu yazı savunma içindir.

Kaynaklar
Monorepo notu
Workspaces kullanıyorsanız kökte npm ci davranışını dokümante edin. Private paketler için kimlik bilgisini CI secret'tan verin; laptop'taki .npmrc'yi paylaşmayın. SBOM (cyclonedx) üretmeyi release job'una ekleyin.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   18-k03-npmci.png (Dosya Boyutu: 110.99 KB / İndirme Sayısı: 13) ]]> [Resim: attachment.php?aid=335]
Selam,

Ekim 2026'da OVHcloud CLI release'lerinin zehirlenmesi, "CI yeşil ama artifact değişti" sınıfını tekrar gündeme getirdi. JavaScript tarafında günlük savunma: npm ci, kilit dosyası ve mümkünse immutable releases. Bu yazı pratik alışkanlık listesi.

npm install vs npm ci
  • npm install: lock'u güncelleyebilir, sürpriz minor/patch alabilir
  • npm ci: temiz kurulum; package-lock.json / npm-shrinkwrap.json ile birebir; CI için tasarlandı

Kod:
# CI job iskeleti npm ci --ignore-scripts # mümkünse; postinstall riskini azaltır npm test # scripts lazımsa: önce audit, sonra bilerek çalıştır

GitHub immutable releases
GitHub dokümantasyonundaki Immutable releases, yayımlanmış release asset'lerinin sonradan değiştirilmesini engellemeye yardımcı olur. OVHcloud olayında immutability kapalı olduğu için privileged hesap mevcut release'leri değiştirebildi. Org ayarlarınızda bunu açın; imzalama (Sigstore) ekleyin.

Ek kontroller
  • package-lock'u commit'leyin; --no-package-lock kullanmayın
  • .npmrc'de audit=true; kritik yollarda --dry-run
  • Özel registry / Verdaccio ile internal mirror
  • Dependabot/Renovate + insan incelemesi
  • postinstall çalıştıran paketleri gözden geçirin

Yasal uyarı
Başkalarının paketlerine zararlı kod enjekte etmek suçtur. Bu yazı savunma içindir.

Kaynaklar
Monorepo notu
Workspaces kullanıyorsanız kökte npm ci davranışını dokümante edin. Private paketler için kimlik bilgisini CI secret'tan verin; laptop'taki .npmrc'yi paylaşmayın. SBOM (cyclonedx) üretmeyi release job'una ekleyin.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   18-k03-npmci.png (Dosya Boyutu: 110.99 KB / İndirme Sayısı: 13) ]]>