Kritik açıklar artık haftalık, yama takviminiz hâlâ aylık mı?

Bir haftaya sığan üç ciddi haber

16 Ekim'de Paris'teki Hexacon konferansında güvenlik firması Calif, iOS 27.0.1 çalıştıran bir iPhone 18 Pro üzerinde yeniden başlatmaya dayanıklı bir jailbreak gösterdi. Telefon kapatılıp açıldığında root erişimi geri geliyordu. Aynı sunumda Signal ve iMessage üzerinden tek tıkla çalışan istismar olarak etiketlenmiş videolar da yer aldı.

Birkaç gün sonra Google'ın Brotli sıkıştırma kütüphanesindeki bir bellek hatası önce Node2Shell adıyla duyuldu. Python paketleri, Bun ve başka HTTP kütüphaneleri de etkilenince adı HTTP2Shell'e döndü. Aynı hafta PHP'de iki kritik uzaktan kod çalıştırma açığı, yani PHP2Shell, planlanan yama yayımlanmadan sızdı ve istismar edildi.

23 Ekim'de yayımlanan “Is this the new cyber normal?” başlıklı yazı bu olayları yapay zekâ destekli açık avcılığına bağladı. Soru yerinde. Ama bence asıl soru şirketin içinde duruyor: bu tempoya göre çalışan bir ekibiniz var mı, yoksa güvenlik hâlâ ayda bir hatırlanan bir iş kalemi mi?

iPhone tarafında ne biliniyor, ne bilinmiyor

Önce paniği dindirecek kadar netlik. Calif kullandığı açıkları adlandırmadı ve ortada kamuya açık bir araç yok. Araştırmacılar yalnızca her şeyin “zamanı gelince” yayımlanacağını söyledi. Yani bugün sıradan bir saldırganın elinde bu zincir yok.

Apple gösteri tarihi itibarıyla kamuya yorum yapmadı; şirket yama hazır olmadan güvenlik sorunlarını doğrulamıyor. İlginç bir ayrıntı var: Apple'ın iOS 27 güvenlik notlarında Calif.io, Claude ve Anthropic Research ile birlikte bulduğu iki ilgisiz hata için anılıyor. 19 Ekim'de güncellenen bildirimde bunlar bir çekirdek sınır dışı yazma hatası (CVE-2026-28968) ve bir TCC yol geçişi hatası (CVE-2026-86886) olarak geçiyor.

İşletme açısından can sıkıcı kısım takvim. Calif'e göre iOS 27.2 beta zincirin büyük bölümünü zaten kapatıyor, ancak iOS 27.1 mevcut iPhone'lara güvenlik düzeltmesi getirmiyor, çünkü yalnızca yeni iPhone Duo'ya kuruluyor. Calif'in Duo'yu da piyasaya çıkışından saatler sonra kırdığı bildiriliyor; güvenlik araştırmacısı Stefan Esser açıkların 27.2'de kapanacağını söylüyor.

Kısacası bir süre yama bekleyeceksiniz. Bu bekleme süresini nasıl geçireceğiniz ise tamamen sizin cihaz politikanıza bağlı.

HTTP2Shell ve “bizde Node yok” yanılgısı

CVE-2026-111497, Brotli kod çözücüsünün 1.0.3 ile 1.2.0 arasındaki sürümlerinde bulunan bir sınır dışı yazma hatası ve CVSS v4.0 puanı 9.2. Aikido'nun aktardığına göre açığı OpenAI şubatta bulmuş, kök neden de şubatta kaynak kodda düzeltilmiş. Fakat güvenlik sorunu olarak tanınmadığı için düzeltme bugüne kadar hiçbir sürümle dağıtılmamış. Sonuç olarak Brotli'yi kendi içine gömen her proje kendi güncellemesini çıkarmak zorunda kaldı.

Düzeltilmiş sürümler dağınık. Brandefense'in özetine göre Node.js 21 Ekim'de 22.23.4, 24.22.1 ve 26.12.1 sürümleriyle düzeltildi, Bun'da düzeltme 1.4.4'te. GitHub'ın kritik bildirimi PyPI'daki brotli paketini 1.2.1'e kadar savunmasız sayıyor ve brotlicffi'yi de kapsıyor. Bir Python ekibi “biz Node kullanmıyoruz” diye rahatlayabilirdi; yanlış güven tam olarak buradan doğuyor.

