8–22 Temmuz 2026 Güvenlik Gündemi: Aktif İstismarlar, Next.js Yamaları ve AI Uygulamalarındaki Yeni Riskler

Kısa özet: 8–22 Temmuz 2026 döneminde güvenlik gündemini yalnızca yeni açıklanan açıklar değil, gerçek saldırılarda kullanıldığı doğrulanan güvenlik açıkları belirledi. CISA altı farklı günde toplam 16 açığı Known Exploited Vulnerabilities kataloğuna ekledi. Next.js dokuz güvenlik açığı için yama yayımladı. Microsoft şirket içi SharePoint kurulumlarının aktif saldırı altında olduğunu doğruladı. Google, Agent Studio ile daha önce oluşturulan web uygulamalarının yeniden üretilmesini gerektiren bir SSRF düzeltmesi duyurdu. Node.js ise 27 Temmuz için HIGH seviyeli güvenlik yayını planladı.

Kısa doğrudan cevap

8–22 Temmuz 2026 döneminin en acil güvenlik aksiyonları şunlardır: Next.js kullanan projeleri 16.2.11 veya 15.5.21 sürümüne yükseltmek, şirket içi SharePoint sunucularını güncellemek ve olay izleri açısından incelemek, CISA KEV kataloğuna eklenen internet erişimine açık ürünleri önceliklendirmek, 1 Temmuz 2026 öncesinde Agent Studio ile oluşturulan web uygulamalarını yeniden üretmek ve Node.js için 27 Temmuz bakım penceresi ayırmak. Next.js sürümü, sunucu ürünü, CMS eklentisi veya AI uygulaması kullandığınızı bilmiyorsanız ilk yapılacak iş teknoloji envanteri çıkarmaktır.

Dönemin güvenlik gündemi: hızlı özet

1. Next.js dokuz güvenlik açığı için yama yayımladı

Next.js, 20 Temmuz 2026 tarihinde ilk planlı aylık güvenlik yayınını yayımladı. Yayın dört HIGH ve beş MEDIUM seviyeli güvenlik açığını kapatıyor. Güncel yamalı sürümler Next.js 16 hattı için 16.2.11, Next.js 15 hattı için ise 15.5.21 olarak açıklandı. Next.js 16 Active LTS, Next.js 15 ise Maintenance LTS durumunda bulunuyor; Next.js 14 ve daha eski ana sürümler mevcut destek politikasının dışında.

Neden önemli?

Bu yayın, tek bir güvenlik açığından daha geniş bir etkiye sahip. Next.js artık güvenlik yamalarını mümkün olduğunca önceden duyurulan ve planlanabilir bir yayın modeliyle sunacağını belirtiyor. Böylece işletmeler ve geliştirme ekipleri güvenlik güncellemelerini yalnızca acil olay yönetimi olarak değil, planlı bakım sürecinin parçası olarak ele alabilir.

Kimler etkileniyor?

• Next.js 16.2.x kullanan projeler
• Next.js 15.5.x kullanan projeler
• Next.js 14 veya daha eski destek dışı sürümlerde kalan uygulamalar
• App Router, Server Actions ve sunucu tarafı özellikleri kullanan projeler
• Next.js'i self-hosted biçimde çalıştıran ekipler
• Kurumsal web platformları ve SaaS uygulamaları

Ne yapılmalı?

# Next.js 16 hattı
npm install next@16.2.11
# Next.js 15 hattı
npm install next@15.5.21

Yükseltme önce staging ortamında uygulanmalı; kimlik doğrulama, Server Actions, görsel optimizasyonu, middleware, cache ve sunucu tarafı istek akışları test edilmelidir. Next.js 14 veya daha eski sürüm kullanan ekipler için konu yalnızca yama değildir. Desteklenen bir ana sürüme migration planı hazırlanmalıdır. Next.js'in resmî destek politikası yalnızca 15.x ve 16.x hatlarını desteklenen sürümler arasında gösteriyor.

İşletmeler için çıkarım

