🔧 E-ticaret sistemleri geliştiricisi | 🤖 AI tutkunu | Her dil, yerinde güçlüdür; doğru yerde doğru kod! | This is the way!
Ankara, Turkey
Joined September 2009
- Tweets4.7K
- Following270
- Followers1K
- Likes2.8K
Dünya iki gündür PHP'nin çekirdeğinde keşfedilen kritik güvenlik açıklarıyla uğraşıyor. CVE-2026-109618 ve CVE-2026-109619. İkisinin de önem derecesi 9,2/10.
Güvenlik şirketleri uyarı yayımlıyor, sistem yöneticileri sunucularını güncelliyor, hosting firmaları altyapılarını kontrol ediyor.
Biz de Globya tarafında boş durmadık.
Ortağım Emre oturdu, bu süreçte gerçekten işe yarayabilecek küçük ama faydalı bir araç geliştirdi:
php2shellchecker.net/
PHP2Shell Checker.
Bir web sitesinin adresini giriyorsunuz. Araç, normal bir HTTP isteğiyle sunucunun dışarıya açıkladığı PHP bilgilerini kontrol ediyor ve kullanılan sürümün söz konusu güvenlik açıklarından etkilenme ihtimalini değerlendiriyor.
İsterseniz sunucuya erişiminiz varsa php -v çıktısını da doğrudan yapıştırabiliyorsunuz.
Ücretsiz. Üyelik yok. Reklam yok. 19 dilde çalışıyor.
Ama özellikle altını çizmek istediğim bir şey var:
Bu araç sunucunuza saldırmıyor, exploit çalıştırmıyor, açık sömürmeye kalkışmıyor.
Dolayısıyla “güvenlisiniz” diye kesin hüküm de vermiyor. Sunucunun açıkladığı bilgilerle bir ön değerlendirme yapıyor. Sürüm gizlenmişse veya güvenlik düzeltmesi eski sürüme geri taşınmışsa bunu da hesaba katmanız gerekiyor.
Çünkü güvenlikte yanlış bir güven duygusu, bazen güvenlik açığının kendisi kadar tehlikelidir.
Sitenin içinde güncelleme rehberi, düzeltilmiş sürümler, resmî kaynaklar ve sunucuda yapmanız gereken kontroller de var.
Bana sorarsanız yazılım dünyasında ihtiyacımız olan şey tam olarak bu yaklaşım.
Bir güvenlik olayı çıktığında yalnızca felaket senaryoları üretmek ya da sosyal medyada ahkâm kesmek yerine, insanların işini kolaylaştıracak bir şey ortaya koymak.
Dünyayı kurtardığımızı iddia etmiyoruz. PHP'nin bütün güvenlik problemlerini de çözmedik.
Ama belki bir sistem yöneticisinin eski bir PHP sürümünü fark etmesini sağlayacağız. Belki bir hosting müşterisi sağlayıcısına doğru soruyu soracak. Belki birisi güncellemesini bugün yapacak.
Bazen faydalı yazılım dediğimiz şey bu kadar basit.
Emre'nin eline sağlık.
“PHP öldü” tartışmaları devam ederken biz yaşayan sistemleri nasıl ayakta tutacağımızla uğraşmaya devam ediyoruz. 🙂
PHP2Shell meselesi iki günde kapanıp gidecek bir güvenlik olayı değilmiş. Rakamlar pek iç açıcı görünmüyor.
21 Ekim'de PHP'nin çekirdeğindeki iki kritik güvenlik açığı için yamalar yayımlandı. Aradan iki gün geçti.
Censys'in 23 Ekim 2026 tarihli küresel tarama verilerine göre:
🌍 41,3 milyondan fazla PHP servisinde, 21 Ekim'den bu yana etkilenen sürüm gözlemlenmiş.
🔴 34.326.869 servis hâlâ etkilenen sürüm bilgisi gösteriyor.
🟢 7.054.228 serviste yamalı sürüme geçiş tespit edilmiş.
Yani gözlemlenen servislerin yaklaşık %83'ü hâlâ riskli sürüm bilgisi gösteriyor.
Dikkat, burada 34 milyon web sitesinin kesin olarak savunmasız olduğunu söylemiyoruz. Bunlar servis bazlı tarama kayıtları. Aynı sunucuda birden fazla servis bulunabilir; ayrıca bazı Linux dağıtımları sürüm numarasını değiştirmeden güvenlik yaması uygulayabilir.
Ama rakamın büyüklüğü ortada.
Bizim Globya'da geliştirdiğimiz PHP2Shell Checker'ın istatistikleri de ilginç.
Şu ana kadar 1.026 kontrol yapılmış. PHP sürümü tespit edilip sınıflandırılabilen kontrollerin:
✅ %34'ü yamalı sürümde.
⚠️ %63'ü etkilenen veya resmî desteği sona ermiş sürümde.
Bunlar elbette internetin tamamını temsil eden rastgele bir örneklem değil. Aracı kullanan kişilerin kontrol ettiği sistemler. Ancak bireysel kontrollerde bile güncel olmayan PHP kurulumlarının ne kadar sık karşımıza çıktığını gösteriyor.
Ve daha ilginç bir ayrıntı var.
Kontrol edilen sistemler arasında PHP 7.4.33, 5.6.40, hatta 5.3 gibi yıllar önce desteği bitmiş sürümler hâlâ görülüyor.
2026 yılındayız.
Bir tarafta PHP'nin öldüğünü anlatanlar var. Diğer tarafta on yıldan eski PHP sürümleriyle production çalıştıranlar.
PHP'nin ölmesinden önce bazı sunucuların emekli edilmesi gerekiyor galiba.
Şaka bir yana, burada asıl problem teknolojinin yaşı değil. Bakımı yapılmayan sistemler.
Güvenlik yaması yayımlandı diye güvenlik olayı bitmiyor. O yamanın milyonlarca sisteme ulaşması, uygulanması, süreçlerin yeniden başlatılması ve gerekiyorsa geçmişe dönük ihlal incelemesi yapılması gerekiyor.
Üstelik sistem bugün yamalanmış olsa bile, dün istismar edilmediği anlamına gelmiyor.
İşte gerçek dünyadaki yazılım mühendisliği biraz da böyle bir şey.
Yeni framework öğrenmek güzel. Yeni dil öğrenmek daha da güzel.
Ama eski diye küçümsediğiniz sistemlerin dünyanın dört bir yanında çalışmaya devam ettiğini ve güvenli tutulması gerektiğini de unutmamak lazım.
Emre, PHP2Shell Checker'a bir de canlı istatistik sayfası ekledi. PHP sürümlerinin dağılımını, yama oranlarını, barındırma ülkelerini ve Censys'in küresel verilerini takip edebiliyorsunuz.
php2shellchecker.net/tr/stat…
Biz verileri herkesin görebileceği şekilde yayımlamaya devam edeceğiz.
Çünkü mesele PHP'nin ölüp ölmediği değil. Mesele, yaşayan sistemleri ne kadar güvenli tuttuğumuz.
PHP bugün 8.5.12, 8.4.27, 8.3.36 ve 8.2.35'i çıkardı: PHP2Shell (CVE-2026-109618/109619), CVSS 9.2, kimlik doğrulamasız RCE. Güncelleyebilen hemen güncellesin. Bu dizi güncelleyemeyenler için.
Yamalı sürümler, test edilmiş Apache/nginx/FPM ayarları ve ajan görev metinleri burada: halityesil.com/php2shell-yam…
Halit YEŞİL retweeted
Security called me at 6:12 AM today.
"Patch every PHP server immediately."
I asked what happened.
"Two critical vulnerabilities. Remote code execution. No authentication required."
Cool.
How many PHP servers do we have?
According to inventory: 12
According to reality:
Nobody knows.
We found one running WordPress.
Three running old internal tools.
One under someone's desk.
Two inside vendor appliances.
A forgotten employee directory from 2016.
And a server named:
PHP-OLD-DO-NOT-TOUCH
Naturally, that one runs payroll exports.
Then we found a PHP 5.6 box.
I asked who owned it.
The documentation said:
BRIAN.
Brian left in 2019.
We called Brian.
He said:
"Oh wow, that's still running?"
Excellent.
By 8 AM, leadership joined the incident call.
CEO:
"Can hackers actually get in?"
Security:
"Potentially yes."
CEO:
"Without a password?"
Security:
"Yes."
CEO:
"Then why do WE need passwords?"
Not the lesson.
Finance asked if we could wait until the weekend to patch because downtime affects revenue.
Security explained that the alternative was letting strangers execute code on our servers.
Finance asked for a cost comparison.
At 9:17, someone suggested temporarily taking the vulnerable websites offline.
Marketing refused.
"Our campaign is live."
So for the next hour, the company officially decided maintaining a landing page for 20% off webinar registration was more important than preventing remote server takeover.
We finally patched everything we could find.
Then our scanner discovered another PHP server.
Hostname:
TEMP-PHP-2014
Uptime:
4,512 days.
Nobody knows what it does.
Nobody owns it.
Nobody can shut it down.
But every time we block network access, the warehouse stops printing shipping labels.
Security has classified it as critical infrastructure.
It is running PHP 5.4.
The vulnerability has existed longer than half our employees.
The emergency patch took four hours.
Finding out what PHP actually runs took eleven.
The internet isn't held together with code.
It's held together with servers everyone is afraid to turn off.
Halit YEŞİL retweeted
PHP isn’t the most sexy language, I give you that. Where I live in Belgium, government, school, hospital, help line, media, news, and what not websites are down.
It’s not because we don’t often hear about it that it isn’t big. Usually, PHP simply does the job. Nothing sexy, nothing worth shouting about. Only on these rare occasions do you get a feeling of the true impact of the language.
“PHP öldü” diyenler, bugün cenazenin neden bütün interneti ayağa kaldırdığını açıklayabilir mi?
Yıllardır aynı terane. PHP öldü, PHP bitti, PHP eski teknoloji, gerçek yazılımcılar artık PHP kullanmıyor...
Hatta bazı arkadaşlar için PHP yazdığını söylemek, teknoloji dünyasında sabıkalı olmakla eşdeğer.
Güzel kardeşim, bir sandalyeye otur. Sana bugün internette neler olduğunu anlatayım.
Takvim 21 Ekim 2026.
PHP'nin çekirdeğinde iki kritik güvenlik açığı ortaya çıktı. CVE-2026-109618 ve CVE-2026-109619. İkisinin de CVSS skoru 9,2. Uygun koşullarda kimlik doğrulaması olmadan uzaktan kod çalıştırılabiliyor.
Yani mesele, WordPress'e yüklenen dandik bir eklenti, kötü yazılmış bir Laravel uygulaması veya SQL sorgusuna parametre gömmüş acemi bir yazılımcı değil.
Doğrudan PHP'nin kendisi.
Ve dünya bir anda ayağa kalktı.
NSA uyarı yayımlıyor. Almanya'nın BSI'ı, Fransa'nın ANSSI'si, İngiltere'nin NCSC'si, Avrupa Birliği'nin CERT-EU ekibi alarm veriyor.
Cloudflare koruma kuralları devreye alıyor. Cisco Talos saldırı tespit imzaları hazırlıyor. Palo Alto Networks milyonlarca potansiyel maruziyeti raporluyor. Google Cloud müşterilerini uyarıyor. OpenAI, Wiz ve güvenlik araştırmacıları PHP ekibiyle koordineli çalışıyor.
Avrupa'da bazı kamu kurumları, sağlık ve eğitim hizmetleri önlem amacıyla sitelerini geçici olarak kapatıyor.
Bir tarafta güvenlik ekipleri yamaları yetiştirmeye çalışıyor, diğer tarafta sistem yöneticileri production sunucularının başında nöbet tutuyor.
Hani PHP ölmüştü?
Peki, ölü bir dil için neden dünyanın dört bir yanında devlet kurumları, teknoloji devleri ve siber güvenlik ekipleri seferber oluyor?
Rakamları da masaya koyalım.
W3Techs'in 21 Ekim 2026 verilerine göre, sunucu tarafında kullanılan programlama dili tespit edilebilen web sitelerinin %69,3'ünde PHP var.
Tekrar okuyun: %69,3.
Bu, internetteki her sitenin %69,3'ünün savunmasız olduğu anlamına gelmiyor. Matematikle kavgalı değiliz. Ama PHP'nin web ekosistemindeki ağırlığını gayet net gösteriyor.
Palo Alto Networks'ün Cortex Xpanse telemetrisi ise 22,6 milyondan fazla potansiyel maruziyet kaydı tespit etmiş.
Bu da 22,6 milyon sunucunun ele geçirildiği anlamına gelmiyor. Maruziyet kaydıyla ele geçirilmiş sistem arasındaki farkı biliyoruz.
Ama bu büyüklükte bir saldırı yüzeyinden söz ediyorsak, ortada pek de ölüye benzeyen bir şey yok.
PHP'nin cenazesini kaldırmaya çalışanlar, meğer internetin taşıyıcı kolonlarından birine tabut hazırlıyormuş.
Şimdi burada küçük ama hayati bir ayrım yapalım.
Bu güvenlik açığı PHP'nin başarısı değil. Tam tersine, yıllardır kullanılan bir dilin çekirdeğinde böyle kritik bellek yönetimi kusurlarının bulunması ciddi bir problem.
Açık kaynak romantizmi yapıp güvenlik zaafını halının altına süpürecek değilim.
Kritik açık kritiktir. İster PHP'de çıksın, ister Java'da, ister Python'da, ister dünyanın en havalı Rust projesinde.
Ama bir güvenlik açığının bu kadar geniş çaplı sonuç doğurması, o teknolojinin ne kadar yaygın ve ne kadar kritik bir altyapının parçası olduğunu da gösterir.
İşte yıllardır anlatamadığımız mesele bu.
Popüler olmakla moda olmak aynı şey değil.
Yazılım dünyasında bazı arkadaşlar teknolojinin değerini konferans alkışlarıyla, GitHub yıldızlarıyla veya LinkedIn'de hangi framework'ün daha çok konuşulduğuyla ölçüyor.
Sanki production ortamındaki yazılım, her altı ayda bir gardırop değiştirir gibi teknoloji değiştirmek zorundaymışız gibi.
Oysa gerçek dünya biraz farklı.
Orada sipariş alan e-ticaret siteleri var. Ödeme işleyen sistemler var. Kamu hizmetleri, hastaneler, üniversiteler, kurumsal uygulamalar, yılların birikimiyle çalışan yazılımlar var.
Ve bunların önemli bir bölümünün motor kaputunu açtığınızda karşınıza PHP çıkıyor.
Üzerindeki boya eskimiş olabilir. Yeni nesil framework'ler kadar havalı görünmeyebilir. Ama motor çalışıyor, yük taşıyor ve birçok yerde işin ekonomik gerçeklerine hâlâ gayet iyi cevap veriyor.
Ben yıllardır PHP ile üretim ortamında çalışan biriyim. Hatalarını da gördüm, saç baş yolduran taraflarını da.
Daha geçen ay kendi blogumda PHP 8.1'den 8.5'e yükseltme yaparken yaşadığım sorunları yazdım. Üstelik yıllardır ertelediğim güncelleme yüzünden kendime de güzelce saydırdım.
PHP'yi savunmak, eski sürümü production'da çürümeye bırakmayı savunmak değildir.
Tam tersine.
Bugün PHP 8.5 kullanıyorum demek bile tek başına yeterli değil. Güvenlik düzeltmesinin bulunduğu 8.5.12'ye geçmeniz gerekiyor. Diğer desteklenen dallar için de 8.4.27, 8.3.36 ve 8.2.35 yayımlandı.
Çünkü mesele hangi dili kullandığınızdan önce, kullandığınız teknolojinin sorumluluğunu alıp almadığınız.
PHP kullanıyorsunuz diye kötü yazılımcı olmazsınız.
Node.js kullanıyorsunuz diye yazılım mimarı olmazsınız.
Go öğrenince dağıtık sistem uzmanlığı otomatik yüklenmez.
Rust yazınca da bellek güvenliği dışındaki bütün güvenlik problemleri sihirli biçimde ortadan kalkmaz.
Diller araçtır. Mühendislik ise o araçlarla ne yaptığınız, neyi ölçtüğünüz, nasıl test ettiğiniz ve nasıl işlettiğinizdir.
Bugünkü olaydan çıkarılacak ders “PHP kötüymüş” değil.
Ders şu:
İnternet, hakkında yıllardır ölüm ilanı yazılan teknolojilerin üzerinde çalışmaya devam ediyor.
Ve o teknolojilerde kritik bir sorun ortaya çıktığında, konferans sahnelerinde anlatılan masallardan bağımsız olarak gerçek dünyanın nasıl etkilendiğini hep birlikte görüyoruz.
PHP ölmedi.
PHP kusursuz da değil.
PHP, 2026 yılında hâlâ web'in en yaygın sunucu tarafı teknolojilerinden biri. Büyük bir mirası, ciddi teknik borçları ve aynı ölçüde büyük bir sorumluluğu var.
Bugün yaşananlar PHP'yi kutsamak için değil, bu sorumluluğun büyüklüğünü anlamak için önemli.
O yüzden “PHP öldü” demek isteyen arkadaşlara küçük bir önerim var:
Önce bir production sunucusunun başına geçin. Gerçek trafik görün. Güvenlik yaması uygulayın. Geriye dönük uyumluluk yönetin. Birkaç milyon satırlık çalışan sistemin sorumluluğunu alın.
Sonra hangi dilin ölü, hangisinin diri olduğuna birlikte karar veririz.
Bugün dünyanın dört bir yanında insanlar PHP'yi yamamak için uğraşıyor. Çünkü çalışan sistemleri ayakta tutmak, hangi dilin daha havalı olduğuna dair tartışma kazanmaktan çok daha önemli.
Ve son bir şey...
Bir programlama dilinin öldüğünü anlamak için Twitter'daki teknoloji kahinlerine değil, gerçek dünyadaki kullanımına bakın.
Çünkü bazı teknolojiler gerçekten ölür. Bazılarının ise yıllarca cenaze namazını kıldırırsınız, tabutu taşıyanların sistemleri bile üzerinde çalışmaya devam eder.
#PHP #PHP2Shell #WebDevelopment
PHP yaması an itibari ile yayınlandı
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Ajanla uzun bir oturumun kırkıncı turunda ajanın elindeki talimat sizin yazdığınız cümle değil, o cümlenin özeti. Bir sıkıştırma daha olursa özetin özeti. Kulaktan kulağa oyunu; bu kez bütün kulaklar aynı modelin.
Dilim tanımı, dört aracın plan modları ve geri alma sınırları, PLAN.md örneği ve dilim ölçen PHP betiği burada: halityesil.com/vibe-coder-4-… — Claude Code en iyi uygulamalar dokümanı: code.claude.com/docs/en/best…
Checkpoint'e yaslanmayın. Claude Code'un /rewind'ı ajanın bash ile yaptığı rm, mv, cp değişikliklerini geri getirmiyor. Cursor'un checkpoint'i elle yaptıklarınızı izlemiyor. Codex'in komut tablosunda geri alma yok. Ortak payda git.
2026 itibarıyla banka/sanal POS tarafındaki gecikme artık “henüz erken” veya “ihtiyaç duyan geçsin” diye geçiştirilebilecek bir noktada değil.
E-ticaret geliştiricileri ve altyapı sağlayıcıları (CDN, hosting, framework’ler) yıllardır dual-stack’e adapte oldu. Modern tarayıcılar Happy Eyeballs ile IPv6’yı tercih ediyor, ISP’ler de uzun zamandır abonelere dual-stack (hatta bazı yerlerde IPv6-only + NAT64) veriyor. Bireysel kullanıcının “ben IPv4 istiyorum” deme şansı zaten yok. Bu yüzden site tarafında IPv6’yı desteklememek, müşteri kaybı ve hata demek oluyor. Biz de bunu yaşadığımız için AAAA’yı kapatma çözümüne gittik; bu da tipik bir geçici yama.
Banka ve sanal POS tarafında ise durum farklı. Onlar:
IP adresini genellikle fraud, risk skorlama, 3D Secure loglama ve “CustomerIPAddress” gibi alanlarda kullanıyor.
Bu alanları yıllar önce IPv4 string’i olarak tasarlamışlar ve validasyonu da ona göre yazmışlar (regex, inet_aton, “valid IP” kontrolü vs.).
Değişiklik yapmanın maliyeti ve regülasyon (BDDK, PCI-DSS, denetim) yükü yüksek olduğu için “çalışıyor, dokunmayalım” refleksi devam ediyor.
Ortaya çıkan şey şu: Trafiğin bir kısmı IPv6 ile geliyor, POS “bu geçerli IP değil” deyip işlemi düşürüyor. Bu, kullanıcı hatası değil, karşı tarafın eski varsayımı. “Nereden çıktı bu IPv6” demek için gerçekten çok geç. IPv4 havuzu tükeneli yıllar oldu, mobil operatörler ve büyük ISP’ler IPv6’yı varsayılan hale getirdi.
Türkiye’deki genel kullanım oranı hâlâ düşük kalsa da (2026 başında yaklaşık %19 civarı), e-ticaret ve bankacılık trafiğinde IPv6 payı daha yüksek ve büyüyor.
Bunu “ihmalkârlık” olarak görmek abartılı değil. Çünkü:
Karşı taraf (e-ticaret) ve altyapı (ISP) uyumlu.
Sorun, sadece kendi sistemlerinin IPv6’yı “geçerli IP” saymamasından kaynaklanıyor.
Çözüm teknik olarak zor değil (IPv6 string’ini de kabul etmek, loglamak, fraud kurallarını dual-stack’e göre güncellemek). Asıl engel öncelik ve süreç.
Bazı bankalar/POS sağlayıcıları bunu çözmüş görünüyor. @GarantiBBVA gibi bazıları ise geride kalmış. Bu da “sektörde herkes böyle” argümanını zayıflatıyor.
Kısaca: Geliştirici tarafı olarak “biz uyumlu kodluyoruz, banka hâlâ IPv4 sanıyor” dememiz haklı. Bankanın 2026’da hâlâ “valid IP = IPv4” diye işlemi reddetmesi ise artık teknik borç ve operasyonel gecikme. Geçici çözüm olarak AAAA kapatmak iş görüyor ama kalıcı çözüm POS tarafının IPv6’yı da birinci sınıf vatandaş gibi kabul etmesi.
