Node.js, Python ve Next.js yama haftası: canlı sunucularda güncelleme sıram

Bir hafta içinde Node.js, Python ve .NET güvenlik düzeltmeleri yayınladı, Next.js ise desteklenen dala hata düzeltmelerini geri taşıdı. Kendi sunucunuz, siteniz ya da entegrasyonlarınız varsa bir şey yapmak gerekiyor. Bunu sunucudan sorumlu kişi, önceden bildiği bir sırayla yapmalı. Aşağıda ne çıktı ve ben nasıl güncelliyorum.

Ne çıktı

Node.js 21 Ekim'de üç güvenlik sürümü yayınladı: 26.12.1, 24.22.1 LTS ve 22.23.4 LTS. 26.12.1 dokuz CVE kapatıyor, 24.22.1 sekiz, 22.23.4 yedi. Her hatta High seviyesinde açıklar var: tls'de kanonik olmayan IP adreslerinin reddedilmesi, dns'te resolve girdisinin sıfır baytlara karşı kontrolü ve Brotli açmadaki açık, CVE-2026-111497. Üç sürüm de kök sertifika listesini NSS 3.131.1'e güncelliyor ve engellenmiş açık anahtarlı zincirleri reddediyor. Notlarda sebep söylenmiyor, ama tarihlere bakınca bu, birkaç gün önce yazdığım eMudhra sertifika otoritesi hikâyesi.

Python 25 Ekim'de 3.14.10 ve 3.13.18 sürümlerini yayınladı. İkisi de hızlandırılmış sürüm ve sebebi yine eMudhra: ele geçirilen anahtarları artık ssl modülü engelliyor ve sıradan pip, pip'in kendi güncellemesi dahil, pip henüz güncellenmemiş olsa bile bu anahtarlarla yapılan saldırılara karşı korunuyor. 3.14.10'da bunun dışında 63 katılımcıdan yaklaşık 120 düzeltme ve tarfile.tar_filter'daki kapatılan açık var, CVE-2026-114583. 3.13 dalı Ekim 2028'e kadar “yalnızca güvenlik düzeltmeleri” modunda. Onun için artık yükleyici yok, yalnızca kaynak kod.

Microsoft 25 Ekim'de plan dışı .NET güncellemeleri yayınladı: 8.0.33, 9.0.22, 10.0.14 ve .NET 11 RC3. Orada Node.js'tekiyle aynı Brotli açığı var, CVE-2026-111497: açma sırasında tampon taşması, süreç belleğinin okunması ya da bozulması. .NET'te bu yalnızca uygulamanın Brotli açtığı yerlerde tetikleniyor: ASP.NET Core'daki request decompression'da, HttpClient'ın yanıtları otomatik açmasında ya da System.IO.Compression üzerinden. Aynı yazıda yalnızca .NET için geçerli olmayan bir eylem listesi de var: framework-dependent uygulamalar çalışma zamanını güncelleyip yeniden başlar, self-contained olanlar yeniden derlenir, konteynerler güncellenmiş imajlardan yeniden derlenir.

Next.js 23 Ekim'de 16.4.3 sürümünü yayınladı. Bu, aktif LTS dalına düzeltmelerin geri taşınması, yeni özellik yok: Google yazı tipi URL'leri ve OpenTelemetry izleri de aralarında. Güvenlik hakkında bir şey söylenmiyor. Sitem kononov.dev Next.js ve Node.js 24 üzerinde duruyor, dolayısıyla bu güncelleme Node ile aynı döngüye giriyor.

Güncellemeler neden ertelenir

30 kişilik bir hizmet şirketini ele alalım. Sitesi, satıcılar için uygulaması, telefon sistemi ve belge parser'ları var ve hepsi tek sunucuda. Node.js'i güncellemek, hem sitenin hem uygulamanın çalıştığı API'yi yeniden başlatmak demek. Gündüz müşteriler arıyor, gece bakacak kimse yok ve güncelleme gelecek haftaya kalıyor. Böyle bir ay geçiyor, sonra sıradaki yama paketi çıkıyor ve iki sürümü birden atlamak gerekiyor.