Dengeli olmak gerekirse, 22 Ekim itibarıyla sahada istismar raporu yoktu. Araştırmacılar değiştirilmemiş bir Node.js 24.22.0 üzerinde laboratuvar koşullarında kod çalıştırabildi, ama istismar her denemede tutmadı. Bu, beklemek için bir bahane değil; panik yerine düzenli bir sırayla hareket etmek için bir gerekçe. İlk gün cevaplanması gereken sorular şunlar:

• Hangi servislerimiz hangi Node.js, Bun ve Python sürümünde çalışıyor?
• brotli veya brotlicffi doğrudan değil de dolaylı bağımlılık olarak nerelerde var?
• Container imajlarımızda eski bir çalışma ortamı gömülü kalmış mı?
• Kullandığımız hazır yazılım ve SaaS ürünlerinin tedarikçileri etkilenip etkilenmediklerini açıkladı mı?

Yama ile istismar arasındaki mesafe kapanıyor mu?

PHP2Shell somut bir örnek. CVE-2026-109618 ve CVE-2026-109619 haberleri 20 Ekim'de sızdı, VulnCheck'in tuzak sistemleri 21 Ekim'de tarama ve istismar denemeleri kaydetti. Recorded Future'ın aktardığına göre Patchstack, PHP'nin güvenlik sürümünden önce, 21 Ekim 07:34 UTC'ye kadar barındırma ortaklarından birden fazla aktif istismar vakası raporu aldı. Wiz de WordPress, Drupal ve Joomla'ya karşı kimlik doğrulamasız uzaktan kod çalıştırmayı gösterdi.

Blog yazısının ana iddiası şu: bir güvenlik yaması kamuya duyurulduğu anda insanlar dil modellerini kod tabanına yöneltiyor, diff'leri okuyor ve istismar edilebilir açığa geriye doğru ulaşıyor. Aynı yazı, PHP hatalarını Calif'in OpenAI'ın “Patch the Planet” programı kapsamında bulduğunu da not ediyor. Yani yapay zekâ hem açığı bulan hem de yamayı silaha çeviren tarafta.

Sektör verileri de baskıyı doğruluyor. Stingrai'nin derlemesine göre Mandiant M-Trends 2026, 2025 için ortalama istismar süresini yaklaşık eksi yedi gün olarak veriyor; istismar ortalamada yamadan bir hafta önce başlamış. Verizon 2026 DBIR'da açık istismarı yüzde 31 ile en yaygın ilk erişim yolu olmuş, bir önceki raporda bu oran yüzde 20'ymiş. 2025'te toplam 48.185 CVE yayımlanmış.

Yine de bir nüans var. VulnCheck, 2025'te ilk kez istismar edilen 884 açığın yüzde 28,96'sının CVE yayımlandığı gün ya da öncesinde istismar edildiğini ve zamanlama örüntülerinin 2024'le büyük ölçüde tutarlı olduğunu söylüyor. Benim okumam şu: “yeni normal”in bir kısmı aslında yeni değil, yeni olan bu tempoyu artık görmezden gelemeyecek kadar sık ve görünür yaşamamız. Sonuç her iki durumda da aynı; aylık bir yama ritmi buna yetmiyor.

“Gelecek ay güncelleriz” neden varsayılan olamaz

Aylık bakım penceresi, yamanın önceden duyurulduğu ve istismarın haftalar sonra geldiği bir dünya için tasarlandı. PHP2Shell'de istismar yamadan önce başladı. Böyle bir ortamda ayın son cumasını beklemek, saldırgana koca bir ay hediye etmek demek.

Bu, her şeyi anında yamalayın demek değil. Her güncellemeyi acil sayan bir ekip birkaç hafta içinde yorulur ve gerçekten acil olanı kaçırır. Daha sürdürülebilir olan, varlıkları maruziyetlerine göre ayıran katmanlı bir takvim:

Asıl değişiklik teknik değil, yetkiyle ilgili. Gece bir servisi yeniden başlatmak için üç ayrı onay gerekiyorsa en iyi takvim bile kâğıt üstünde kalır. Kimin acil yama kararı verebileceğini önceden yazın; olay anında tartışılacak konu bu olmamalı.

• İnternete açık servislerde kimlik doğrulamasız uzaktan kod çalıştırma: aynı gün değerlendirme, yama yoksa servisi kısıtlama, erişimi daraltma ya da geçici kural gibi önlemler.
• Kritik puanlı ama dışarıdan erişilemeyen iç sistemler: haftalık bakım penceresinde öncelikli olarak.
• Rutin güncellemeler: mevcut aylık ritim devam edebilir.
• Yaması henüz olmayan açıklar: risk kaydına girer, bir sahibi ve yeniden bakılacak bir tarihi olur.

