PHP’nin Ekim güvenlik güncellemeleri: Kurumlar için envanter, yama ve hizmet sürekliliği gündemi

Ayrıntılar

2026 güncel dosyası — Bu haber 23 Ekim tarihli son açıklamaları içerir; kaynaklar 24 Ekim 2026 itibarıyla değerlendirilmiştir. Belirli bir kurumun sisteminin etkilendiği veya saldırıya uğradığı yönünde tespit içermez.

Avrupa Birliği siber güvenlik kurumlarının 21 Ekim’de yaptığı ortak PHP uyarısı, internet üzerinden hizmet veren işletmelerde yazılım bakımını yeniden öncelikli gündeme taşıdı. ENISA, Avrupa Komisyonu, CERT-EU, Europol EC3 ve ulusal müdahale ekipleri ağı, iki kritik açıklığın giderilmesi için kuruluşları harekete geçmeye çağırdı. Ortak açıklama, PHP tabanlı uygulamaların belirlenmesini, barındırma sağlayıcılarıyla koordinasyonu ve özellikle internete açık sistemlerin önceliklendirilmesini istedi. PHP’nin 23 Ekim’de yayımladığı ek bilgilendirme ise belirli bir yapılandırma birleşimine ilişkin ayrı bir riski ele aldı. Bu nedenle güncel durum değerlendirmesi iki duyurunun kapsamını birlikte okumayı gerektiriyor. [1][2]

21 Ekim düzeltmeleri hangi sürümleri kapsıyor?

PHP projesinin resmî arşivine göre 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri CVE-2026-109618 ile CVE-2026-109619 için düzeltme içeriyor. Proje, web isteklerini karşılayan kurulumların risk kapsamında değerlendirilmesini istiyor. Destek süresi sona ermiş eski dallarda durum ayrıca incelenmeli: dağıtım veya uzun süreli destek sağlayıcısı düzeltmeyi kendi paketine taşıyabilir. Dolayısıyla yalnızca ana sürüm numarasına bakmak yerine kullanılan paketin bakım kaydını ve sağlayıcının açıklamasını kontrol etmek gerekiyor. Bir test sürümünün bulunması, onun üretim ortamına uygun olduğu anlamına gelmiyor; proje sürüm türlerini resmî yayın notlarında ayırıyor. [2]

23 Ekim açıklaması ilk duyurudan nasıl ayrılıyor?

CERT-EU’nun 23 Ekim tarihli güncellemesi, ilk iki açığa ek olarak alışılmadık bir uygulama yapılandırmasıyla ilişkili üçüncü riske değiniyor. Kurum, bu riskin kapsamının genel bir “bütün uygulamalar aynı şekilde etkileniyor” yorumuna dönüştürülmemesi gerektiğini gösteren teknik koşulları aktarıyor. PHP, sonraki olağan hata düzeltme yayınına kadar ilgili oturum yükleme ilerlemesi özelliğine yönelik geçici önlemi açıklıyor. Bu ek uyarı, ilk iki kritik açık için yayımlanmış güncellemelerin yerine geçmiyor. Kurumların kendi yapılandırmalarıyla resmî açıklamayı eşleştirmesi ve güncelleme sonrası kalan koşulları ayrıca değerlendirmesi gerekiyor. Bu dosya saldırı uygulama adımları değil, kurumsal bakım kararları üzerinde duruyor. [3]

Bir web sitesinden daha geniş bir yazılım envanteri

NCSC-NL’nin operasyonel deposu, PHP bağımlılığının doğrudan görünen web uygulamalarıyla sınırlı olmayabileceğini ortaya koyuyor. Yönetim arayüzleri, cihazlara gömülü çalışma ortamları ve başka ürünlerle paketlenmiş bileşenler de envanter açısından önem taşıyor. Bu tür ürünlerde kurumun PHP’yi bağımsız değiştirmesi mümkün olmayabilir; üreticinin hazırladığı güncelleme paketini izlemek gerekebilir. Depodaki ürün listeleri gelişen bilgiye göre güncelleniyor. Listede bir ürünün bulunmaması tek başına güvenli olduğunu kanıtlamaz; kuruluşun kendi bağımlılık kaydı ve sağlayıcı teyidi esas alınmalıdır. Bu ayrım, satın alma sırasında ürün adıyla izlenen bir hizmetin teknik bakımda bileşen düzeyinde de değerlendirilmesini gerektiriyor. [4]

Yama yönetimi neden bir iş süreci?

NIST’in 2022 tarihli kurumsal yama yönetimi rehberi, güncellemeyi teknoloji için önleyici bakım olarak ele alıyor. Rehberin kapsamı; gerekli düzeltmeyi belirleme, öncelik sırasını oluşturma, edinme, kurma ve kurulumun gerçekleştiğini doğrulama aşamalarını içeriyor. Ayrıca iş birimleri ile teknik ekiplerin bakımın değerini farklı değerlendirebileceğine dikkat çekiyor. Bu kaynak, Ekim 2026 olayının bir duyurusu değil, kurumsal yaklaşımı açıklayan arka plan çerçevesidir. Buradan çıkan yönetim sorusu, bakımın kimin sorumluluğunda olduğu ve uygulama sonrasında hangi kanıtın yeterli kabul edildiğidir. Sadece bir iş emrinin kapatılmasıyla teknik doğrulamanın tamamlanması aynı kayıt değildir. [5]

