The technical details of web server stacks are worth learning about. Preferably not from the TV news. Last week, knowing about PHP was a niche professional interest. This week, cab drivers have opinions.
PHP is not the story; it's the illustration. There are good reasons that it has this most unfortunate of spotlights. It's very old, and it shows. Growing from roots in the mid-1990s, it has never suffered from the straitjacket of a specification, and while it has seen a lot of refactoring and modernization, it retains design elements from more than 20 years ago.
PHP is emphatically not the only project where urgent demands for better performance, reliability, and features consume the resources needed to tidy up ugly internals that appear to work just fine. Until, one day, that technical debt falls due. There will be many more days like this.
PHP's significance is that it isn't unique. The details don't matter that much, although this annotated comic book version is both fun and granular if you want to learn about it. Now the dynamics of AI-assisted cybersecurity are becoming clearer, defenders can use the tools to uncover dangerous flaws, but motivated and inventive attackers can use them too. Neither side has a monopoly on resources or ingenuity. The pace and scale of the conflict are growing so quickly that we have to look at how actual global warfare works to reconfigure.
The most pertinent aspect of PHP2Shell is the people, not the machines. We know how the LLMs identified the mix of problems and their exploitation over a few days in August, and we know how quickly any public information about such things can be weaponized. It took days, not months, to find, and hours rather than days to exploit. The correct protocol is to disclose patches privately to major, trusted organizations, and then when core services are protected, go public and go hard.
But PHP2Shell didn't work out like that, because it was too tasty a treat to keep secret. The first attacks were seen days before the anonymous Hacker News post that announced the presence and severity of the problems. That post had the correct CVE numbers. It came from someone in the loop.
The devastating effect of leaked intelligence and the tensions between keeping valuable data secret and being able to use it were abundantly apparent in the Second World War. This led to the system of clearances, classification, and trained liaison officers by which the output of places like Bletchley Park could be filtered, guided, and protected on its way to the people who needed it, and kept away from the eyeballs of those who didn't. It wasn't perfect, and security researchers don't need to work in huts while pretending to be supply clerks, but the lessons learned have proved good to this day.
Disclosure needs to be a discipline, not a protocol. It's no good telling an entire IT sec team ahead of time – the absolute minimum number of people should hold the secret for as long as possible. They have to be trained and trusted by the patch developers and their own organizations. If your organization can't field someone with the highest of standards, you'll go down the pecking order of when you're entrusted with the secrets.
Patch liaison has to become a hirable position with its place in career structures and qualification requirements. It needs to be part of an industry-wide structure where information can flow both ways.The presence and quality of the person in that role will define where you sit in the classified sequence of deployment. It's a way of managing risk in a very messy, very fast moving, and very consequential part of the IT machine. We need focus, intelligence, and skills just as much as we expect them elsewhere.
For all this to work, someone has to manage the whole thing across the industry. Tools and processes need to be developed with the explicit purpose of deploying without disclosure. Hand in hand with that must be a formalized system of identifying, analyzing, and setting in place expeditious factions for the most dangerous infrastructure components, both by deployed base and design nature.
There will be a lot of arguments whether PHP can and should be Rusted, for example, but no forum where the debate can be run to a high standard and appropriate resources provided to make the decision happen quickly. Expensive by some standards, staggeringly cheap by others.
We've never had to think formally about this as a discipline to be built to professional standards, but we've never had such a combination of complex, powerful attack vectors in a hostile and richly equipped environment. It's serious. It's war. ®