21 Ekim 2026'da PHP güvenlik ekibi, acil bir güncelleme yayımladı. İki kritik açık — CVE-2026-109618 ve CVE-2026-109619 — PHP çekirdeğinin kendisinde, yani web'in yaklaşık yüzde kırkında çalışan yorumlayıcıda bulunuyor. Her ikisi de kimlik doğrulaması gerektirmeksizin uzaktan kod çalıştırılmasına (RCE) izin veriyor ve CVSS v4.0 puanı 9.2. PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 ile giderildi; ancak milyonlarca sunucu henüz yamalanmamış durumda. Araştırmacılar, kamuya açıklanan proof-of-concept kodunun yayımlanmasının ardından WordPress sitelerine yönelik istismar denemelerinin saatler içinde başladığını raporluyor. 1 2
Bu PHP krizinin hemen öncesinde, Eylül 2026'da CISA, WordPress çekirdeğindeki CVE-2026-87902 açığını "Bilinen Sömürülen Açıklar" kataloğuna ekledi. 3 4 WordPress 4.7.0–7.1.1 sürümlerini etkileyen bu remote file inclusion açığı da CVSS 9.2 ile derecelendirildi ve düzeltme yayımlanır yayımlanmaz aktif istismar başladı. Bunların yanı sıra Bricksforge eklentisinde keşfedilen CVSS 10.0 açığı (Ekim 2026) da saldırganlar tarafından hızla kullanıma alındı. 5
Bu kriz tek bir soruyu gündeme getiriyor: Sunucu yazılımının kendisi, çalıştırdığı dilden bağımsız olarak ne kadar güvenli?
PHP Açıklarının Kök Nedeni: Yorumlayıcı Katmanı
CVE-2026-109618 ve CVE-2026-109619, PHP'nin istek işleme sırasında iç veri yapılarını kısmen başlatılmış hâlde bıraktığı ve daha önce serbest bırakılan belleğin ardından kullanılabildiği iki farklı senaryoyu kullanıyor. Açıkların özünde, C ile yazılmış bir yorumlayıcının bellek yönetimindeki ince hatalar yatıyor.
PHP'nin tasarımı bu tür risklere yapısal olarak açık. Her HTTP isteği PHP yorumlayıcısını çalıştırır; yorumlayıcı uygulamanın kaynak kodunu okur, derler ve yürütür. Bu çok katmanlı yapı, saldırı yüzeyini ikiye katlar: hem uygulama kodundaki (WordPress, eklentiler) hatalar hem de yorumlayıcının çekirdeğindeki hatalar birer giriş kapısına dönüşür. Nitekim ekim 2026 krizinde WordPress'in kodunda değil, PHP'nin kendisinde bir açık bulundu — ve WordPress sitelerinin tümü bu riskten etkilendi.
FFS'in C++ ile İnşa Edilmesinin Güvenlik Gerekçesi
FFS, PHP'nin yorumlayıcı modeline karşı kasıtlı olarak farklı bir temel üzerine oturur.
Yorumlayıcı katmanı yok. FFS, C++23 ile yazılmış ve Linux üzerinde doğrudan çalışan tek bir yürütülebilir dosyadır. HTTP isteği geldiğinde PHP, Python veya Ruby yorumlayıcısı çalıştırılmaz; kaynak kodu okunmaz. Çalışan kod, derleme zamanında üretilmiş ve tip sistemi tarafından doğrulanmış makine kodudur. CVE-2026-109618 ve CVE-2026-109619 gibi yorumlayıcı düzeyindeki açıkların FFS'i etkilemesinin hiçbir yolu yoktur.
Bellek güvenliği derleme zamanında sağlanır. PHP'de use-after-free ve kısmen başlatılmış arabellek hataları çalışma zamanında ortaya çıkar. FFS, modern C++ semantikleriyle (RAII, akıllı işaretçiler, move semantics) bu hata sınıfını derleme zamanında büyük ölçüde ortadan kaldırır. Nesnenin ömrü derleyici tarafından izlenir; bellek, kapsam dışına çıkıldığında deterministik olarak serbest bırakılır.
Bileşen izolasyonu saldırı yüzeyini sınırlar. Her sayfa, .so paylaşılan kütüphanesi olarak bağımsız yüklenir. Bir bileşen sorunlu olsa bile çekirdek sunucu kodu etkilenmez. WordPress'te ise bir eklenti açığı tüm uygulamanın yürütme bağlamında çalışır.
Tek bağımlılık zinciri, tek saldırı yüzeyi. WordPress 55.000'den fazla eklentiye, sayısız PHP kitaplığına ve npm paketine bağımlıdır. FFS'in çalışma zamanı bağımlılıkları tek elde tutulur; her bağımlılık SHA doğrulamasıyla paketlenir.
Gerçek Dünyadan Kanıt: fedem.eu Günde ~300 Saldırı Probuyla Karşılaşıyor
fedem.eu, teorik güvenlik değerlendirmelerinin ötesinde, gerçek saldırı trafiğini her gün deneyimliyor. Günlükler tutarlı biçimde yaklaşık 300 benzersiz IP'den gelen otomatik tarama ve istismar denemelerini gösteriyor. Bu problar arasında en yoğun olanlar şunlar:
/wp-admin,/wp-login,/wp-config.phpistekleri — WordPress güvenlik açıklarını hedefleyen tarayıcılar.phpuzantılı dosyalara yönelik istekler — PHP yorumlayıcısı ve uzaktan dosya dahil etme denemeleri/phpmyadmin,/pma— veritabanı yönetim paneli keşfieval-stdin.php,phpunit— PHPUnit RCE istismarları/.env,/.git/config,private.key— gizli bilgi sızdırma girişimleri- JNDI enjeksiyonu (
${jndi:...}) — Log4Shell kalıntı saldırıları ../yol geçişi ve/etc/passwdprobları — dosya sistemi keşfi
Tüm bu saldırı vektörlerinin FFS kurulumunda hiçbir anlamı yok: sunucuda PHP yorumlayıcısı çalışmıyor, WordPress yok, veritabanı yönetim paneli yok, .php dosyası yok. Ancak tarayıcılar bu gerçekten habersiz, saniyeler içinde yüzlerce probe gönderiyor.
FFS Guard: İlk İsteğinde Engelle
FFS'in yerleşik Guard modülü bu tehdide tek tepkiyle yetinmiyor; davranışı analiz ederek IP'yi blacklist'e alıyor.
Yol ve Örüntü Analizi
Guard, iki katmanlı bir kural kümesiyle çalışır:
Yasaklı yollar (banned-paths.txt) — WordPress, Joomla, Drupal, phpMyAdmin, /cgi-bin, /admin, /phpmyadmin, Git/SVN metadata dizinleri ve Linux sistem dizinleri gibi FFS'te hiçbir zaman var olmayan yolları kapsar. Bu yollardan birine gelen istek, Wt oturumu bile oluşturulmadan HTTP 404 döndürür; greylist sayacı artar.
Örüntü analizi (banned-patterns.txt) — Regex tabanlı ikinci katman, yol uzantılarını, sorgu parametrelerini ve URL kodlamasını çözdükten sonra tarar. Herhangi bir .php isteği, eval-stdin, JNDI ${...} kalıpları, yol geçiş dizileri (../), gizli dosya adları (.env, id_rsa, .git-credentials) burada eşleşir.
Honeypot Mekanizması
Guard'ın en güçlü unsurlarından biri honeypot yollarıdır. Sitenin hiçbir yerinde link verilmeyen, hiçbir sitemap'te yer almayan sahte yollar sunucuya kayıt edilir. Meşru hiçbir ziyaretçi ya da iyi davranışlı bot bu yolları keşfedemez. Bu yollardan birine erişen IP, greylist eşiğini beklemeksizin anında kalıcı blacklist'e alınır — otomatik tarayıcı için kesin kanıt.
Kademeli Tepki
Bir IP greylist eşiğini aşarsa otomatik blacklist'e alınır. Yeterince ağır bir işaret (honeypot isabeti, belirli kritik örüntüler) varsa bu terfi anında gerçekleşir. Karar, sunucu başlamadan önce kuralları yükleyen whitelist filtresiyle de korunur: beyaz listedeki bir IP asla blacklist'e düşmez.
Bu tasarımın kritik özelliği, saldırıyı uygulama katmanına ulaşmadan, HTTP katmanında, Wt oturumu oluşturulmadan kesmesidir. PHP tabanlı sistemlerde her /wp-admin isteği en azından yorumlayıcı başlatır, oturum kurar ve bellek ayırır. FFS'te bu maliyet sıfırdır.
PHP'den C++'a: Rakamlarla Tablo
| PHP / WordPress | FFS (C++) | |
|---|---|---|
| Yorumlayıcı katmanı | Var — her istekte | Yok |
| Ekim 2026 PHP RCE açığı | Doğrudan etkilenir | Etkilenmez |
| CVE-2026-87902 (WordPress RCE) | Doğrudan etkilenir | Etkilenmez |
| Bağımlılık yüzeyi | 55.000+ eklenti ekosistemi | Tek, SHA-doğrulamalı |
| Bellek yönetimi | Çalışma zamanı GC, use-after-free riski | RAII, derleme zamanı ömür denetimi |
| Saldırı tespiti | Üçüncü taraf eklentiye bağımlı | Yerleşik Guard modülü |
| HTTP katmanı engeli | Yok | Wt oturumu açılmadan 404 |
Sonuç
PHP/WordPress topluluğu bir kez daha acil yama döngüsündedir. Bu kez sorun uygulama kodunda değil, çalışma zamanının kendisindedir; yamalar yüklense bile istismar girişimleri eylülden bu yana devam ediyor.
FFS bu tartışmanın içinde değil. Sunucuda PHP yorumlayıcısı olmadığı için PHP açıkları bağlamı dışında kalır; WordPress eklenti ekosistemi olmadığı için CVE-26-87902 türü zincirler kurulmaz. Güvenlik, üçüncü taraf bir eklente devredilmemiş, doğrudan çekirdeğe işlenmiştir.
fedem.eu'nun günlük 300 IP'lik saldırı trafiği bir sorun değil, Guard'ın sağlığını gösteren bir ölçümdür. Bu sayılar, açık kaynaklı PHP yorumlayıcısı ve 55.000 eklentiden oluşan bir ekosisteme dayalı bir sistemde çok farklı bir anlam taşırdı.
Mimariye dayalı güvenlik ve FFS hakkında konuşmak için iletişime geçin.
Kaynaklar
- OX Security — CVE-2026-109618 & CVE-2026-109619: Two Vulnerabilities Allow Unauthenticated RCE in PHP ↩
- Patchstack — Major security alert: PHP vulnerable to critical RCE, attacks ongoing ↩
- The Hacker News — Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure ↩
- CISA — CISA Adds One Known Exploited Vulnerability to Catalog (2026-09-25) ↩
- The Hacker News — Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE ↩