Örnek bir işletmede karar akışı nasıl kurulabilir?

Aşağıdaki örnek, kaynaklardaki açıklamaların editoryal değerlendirmesidir; belirli bir işletmenin uyguladığı süreç olarak sunulmamaktadır. İnternet üzerinden başvuru alan bir kurum düşünelim. Başvuru formu, dosya yükleme alanı ve arka ofis ekranı aynı sunucuda bulunabilir; ayrıca dışarıdan sağlanan bir bordro uygulamasının farklı bakım takvimi olabilir. Böyle bir durumda tek bir “site güncellendi” ifadesi bütün hizmetleri kapsadığını göstermeyecektir. Her hizmet için teknik sorumlu, sağlayıcı, kullanılan paket ve doğrulama durumu ayrı kaydedilebilir. Böylece bakım kararının kapsamı çalışanlara ve yöneticilere anlaşılır biçimde aktarılır.

İkinci karar, değişikliğin hizmet üzerindeki etkisidir. Güncelleme planında kısa bir bakım aralığı, geri dönüş koşulları ve temel işlev kontrolü birlikte düşünülebilir. Başvuru örneğinde yalnızca ana sayfanın açılması yeterli bir kabul ölçütü değildir: formun gönderilmesi, ek dosyanın alınması, kaydın yönetim ekranında görünmesi ve kullanıcıya doğru bildirim verilmesi ayrı işlevlerdir. Bunlar örnek kontrol noktalarıdır; her kurum kendi hizmetinin kritik adımlarını belirler. Amaç, güvenlik bakımını günlük faaliyetten kopuk bir işlem olarak ele almadan değişikliğin çalışır durumda tamamlandığını ortaya koymaktır.

Yönetimin izleyeceği kayıtlar ve açık kalan sorular

Editoryal açıdan yararlı bir bakım kaydı, kaç sistemin incelendiğiyle kaç sistemde işlemin tamamlandığını birbirinden ayırır. Henüz sağlayıcı yanıtı bekleyen bir ürün, güncellenmiş bir ürünle aynı sütunda gösterilmemelidir. Aynı şekilde teknik inceleme sürerken “ihlal yaşanmadı” veya “tüm veriler güvende” gibi kesin sonuçlar çıkarılamaz. Bir güvenlik açığının açıklanması ile o açığın belirli bir kurumda kullanıldığına ilişkin kanıt farklı konulardır. Teknik bulgu bulunmadan olay atfetmek, karar verenleri de hizmet kullanıcılarını da yanıltır.

Öncelikler yeniden gözden geçirilirken bakım personelinin ulaşılabilirliği, dış hizmet sağlayıcısının dönüş süresi ve iş birimlerinin doğrulama desteği birlikte planlanabilir. Bu olayın insan kaynağı boyutu, yalnızca uzman sayısı değil, uzmanların doğru sistem bilgisine zamanında ulaşabilmesidir. Teknik sorumlunun değişmesi veya hizmetin başka bir tedarikçiye taşınması halinde envanterin güncel tutulması bu nedenle değerlidir. Tek seferlik yoğun çalışmanın ardından kayıtların sürdürülebilir biçimde sahiplenilmesi, bir sonraki duyuruda karar süresini kısaltabilecek kurumsal bir hazırlık olarak görülebilir.

24 Ekim itibarıyla bu dosyanın dayanağı, resmî güvenlik duyuruları ve bakım rehberidir. Daha sonra çıkabilecek düzeltmelerin kapsamı burada gerçekleşmiş gibi anlatılmamıştır. Kuruluş bazında sürüm uygunluğu ve olası olay incelemesi, ilgili teknik ekip ile hizmet sağlayıcısının kendi kayıtları üzerinden yürütülmelidir. [1][3][4]

Bakımın kurumsal izlenebilirliği için kayıtların tarih taşıması da yararlıdır. Aynı uygulamanın farklı sunuculardaki kopyaları aynı anda güncellenmemiş olabilir. Örnek bir değerlendirmede hizmet adı, ortam, işlem zamanı, uygulayan ekip ve işlev kontrolünün sonucu birlikte tutulabilir. Böylece daha sonra gelen bir duyuruda hangi kurulumun tekrar ele alınacağı anlaşılır. Bu öneri belirli bir ürün satın alınmasını gerektiren bir model değildir; kurumun mevcut kayıt düzeni içinde uygulanabilecek bir sorumluluk paylaşımı örneğidir. İncelemede kullanılan bilgi eskidiğinde kaydın yeniden açılabilmesi, tamamlanmış işin de izlenebilir olmasını sağlar.

Kaynaklar

[1] ENISA — Joint statement on critical PHP vulnerabilities — https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities

[2] PHP — 2026 haber arşivi, 21 ve 23 Ekim güvenlik duyuruları — https://www.php.net/archive/2026.php

[3] CERT-EU — Security Advisory 2026-018, 23 Ekim güncellemesi — https://cert.europa.eu/publications/security-advisories/2026-018/

[4] NCSC-NL — PHP bağımlılıklarına ilişkin operasyonel bilgi — https://github.com/NCSC-NL/php2shell

[5] NIST — SP 800-40 Rev.4, kurumsal yama yönetimi — https://csrc.nist.gov/pubs/sp/800/40/r4/final