When a Nobel laureate economist devotes his column to the exact vulnerability you spent the past week mitigating across production cloud infrastructure, you pay attention. What Paul Krugman’s "Hack Apocalypse" Gets Right About the Panic—and Wrong About the Tech.
Last week I spent most of my time dealing with PHP2Shell (CVE-2026-109618 and CVE-2026-109619), the PHP bugs that let attackers run their own code on a server and briefly took several European government websites offline. So I was interested to see Paul Krugman write about it in his column, Hack Apocalypse Now.
He's right that AI is speeding up how quickly attacks happen. But a few of the technical details are worth clearing up, because they change what the right response looks like.
1. PHP's age isn't the problem. Modern PHP (8.2 through 8.5) supports strict typing, has a JIT compiler, and has very little in common with the PHP of the 1990s. Plenty of critical software, including the Linux kernel and OpenSSL, also goes back decades. The bigger issue is funding. PHP runs about three-quarters of websites whose server-side language is known, but the PHP Foundation's annual budget is around $700,000. If your business runs on open-source software, the people maintaining it are part of your security, whether you pay them or not.
2. Abliteration isn't the same as jailbreaking. Jailbreaking means tricking an AI model with clever prompts. Abliteration means editing an open model's weights directly to remove its ability to refuse requests. Once someone has the weights, the safety training can be stripped out fairly quickly. The practical takeaway is to assume attackers have capable AI tools with no restrictions, and plan your defenses around that.
3. Patch diffing is real, and layered defenses handle it. When a security fix comes out, AI can compare the old and new code and help build a working exploit within minutes. That leaves much less time to patch. In our case, our servers already sat behind a web application firewall (WAF) and a content delivery network (CDN), and they only accept traffic that comes through that layer. Before we patched a single container, we added firewall rules that blocked the exploit at the edge. After that, our pipelines rebuilt and redeployed patched container images across the cluster.
From what I saw, the sites that went down were mostly ones with servers exposed directly to the internet, without that protective layer.
What I'd take from last week:
Don't expose application servers directly to the internet. Make sure you can roll out firewall rules quickly to cover the gap between a bug's disclosure and your patch. Make patching an automated rebuild, not a manual job. Budget for the open-source projects you depend on.
The harder question is what happens to organizations that can't afford this setup: small businesses, local governments, nonprofits with one IT person. As the time from disclosure to exploit keeps shrinking, they're the most exposed. Making solid protection affordable and simple for them is going to matter a lot.
#CloudSecurity #Cybersecurity #PHP #OpenSource #DevOps
Comments