Web sitesini veya SaaS ürününü dış kaynakla geliştiren bir işletmenin tedarikçisine yalnızca “güncellediniz mi?” diye sorması yeterli değildir. Şu dört çıktı yazılı olarak istenmelidir:

• Kullanılan Next.js sürümü
• Uygulanan yeni sürüm
• Çalıştırılan testlerin listesi
• Üretim dağıtımının doğrulandığı tarih

2. CISA, 12 gün içinde 16 aktif istismar edilen açığı kataloğa ekledi

CISA, 10–21 Temmuz 2026 arasında altı ayrı duyuruyla toplam 16 güvenlik açığını Known Exploited Vulnerabilities kataloğuna ekledi. KEV'e eklenme, açığın yalnızca teorik olarak mümkün olduğunu değil, gerçek saldırılarda kullanıldığına ilişkin kanıt bulunduğunu gösteriyor.

10–21 Temmuz 2026 CISA KEV eklemeleri

CISA'nın KEV kataloğunda bulunmak, tüm kuruluşlar için hukuken aynı yama süresini doğurmaz. Ancak bir açığın aktif saldırılarda kullanıldığını gösterdiği için, risk önceliği açısından CVSS puanından daha güçlü bir operasyonel sinyal oluşturur.

Bu listedeki ortak desenler

İnternete açık kurumsal ürünler hedefte

SonicWall SMA1000, SharePoint, AD FS, FortiSandbox ve Oracle E-Business Suite gibi ürünler doğrudan kurumsal ağın kimlik, uzaktan erişim, doküman yönetimi, ödeme veya güvenlik katmanlarında bulunuyor. Bu ürünlerdeki açıkların etkisi yalnızca tek bir web sayfasıyla sınırlı kalmaz. Başarılı saldırı:

• İç ağa erişim
• Kimlik sistemi üzerinde yetki kazanımı
• Kurumsal dokümanlara erişim
• Güvenlik cihazının kontrol edilmesi
• Kalıcı erişim oluşturulması
• Diğer sistemlere yatay hareket

gibi sonuçlar oluşturabilir.

Eski açıklar hâlâ kullanılabiliyor

13 Temmuz'da KEV'e eklenen Cisco IOS açığının CVE yılı 2008, DD-WRT açığının CVE yılı ise 2021. Bir açığın eski olması, artık kullanılmadığı anlamına gelmiyor. Aksine destek dışı cihazlar ve unutulmuş internet erişimli sistemler saldırganlar için daha öngörülebilir hedefler haline gelebiliyor.

CMS çekirdeği ve eklenti riski birlikte görülüyor

10 Temmuz eklemeleri Joomla eklentilerini, 21 Temmuz eklemeleri ise WordPress çekirdeğini etkiliyor. Bu durum “yalnızca eklentiler risklidir” veya “çekirdek güncelse sistem güvendedir” gibi basit varsayımların yetersiz olduğunu gösteriyor. CMS, tema, eklenti, web sunucusu ve hosting ortamı tek envanter altında izlenmelidir.

3. Şirket içi SharePoint sunucuları aktif saldırı altında

CISA, 14 Temmuz 2026 tarihli uyarısında şirket içi Microsoft SharePoint Server kurulumlarını etkileyen dört açığın aktif olarak kullanıldığını bildirdi: CVE-2026-32201, CVE-2026-45659, CVE-2026-56164 ve CVE-2026-58644. Son iki açık 14 ve 16 Temmuz tarihlerinde KEV kataloğuna eklendi. Uyarı özellikle on-premises SharePoint sunucularını kapsıyor.

Kimler etkileniyor?

• Şirket içinde SharePoint Server çalıştıran kuruluşlar
• SharePoint Central Administration arayüzü internete açık olanlar
• SharePoint'i kurum içi kimlik altyapısına bağlayanlar
• Güncellemeleri merkezi olarak yönetilmeyen SharePoint farm'ları
• Eski veya destek dışı SharePoint sürümleri
• İnternete açık doküman portalı kullanan şirketler

Yalnızca yama yeterli mi?