Sonuç: güncelleme, prova edilmediği zaman ertelenir. Sıra biliniyorsa ve bir saat sürüyorsa aynı gün yapılır.

Ben nasıl güncelliyorum

Sunucularım: ABD'deki PDR şirketi, orada Google Cloud'da Debian üzerinde Node.js API'si, site, telefon sistemi ve Python belge parser'ları çalışıyor; sipariş hesaplamasının PM2 altında Node.js ve Express ile bir sunucuda yaşadığı üretim şirketi; Docker'da Next.js ve Node.js 24 üzerindeki sitem; ve stüdyonun 2 GB bellekli aynı ortak sunucusundaki “Birlikte Kahve” iç servisi. Sıra her yerde aynı.

Önce envanter. Hangi çalışma zamanının hangi sürümünün nerede olduğunu yazıyorum: sistemde, her Docker imajında, parser'ların sanal ortamında. Bu liste olmadan sürümde kapatılan şeyin bizde kapalı olup olmadığı söylenemez.

Sonra neyin düzeltildiğini okuyup kendi kodumla karşılaştırıyorum. Brotli, HTTP istemcisinin sıkıştırılmış yanıt kabul ettiği yerde açılıyor; demek ki bu API'yi ve dış servislere giden her şeyi ilgilendiriyor. dns açığı, kullanıcı verisinden adres çözen her şeyi ilgilendiriyor. Böylece önce neyin güncelleneceği belli oluyor.

Ardından derleme. Konteynerler için temel imajı değiştirip derliyor ve uygulamayı yerelde çalıştırıyorum. Stüdyo sunucusunda derlemeye bazen bellek yetmiyor, bu yüzden imaj sunucu dışında derlenip hazır olarak yükleniyor. Önceki imaj yerinde kalıyor ki geri dönecek bir yer olsun.

Başlatma. “Birlikte Kahve”de güncelleme sırasında eski kopya, yenisi başlamadan önce durduruluyor: 2 GB'ta iki kopyaya yer dar, bu yüzden konteynerlerin sıkı bellek limitleri var. Parser'lar için önce işlemede askıda bir şey kalmadığını kontrol ediyorum, ancak ondan sonra yeniden başlatıyorum.

Başlattıktan sonra loglara bakıyor ve bir çalışma senaryosunu elle deniyorum. Bir şey yolunda değilse önceki imaja dönüyorum. Sıra prova edildiğinde bütün yama haftası saatlere sığıyor.

Sizin yerinizde ne yapardım

Sunucuya bakan kişiye hangi Node.js, Python ya da .NET sürümlerinin tam olarak nerede kurulu olduğunu sorardım. Cevap bir gün içinde gelmiyorsa ilk sorun bu.

Bir güncelleme penceresi üzerinde anlaşırdım: sistem ne zaman yeniden başlatılabilir ve ayağa kalktığını kim kontrol eder.

Güncellemenin imajların yeniden derlenmesiyle yapılmasını ve önceki sürümün el altında kalmasını isterdim.

Sırayı bir kez yazardım. Bir sonraki böyle haftada yine gerekecek ve o zaman güncelleme bir saat alacak.

Arka plan görevlerinin yeniden başlatmayı nasıl atlattığı üzerine: Worker'lar: arka plan görevleri ve yeniden denemeler. Yayınlanabilen ve geri getirilebilen altyapı: DevOps ve altyapı. Sözü geçen sunucu ve API, PDR şirketiyle teknik ortaklık vakasında ve birkaç uygulama için kendi API'si sayfasında anlatılıyor. Yakın yazılardan: PHP2Shell ve kendi sunucularını kontrol etmek, bir güncellemenin etki alanı ve kimsenin geri yüklemediği yedek; daha önce sürüm geri alma ile Docker uygulaması yayınlamak üzerine yazmıştım. Sunucunuz var ama güncelleme sıranız yoksa, üzerinde ne kurulu olduğunu anlatın, nereden başlayacağınızı önereyim. Görevi konuşalım.