Jenkins 20 eklenti açığını yamaladı; yedi sandbox kaçışı controller üzerinde kod çalıştırmaya izin veriyor

Duyurunun kapsamı

Jenkins, 16 Eylül 2026 tarihinde eklenti ekosistemini kapsayan 20 güvenlik açığını içeren bir güvenlik duyurusu yayınladı. dev.to üzerinde yayınlanan pratik bir sertleştirme rehberine göre bu açıklardan yedisi Script Security sandbox'ını aşıyor ve her biri Jenkins controller üzerinde rastgele kod çalıştırma ile sonuçlanıyor.

20 açığın tamamı için yama mevcut, ancak hiçbir açık Jenkins core yükseltmesiyle giderilmiyor. Etkilenen her bileşen bir eklenti; bu nedenle ekiplerin core güncellemesine güvenmek yerine kurulu eklentilerin ve sürümlerin doğru bir envanteriyle çalışması gerekiyor. Rehber, adı geçen bileşenleri — Script Security, Robot Framework, Gradle, Bitbucket, Warnings, Coverage ve Dependency-Check — çoğu olgun kurulumun en az birini çalıştıracak kadar yaygın olarak işaretliyor.

Öncelik sırasına göre düzeltmeler

En yüksek öncelikli kalem 1422.v06869826dd9b_ sürümünde düzeltilen Script Security Plugin; etkilenen sürümler 1415.v9a_f9b_3a_c253d ve öncesi. Duyurudaki yedi sandbox bypass'ının tamamı burada son buluyor.

6.2.2 ve öncesi sürümler için 6.3.0'da düzeltilen Robot Framework Plugin, rehbere göre uzaktan kod çalıştırmaya yükselebilen bir path traversal açığı taşıyor.

Gradle ve Bitbucket eklentilerinin her ikisi de saklı kimlik bilgilerini ele geçirebilecek server-side request forgery sorunlarına sahip. dev.to rehberi, duyuruda listelenen düzeltilmiş sürümlere güncelleme yapıp ardından bu job'ların erişebildiği kimlik bilgilerini döndürmeyi öneriyor.

Warnings, Coverage ve Dependency-Check eklentileri, ciddiyeti daha düşük olsa da aynı bakım penceresine dahil edilmesi gereken stored cross-site scripting açıkları taşıyor.

Duyurudaki CVE-2026-92134 ve CVE-2026-92135 olmak üzere iki kalem, diğerlerinden farklı düzeltilmiş sürüm dizelerine sahip; bu yüzden rehber tek tip bir yükseltme yolu varsaymamayı ve sürüm tablosunu doğrudan okumayı öğütlüyor.

Öne çıkan bir operasyonel not: güncellemeden sonra kurulu sürümleri doğrulayın. Otomasyonla uygulanan eklenti güncellemeleri ekiplerin beklediğinden daha sık sessizce başarısız oluyor ve başarısız bir güncelleme panelden bakınca başarılı olandan ayırt edilemiyor.

Güvenlik ihlali varsayıp varsaymamaya karar vermek

Jenkins projesi, yayım anında bilinen aktif sömürü olmadığını ve kamuya açık bir proof-of-concept bulunmadığını bildiriyor. Rehber, bunun ifşa anındaki satıcı değerlendirmesi olduğunu ve hiçbir özel ortam için garanti anlamına gelmediğini vurguluyor.

Maruz kalma penceresi kısaysa ve Pipeline yazma hakları sıkı biçimde kontrol ediliyorsa yamalama yeterli olabilir. Pipeline tanımlama haklarının genişçe verildiği ya da etkilenen eklentilerin sürüm takibi yapılmadan uzun süredir kurulu olduğu durumlarda rehber daha temkinli bir duruş öneriyor:

• Deployment anahtarları, bulut sağlayıcı token'ları, container registry girişleri ve downstream ortamların secret'ları dahil olmak üzere controller düzeyindeki bir job'ın erişebildiği her kimlik bilgisini döndürün.

• Yapılandırmanın kod olarak saklandığı yerlerde sürüm kontrolüyle karşılaştırarak job tanımlarında beklenmeyen değişiklikleri inceleyin.

• Normal düzenin dışında çalışan job'ların build geçmişini gözden geçirin.

• Maruz kalma penceresi sırasında üretilen artifact'ları dağıtımdan önce bağımsız doğrulama gerektiren olarak değerlendirin.

Bu yama döngüsünden sonra kalıcı olacak yapılandırma

Rehberin ana tezi, bir sonraki duyurunun neden olacağı hasarın yalnızca yamalama hızından değil, yapılandırmadan belirlendiği yönünde. Önerileri:

• Pipeline yazmayı kısıtlayın. Bu duyurudaki her sandbox bypass'ı, saldırganın bir Pipeline tanımlayıp çalıştırabilmesini gerektiriyor. Bu hakkı küçük ve denetlenen bir gruple sınırlamak, tüm saldırı sınıfının ön koşulunu ortadan kaldırıyor — bu, mevcut en yüksek etkili yapılandırma değişikliği olarak tanımlanıyor.

• Kimlik bilgilerine en az ayrıcalık uygulayın. Her job'ın erişebildiği global kimlik bilgileri, controller düzeyindeki herhangi bir ihlali tam kimlik bilgisi ifşasına dönüştürür. Kimlik bilgilerini ihtiyaç duyan job'lara kapsamlandırın ve uzun ömürlü statik secret'lar yerine kısa ömürlü veya dinamik olarak verilen secret'ları tercih edin.

• Agent'ları segmentlere ayırın. Controller her agent'a erişebildiği için agent güven sınırları, bir controller ihlalinin ne kadar yayılacağını belirler.

• Controller'ı yüksek değerli bir varlık olarak izleyin. Job tanımı değişiklikleri, eklenti kurulumları ve script console kullanımı, post-exploitation faaliyetine işaret eden olaylardır.

• Eklenti sürümlerini sürekli takip edin. Jenkins işlevselliği ayrı sürüm takvimleriyle bakımı yapılan eklentiler aracılığıyla sunulur; tek bir duyurunun 20 kalem içermesinin nedeni budur. Doğru bir envanter, bir sonrakini günler değil saatler içinde eyleme dönüştürür.

Neden önemli

Yaygın biçimde dağıtılmış bir CI sistemindeki sandbox bypass'ları çekici hedeflerdir; çünkü mütevazı bir ayrıcalığı — Pipeline yazabilme yeteneğini — bir kuruluşun deployment kimlik bilgilerini tutan sistemin kontrolüne dönüştürürler. Bu duyuruda olduğu gibi aynı anda açıklanan yedi böyle açık, maruz kalmış eklentilere sahip her Jenkins kurulumu için yamalamayı acil hale getiriyor. Düzeltmelerın kendisi basit ve etkilenen sürümler belgelenmiş durumda. Bir sonraki duyurunun ne kadar hasara yol açacağını, dev.to rehberinin de dediği gibi yamaların çevresindeki yapılandırma belirliyor: kimler Pipeline yazabiliyor, controller neye erişebiliyor ve kullanıldığında bunu kimse fark eder mi.