Aktif istismar doğrulanmışsa, güvenlik güncellemesi uygulamak yalnızca gelecekteki saldırıları engeller. Daha önce erişim sağlanıp sağlanmadığını tek başına göstermez. Bu nedenle süreç iki parçaya ayrılmalıdır:

1. Maruziyeti kapatma

• Resmî Microsoft güncellemelerini uygulamak
• Central Administration erişimini dış dünyaya kapatmak
• Farm ve veritabanı iletişimini gereken sistemlerle sınırlamak
• Destek dışı sürümleri migration planına almak

2. Olay izi araştırması

• Olağan dışı web isteklerini incelemek
• Yeni oluşturulan yönetici hesaplarını kontrol etmek
• Web.config ve sistem dosyalarındaki değişiklikleri incelemek
• Şüpheli process ve scheduled task kayıtlarını araştırmak
• Makine anahtarlarının veya kimlik bilgilerinin ele geçirilip geçirilmediğini değerlendirmek
• Gerekirse olay müdahale süreci başlatmak

İşletmeler için çıkarım

“Sunucumuz güncel” ile “sunucumuz saldırıya uğramadı” aynı ifade değildir. Aktif istismar edilen bir açıkta işletmenin tedarikçisinden veya BT ekibinden şu iki belge ayrı ayrı istenmelidir:

• Yama uygulama ve sürüm doğrulama kaydı
• Geçmiş saldırı izi bulunmadığına ilişkin inceleme kaydı

4. Ağ cihazları ve router hijyeni yeniden gündemde

CISA ve uluslararası ortakları, 13 Temmuz 2026 tarihinde Rusya bağlantılı devlet destekli aktörlerin ağ altyapılarını hedeflemesine karşı router güvenliği rehberi yayımladı. Rehber; internet üzerinden erişilebilen yönetim yüzeylerinin kapatılması, cihaz yazılımlarının güncellenmesi, ömrünü tamamlamış cihazların değiştirilmesi ve şüpheli yönetim faaliyetlerinin izlenmesi üzerinde duruyor. Aynı gün 2008 tarihli bir Cisco IOS açığının, 21 Temmuz'da ise 2021 tarihli bir DD-WRT açığının KEV'e eklenmesi bu uyarının neden önemli olduğunu gösteriyor.

Ağ ekibinin kontrol etmesi gerekenler

• İnternete açık router yönetim panelleri
• HTTP veya Telnet üzerinden yönetim
• Varsayılan veya paylaşılmış yönetici parolaları
• EOL router ve firewall cihazları
• Güncellenmeyen VPN cihazları
• Kullanılmayan yönetim servisleri
• IPv6 üzerinden erişilebilen yönetim yüzeyleri
• Merkezi loglamaya gönderilmeyen router kayıtları
• Aynı parolanın birden fazla cihazda kullanılması
• Tedarikçi desteği sona ermiş firmware sürümleri

İşletmeler için çıkarım

Router ve firewall cihazları çoğu teknoloji envanterinde “altyapı” başlığı altında tek satır olarak tutuluyor. Oysa her cihazın:

• Modeli
• Firmware sürümü
• Destek bitiş tarihi
• Yönetim IP'si
• İnternete açıklık durumu
• Sorumlu ekip veya tedarikçisi

ayrı ayrı kayıt altına alınmalıdır.

5. WordPress ve Langflow açıkları AI altyapısı ile klasik web riskini aynı tabloda buluşturdu

CISA, 21 Temmuz 2026 tarihinde WordPress çekirdeğini etkileyen CVE-2026-63030 ve CVE-2026-60137 açıklarını KEV kataloğuna ekledi. Aynı duyuruda Langflow için CVE-2026-0770 ve DD-WRT için CVE-2021-27137 de yer aldı. WordPress açıklarının birlikte kullanılması SQL injection ve uzaktan kod çalıştırma zinciri oluşturabiliyor. NVD kayıtları CVE-2026-63030'un REST API batch endpoint yönlendirme karışıklığını, CVE-2026-60137'nin ise SQL injection açığını içerdiğini belirtiyor. Langflow CVE-2026-0770 ise AI akışları ve ajan entegrasyonları geliştirmek için kullanılan bir platformda uzaktan kod çalıştırma riski oluşturuyor. Açığın KEV'e eklenmesi, AI altyapılarının artık yalnızca deneysel geliştirme araçları değil, aktif saldırı yüzeyleri olduğunu gösteriyor.

