Siber Güvenlik Başkanlığından PHP uyarısı: Kurumlar için yapılacaklar
T.C. Siber Güvenlik Başkanlığının 21 Ekim 2026 tarihli TR-26-1372 numaralı PHP güvenlik bildirimi, kurumların PHP tabanlı sistemlerini gözden geçirmesini istiyor. Önceki yazıda iki açığın teknik tarafını ele almıştım; burada resmî uyarıyı bir kurumun yapacağı somut işe çevirmek istiyorum.
Bildiri, açıkların başarılı biçimde kullanılması hâlinde uygulamanın yetkileriyle kod çalıştırılabileceğine dikkat çekiyor. Bu, yalnızca internet sitesinin görünümünün bozulması anlamına gelmez: uygulamanın okuyabildiği dosyalar, erişebildiği veriler ve sunduğu hizmet de risk kapsamına girebilir. Etkinin büyüklüğü, uygulamanın erişim yetkileri ve kurulumun özellikleriyle birlikte değerlendirilmelidir.
Bildirinin tarihi ile bugünkü durumu ayırmak gerekiyor
Resmî metin yayımlandığında PHP ekibinin ayrıntılı güvenlik duyurusu ve güncellemesi bekleniyordu. 22 Ekim 2026 itibarıyla bu bekleme aşaması sona ermiş durumda: düzeltmeler yayımlandı. Dolayısıyla bildirideki güncelleme beklentisini bugünkü haberin içine aynen taşıyıp “henüz yama yok” demek yanıltıcı olur.
PHP’nin resmî güvenlik duyurusunda bu iki açık için belirtilen düzeltilmiş sürümler şöyle:
| Kullanılan seri | Bu iki açığı düzelten sürüm |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Bu tablo, yalnızca burada ele alınan iki açık için düzeltme eşiğini gösterir. Dağıtım üreticileri yamayı kendi paketlerine geri taşıyabildiği için paket duyurusu da kontrol edilmelidir; ana sürüm numarası tek başına bu değerlendirmeye yetmeyebilir.
Teknik olarak hangi iki sorun konuşuluyor?
CVE-2026-109618, bellek yetersizliği sırasında isteğin işlenmesinin kesilmesiyle bazı iç verilerin geçersiz durumda kalmasına ilişkin bir hata. CVE-2026-109619 ise serbest bırakılmış belleğe bağlı iç durumun sonraki isteklerde yeniden kullanılabilmesiyle ilgili. İkisi de uygun koşullar oluştuğunda uzaktan kod çalıştırma riskine dönüşebiliyor.
Burada “bütün kurulumlar aynı yöntemle ele geçirilir” sonucuna varmamak gerekiyor. PHP’nin çalışma biçimi ve uygulamanın davranışı saldırı yolunu etkiliyor. Buna karşılık yalnızca belirli bir sunucu türünde çalışıyor olmak, güncellemeyi ertelemek için yeterli güvence değil.
Kurum tarafında ben nasıl ilerlerdim?
İlk adım, uygulama ile sunucuyu eşleştiren kısa bir envanter olurdu. Hangi hizmet internete açık, hangi PHP paketini kullanıyor, sorumlusu kim ve güncelleme hangi bakım penceresinde uygulanacak? Bu dört sorunun cevabı olmadan “sunucuları güncelledik” ifadesini doğrulamak zor.
İkinci adımda, çalışan hizmeti günceller ve gerekli süreçleri yeniden başlatırdım. Ardından yalnızca terminaldeki sürüme bakmakla yetinmez, gerçek web isteğini karşılayan PHP hizmetini ve ayrı çalışan süreçleri de kontrol ederdim. Konteyner kullanılan bir yapıda, değişikliği sonraki yeniden oluşturma sırasında kaybolmayacak şekilde imaja veya kalıcı yapılandırmaya taşımak da bu işin parçasıdır.
Başkanlığın önerdiği erişim kısıtlarını da uygulamanın ihtiyacına göre ele almak gerekiyor: yönetim ekranlarını ve kritik servisleri yetkili adreslerle sınırlandırmak, uluslararası erişim gerekmeyen sistemlerde bu trafiği kapatmak. Bunlar saldırganın sisteme ulaşabileceği yolları azaltır; PHP güncellemesinin yerine geçen kalıcı bir çözüm olarak görülmemelidir.
Son kontrolüm, bir sorumlunun kaydı kapatabilmesini sağlayan kanıt olurdu: kullanılan paket, etkin sürüm, yeniden başlatılan hizmetler ve başarılı uygulama kontrolleri. Bu yazı belirli bir kurumun sistemlerini denetlediğim veya herhangi bir saldırı tespit ettiğim anlamına gelmiyor; resmî uyarıdan çıkardığım uygulanabilir çalışma sırasını anlatıyor.
Kapak temsili olarak yapay zekâyla üretilmiştir. Spiker videosu, insan haber spikeri veya gerçek canlı yayın kaydı olmayan bir yapay zekâ sunumudur.