Şirket telefonları için gerçekçi bir filo politikası

iPhone vakası, mobil cihazlarda yamanın sizin elinizde olmadığını hatırlatıyor. Apple 27.2'yi yayımlayana kadar yapabileceğiniz en değerli şey, yama geldiği gün onu herkese ulaştırabilecek durumda olmak. Bunun ilk adımı envanter: hangi çalışan, hangi modelde, hangi sürümü kullanıyor? Pek çok küçük şirket bu soruya bir tablo açıp birkaç kişiye mesaj atmadan cevap veremiyor.

Bir mobil cihaz yönetimi (MDM) çözümünüz varsa minimum işletim sistemi sürümü kuralı koyun ve bu sürümün altındaki cihazların kurumsal e-postaya ya da iş uygulamalarına erişimini kısıtlayın. MDM yoksa açık konuşalım: birkaç düzine cihazı elle takip etmek uzun vadede çalışmıyor. Kısa vadede düzenli hatırlatma ve basit bir kontrol listesi bile hiç yoktan iyidir.

Kendi cihazını getir (BYOD) modelinde iş daha zor, çünkü çalışanın kişisel telefonunu zorla güncelleyemezsiniz. Burada yapılabilecek olan, hassas verinin hangi uygulamalarda tutulduğunu sınırlamak ve güncel olmayan cihazın kurumsal hesaplara erişimini koşula bağlamak. Gösterilen tek tıklık istismar videolarının Signal ve iMessage üzerinden olması da yönetici ve finans ekiplerinin telefonlarının neden ayrıca dikkat istediğini gösteriyor.

Tedarikçi sözleşmelerinde artık sorulması gerekenler

Brotli örneği tedarik zincirinin zayıf halkasını açıkça gösteriyor: düzeltme kaynakta aylarca durdu ama güvenlik sorunu olarak etiketlenmediği için kimse sürüm çıkarmadı. Kullandığınız yazılımın ya da SaaS hizmetinin içinde hangi kütüphanelerin gömülü olduğunu biliyor musunuz? Sözleşmelerin çoğu bu konuda tamamen sessiz.

Yeni sözleşmelerde ya da yenileme dönemlerinde en azından şu başlıkları masaya getirin:

Küçük bir şirketin büyük bir tedarikçiye madde dayatma gücü sınırlı, bunu kabul edelim. Ama soruyu sormak bile bilgi verir. Bu sorulara bugün yanıtı olmayan tedarikçinin kriz günü de yanıtı olmayacaktır ve bu, satın alma kararında açıkça tartılması gereken bir risktir.

• Kritik bir açık öğrenildiğinde müşteriye ne kadar sürede ve hangi kanaldan bildirim yapılacağı
• Önem derecesine göre yazılı yama süresi taahhüdü
• Ürünün içindeki bileşenlerin listesi (SBOM) ve bu listenin güncel tutulması
• Yama gecikirse önerilecek geçici önlemler
• Olay sonrası yazılı rapor
• Dış güvenlik araştırmacılarının açık bildirebileceği bir sorumlu açıklama kanalı

Yamayı kesinti değil, işin parçası saymak

Güncelleme bildiriminde sürekli “yarın hatırlat”a basan çalışan kötü niyetli değil. Ona kimse bunun neden önemli olduğunu anlatmadı ve işini kesmenin bedelini o ödüyor. Yöneticiler için de durum farklı değil; ay sonunda satış ekibinin sistemlerinin yeniden başlatılmasını kimse istemiyor.

Birkaç pratik alışkanlık çok şey değiştiriyor. Haftalık kısa bir güvenlik gündemi ve bu gündemde kaynakları kimin takip ettiğinin net olması. Telefon güncellemelerinin akşam şarjdayken kurulmasının normal kabul edilmesi. Acil bir yama kararının ardından ekibe iki cümlelik bir açıklama yapılması, çünkü gerekçesini bilen insan kesintiye daha kolay katlanır.

Bir de tatbikat: bir sonraki kritik açık geldiğinde kimin ne yapacağını masa başında bir kez prova edin. Bu haftanın açıklarının çoğu yamalandı ya da yamalanacak. Ama gelecek hafta yenisi gelecek ve ritmini değiştirmeyen şirket, aslında şansına güvenen şirkettir.