WordPress kullanan ekipler ne yapmalı?

• WordPress çekirdek sürümünü doğrulamak
• Güvenli sürüme güncellemek
• Güncelleme öncesi yedek almak
• Bilinmeyen yönetici hesaplarını kontrol etmek
• Yeni veya değiştirilmiş plugin dosyalarını incelemek
• Web root altında şüpheli PHP dosyaları aramak
• Güvenlik loglarını güncellemeden önceki dönem için incelemek
• Admin ve hosting parolalarını döndürmek
• Gerekirse temiz kaynaktan yeniden kurulum yapmak

Langflow kullanan ekipler ne yapmalı?

• Çalışan Langflow sürümünü doğrulamak
• Platformu doğrudan internete açmamak
• Kimlik doğrulama ve ağ erişim katmanlarını kontrol etmek
• Güvenli sürüme yükseltmek
• Langflow'un erişebildiği secret ve API anahtarlarını belirlemek
• Şüpheli workflow, component ve process kayıtlarını incelemek
• Gerekirse erişim anahtarlarını değiştirmek
• Container imajını güncel ve temiz kaynaktan yeniden oluşturmak

InoviqLab değerlendirmesi

AI araçları genellikle “geliştirici ortamı” olarak görülüp üretim sistemlerine uygulanan güvenlik kontrollerinin dışında bırakılıyor. Ancak Langflow gibi araçlar veri tabanlarına, model API'lerine, dosya sistemlerine ve secret'lara erişebiliyor. Bir araç hassas kaynaklara erişebiliyorsa, adı “AI workflow builder” olsa bile klasik bir backend servisi gibi korunmalıdır.

6. Google Agent Studio uygulamalarında SSRF düzeltmesi

Google Cloud, 20 Temmuz 2026 tarihli sürüm notlarında Gemini Enterprise Agent Studio ile oluşturulan web uygulamalarındaki otomatik /api-proxy backend endpoint'ini etkileyen bir Server-Side Request Forgery açığını düzelttiğini açıkladı. Düzeltme, 1 Temmuz 2026'dan önce oluşturulan, indirilen veya dağıtılan web uygulamalarının yeniden üretilmesini ve yeniden dağıtılmasını gerektiriyor. Yeni üretilen backend kodu, hedef hostname'lerin izin verilen Google Cloud domain'leriyle bitmesini zorunlu tutan daha sıkı bir domain allowlist doğrulaması içeriyor.

Kimler etkileniyor?

• Agent Studio'dan web uygulaması kodu oluşturanlar
• 1 Temmuz 2026'dan önce kodu indirenler
• Oluşturulan /api-proxy endpoint'ini üretime alanlar
• Agent Studio web uygulamalarını özel frontend'lere entegre edenler
• Otomatik üretilen backend kodunu daha sonra manuel olarak değiştirenler

Ne yapılmalı?

• Uygulamanın Agent Studio'da oluşturulduğu tarihi belirleyin.
• Uygulama 1 Temmuz 2026'dan önce oluşturulduysa Agent Studio'dan yeniden üretin.
• Yeni kodu eski sürümle karşılaştırın.
• Manuel değişiklikleri kontrollü biçimde yeni sürüme taşıyın.
• Yeni uygulamayı staging ortamında test edin.
• Yeniden dağıtım yapın.
• Eski deployment'ı kapatın.
• /api-proxy loglarını şüpheli hedefler açısından inceleyin.
• Endpoint'in erişebildiği kimlik bilgilerini gözden geçirin.
• Şüpheli kullanım varsa ilgili anahtarları değiştirin.

İşletmeler için çıkarım

