# Teku ve Besu’dan Ethereum düğümleri için güvenlik yaması Yazar: Abdullah Özkurt Dil: Türkçe Yayınlanma: 2026-10-29T12:02:48+03:00 Güncellenme: 2026-10-29T12:02:48+03:00 ![Ethereum simgeli metal düzenekte mavi sertifika levhalarından ayrılmış kırmızı levha.](https://kriptometa.com/uploads/teku-ve-besu-dan-ethereum-dugumleri-icin-guvenlik-yamasi-37465adf3ff2_article.webp) ## Önemli noktalar - Besu 26.10.2, 26 Ekim’de; Teku 26.10.3, 27 Ekim’de yayımlandı. Ekipler Docker paketlerinden dört kök sertifikayı çıkardı. - Geliştiriciler varsayılan ana ağ kurulumlarının etkilenmediğini ve açıklama tarihinde bilinen bir saldırı bulunmadığını belirtiyor. - Arşiv dosyasından kurulum yapanlar, kullandıkları Java’nın sertifika deposunu ayrıca kontrol etmeli. Teku ve Besu ekipleri, saldırganların sahte sertifikalarla bazı özel Ethereum kurulumlarında blok ücretlerini başka adrese yönlendirebilmesine karşı güncelleme yayımladı. Yapılacak işlem, hazır Docker paketi veya ayrı bir Java kurulumu kullanılmasına bağlı. Teku ve Besu ekipleri, eMudhra kaynaklı sertifika sorununa karşı [Ethereum düğümleri](https://kriptometa.com/sozluk/ethereum-ether) için güvenlik güncellemeleri yayımladı. [Besu 26.10.2’nin 26 Ekim tarihli](https://github.com/besu-eth/besu/releases/tag/26.10.2) ve [Teku 26.10.3’ün 27 Ekim tarihli](https://github.com/Consensys-Incorporated/teku/releases/tag/26.10.3) sürümleri, hazır Docker paketlerinden dört kök sertifikayı çıkarıyor. Programı arşiv dosyasından kuran işletmecilerin, istemciyle birlikte kullandıkları Java kurulumunu da kontrol etmesi gerekiyor. [Teku ekibinin 28 Ekim’de güncellediği güvenlik açıklamasına](https://hackmd.io/@teku/S1DCreh2Ge) ve [Besu’nun olay raporuna](https://github.com/besu-eth/besu/wiki/Incident-Report-2026-10-26-eMudhra-CA-Compromise) göre varsayılan ana ağ ayarları bu sorundan etkilenmiyor. Risk, belirli HTTPS bağlantıları veya sertifikaya dayalı erişim ayarları kullanan düğümlerde ortaya çıkıyor. İki ekip de açıklamalarında bilinen bir kötüye kullanım bildirmiyor; doğrulanmış bir ETH kaybı veya etkilenen işletmeci sayısı vermiyor. ## Sahte sertifika hangi işlemleri etkileyebilir? Teku, Ethereum’da düğümlerin bloklar üzerinde uzlaşmasını sağlıyor ve doğrulayıcı görevlerini yerine getiriyor. Besu ise ağdaki işlemleri yürütüyor. İkisi de Java ile çalışıyor. HTTPS bağlantısında sunucunun kimliğini doğrulayan TLS sertifikası, blokların Ethereum kurallarına uygunluğunu denetleyen ağ mekanizmasından ayrı bir güvenlik katmanı. Teku ekibi, en büyük riski HTTPS üzerinden bağlanılan harici imzalayıcıda görüyor. Bu hizmet doğrulayıcının [özel anahtarlarını](https://kriptometa.com/sozluk/ozel-anahtar) ayrı bir sistemde tutuyor ve istenen mesajlar için [dijital imza](https://kriptometa.com/sozluk/dijital-imza) üretiyor. Saldırganın önce ağ trafiğinin arasına girebilmesi gerekiyor. Sahte sertifikayla imzalayıcıyı taklit edebilirse doğrulayıcının ağdan çıkışını başlatan geri alınamaz bir mesajı veya blok ücretlerinin başka adrese gönderilmesini isteyen kaydı imzalatabilir. Saldırganın çelişkili mesajları imzalatıp doğrulayıcının stake ettiği ETH’den [slashing cezası](https://kriptometa.com/sozluk/slashing) kesilmesine yol açabilmesi için, imzalayıcının kendi çifte imza korumasının da kapalı olması gerekiyor. İki tarafın birbirine sertifika sunduğu karşılıklı TLS doğrulaması ise açıklamadaki harici imzalayıcı saldırısını hizmet kesintisiyle sınırlandırıyor. Teku’nun kendi çifte imza kontrolleri, sahte bir uzak beacon düğümüne bağlanma senaryosunda çalışmaya devam ediyor. Saldırgan, uzak düğümü, blok oluşturucuyu veya aktarıcıyı taklit ederse yanlış blok verisi göndererek görevlerin kaçırılmasına yol açabilir ya da blok içeriğini teslim etmeyebilir. Teku ücret alıcısını bir HTTPS adresinden okuyorsa, saldırgan ayarlar yenilenirken kendi adresini yerleştirebilir. Yerelde çalışan mev-boost ise bağlandığı aktarıcıların açık anahtarlarını ayrıca denetliyor. ## Besu’daki özel erişim ayarı neden farklı? Besu işletmecisi “--rpc-http-tls-ca-clients-enabled” seçeneğini açıp bağlanan uygulamaların sertifikalarını Java’nın varsayılan kök sertifikalarıyla doğruluyorsa, saldırgan bu kontrolü aşabilir. Saldırganın bu durumda ağ trafiğinin arasına girmesi gerekmiyor; uygulamaların düğüme istek gönderdiği ilgili RPC veya Engine API adresine erişebilmesi yeterli olabilir. Etkisi hangi API işlevlerinin açık olduğuna bağlı. Ayrı kullanıcı doğrulaması veya JWT erişim anahtarı etkinse saldırganın bunları da sağlaması gerekiyor. Varsayılan Engine API’nin paylaşılan gizli JWT anahtarı bundan etkilenmiyor. Yalnız önceden belirlenmiş istemcileri kabul eden ya da kendi sertifika otoritesini kullanan kurulumlar da korunuyor; ancak işletmecinin sorunlu Java köklerini kendi sertifika deposuna kopyalamamış olması gerekiyor. Besu’nun dışarıya yaptığı belirli HTTPS veya WSS bağlantılarında ise Teku’dakine benzer biçimde saldırganın ağ trafiğinin arasına girebilmesi gerekiyor. Raporda isteğe bağlı ERA1 geçmiş verisi indirme, uzak başlangıç düğümü listeleri ve bazı izleme bağlantıları örnekleniyor. ERA1 varsayılan olarak kapalı; sahte geçmiş verisi verilse bile bloklar başlangıçtan itibaren doğrulandığı için otomatik olarak geçerli bir sahte zincir oluşmuyor. Ana ağ için belirtilen istisna bütün test ağı kurulumlarını kapsamıyor. Teku, Sepolia, Hoodi veya Ephemery’de boş veritabanıyla başlarken varsayılan olarak HTTPS üzerinden başlangıç dosyası indirebiliyor. Güvenilir yerel dosya kullanmak veya harici imzalayıcıya yalnız işletmecinin kendi sertifika otoritesiyle bağlanmak, açıklamada sıralanan önlemler arasında. ## Docker ve Java güncellemeleri nasıl ayrılıyor? Kurulum türüne göre hangi bileşen güncellenmeli? | Kurulum | Güncellemenin kapsamı | |---|---| | Teku’nun hazır Docker paketi | 26.10.3, paketin içindeki Java deposundan dört kök sertifikayı çıkarıyor. | | Besu’nun hazır Docker paketi | 26.10.2, paketin içindeki Java deposundan aynı dört kökü çıkarıyor. | | Arşiv dosyasıyla kurulan istemci | İşletmeci kullandığı Java’yı ayrıca kontrol edip gerekli düzeltmeyi uygulamalı. | Çıkarılan kökler emSign ECC Root CA–G3, emSign Root CA–G1, emSign Root CA–G2 ve AAA Certificate Services. Son sertifika, çapraz imza sayesinde aynı sertifikaların başka bir kök üzerinden kabul edilmesini sağlayabildiği için çıkarılıyor. Teku’nun önceki 26.10.2 Docker paketi, Java 25 veya 26 etiketini taşısa da bu düzeltmeyi içermiyor. Ana makinenin Java’sını güncellemek de kapsayıcının içindeki ayrı Java ortamını değiştirmiyor. [OpenJDK ekibi, 24 Ekim tarihli yönlendirmesinde](https://openjdk.org/emudhra) öncelikle Java sağlayıcısının sorunu gideren sürümüne geçilmesini öneriyor. Alternatif yöntemler arasında sertifika deposunun yedeğini aldıktan sonra ilgili köklerin kaldırılması ve bütün Java işlemlerinin yeniden başlatılması var. Büyük sürüm numarası tek başına yeterli değil: kullanılan dağıtım, güncelleme paketi ve gerçekten yüklenen sertifika deposu kontrol edilmeli. Teku ekibi, Java 26’nın desteğinin eylülde bittiğini ve bu sürüm için düzeltilmiş paket beklenmediğini de belirtiyor; uzun süreli destek (LTS) sunulan Java 25’e geçilmesini öneriyor. OpenJDK ayrıca Debian ve Ubuntu’da sistem sertifika paketini güncellemenin Java’nın önbellekteki deposunu her zaman yenilemediği konusunda uyarıyor. İşletmecilerin kullandıkları dağıtıma ait adımları izlemesi gerekiyor. ## eMudhra sekiz ara sertifikayı iptal etti [eMudhra’nın 28 Ekim’de güncellediği açıklamaya](https://emudhra.com/en/post/certificate-security-incident) göre sekiz ara sertifikanın özel anahtarları, anahtar üretimindeki bir hata nedeniyle kamuya açık sertifikalardan hesaplanabilir hâle geldi. Şirket, 17 Ekim’de haberdar olduğu sorunu doğruladıktan sonraki 14 saat içinde, 18 Ekim’de sertifikaları iptal ettiğini söylüyor. Sekiz ara sertifikadan son kullanıcı sertifikası üretilmediğini ve altyapısına veya müşteri verilerine girilmediğini de belirtiyor. Java, TLS sertifikalarının iptal durumunu varsayılan olarak denetlemediği için uygulamalar iptal edilen sertifikaları hâlâ kabul edebiliyor. eMudhra’nın 28 Ekim’de bildirdiği yaklaşık 30.800 sertifika, ABD müşterilerinin kullandığı daha geniş G3 yapısına ait. Şirket bu sayıyı sekiz sorunlu ara sertifikadan üretilen sertifika veya Ethereum doğrulayıcısı sayısı olarak vermiyor. Şirket müşterileri geçici olarak G1 köküne dayanan alternatif bir zincire taşımayı, geçiş tamamlanınca tarayıcı ve işletim sistemlerinin varsayılan olarak güvendiği TLS sertifikalarını üretmeyi bırakmayı planlıyor. Diğer elektronik imza ve kurumsal sertifika hizmetlerini sürdüreceğini belirtiyor. Teku ve Besu’nun eşler arası ağ iletişimi bu sertifika otoritelerine dayanmıyor. Ekipler işletmecilerden ilgili Java kurulumunu ve bağlantı ayarlarını düzeltmesini istiyor; HTTPS’yi kapatmayı önermiyor. Teku ekibi, 27 Ekim saat 08.01 TSİ’de 26.10.3 sürümünü duyurdu ve güvenlik açıklamasına bağlantı verdi. [Teku’nun 27 Ekim tarihli güvenlik güncellemesi](https://x.com/Teku_Consensys/status/2114945459055956118)