Kim

Lot of #PHP snark going around right now from folks who've either never written software, or never done it in PHP (in the last 20 years). I've architected, designed and hand-coded copious amounts of software in Java/Spring/Hibernate, .Net/C# Entity Framework and PHP/Symfony/Doctrine, applying very similar patterns and better practices of completely stack-agnostic concepts such as: - Test-Driven Development (and given half-day and full-day hands-on live-coding workshops at conferences worldwide) - Onion/Hexagonal Architecture - Domain-Driven Design - Data Mapper ORMs Beyond workshops, I have spoken on these topics at conferences worldwide as well. I might argue that I am not completely devoid of clue when it comes to these stacks' capabilities. In fact, I have hired, coached and cross-trained engineers across these 3 stacks. And I can assure you PHP shines within these paradigms, with an extremely vibrant, mature and robust ecosystem of Application Frameworks, Security Frameworks and Tools, and Open-Source Software Components and Libraries. PHP is not WordPress. WordPress is not PHP. If you care about quality software, PHP is a great home for you. So is Java. So is C#. So are other languages. If you suck at software you'll suck in any stack. If you're good, each stack has strengths you can play to. NOW let's talk about security. This vulnerability, is the very first RCE to this level in PHP's history. It was reported back in August. AI did help. A lot. (Wiz claims one researcher did in a week what would previously have taken a team months) Previous PHP RCEs had limited attack surfaces: - 2024 - Windows CGI Only - 2019 - One specific nginx setup - 2012 - CGI only None of which applied to reasonably-better practice typical Linux + Nginx + php-fpm deployments. This right here was ... unique, I think even across any stack. The only language-runtime equivalent to it was probably Windows IIS Code Red. That's not to say other stacks didn't have framework-level vulnerabilities with devastating impacts, if memory needs refreshed: Ruby — Rails CVE-2013-0156: every Rails app, default config, pre-controller, botnet-exploited. The strongest analogue in any stack. Java — Struts 2 CVE-2017-5638 (Equifax). Log4Shell needed the app to log attacker input; Spring4Shell needed WAR-on-Tomcat + JDK 9+ + POJO binding. Node — React2Shell CVE-2025-55182 (Dec 2025, CVSS 10, CISA KEV): default create-next-app exploitable, but Express/Fastify/Nest untouched. .NET — MS10-070 padding oracle (2010) leaked web.config/machineKey on every ASP (dot NET) site; RCE was a derived second step. Kestrel/ASP.NET Core has never had an RCE. Look ... let's drop the snark. LLM-driven vulnerability research and breaching frameworks are about to humble the absolute heck out of all of us. They already have. If you think your stack is not at risk, think again.