“Platform güvenlik açığını düzeltti” ifadesi her zaman kullanılan uygulamanın otomatik olarak düzeldiği anlamına gelmez. Google bu olayda daha önce üretilmiş uygulama kodlarının yeniden oluşturulmasını açıkça istiyor. Kod işletmenin reposuna indirildiyse, platform tarafındaki düzeltme mevcut deployment'a kendiliğinden ulaşmaz.

7. CodeQL sistem prompt injection akışını taramaya başladı

GitHub, 10 Temmuz 2026 tarihinde CodeQL 2.26.0 sürümünü yayımladı. Yeni sürüm JavaScript ve TypeScript projeleri için js/system-prompt-injection sorgusunu getiriyor. Sorgu, kullanıcı tarafından kontrol edilen güvensiz değerlerin AI modelinin sistem prompt'una ulaşabildiği veri akışlarını tespit etmeyi amaçlıyor. CodeQL ayrıca OpenAI, Anthropic ve Google GenAI SDK'larındaki yeni prompt sink'lerini modellemeye başladı. Bunlar arasında OpenAI Realtime session instruction alanları, Anthropic completion prompt'ları ve Google GenAI system instruction alanları bulunuyor.

Bu neyi değiştiriyor?

Prompt injection uzun süre yalnızca prompt yazımı veya kullanıcı eğitimi sorunu gibi ele alındı. CodeQL'in veri akışı sorgusu yaklaşımı, sorunu klasik uygulama güvenliği çerçevesine taşıyor: Güvensiz kullanıcı girdisi ↓ Dönüştürme veya birleştirme ↓ Sistem prompt'u ↓ Model davranışının değiştirilmesi Bu yaklaşım her prompt injection açığını bulmaz. Ancak kullanıcı girdisinin doğrudan yüksek yetkili talimat katmanına aktarıldığı belirgin kod akışlarını otomatik olarak işaretleyebilir.

Kimler kullanmalı?

• OpenAI, Anthropic veya Google GenAI SDK kullanan JS/TS projeleri
• Müşteri verisini sistem prompt'una ekleyen uygulamalar
• Doküman özetleyen AI sistemleri
• AI müşteri destek uygulamaları
• Araç çağırabilen ajan sistemleri
• Kullanıcı girdisine göre dinamik sistem prompt'u oluşturan ürünler

GitHub ayrıca 10 Temmuz'da code scanning uyarılarının Copilot'a atanabildiği agentic autofix özelliğini public preview olarak duyurdu. Sistem ilgili dosyaları inceliyor, düzeltme öneriyor ve uyarının kapanıp kapanmadığını doğrulamak için analizi yeniden çalıştırıyor. Ancak oluşturulan pull request yine geliştirici incelemesi gerektiriyor.

8. Node.js 27 Temmuz güvenlik yayınına hazırlanıyor

Node.js projesi, 21 Temmuz 2026 tarihinde 26.x, 24.x ve 22.x sürüm hatları için 27 Temmuz'da veya kısa süre sonrasında güvenlik sürümleri yayımlayacağını duyurdu. Her üç sürüm hattındaki en yüksek önem derecesi HIGH olarak açıklandı. CVE numaraları ve yamalı sürümler yayın anında açıklanacak. Node.js ayrıca EOL sürümlerin güvenlik yayınlarında her zaman etkilenmiş kabul edilmesi gerektiğini vurguluyor.

27 Temmuz öncesinde yapılacaklar

• Üretimdeki Node.js sürümlerini listelemek
• Container temel imajlarını tespit etmek
• CI runner sürümlerini kontrol etmek
• Destek dışı Node.js hatlarını belirlemek
• Staging bakım penceresi ayırmak
• Smoke test setini hazırlamak
• Uygulama imajını yeniden oluşturma süresini ölçmek
• Geri alma planını doğrulamak
• Node.js güvenlik duyuru kanalını takip etmek

Şimdilik yapılmaması gerekenler

• CVE numarası tahmin etmek
• Açıkların niteliği hakkında spekülasyon yapmak
• “Kritik açık geliyor” demek
• Belirli Node.js özelliklerinin etkilendiğini varsaymak
• Henüz açıklanmamış sürüm numarasını yazmak

