29.10.2026
New age of security chaos
PHP2Shell is the latest of many disastrous security vulnerabilities. Their discovery and exploitation are easier than ever in the age of AI. Buckle up, advises Paul Demarty
On October 23, the government blithely advised the British population that they should have three days’ worth of drinking water and canned foods on hand, in case of emergency. “Unexpected events,” said smiley Andy Burnham, “seem to be becoming more common.” (Keep calm, and carry on panicking.)
This is widely interpreted as part of the overall political offensive in favour of rearmament in the face of the supposed Russian threat, and has therefore been widely ridiculed by this country’s anti-imperialists. Yet in a certain respect, we must regretfully accept that it is not terrible advice. The government mentioned climate as a possible cause of the “unexpected”, and indeed Britain has been battered by two fierce Atlantic storms in quick succession.
It also mentioned technological problems, and here the timing was even more ominous. Two days before, it was revealed that two critical security flaws in the PHP programming language had been fixed. The world’s IT people - among them your humble correspondent - were suddenly in a rush to apply them. Details remain fuzzy about exactly how these flaws could be exploited - only that it was now certain that they could be. The extent of the coordinated push to get the fixes out - from the PHP maintainers themselves to cloud providers and others - strongly suggests that this is a very serious matter.
Bad design
PHP is a stupendously popular programming language. It is the basis for several web development platforms - most notably WordPress, which started out as a blog-maker in the late 1990s, but is now by far the most common construction set for websites across the world. This attack surface is very concerning, and many government and corporate websites were taken offline while the fix was applied.
Programming languages in the end are themselves programs - you feed them source code as input, and they give you back instructions executable by an actual computer as output. (Computers cannot inherently understand human-written code - they understand machine code, which consists entirely of numbers, some of which represent data, like a web page or a Word document, and some of which represent the small number of basic operations, addition and so forth, that a computer processor can actually do.) Programs can always have bugs.
Unfortunately, given its popularity, PHP is well known among programmers, IT and information security people as a catastrophically poorly designed piece of software. Much of this poor design is vexatious, but basically harmless. It is extremely inconsistent. A program will blow up in your face, even if there should be a way to handle the problem; it will, alternatively, motor on and produce idiotic output when really it should blow up. More sophisticated programming concepts have been spliced in over the years, to the point that it now resembles nothing so much as a huge philosophical teratoma. Writing it is torture to the seasoned professional, but superficially easy to the clueless beginner. (Fortunately, over the years, the far superior Python programming language has supplanted it as the typical language of coding education.)
Scandals
The security flaws in PHP, however, are not so benign. In the earlier days of the language, from roughly 1993 to 2010, PHP was routinely the centre of cybersecurity scandals. Perfectly reasonably written websites would be found, all of a sudden, to allow attackers to take over their servers with trivial scripts, because of design decisions by the language maintainers that, to any industry professional - or so you would have thought! - were prima facie insane. (Much of the insane stuff is still in there, for backwards compatibility reasons, though later versions of the language have been generally more robust.)1
So it was that we all, as an industry, woke up to the news on October 21 - half with a nostalgic chuckle for the good old days, half with PTSD flashbacks. Some of the story, indeed, is good old-fashioned PHP insanity. The parts of the code that were patched had been identified as potentially vulnerable some years ago; but the maintainers could not agree on how to fix them, and with no actual proof-of-concept exploit, they felt no urgency. Perhaps they should have done, since these were memory-safety problems, which - sparing the technical details - are among the most serious vulnerabilities, if exploited.
The bigger story, however, is how the exploits were apparently identified a couple of months ago: by security researchers using AI coding agents. The use of large language models (LLMs) for code generation is now widespread, and rightly so: programming is a generally more pleasant and less frustrating activity with LLMs, even taking into account their occasional flights of fancy. If you want to find an exploit for a vulnerability - I should say that both the reported exploits originated from legitimate security researchers and not ‘black-hat’ hackers, for which we should all be grateful - throwing agents in the general direction of a known weak point is a good way to do it.
But, as I argued with respect to the recent FBI hack incident,2 there is no technical difference between finding an exploit in order to harden a system and finding one in order to compromise it. The available technologies are equally capable in either case. It is unusual, by my reckoning, for exact details of the exploits to be withheld for quite this long; but surely uppermost in the minds of the responsible parties is the problem that, as soon as this is revealed, an onslaught on much of the known web will be unleashed.
In the old days, when a vulnerability was discovered, a hacker at least had to build her own botnet and write her own scripts (or at least some hacker had to write them, to be copied by others). The level of technical knowledge required to make mischief, in the age of Claude, is very minimal. Tell Claude to read about the vulnerability; tell it to write a script, in whatever massaged way is required to get around the feeble safeguards: Bob’s your uncle and Fanny’s your aunt. Possibly the mere fact of the patches is enough input: after all, they necessarily indicate exactly where the problems are in the PHP code, so the work of these doughty security researchers may be repeated trivially.
Though PHP is widely used, the dangers of this particular problem are probably limited. It is basically used for writing websites and web applications, for which it is designed, such as it is. People do not control logistics, or airliners, or nuclear weapons arsenals, with PHP. Likely the worst that can happen is the leak of passwords, bank details and the like: bad enough, but not civilisation-threatening. Yet similar problems have arisen in far more troubling places. The 2014 Heartbleed vulnerability, which affected the very basis of encryption over the internet and therefore potentially exposed every networked application in the world to attack, was potentially far more severe. But the low-effort hackers of 2014 did not have Claude.
The struggle between hackers and information security has always been in the nature of an arms race, but an oddly asymmetric one. The decentralised architecture of the internet, the ease with which it spills over juridical borders and its ample support for obscuring the source of attacks, mean that attackers are not in general exposed to repercussions for their actions. It is an arms race, as it were, between one state with a nuclear arsenal and another with missile defence.
Yet these are not actual states, of course. They are more like tribes that spill over national borders. The ‘national interest’ of actually existing states employs both these tribes, as in the old days a king might have hidden behind a high-walled castle and, at the same time, hired steppe nomads as mercenaries to attack the next king. One attempts, as best as possible, to defend one’s own territory, while simultaneously maintaining offensive capacity against others.
State actors
It is this fact of inter-state competition that makes the whole situation more dangerous. The immediate impact of the availability of AI coding tools in the hacking space is one of upward-levelling - weaker actors become better equipped relative to stronger actors. But this effect is not uniform. Individuals close the gap to criminal gangs; small criminal gangs to larger ones. Nation-state actors have always enjoyed an enormous advantage (although even there the gaps between weak and strong are smaller than they are with respect to conventional and nuclear armaments).
It is a convenient fact for us, perhaps, that PHP is essentially an Israeli product. The existence of this absurd software system might be regarded, if one were uncharitable, as a single, unending cyberattack against the entire world - a sort of digital Samson doctrine. Israel is one of the most offensively capable cyber actors in the world, certainly relative to population size. The likes of Burnham would cite the Russians as the big threat here; no end of luckless people the world over would mention the Americans.
We have not really woken up to the instability this poses. The repeated cyberattacks against major corporations in recent years have been highly disruptive, despite being the actions of common criminals. A truly no-holds-barred conflict between states that spilled into our computer systems could be genuinely apocalyptic. Food deliveries rotting in the stockyards, planes falling out of the sky, nuclear power plants being rammed into meltdown: scarcely any activity undertaken in the global economy is untouched by IT. The prospect is truly terrifying.
I will not blame any reader, then, for taking the government’s advice and throwing a few extra cans of chickpeas into the trolley at the next visit to Tesco. Yet this is hopelessly inadequate. It is a kind of Robinsonade - a myth of self-sufficiency, as if some random individual or family in contemporary society could insulate themselves from a general social breakdown. In reality, this was a myth even in premodern society, where rural communities depended in the end on production of agricultural tools in the towns, and military production to defend against the aforementioned steppe nomads. In today’s Britain, with half of all food imported and industry supplanted by games of financial silly buggers, it is a real joke.
The solution is more radical, and in the end orthogonal to technology. It is inter-state competition itself which produces the weapons of mutual ruin. We must turn the swords into ploughshares, true, but the prophet Isaiah knew well this required political revolution (in the form of the messiah).
On top of that, we face the mere fact that our economies are plausibly vulnerable to cheap and well-understood technological attack. There is no solution for this, except what we call in the industry “graceful degradation”: sure, use the computer if it is operable, but do not depend on it. There must be ways to move food, to conduct surgery, that do not depend on it. That, in turn, requires maintaining the general intellect required to do these things manually, which means they must be done manually often enough to keep the reflexes sharp, even in good times.
From a capitalist point of view - always searching for another sliver of profit - this is as insane a way to go about things as programming in PHP is insane to me. Negative externalities are all but invisible to capital. It is democratic planning, by people who would really rather be able to go on eating and drinking, that holds the solution here.