Yazar: Atakan Akbulut
PHP kullanan bir web sitesi veya uygulama yönetiyorsanız, sunucunuzdaki PHP sürümünü kontrol etmenin zamanı geldi. PHP ekibi, CVE-2026-109618 ve CVE-2026-109619 numaralı iki kritik güvenlik açığı için 21 Ekim 2026'da güncelleme yayımladı. Bu açıklar, belirli koşullarda kimlik doğrulaması gerektirmeden uzaktan kod çalıştırılmasına izin verebiliyor. [1]
İlk yapılacak işlem: Kullandığınız PHP dalında yamalı sürüme geçin. Düzeltmeleri içeren ilk sürümler PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12. Önceki duyurulardaki “henüz yama yok” bilgisi artık geçerli değil. [1]
CVE-2026-109618, PHP'nin bellek yetersizliği durumlarını işlemesiyle ilgili. Bir işlem uygun olmayan noktada kesildiğinde, PHP henüz tam hazırlanmamış iç verileri geçerli kabul edebiliyor. Bu durum bellek bozulmasına ve uzaktan kod çalıştırılmasına yol açabiliyor. Doğrulanmış saldırıda kod, web sunucusunun PHP işlemini çalıştıran hesabın yetkileriyle yürütülüyor; bu, otomatik olarak root yetkisi elde edildiği anlamına gelmiyor. [2]
CVE-2026-109619 ise bir istek bittikten sonra bellekte kalan geçersiz iç durumun, aynı PHP worker'ının işlediği sonraki istekte kullanılabilmesiyle ilgili. Kullanılabilirlik; uygulamadaki işlemlere, hata koşullarına ve sunucu yapılandırmasına bağlı. Etkilenen sürümün kurulu olması, her isteğin saldırıyla sonuçlanacağı anlamına gelmiyor. [3]
| Kullanılan PHP dalı | Düzeltmeyi içeren ilk 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 |
Örneğin PHP 8.3.35'ten 8.4.26'ya geçmek bu açıkları kapatmıyor. PHP 8.3 dalında 8.3.36 veya daha yeni yamalı bir sürüm seçilmeli. Dağıtımınız düzeltmeyi eski sürüm numarasına geri taşıdıysa, sağlayıcının paket güvenlik duyurusunu esas alın. PHP 8.1 ve daha eski dallarda resmî düzenli güncelleme desteği bulunmadığından sağlayıcının yama durumunu ayrıca doğrulayın. [1]
Evet; upload formunun bulunmaması tek başına koruma sağlamıyor. Apache mod_php üzerinde doğrulanan saldırı, PHP'nin gelen isteği otomatik işlemesi sırasında, uygulama kodu başlamadan gerçekleşebiliyor. Bu nedenle uygulamada dosyayı kaydeden bir endpoint bulunması şart değil. [2]
PHP-FPM tarafında koşullar farklı. Belgelenen session yolunda, uygun bir uygulama işlemi sırasında oluşan fatal error sonrasında kalan durumun sonraki istekte kullanılması gerekiyor. Session upload progress mekanizması için uygulamanın session_start() çağırması da şart değil. Dolayısıyla yalnızca giriş sayfasına veya yükleme formuna bakarak güvenli olduğuna karar vermek yeterli değil. [3]
session.upload_progress.enabled = Off
Bu ayar doğrulanmış session saldırı yollarını engelleyebilen geçici bir önlem. Diğer yolları ve iki açığın tamamını kapatmıyor. İlgili yapılandırmanın istek işlenmeden önce uygulanması ve PHP worker'larının yeniden başlatılması gerekiyor. Uygulama içindeki ini_set() veya FPM'deki .user.ini bu amaçla güvenilir bir alternatif değil. Kalıcı çözüm, tam düzeltmeyi içeren PHP güncellemesi. [3]
Önce hosting panelinden veya sunucu yöneticinizden sitenin gerçekten kullandığı PHP sürümünü öğrenin. Terminaldeki php -v çıktısını tek başına yeterli kabul etmeyin: komut satırı ve web sitesi farklı PHP kurulumları kullanabilir.
Güncelleme öncesinde dosya ve veritabanı yedeği alın. Ardından ilgili PHP paketlerini güncelleyin, çalışan PHP servislerini yeniden başlatın ve sitenin yamalı sürümle çalıştığını doğrulayın. Son kontrolde kullanıcı girişi, form gönderimi, fotoğraf yükleme, ödeme ve API işlemleri gibi işletmeniz için önemli akışları deneyin.
Yalnızca güvenlik düzeltmesi için 8.3'ten 8.4'e geçmek zorunda değilsiniz. Dal değiştirmeyi planlıyorsanız önce test ortamında uyumluluğu kontrol edin; PHP 8.4'te bazı eski kullanımlar deprecated bildirimi, bazı geçersiz parametreler ise exception oluşturabiliyor. [4]
PHP tabanlı bir emlak web sitesi veya CRM kullanıyorsanız, bu açıkların etkisi sitenin çalışmamasıyla sınırlı kalmayabilir. Açığın başarıyla istismar edilmesi durumunda, uygulamanın erişebildiği müşteri iletişim bilgileri, talep ve görüşme notları, portföy sahiplerinin bilgileri ve sistemde saklanan belgeler yetkisiz kişilerin erişimine açılabilir. İlan bilgilerinin değiştirilmesi, dosyaların silinmesi veya hizmetin kesintiye uğraması da olası sonuçlar arasındadır.
Riskin kapsamı, sunucunun yapılandırmasına ve uygulamanın hangi verilere erişebildiğine bağlıdır. Örneğin yalnızca ilanları yayımlayan bir web sitesiyle müşteri kayıtlarını ve özel belgeleri de yöneten bir CRM aynı miktarda veri barındırmaz. Etkilenen bir PHP sürümünü kullanıyor olmanız, bilgilerinizin ele geçirildiğini göstermez; ancak güvenlik güncellemesinin geciktirilmemesi gerekir.
Hayır. Bir güvenlik duyurusu veya etkilenen sürüm tespiti, tek başına başarılı saldırı kanıtı değildir. Ancak güncelleme de daha önce bir ihlal yaşanmadığını kanıtlamaz. Şüpheli dosya değişiklikleri ya da beklenmeyen işlemler varsa, güncellemenin yanında olay incelemesi de gerekir.
Web sitenizde hangi PHP sürümünün kullanıldığından veya güncellemenin uygulamanızı nasıl etkileyeceğinden emin değilseniz, mevcut altyapınızın değerlendirilmesi için Alanya Digital Solutions ile iletişime geçebilirsiniz.