İşletmeler için çıkarım

Ön duyuru, güvenlik açığının ayrıntılarını erken paylaşmak için değil; bakım kapasitesi ayırmak için yapılır. 27 Temmuz geldiğinde ekibin ilk kez “hangi sunucuda hangi Node.js var?” sorusunu sorması, ön duyuru penceresinin boşa harcandığı anlamına gelir.

Dönemin ortak güvenlik eğilimleri

1. Aktif istismar, önceliklendirmede temel sinyal haline geliyor

CISA'nın yeni BOD 26-04 yaklaşımı, yalnızca CVSS puanına göre sıralama yapmak yerine, internete açık ve tam kontrol sağlayan aktif istismar edilen açıkları daha hızlı ele almayı öne çıkarıyor. Bir şirket için pratik öncelik sırası şu şekilde kurulabilir:

• Aktif istismar edilen ve internete açık sistem
• Kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırma
• Kimlik, VPN veya güvenlik altyapısını etkileyen açık
• Hassas veri işleyen uygulama
• Destek dışı sistem
• İnternete kapalı ve ek kontrollerle korunan sistem

2. Yama uygulamak ile olay müdahalesi farklı süreçlerdir

Aktif istismar duyurulduğunda yalnızca sürümü yükseltmek yeterli olmayabilir. İki ayrı kontrol gerekir:

• Açık hâlâ kullanılabilir mi?
• Açık kullanılabilirken saldırgan sisteme girmiş olabilir mi?

İlk soru yama yönetiminin, ikinci soru olay müdahalesinin konusudur.

3. AI geliştirme araçları klasik uygulama güvenliği kapsamına girdi

Langflow uzaktan kod çalıştırma açığı, Agent Studio SSRF düzeltmesi ve CodeQL sistem prompt injection sorgusu aynı yöne işaret ediyor: AI uygulamaları artık yalnızca model kalitesiyle değil;

• API güvenliği
• Secret yönetimi
• Sunucu tarafı istekler
• Yetkilendirme
• Kod enjeksiyonu
• Prompt veri akışı
• Tedarik zinciri

açısından da incelenmelidir.

4. Destek dışı sistemler en pahalı güvenlik borcuna dönüşüyor

Cisco IOS 2008 açığı, DD-WRT 2021 açığı ve destek dışı Next.js sürümleri aynı temel sorunu gösteriyor: Yaması olmayan veya bakımı yapılmayan sistemde güvenlik ekibi teknik bir çözüm değil, risk kabulü veya migration kararı üretmek zorunda kalır.

İşletmeler için 24 saatlik aksiyon listesi

• İnternete açık sistemlerin listesini çıkarın.
• CISA KEV listesindeki ürünlerle envanterinizi karşılaştırın.
• Şirket içi SharePoint kullanılıp kullanılmadığını doğrulayın.
• Next.js kullanan sitelerin sürümünü öğrenin.
• WordPress ve Joomla sitelerin çekirdek ve eklenti sürümlerini kontrol edin.
• Langflow veya benzeri AI araçlarının internete açık olup olmadığını inceleyin.
• Agent Studio ile oluşturulan uygulamaların tarihini kontrol edin.
• Router ve firewall yönetim panellerinin dışarıya açık olup olmadığını denetleyin.
• Node.js kullanan sistemler için 27 Temmuz bakım penceresi ayırın.
• Aktif istismar edilen ürünlerde yalnızca yama değil, geçmiş olay izi incelemesi isteyin.
• EOL sistemler için sorumlu kişi ve migration tarihi belirleyin.
• Yapılan işlemleri yazılı bakım raporuna dönüştürün.

Geliştirici ve teknik ekipler için kontrol listesi

Web uygulamaları

• Next.js 15.5.21 veya 16.2.11'e yükseltildi mi?
• WordPress çekirdek ve eklenti envanteri çıkarıldı mı?
• Joomla eklentileri KEV ile karşılaştırıldı mı?
• Güncelleme sonrası şüpheli dosya taraması yapıldı mı?
• Server Actions ve middleware test edildi mi?

AI uygulamaları

• Langflow sürümü ve dış erişim durumu kontrol edildi mi?
• Agent Studio uygulaması 1 Temmuz öncesi mi?
• Güvensiz kullanıcı verisi sistem prompt'una ulaşıyor mu?
• CodeQL 2.26.0 veya güncel code scanning kullanılıyor mu?
• Model API anahtarları ve secret'lar gerektiğinde döndürülebiliyor mu?
• AI ajanlarının eriştiği araç ve veri kaynakları envanterde mi?

Sunucu ve altyapı

• SharePoint on-premises var mı?
• SonicWall SMA1000 kullanılıyor mu?
• AD FS ve Oracle EBS sürümleri kontrol edildi mi?
• FortiSandbox cihazları güncel mi?
• Router yönetim yüzeyleri internete açık mı?
• EOL ağ cihazları belirlendi mi?
• Node.js sürümleri otomatik raporlanabiliyor mu?

InoviqLab değerlendirmesi

Bu bölüm InoviqLab'ın yorumudur; yukarıdaki resmî güvenlik duyurularından ayrıdır. Bu dönemin en önemli sonucu, güvenlik ekiplerinin daha fazla CVE takip etmesi gerektiği değil. Asıl sonuç, güvenlik önceliklendirmesinin değişmesidir. Bir işletme yüzlerce yüksek CVSS puanlı bulguya sahip olabilir. Ancak internete açık SharePoint sunucusundaki aktif istismar edilen bir açık, iç ağdaki teorik olarak kritik onlarca bulgudan daha önce ele alınmalıdır. İkinci önemli konu envanterdir. Bu rapordaki aksiyonların neredeyse tamamı aynı soruyla başlıyor: Bu ürünü veya sürümü kullanıyor muyuz? Bu soruya birkaç dakika içinde cevap verilemiyorsa asıl güvenlik açığı tek bir CVE değil, teknoloji envanterinin bulunmamasıdır. Üçüncü konu, yama ile olay müdahalesinin ayrılmasıdır. Bir sistem aktif saldırı altında duyurulduktan sonra yalnızca güncellenip kapatılıyorsa, saldırganın daha önce oluşturduğu hesap, webshell, API anahtarı veya kalıcı erişim noktası sistemde kalabilir. Bu nedenle aktif istismar edilen sistemlerde minimum süreç şu olmalıdır:

• Maruziyeti azalt
• Yama uygula
• Sürümü doğrula
• Geçmiş olay izini incele
• Kimlik bilgilerini değerlendir
• Bulguyu ve alınan aksiyonu raporla

Son olarak, AI uygulamaları ayrı ve daha hafif bir güvenlik sınıfında değerlendirilmemelidir. Bir AI uygulaması dosya sistemine, veri tabanına, API'lere veya müşteri verisine erişebiliyorsa klasik bir backend uygulamasıyla aynı güvenlik yaşam döngüsüne tabi olmalıdır.

Sonuç

8–22 Temmuz 2026 güvenlik gündemi üç net mesaj veriyor:

• Aktif istismar edilen açıklar bekletilmemelidir.
• Güvenlik güncellemesi geçmiş saldırı izini otomatik olarak ortadan kaldırmaz.
• AI uygulamaları, CMS'ler, web framework'leri ve ağ cihazları tek bir teknoloji envanteri içinde yönetilmelidir.

Bu dönem için en acil başlıklar:

• Next.js 15.5.21 ve 16.2.11 yamaları
• On-premises SharePoint incelemesi
• CISA KEV eşleştirmesi
• WordPress ve Langflow kontrolleri
• Agent Studio uygulamalarının yeniden üretilmesi
• Router yönetim yüzeylerinin kapatılması
• Node.js 27 Temmuz bakım hazırlığı

Güvenlik gündemini takip etmenin amacı her yeni CVE için ayrı bir kriz oluşturmak değildir. Amaç, hangi gelişmenin sizin sisteminizi gerçekten etkilediğini birkaç saat içinde belirleyebilen tekrarlanabilir bir süreç kurmaktır.